Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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