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

[REBOL] Re: Bug! in assignment to date! values with stacked set-path values

From: rotenca:telvia:it at: 18-Nov-2002 22:40

Hi Gabriele
> I agree with Ladislav.
Gabriele, you bypass Load for this, i was speaking of Load. And my observation is still valid, also a set-path can be used like a path by the interpreter if it find a function along the path. Now i'm thinking that the problem is all in function refinement, see my previous message.
> 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
This is what i point: no set action at all, the interpreter does not care about the fact the that path is a set-path!
> >> 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.
At least.
> 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!.
Yes you are right and this is what i want to point. I did not want to say that set-path does not exists in absolute, but that in some situations it is like a path. I could make an example: a block which, if at some point contains the word list!, start to behaviour like a list!. Only in this sense i said that it is not a true datatype!.
> RPT> Often I'm asking myself: what are advantages of refinements in
> Economy of expression. Without refinements, using functions like > OPEN would require a lot of arguments.
open: func [file type [integer!]][ if type and 1 [ ;direct] if type and 2 [ ;no-wait] if type and 4 [ ;binary] or open: func [file type [block!]][ if find type 'direct [ ;direct] if find type 'no-wait [ ;no-wait] if find type 'binary [ ;binary]
> Also, one could not extend > functions retaining compatibility like it was done with MOLD (/ALL > refinement) or LOAD (/LIBRARY refinement) etc.
You are right. Also because any-type! cannot help for backward compatibility. --- Ciao Romano