Change in Path Evaluation
[1/7] from: carl:rebol at: 26-Oct-2000 18:46
I've been annoyed for a while that:
>> obj: make object! [t: first [now/time 1 2]]
>> obj/t
== now/time
But:
>> t: first [now/time 1 2]
== now/time
>> t
== 18:35:24
This occurs because paths are aggressively evaluated.
It's sure cute, but it gets in the way of useful code
(like REBOL/Link desktop implementation).
I'm seriously thinking of changing this, so that last
expression would become:
>> t
== now/time
That is, indirectly referenced paths are by default not
evaluated.
Comments?
-Carl
[2/7] from: jschuhr:ho:tmail at: 26-Oct-2000 21:02
Would this affect object methods? E.g.
obj: make object! [
t: func [] [
now/time
]
]
>> obj/t
== now/time
???
--John
----- Original Message -----
From: Carl Sassenrath
Sent: Thursday, October 26, 2000 8:56 PM
To: [rebol-list--rebol--net]
Subject: [REBOL] Change in Path Evaluation
I've been annoyed for a while that:
>> obj: make object! [t: first [now/time 1 2]]
>> obj/t
== now/time
But:
>> t: first [now/time 1 2]
== now/time
>> t
== 18:35:24
This occurs because paths are aggressively evaluated.
It's sure cute, but it gets in the way of useful code
(like REBOL/Link desktop implementation).
I'm seriously thinking of changing this, so that last
expression would become:
>> t
== now/time
That is, indirectly referenced paths are by default not
evaluated.
Comments?
-Carl
--
To unsubscribe from this list, please send an email to
[rebol-request--rebol--com] with "unsubscribe" in the
subject, without the quotes.___________________________________________________________
Get more from your time online. FREE MSN Explorer download : http://explorer.msn.com
[3/7] from: carl::rebol::com at: 26-Oct-2000 19:18
No. That would work as before.
At 10/26/00 09:02 PM -0500, you wrote:
[4/7] from: carl:rebol at: 26-Oct-2000 19:27
I withdraw the suggestion. Although it's a two line change to the
interpreter, it creates an exception in evaluation semantics, and
that is never good.
The use of :t for general expression traversing is a requirement
anyway, due to parens and functions. The :t works fine here.
-Carl
At 10/26/00 06:46 PM -0700, you wrote:
[5/7] from: al:bri:xtra at: 27-Oct-2000 15:39
Carl Sassenrath wrote:
> >I've been annoyed for a while that:
> >
<<quoted lines omitted: 8>>
> >>> t
> >== 18:35:24
Have you considered changing the _first_ to make it like the second? So the
result of:
obj/t
is:
18:35:24
? I'd like it a lot. :-)
Andrew Martin
ICQ: 26227169
http://members.nbci.com/AndrewMartin/
[6/7] from: jelinem1:nationwide at: 27-Oct-2000 11:03
The "aggresive path evaluation" really bugged me too when I was
experimenting with paths and blocks. I eventually had to scrap my path
ideas and use a different mechanism. I would support the change.
- Michael Jelinek
Carl Sassenrath <[carl--rebol--com]>@rebol.com on 10/26/2000 08:46:17 PM
From: Carl Sassenrath <[carl--rebol--com]>@rebol.com on 10/26/2000 08:46 PM
Please respond to [rebol-list--rebol--com]
Sent by: [rebol-bounce--rebol--com]
To: [rebol-list--rebol--net]
cc:
Subject: [REBOL] Change in Path Evaluation
I've been annoyed for a while that:
>> obj: make object! [t: first [now/time 1 2]]
>> obj/t
== now/time
But:
>> t: first [now/time 1 2]
== now/time
>> t
== 18:35:24
This occurs because paths are aggressively evaluated.
It's sure cute, but it gets in the way of useful code
(like REBOL/Link desktop implementation).
I'm seriously thinking of changing this, so that last
expression would become:
>> t
== now/time
That is, indirectly referenced paths are by default not
evaluated.
Comments?
-Carl
[7/7] from: rebol:techscribe at: 27-Oct-2000 12:36
Hi Carl,
if you eliminate the "aggressive" path evaluation, then paths can no
longer be used programmatically to access values contained in a block or
an object:
path: make path! [a b c]
value: path
Currently value will reference the value at the path a/b/c. Without
aggressive path evaluation, value will reference the path a/b/c and not
its value. We can currently reference the path instead of its value by
using the get-word notation :path. It would duplicate this and eliminate a
simple shortcut way of accessing values. We would be forced to always use
the notation
>> get in copy/part path (- length? path 1) last path ;- assuming
none-aggresive path evaluation. For current implementation replace path by
:path.
instead of the much simpler notation
>> path
to get at the value located at path.
This is not very elegant. Why can't we just continue using :path if we
want the path and path to get at the value?
My $0.02
Elan
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted