[REBOL] Re: Bug! in assignment to date! values with stacked set-path values
From: rotenca:telvia:it at: 18-Nov-2002 14:42
Hi Ladislav
> > Do you means that set-path should be fetched only one time?
>
> I mean, that paths should be evaluated differently, than set-paths (the
> order of evaluation should be different for these two datatypes).
OK!
> > I think that the problem with path could arise from the fact that set-path
> > does not exists as true datatype!, it is only the last item in the path
> that
> > make rebol thinks it is a set-path.
>
> I don't agree with that, every Rebol datatype has got a type attribute
> attached to it, IMO.
Yes: load set it, but it can only set it with a rule: it ends with #":".
The evaluation then can demonstrate another thing: that it was not a set-path
but a function call with refinement.
> > The result is a strange behaviour: a set-path which works like a path
> >
> > x: func [/b][3]
> > type? first [x/b:];== set-path!
> > x/b: ;==3
>
> This is unexpected, but it may be justified as an attempt to "do something
> meaningful" instead of firing an error.
I do not think the same. Here the attempt is not set something, but only to
evaluate the path. If a set-path is by default "set the value referenced by
the path" this construct should trigger an error or a crash. Obviously this
can be corrected adding an error! ad hoc, but ist shows for me the interpreter
behaviour.
> > Another strange thing:
> > :x ;== function?
> > :x/b ;== 3
>
> This is consistent with something like a/:i, when the interpreter considers
> such a thing to be a path:
>
> type? first [:x/b] ; == path!
Yes, get-path does not exist. The problem for me is that using a function with
a refinement and using a function without any refinement are two different
things at all, if one use a get-word.
Often I'm asking myself: what are advantages of refinements in functions?
Often i see only the bad side.
---
Ciao
Romano
