[REBOL] Re: Bug! in assignment to date! values with stacked set-pathvalues
From: joel::neely::fedex::com at: 12-Nov-2002 8:09
Hi, Ladislav,
Let's not start *that* again!!! ;-)
In addition, I don't think that dates are the issue here.
Ladislav Mecir wrote:
> Hi Andrew,
>
> ----- Original Message -----
> From: "Andrew Martin"
>
> Subject: [REBOL] Bug! in assignment to date! values with stacked
> set-path values
>
> > >> x: now/date ; Get fresh value.
> > == 12-Nov-2002
> > >> x/month: x/day: 1 ; Now stack up the assignments.
> > == 1 ; correct value is returned, but...
> > >> x
> > == 12-Jan-2002 ; Note that only the MONTH is altered...
>
> This is an artifact that is caused by immutability of dates...
>
Instead of pointing the WayBack machine to "Mutability", let's set
it to "Referential Transparency" instead. The principle of RT is
that expressions which yield equivalent results should be freely
interchangeable without altering the net value. Since
1 + 1
and
2
are equivalent expressions, we'd expect the larger expressions
pick "abcde" 1 + 1
and
pick "abcde" 2
to yield equivalent values. A notation/implementation in which
thing1: someval
yields a resulting value equivalent to
someval
and yet
thing2: thing1: someval
behaves differently from
thing1: someval
thing2: someval
defies both the principle of RT and (for those who claim that
REBOL is for non-programmers) what I believe most "normal humans"
would expect from such a rewriting, as REBOL normally allows one
to "chain" setting expressions freely (as long as the result of
each setting expression is equivalent to the set value):
>> x/2: a: foo/month: b: 1
== [0 1 0]
>> x
== [0 1 0]
>> a
== 1
>> foo
== 12-Jan-2002
>> b
== 1
The disclaimer, of course, is due to the fact that setting X/2
yields a value that is *not* equivalent to 1, but in the case of
FOO/MONTH the value yielded *is* equivalent to 1!
As with the concurrent discussion of REVERSE (but even more so in
this case), it's distressing to have specific instances of *very*
non-intuitive behavior marring an otherwise nice notation, when
the user has access to no documentation explaining such cases!
As a demonstration of my "even more so" position, consider the
following ...
>> foo: now/date
== 12-Nov-2002
>> blk: [foo/month: 1]
== [foo/month: 1]
>> do blk
== 1
>> foo
== 12-Jan-2002
>> foo: now/date
== 12-Nov-2002
>> foo/day: do blk
== 1
>> foo
== 1-Nov-2002
>> foo: now/date
== 12-Nov-2002
>> x: do blk foo/day: x
== 1
>> foo
== 1-Jan-2002
>> foo: now/date
== 12-Nov-2002
>> foo/day: do blk
== 1
>> foo
== 1-Nov-2002
... which shows the presence of hidden state that can cause
the effect we're discussing to be buried arbitrarily deeply!
I really have to regard this as a serious flaw of documentation
(at least!), and respectfully repeat my passionate request for
the kind of official, authoritative documentation that would
allow users to understand what is happening and why!
(I have my own opinions, but they're not authoritative!)
-jn-
--
; Joel Neely joeldotneelyatfedexdotcom
REBOL [] do [ do func [s] [ foreach [a b] s [prin b] ] sort/skip
do function [s] [t] [ t: "" foreach [a b] s [repend t [b a]] t ] {
| e s m!zauafBpcvekexEohthjJakwLrngohOqrlryRnsctdtiub} 2 ]
