Hi,
it emerged from a practical program. I had to construct a block
containing any possible set of rebol values, including Unset and
modify it somehow. Then I discovered that changing values to Unset
was not possible.
My opinion is: as long as Unset is a legal Rebol value (very
arguable subject), there should be a method to store it into
blocks and, moreover, to change elements of a block to Unset.
Allow me to tell you why the legality of Unset is questionable
(don't take my words too seriously, please):
Unset should be a value usable for the test, if a word has been
initialized (that is its raison d' etre, IMHO).
That means, that:
if unset? get/any 'a [print "'a has not been initialized"]
this looks perfectly logical. But, it is not, because if we
previously did:
a: 1
set/any 'a ()
the 'a has surely been set previously (twice!), although Rebol
claims the opposite.
Such things make Rebol more complicated than necessary, which
influences Rebol interpreter and programs too. The most general
way to set a 'word is:
set/any 'word get/any 'value
Without Unset the previous expression could have been simpler:
word: :value
and, moreover, if you write a program handling any legal Rebol
value, the unset? protection is not allowed to find your bugs
related to the use of unitialized words - when you consider Unset
a legal value, every word becomes initialized. So, in the case
of Unset less could mean more - less legal datatypes could mean
more protection and simplicity for programs.
Ladislav
>
>
>
> > Ladislav wrote:
> > =================
> > did anyone report The following?
> >
> > >> head insert copy [] ()
> > == [unset]
> > >> change copy [1] ()
> > ** Script Error: change is missing its value argument.
> > ** Where: change copy [1] ()
> >
> > =================
> >
>
> >> ()
> >> type? ()
> == unset!
> >> copy [()]
> == [()]
> >> compose copy [()]
> == []
> >> first compose copy [()]
> ** Script Error: Out of range or past end.
> ** Where: first compose copy [()]
>
> well, compose seems to turn () in a block into literally
nothing, not unset!,
> so which do you think is right, the insert that sticks an unset
value into the
> block,
> or the copy which refuses to change 1 to nothing at all?
>
> Is there some great use to having unset in a block ?
>
> Or were you just saying the two should behave consistently but
don't?
>
> -galt
>
>
>
