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