[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