I agree with Allin about keeping the two styles distinct, and the
usage of the new one should be encouraged already from the next
release, IMHO.
Cheers,
Stefano
2009/8/11 Allin Cottrell <cottrell(a)wfu.edu>:
On Tue, 11 Aug 2009, Sven Schreiber wrote:
> Allin Cottrell schrieb:
> > Up till now, the definition of a user-function in gretl has
> > been required to follow this pattern:
> >
> > function <function-name> (<parameters>)
> > <function-body>
> > [ return <return-type> <variable-name> ]
> > end function
> >
> > where <...> indicates a placeholder and [...] indicates an
> > optional element (functions are not required to return anything).
> >
> > This has served us OK, but it's a bit clunky. Consider writing a
> > function to multiply a matrix by 2 (I know, pretty silly). The
> > most compact version would be something like:
> >
> > function mtwo (matrix m)
> > x = 2 * m
> > return matrix x
> > end function
> >
> > I've now relaxed the requirement that return lines must match the
> > pattern above. You can now do
> >
> > return <expression>
> >
> > The price you pay for this is that you have to specify the return
> > type as part of the first line of the definition:
> >
> > function <return-type> <function-name> (<parameters>)
> >
> > For example,
> >
> > function matrix mtwo (matrix m)
> > return m * 2
> > end function
> >
> > For a function that does not return anything you can write
> >
> > function void <function-name> ...
> >
> > The old-style syntax is still supported alongside the new.
> > Eventually we may want to mark it as deprecated and, after a
> > suitable lag, remove support.
>
> well, that would break almost every script that contains a function,
> right? IMHO that would frustrate too many gretl users too much, so
> either the lag that we're talking about here should be in the order of
> at least several years, or both styles should be continued to be
> supported, at least internally.
Yes, I'm not suggesting we rush that process.
> I mean, now that 'return' accepts an expression, it wouldn't be too
> difficult to also allow the old placement of the returned variable type,
> would it?
>
> (as in:
> function mtwo (matrix m)
> return matrix m * 2
> end function
> )
It's cleaner, I think, to keep the two styles of function
definition distinct. That is, either you do
function foo (parms)
# stuff
return <type> x
end function
OR you do
function <type> foo (parms)
# stuff
return <expr>
end function
I don't much like the iea of mixing-and-matching. Right now (in
CVS), giving a type specifier on the first line of the definition
is the marker for a new-style function, which is then parsed
accordingly.
My idea is that at some point (maybe 1.8.4, maybe later) we change
the manual to reflect the new style, but add a note on the old
style. The old style could then be supported for as long as
necessary (maybe forever).
Allin.
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel