Steve,
Maybe it's my cold, but when I read "The same logic could be applied to
obtaining a local from higher up the food chain" - I took pause. I understood
that variable(x) := expr could only assign within the current scope global,
local/static. I infer from your statement that I could assign to my callers
local/static variables? Am I overlooking/forgetting something? A way to pass
down a variable?
David
________________________________
From: Steve Wampler <swamp...@noao.edu>
To: unicon-group@lists.sourceforge.net
Sent: Thu, June 30, 2011 11:28:44 AM
Subject: Re: [Unicon-group] bug: variable("x") := 1 fails in Unicon V12
On 06/29/2011 05:59 PM, Clinton Jeffery wrote:
> Jafar's comments are correct. I will add that the rationale for dereferencing
>is: you have to dereference things that
> might not be there later on when you come back to use it. When you say
> "return
>x" in regular Icon, if x is a local it
> must be dereferenced. Variable() must follow similar rules. But we might
> figure
>out a workaround.
Hmmm, I'm not sure I understand. Variable() isn't referencing one of its own
local
(or static) variables, but rather a variable in the caller [ignoring, for the
moment,
that it might be local/static from higher up in the calling sequence]. So
variable("X")
would be returning a reference for X to the environment in which X exists. I
would
expect a dereference to be forced if trying to return that reference from *that*
environment, but don't see why variable() would need do the dereferencing.
So, I'd expect:
procedure f()
local x
variable("x") := 1 # no deference, so this should work
return variable("x") # return deferences the result produced by
variable("x")
end
The same logic could be applied to obtaining a local from higher up the food
chain -
it would be valid until an attempt is made to return the reference from that
higher-up defining context - though it might be a reasonable simplification to
just
have return variable("x") [and variable("x")@A] always dereference the variable
(i.e. the result of variable("x") is treated as if it were a local variable,
even
though it might reference a variable that would still be valid after the return
or activation). This simplification would reduce the utility of variable()
is some situations, but would be better than the current situation where
variable("x")
is only useful for global variables (other than for testing the existence of a
variable of course).
Now, I'll happily accept that Multi-threading Icon/Unicon somehow interferes
with
the above logic, but I wish I understood why...
--
Steve Wampler -- swamp...@noao.edu
The gods that smiled on your birth are now laughing out loud.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group
