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

[ALLY] new functions?

 [1/9] from: bobr:dprc at: 11-Apr-2001 2:39


anton, this is a good function to be part of /core too. [thus I crosspost to both lists] I had proposed an earlier one called 'default.
>if not value? 'default [ > >default: func ['w1 [any-word!] v2 [ any-type! ] ] > [ if not value? w1 [ set/any w1 v2 ] ] > ]
it does more than reduce code size. it is most useful when you want to set up sample values that make rebol scripts runnable without editing just by 'do -ing them from another script. perhaps you can get both pieces of functionality by adding a default/ifnone refinement (maybe a default/none?) and by changing it to allow a path. I have this 'default function in wiki.r and several other places. notice that it too can have a better one instantiated before it is defined. 'default allows building on the work of others without altering their code. by having a word like 'default in obvious places in your script you can also build a configuration tool/gui for editing these defaults. you could be the author of such a universal app-configurator! I know of no other language that lets you [portably] edit remote application startup configuration parameters without knowing anything about the application other than the word 'default. that alone should wow rebol wannabees! At 03:08 PM 4/11/01 +1000, anton wrote:
>Hi, >I was just looking at this code, which seems to occur often:
<<quoted lines omitted: 16>>
>[ally-request--rebol--com] with "unsubscribe" in the >subject, without the quotes.
;# mailto: [bobr--dprc--net]

 [2/9] from: carl:rebol at: 11-Apr-2001 5:57


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'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. Let me know what you think... -Carl

 [3/9] from: arolls:bigpond:au at: 11-Apr-2001 15:08


Hi, I was just looking at this code, which seems to occur often: if not system/view/highlight-start [ system/view/highlight-start: system/view/caret ] and I wonder if new functions could be made to shorten such; - not?set - none?set usage example: not?set system/view/highlight-start system/view/caret not?set should take two arguments, the first the value to test and change, the second the value to change it to. I reckon something like this could reduce a lot of code; it seems that long paths occur often in the system object. Or maybe there is a better, more flexible way? Anton.

 [4/9] from: ingo::2b1::de at: 11-Apr-2001 16:56


Hi Carl, I've used this aggressive path evaluation here and there, but most of the time I had to fight against it. I'd say go and change itand make :abc then evaluate the path. kind regards, Ingo Once upon a time Carl Sassenrath spoketh thus: <...>

 [5/9] from: ptretter:charter at: 11-Apr-2001 20:37


maybe just extend empty? with a refinement such as /set so that: empty/set word newvalue

 [6/9] from: agem:crosswinds at: 11-Apr-2001 21:26


[rebol [ title: "quick set-default-hack" aithor: "Volker Nitsch" comment: { would like cold pathes too. but then, could pathes be more similar to words? like [set a 11] and [set a/b 11] [value? a][value? a/b] and so on? } ] without: func ['name [word! path!] block] [ either word? name [ if any [not value? name none? get name] [ do func [set-it] block to set-word! name ] ] [ if any [not name] [ do func [set-it] block to set-path! :name ] ] ] unset 'a without a [set-it none] ? a without a [set-it 123] ? a a: context [b: none] ? a without a/b [set-it 15] ? a without a/b [set-it 28] ? a ]

 [7/9] from: arolls:bigpond:au at: 12-Apr-2001 1:57


So my example could then work like this? hs: 'system/view/highlight-start if not :hs [set :hs system/view/caret] I think this would be a good change. Anton.

 [8/9] 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.
<<quoted lines omitted: 13>>
>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

 [9/9] from: fsievert:uos at: 14-Apr-2001 14:19


Hi Carl!
> I'm going to need to relax the path evalution. It's too > aggressive and is creating problems. We experienced this
<<quoted lines omitted: 12>>
> a few scripts here and there where the coder noticed > this aggressive evaluation and used it.
I used this feature (?) sometimes to make shortcuts for paths. But I don't think, changing the path-evaluation (only) would be enough. There are a some agressive evaluations when using a word to retrieve a value. Please have a look at http://www.sievertsen.de/REBOL/hot-values.r with REBOL/View. You will see, that set-words for example show the same behaviour. You can also see some inconsistent evaluations in using a word! or a path! to retrieve a value. I think, if you really want to change behaviour of path-evalution you should make the the second and the third row look the same for all other values, too. And I would like them to be green for any value except of any-function! unset! and error!. And I would like to have a get-path... What do you think? CU, Frank

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted