Re: [Gretl-devel] function news

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