Hi Mark,

1) I would suggest you to dig into the LL languages conference, it is an
interesting reading (see Joe Marshall's posts).

2) Rebol has evolved since its 1.0 days and it is better now. It doesn't
resemble Scheme as much as it did. Its Contexts (having nothing in common
with Scheme) are powerful and useful.

3) My proposal is getting a little bit outdated these days, I should
actualize some things.

4) Tail recursion - this is a useful feature. I would suggest to reintroduce
it to the language, but it is necessary to have either first class errors or
no errors in the language like in Rebol 1.x to be able to do so. Moreover,
first class errors are a feature that is useful on its own, it would surely
make the interpreter less complicated and faster.

5) Unset - there are two possible orthogonal strategies. The first one is
the strategy where Unset is legal with *no* exceptions (like illegality of
get for unset words e.g.). Its advantage is, that it makes the interpreter
less complicated/faster (no built-in checks for Unset needed). This has got
its cost: no typo protection built into the language i.e. typos in words not
checked for.

My preferred strategy, which is orthogonal too, is to use the "back to the
future" possibility to make Unset illegal with *no* exceptions (similarly as
in Rebol 1.x). This has got the advantage/disadvantage of built-in checking
(the interpreter must check for unset words getting like it does now), but
this is a more human-centric approach to the programming - a computer must
do some work for the language to be more reliable. This approach would make
the language simpler for human users than the above.

Any other strategy is non-orthogonal, violates the principle of least
surprise and complicates the language.

6) I do like the approach to the Set-/Reset- and Local-/Global- issues. It
is the safest approach possible IMO. To be honest, there is one disadvantage
to it: it may need more checking - anytime you set/reset a word, the
computer should check, if the operation is legal. OTOH, the laguage will
have a pretty good protection mechanism built in.

7) I suggest to have only functions as word-active values, as opposed to the
current state (see http://www.sweb.cz/LMecir/interpret.html ), when even
paths, lit-paths, set-paths, parens, lit-words and set-words are defined as
word-active. This simplifies the language and removes some nasty crashes
present in the current Rebol interpreter.

8) The issue with the local words definition is, that a code like:

do [i: 1]

should mean, that 'i wouldn't become global, but rather local to the block.
That is why to set global words, it might mean, that there would be only one
possible solution:

do [set 'i 1]

After setting a word, the reset would of course work well in either case,
i.e. this would reset a global word:

do [i:= 2]

(is anything wrong with i:: , I find that faster for typing), while here:

do [
i: 1
do [
i:= 2
]
]

we reset a local word.

(This is not the only possibility, but it is the most orthogonal one.)

----- Original Message -----
From: <Robbo1Mark@...>
To: <OSCAR-PROJECT@yahoogroups.com>
Sent: Friday, November 30, 2001 8:14 PM
Subject: [OSCAR Project] Words & Unset


Hello everybody,

Here a few more snippets on PRIMO design I've been
thinking about.

I often read Ladislav's writings on REBOL and share
a lot of concerns and appreciate his deep understanding
about many of the aspects and implications of REBOL
as it currently is.

Here, I would like to address certain aspects which
he pointed out in his excellent REBOL enhancement
proposal, and consider these fixes which address
some of the points he raised there.

First of all words & values.

Some Rules for PRIMO,

1. All words are local to the context they are
created in, including and especially functions.
No need to declare /locals, all local by default.

2. Ways of (re)Defining words.

>> Constant word value ; note value any-type! even unset

; note constants can NOT be changed and are immutable for
; the duration / lifetime of the porgram. Use with caution,
; they are CONSTANT and can not be changed once set.
: there is No contant-word! format, word must be explicitly
; defined as constant with the 'CONSTANT function.

>> set word value ; note value any-type! even unset
>> word: value ; set-word! format

; as per existing REBOL behaviour except the word arg
; can be of ordinary word format as it is quoted as a
; lit-word! in the function definition.

>> reset word value ; note value any-type! even unset
>> word:= value ; reset-word! format

; If you try to 'Set a word that is already defined then
; this will raise an exception or fire an error! hence the
; need for a reset-word! type and 'reset function.
; I got this form from PICO language which defines and
; redefines words / variables in this manner.

>> unset ; a value of type? == unset!
== unset
>> first reduce [()]
== unset

Proposal is to make UNSET a first class legal value which
can represent itself just as none represents a none! value.

The function UNSET will be replaced with a To-Unset word
function and also words can be Set or Reset to the unset value.

All words which are unset would still raise an exception or
fire an error! except for the special case word 'UNSET which
would represent the unset value of unset! type.

All this would need is an internal function to identify
words with unset values ( except of course for the word Unset)

see example code below for more examples...

unset-word?: func [ 'word ] [ pick [ true false]
(word? word) and (unset? get/any word) and ((mold word) <> "unset")]

>> x: 1
== 1
>> print x
1
>> loop 4 [ print x:= x + 1]
2
3
4
5
>> x: 2
** Script Error! word x already defined in this context
** Near x: 2
>> x:= 2
== 2
>> print x
== 2
>> x:= unset ; unset is a first class value
== unset
>> type? get/any 'x
== unset! ; unset! is the datatype
>> get/any 'x
== unset ; unset the value
>> unset ; unset used as a word! similar
== unset ; to the way the word! none denotes itself
>> type? unset
== unset!
>> unset? unset
== true
>> word? unset
== false
>> word? 'unset
== true
>> unset? get/any 'x
== true


let me know what you think,

cheers,

Mark Dickson