1:25 p.m.
I was looking at some code that people (Sven, Oleh, myself among others)
have written for function packages and I thought that the fact that we
don't have named arguments for functions like R and Python have is
sometimes a little inconvenient.
So I thought one could pass a string argument to a function with options
of the kind "a = _something_", where _something_ is a scalar or a string,
or better still, a sequence of these statements, separated by semicolons.
The results would be collected in a bundle. I'm attaching a simple inp
file which should exemplify what I have in mind.
If we decide this is worthwhile having, it could be put into the
extra package or perhaps into libgretl.
Comments welcome.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
3:13 p.m.
On 15.10.2018 15:25, Riccardo (Jack) Lucchetti wrote:
I was looking at some code that people (Sven, Oleh, myself among
others) have written for function packages and I thought that the fact
that we don't have named arguments for functions like R and Python
have is sometimes a little inconvenient.
So I thought one could pass a string argument to a function with
options of the kind "a = _something_", where
And the nice thing would be
'_something_ = $some_accesor'
Marcin
--
Marcin Błażejowski
4:07 p.m.
On Mon, 15 Oct 2018, Marcin Błażejowski wrote:
On 15.10.2018 15:25, Riccardo (Jack) Lucchetti wrote:
>
> I was looking at some code that people (Sven, Oleh, myself among
> others) have written for function packages and I thought that the fact
> that we don't have named arguments for functions like R and Python
> have is sometimes a little inconvenient.
>
> So I thought one could pass a string argument to a function with
> options of the kind "a = _something_", where
And the nice thing would be '_something_ = $some_accesor'
I don't think I understand what you mean. Could you provide an example?
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
5:02 p.m.
Am 15.10.2018 um 15:25 schrieb Riccardo (Jack) Lucchetti:
t the fact that we don't have named arguments for functions like R and
Python have is sometimes a little inconvenient.
So I thought
I don't have time right now to look at this thoroughly. However, this is
a very important point, and so I think it should be thought through well
and not rushed.
(This in English is as much a tongue-breaker as it is an eye-twister:
"thought through thoroughly"...)
cheers,
sven
6:18 p.m.
Actually, lagreg has a kind of emulating
named parameters: see help for auto_arima
in the package
Oleh
15 жовтня 2018, 16:25:59, від "Riccardo (Jack) Lucchetti"
<r.lucchetti(a)univpm.it>:
I was looking at some code that people (Sven, Oleh, myself among others)
have written for function packages and I thought that the fact that we
don't have named arguments for functions like R and Python have is
sometimes a little inconvenient.
So I thought one could pass a string argument to a function with options
of the kind "a = _something_", where _something_ is a scalar or a string,
or better still, a sequence of these statements, separated by semicolons.
The results would be collected in a bundle. I'm attaching a simple inp
file which should exemplify what I have in mind.
If we decide this is worthwhile having, it could be put into the
extra package or perhaps into libgretl.
Comments welcome.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
11 p.m.
On Mon, 15 Oct 2018, Sven Schreiber wrote:
Am 15.10.2018 um 15:25 schrieb Riccardo (Jack) Lucchetti:
>
> t the fact that we don't have named arguments for functions like R and
> Python have is sometimes a little inconvenient.
>
> So I thought
I don't have time right now to look at this thoroughly. However, this is a
very important point, and so I think it should be thought through well and
not rushed.
(This in English is as much a tongue-breaker as it is an eye-twister:
"thought through thoroughly"...)
I agree with Sven -- both on the substantive point and the
linguistic observation ;-)
Allin
1:50 p.m.
Am 15.10.2018 um 15:25 schrieb Riccardo (Jack) Lucchetti:
the fact that we don't have named arguments for functions like R
and
Python have is sometimes a little inconvenient.
Thanks again for the initiative. Indeed it would be a major step for
gretl / hansl if something like keyword args (the Python jargon for
that) were possible.
So I thought one could pass a string argument to a function with
options of the kind "a = _something_", where _something_ is a scalar
or a string, or better still, a sequence of these statements,
separated by semicolons.
However, I'm afraid I don't like this string-wrapping approach. It
obfuscates things because the true nature of the arguments is not
visible to gretl anymore and the burden of checking and so forth is
shifted to the hansl user (both the package author and the end user).
or perhaps into libgretl.
For such a fundamental thing I believe core gretl is the only way really.
The question is how to achieve this without too much problems for gretl
(and also for Allin, hehe). So I'm thinking of syntactic constructs that
would be unambiguous for the parser.
One wild idea would be a pair of square brackets to indicate that a
keyword is given. Example:
<hansl-future>
function void myfunc(int a)
print a
end function
# new optional call syntax:
myfunc([a = 5])
</hansl-future>
The idea is that a square bracket after an opening round bracket or a
comma would be illegal everywhere else (right?), so cannot be mistaken.
Then inside those square brackets it would be clear that it's not really
an assignment, but a named arg.
(One pre-requisite for this would be to finally ban the use of "=" as
standing in for "==", otherwise it's next to impossible I guess.)
On the other hand, maybe the "=" itself would already be enough to
signal to the parser that it's a name:
myfunc(a=5)
This of course is basically like it's done in Python (and other languages).
Or maybe with an exclamation mark? As in:
myfunc(a!5)
Cheers,
sven
2:04 p.m.
On Wed, 17 Oct 2018, Sven Schreiber wrote:
Am 15.10.2018 um 15:25 schrieb Riccardo (Jack) Lucchetti:
> the fact that we don't have named arguments for functions like R and Python
> have is sometimes a little inconvenient.
Thanks again for the initiative. Indeed it would be a major step for gretl /
hansl if something like keyword args (the Python jargon for that) were
possible.
>
> So I thought one could pass a string argument to a function with options of
> the kind "a = _something_", where _something_ is a scalar or a string, or
> better still, a sequence of these statements, separated by semicolons.
However, I'm afraid I don't like this string-wrapping approach. It obfuscates
things because the true nature of the arguments is not visible to gretl
anymore and the burden of checking and so forth is shifted to the hansl user
(both the package author and the end user).
> or perhaps into libgretl.
For such a fundamental thing I believe core gretl is the only way really.
Me too.
The question is how to achieve this without too much problems for
gretl (and
also for Allin, hehe). So I'm thinking of syntactic constructs that would be
unambiguous for the parser.
One wild idea would be a pair of square brackets to indicate that a keyword
is given. Example:
<hansl-future>
function void myfunc(int a)
print a
end function
# new optional call syntax:
myfunc([a = 5])
</hansl-future>
The idea is that a square bracket after an opening round bracket or a comma
would be illegal everywhere else (right?), so cannot be mistaken. Then inside
those square brackets it would be clear that it's not really an assignment,
but a named arg.
(One pre-requisite for this would be to finally ban the use of "=" as
standing in for "==", otherwise it's next to impossible I guess.)
On the other hand, maybe the "=" itself would already be enough to signal to
the parser that it's a name:
myfunc(a=5)
This of course is basically like it's done in Python (and other languages).
I reckon that's the best way to go: an identifier directly followed by
a single equals sign in an argument slot should be enough to designate
uniquely a named-parameter construct.
I'm not yet convinced this is worthwhile (I can see the benefit but
I'm not sure it outweighs the cost), but I'm willing to be persuaded.
Allin
2:13 p.m.
Am 17.10.2018 um 16:04 schrieb Allin Cottrell:
On Wed, 17 Oct 2018, Sven Schreiber wrote:
> (One pre-requisite for this would be to finally ban the use of "=" as
> standing in for "==", otherwise it's next to impossible I guess.)
> On the other hand, maybe the "=" itself would already be enough to
> signal to the parser that it's a name:
> myfunc(a=5)
> This of course is basically like it's done in Python (and other
> languages).
I reckon that's the best way to go: an identifier directly followed by
a single equals sign in an argument slot should be enough to designate
uniquely a named-parameter construct.
I'm not yet convinced this is worthwhile (I can see the benefit but
I'm not sure it outweighs the cost), but I'm willing to be persuaded.
In any case I guess it should be noted that in Python for example there
are some restrictions on the ordering of keyword args and positional
args. So not every crazy permutation would have to be supported by
gretl, either.
cheers,
sven
2015
days inactive
2017
days old
8 comments
5 participants
participants (5)
-
Allin Cottrell -
Marcin Błażejowski -
oleg_komashko＠ukr.net -
Riccardo (Jack) Lucchetti -
Sven Schreiber