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

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::hotmail 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