[ALLY] Re: new functions?
From: brian:hawley at: 12-Apr-2001 16:47
Carl wrote:
>Yes, I've noticed this pattern too, and agree with you. A
>default function would be handy. I've used it before.
>
>The problem with the example from Anton is that the path
>would be evaluated, so DEFAULT would not work for the case
>that he has given.
>
>I'm going to need to relax the path evalution. It's too
>aggressive and is creating problems. We experienced this
>when writing REBOL/Link, which uses paths to create the
>namespace for the desktop. It was a pain because every
>path variable had to be treated with :care.
>
>Lightening up path eval, the result would be that:
>
> >> abc: 'a/b/c
> >> type? abc
> == path
>
>Currently, the path would be evaluted, and that result
>would be returned. So literal references to paths are
>aggressively evaluated. That must change.
I've been guilty of using this on occasion, such as
for storing method closures in Delphi-like code. Most
of the time I've just written code that works around
that behavior, code that won't break if it changes.
So I don't have a problem with you changing this.
The question that I have is, how do you intend to get
the value of the less aggressive paths?
Please don't reverse the meaning of :abc like one of
the replies to your message implied! That would make
no sense and would break a lot of code.
I'd suggest that you let GET, SET and UNSET work on
path! values as well. That would be more orthogonal.
The default function mentioned earlier would then be
default: func ['var [any-word! path!] value] [
if unset? get/any var [set var :value]
]
; No point to allowing unset! default values
Testing for none! values, default values for function
parameters for instance, is as simple as
a: any [a 0]
depending on how you want a to be evaluated.
>I'm *VERY* serious about making this change to REBOL's
>core. It will not break most code... but could break
>a few scripts here and there where the coder noticed
>this aggressive evaluation and used it.
Go for it!
On the note of obscure REBOL behavior, I've occasionally
used the similar aggressive evaluation of paren! values
to implement fast, lightweight, no-arg closures. They
are faster than functions and work great, especially now
that the old GC bug is gone. Any chance you could leave
this bit of aggressive evaluation as it is?
Brian Hawley
