Ilya Zakharevich on Tue, 2 Jul 2002 09:09:20 -0400 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: Bug in parsing of local() |
On Tue, Jul 02, 2002 at 02:07:19AM +0200, Karim BELABAS wrote: > 1) make_arg(): parameters with default values are evaluated when the function > is called [ was: when the function is defined (long time ago), see COMPAT-2.2 ] > > Hence default values are really formal expressions [character strings], which > are evaluated to bona fide GENs by make_arg(). > > [ btw, make_arg() was unnecessarily complicated, I simplified it ] *This* probably was the reason for my surprise: that make_arg() would sometimes evaluate args, sometimes not. > 2) copy: clone the value > push: store the address of the value > > Values of arguments are cloned, values of local variables are pushed (the > initial value is assumed not to vary while we evaluate the function). *Why* are they assumed to be constant? [But see below...] > The patch fixes all the bug mentioned above. I'm not 100% sure it fixes all > instances of the problem. I assume that the parameters are not push()ed any more? > It's been in my personal TODO list for a long time to check whether a > function definition like > > f(&x, y) = ... > > would break anything. Here, x is a reference, y is a value. Modifying x in > the function body would modify x in the calling frame. Modifying y would > modify a copy (current behaviour). This interface is *exactly* why I started all this investigation (but my idea was to encode it as f('x, y) = ... ;-) > Not sure about the calling, syntax. Maybe f(x,y), or f(&x, y) to emphasize > we're passing a reference. There is no such emphasis for forprime(X...), thus there should be none for the user defined functions. The *real* (as opposed to efficiency problems ;-) need to have such f's is to allow user functions which have the same syntax as forprime(), ploth() etc. E.g., one could duplicate forprime() as my_forprime('x==a, b, f()) = x=nextprime(a); while(x<=b, f(); x=nextprime(x)) (not checked). There are 3 enhancements needed: allowing '=' to separate variables (very optional, denoted by '==' in the prototype), aliasing (as you propose, denoted by 'x), and a "sexpr" argument autoconverted to a 'local' function f(). Ilya