[REBOL] Re: Bug! in assignment to date! values with stacked set-path values
From: lmecir:mbox:vol:cz at: 13-Nov-2002 18:16
Hi Romano,
I tried to tell, that the behaviour was caused by the fact, that the whole
thing was only a hack.
The hack was most probably not well thought out and the same hack could have
been made for integers and has been made for issues.
> It seems to me that the mutation hack is not enough to explain this. The
> problem is that all the value are pre-fetched before the first assign
start,
> else with or without mutation the result should be right. Instead, the
> pre-fetch works only with mutable values. The bug is prefetch the value of
> set-path.
You are right. The behaviour can be corrected, although that might influence
the speed of the interpreter...
> Neither parens can correct the problem.
> Look at this:
>
> >> a: "aaa" probe a/2: (a: "bbb" #"c") a
> "aca"
> == "bbb"
>
> As you can see the a/2 continue to refer to the old string "aaa" also when
the
> parens block has changed the 'a value with "bbb". I can be wrong but i do
not
> see any mutation hack here.
>
> ---
> Ciao
> Romano
Ah, I didn't read your whole post, sorry. This is interesting and it is a
proof of the fact, that the whole path business is a hack in Rebol (no
surprise).
When we are at it, we shall ask RT to change the path business more
thoroughly to introduce referential transparency. I am afraid, that this
change will affect the way Rebol parser (make block! / load) works, because
I would suggest to not treat #"(" and #")" as ordinary delimiters. Instead
Rebol should treat them as "forbidden" characters, which aren't allowed to
occur in words. Nevertheless,
a/(1 + 2)
should differ from
a / (1 + 2)
, where the former can be treated as a path, while the latter as an
expression, which divides A by 3.
What do you think about the fact, that the difference is small, which may
lead to confusions?
-L
