On looking this over, I think I may have gone overboard - my
apologies for the long-winded comments!
On Sat, 2004-02-07 at 04:51, Wade Bowmer wrote:
> At 06:59 PM 6/02/2004 -0700, Steve Wampler wrote:
>
> >Consider:
> >
> > Procedure f(x:=list(5))
> >
> >you *have* to create a new list each time the call is f() - to not
> >do so would be asking for trouble.
>
> Oh, of course. But a structure could be just copied.
How does one know there's a structure? list(5) might
be a user-defined procedure that does something
entirely different. (That is the code might be something
like:
global a
...
a := list # may or may not be executed before call of f()
...
a := table # may or may not be executed before call of f()
procedure f(x:=a(5))
> What I actually meant was:
>
> procedure f(a := [ x + 1 ])
>
> ... means what, exactly? Which value of 'x' is used? The global variable
> initialized at prescan? The global variable when the procedure is first
> called? The variable in the scope of the call when the procedure is first
> called? The global variable on each call? The in-scope variable at each
> call? A local variable in the procedure?
It means the same as:
procedure f(a)
/a := [x + 1]
Ah, I think I see.
The real issue is where, within the scope
of the procedure definition for f(), is the above
expression evaluated. [This is probably what Wade is
getting at...]
Consider, for example:
procedure f(a:= [x+1])
static x := 1
this could be evaluated as (ignoring the illegal syntax):
(1) procedure f(a)
/a := [x+1]
static x := 1
(2) procedure f(a)
static x := 1
/a := [x+1]
And (1) has three possible interpretations:
(a) either the global or local x (remember: if there's no
local declaration for x, it's still local if there is
no global declaration), but not the static
(b) the static variable x, but before initialization (on the
first call - that is, use the current value of static
variable x).
(c) the static variable x, after initialization, even on the
first call.
I don't think other interpretations (initial value of global x
found during 'prescan', for example - what if there is no
global x - does this create one?) are really reasonable.
I also tend away from 1a as being syntactically misleading.
2 is the same as 1a, so that leaves 1b and 1c as possibilities.
Now consider:
procedure f(a:5) # 1b's approach seems better here
static x := a+1
versus
procedure f(a:g(x)) # 1c's approach seems better here
static x := h(5)
But, remember that static x := <EXPR> is shorthand for
static x
initial x := <EXPR>
so, does 1b really make sense? Only on the first call to f() - and
then *only* if the argument is &null! But 1b is 'syntactically
consistent' with expression evaluation in Unicon in general and 1c
isn't (with 1c, expressions are evaluated in the order one reads
them)...
Hmmm, is this an issue with the current implementation? What's the
ordering of evaluation currently?
My preference is that the evaluation order on a procedure call would be:
evaluate parameter type and default value expressions, if any
evaluate initial clauses, if any, on first call
evaluate local variable initializations, if any
evaluate procedure body
i.e. 1b above.
The scope of a variable is defined during program translation, so
a variable declared local is local in all of the above steps, a
static variable is static in all of the above steps, etc. So
some operations, while legal, won't be sensible - but that's not
unusual, even now.
So, while the code:
procedure f(a:g(x))
static x := 5
is legal, the result is a runtime error on the initial call, *if*
that call is f().
Others will no doubt have different preferences. Clint gets to
decide (no decision is still a decision!). I'm sure he can be
bribed.
--
Steve Wampler <[EMAIL PROTECTED]>
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
