Closures python,scheme,ruby
Sean Ross
sross at connectmail.carleton.ca
Fri Jul 16 08:07:28 EDT 2004
"Bengt Richter" <bokr at oz.net> wrote in message
news:cd7mvc$q61$0 at 216.39.172.122...
> On Thu, 15 Jul 2004 20:49:18 -0700, "Robert Brewer" <fumanchu at amor.org>
wrote:
>
> >Bengt Richter wrote:
> >> ...What if
> >> x <=3D expr
> >> meant evaluate expr and then
> >> find x (as if to do a read access) and rebind it, whatever=20
> >> name space it's found in?
> >
> >Sure, except overloading "less-than-or-equal-to" might be a small
> >problem. ;)
> >
> D'oh. I had it as
> x <- expr
> but then I wanted to bring in the assignment = and changed it
> without thinking *<8^P
> I guess <- is still available, if the tokenizer were made to
> look ahead to recognize it instead of the individual < and -
> so
> x <- expr
> wouldn't mean
> x < -expr
> ;-)
> Regards,
> Bengt Richter
Or, perhaps 'x => expr' or 'x -> expr' or 'x := expr'?
Read 'x is bound to expr', rather than 'expr is bound to x' (x <- expr).
These, atleast, would avoid the less-than-negation confusion posed by
'<-' and the overloading of '<='. But rather than using these to look-up
and re-bind, I would think you would want to use them for the initial
binding (or let statement) and retain '=' for the re-binding (or set/update
statement). Io, for instance, does it this way - it uses ':=' for setSlot
and
'=' for updateSlot. If it were done the other way, then, should we wish to
remain consistent in the appearance of re-binding operations, we
would need to say 'a +=> b' or 'a +-> b' or 'a +:= b' instead of 'a += b'.
No, thank you.
On the other hand, there remain people who wish to be able to say
if a = b:
do_something()
and
while a = b:
do_something()
but others want to avoid the bug of confusing = with ==. Having '=>', '->'
or ':=' as the re-binding operator would allow for this, e.g.
while a => feed():
do_something()
or
while a -> feed():
do_something()
or
while a := feed():
do_something()
You would still need to bind 'a' initially (somewhere), however - unless
you took the above to mean bind 'a', locally, to a value from 'feed()' and
keep binding (not re-binding) 'a', locally, to new values from feed() until
feed() is exhausted. That would limit some of the utility of the construct
though, since it would not allow you to iteratively re-bind a variable from
another scope (you would only ever be creating a new local variable
'a').
More information about the Python-list
mailing list