[REBOL] Re: Bug! in assignment to date! values with stacked set-path values
From: g:santilli:tiscalinet:it at: 18-Nov-2002 15:28
Hi Romano,
On Monday, November 18, 2002, 2:42:45 PM, you wrote:
>> I don't agree with that, every Rebol datatype has got a type attribute
>> attached to it, IMO.
RPT> Yes: load set it, but it can only set it with a rule: it ends with #":".
RPT> The evaluation then can demonstrate another thing: that it was not a set-path
RPT> but a function call with refinement.
I agree with Ladislav.
>> obj: context [a: 1 b: 2]
>> p: to path! [obj a]
== obj/a
>> do reduce [p]
== 1
>> p: to path! [obj a:]
== obj/a:
>> do reduce [p 2]
** Script Error: Invalid path value: a
** Near: obj/a: 2
>> p: to set-path! [obj a]
== obj/a:
>> do reduce [p 2]
== 2
>> p: to set-path! [obj a:]
== obj/a::
>> do reduce [p 2]
** Script Error: Invalid path value: a
** Near: obj/a:: 2
In particular:
>> f: func [/ref] [1]
>> p: to path! [f ref]
== f/ref
>> do reduce [p]
== 1
>> p: to path! [f ref:]
== f/ref:
>> do reduce [p]
== 1
>> p: to set-path! [f ref:]
== f/ref::
>> do reduce [p]
== 1
>> p: to set-path! [f ref]
== f/ref:
>> do reduce [p]
== 1
which shows that REBOL is just being very permissive for functions
with refinements.
RPT> I do not think the same. Here the attempt is not set something, but only to
RPT> evaluate the path. If a set-path is by default "set the value referenced by
RPT> the path" this construct should trigger an error or a crash. Obviously this
RPT> can be corrected adding an error! ad hoc, but ist shows for me the interpreter
RPT> behaviour.
I think that for both set-path! and path!, first of all REBOL
determines the value of the first word. Then, it "decodes" the
path up until the last value, and then it decides what to do based
on the type of the path. Probably, as soon as it finds out that
the first word refers to a function!, it passes the control to the
code handling functions, that simply does not "know" about
set-path!s and so behaves like it was a path!.
RPT> Often I'm asking myself: what are advantages of refinements in functions?
Economy of expression. Without refinements, using functions like
OPEN would require a lot of arguments. Also, one could not extend
functions retaining compatibility like it was done with MOLD (/ALL
refinement) or LOAD (/LIBRARY refinement) etc.
Of course, if we had a formal specification for the REBOL language
and the function interpreter, it would be easier to understand
what is a design decision and what is just an implementation
issue.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
