Version 16 of HereTcl

Peter Lewerin (2004-01-26): HereTcl is an unorthodox, radical, contrastandard, and hopefully interesting variant of Tcl.

The current concept

The reader, taking one line at a time from input, creates an input stream (or queue?) of Snit objects or operators/method names.
Leading objects in the input stream are pushed onto a (results/values) stack.
When the next item in the input stream is an operator/method name, the evaluator appoints a receiver from the stack and calls [$receiver $operandOrMethod]. If the receiver has a corresponding method, it is executed -- otherwise the call is delegated to the receiver's superior.
Any arguments are taken either from the input stream (in effect infix) or from the stack (in effect postfix).
The result of the call is pushed onto the stack.
Repeat.

(2004-01-29) I hadn't realized how many similar ideas were already posted on the Wiki. Having a look now.

Discussion

RS: so binary operators work either infix or postfix (RPN), and the stack is returned, top at left?

(PL): Yes. The stack direction is simply the result of dumping a tcllib stack.

RS would be sorry if postfix notation was abandoned - the great breakthrough of Lukasiewicz (or so), in creating Polish notation, was to do away with all unnecessary infix problems, but you had to read PN right to left. (Tcl is Polish, but remarkably intuitive though...) RPN (as in Forth) was the next step to make the notation more palatable for us left-to-righters. Both have the advantage for friends of FP that hardly any variables are ever needed, if you just keep the stack in mind. See Playing Joy or Minimal RPN. If I'd ever give up Tcl, it might well be for a powerful RPN language...

(PL): A strong reason for me to drop RPN, then. ;-) Or maybe I should branch a second paralanguage called Toast, both for "Tcl-on-a-stack" and for what I'll be when the other Tclers find out I've made you give up Tcl :-)

Seriously, I enjoy stack-based languages too. I'll see if I can't resurrect postfix, but I might have to change preferences: up to now the interpreter has taken operands from the token stream if available, and from the results stack if not. The problems I foresee now might be resolved by having the interpreter take the stack first and the stream second.

Notes

(2004-01-28): I may have to abandon postfix notation, sigh. I'm almost done with simple expressions now, but need to write a better parser before I move on to the good stuff.

I think I will need to use "..." to distinguish string data from code. Sorry, brethren, I may need to bring you back to Egypt on that.

Sample session

> is the interpreter prompt
// means to clear the results stack
; means the operation can't pop from input

 (1)   Values are simply pushed on the results stack until an
       operator appears
 > 2 3 4
 4 3 2

 (2a)  Postfix: two arguments are popped from the results stack
 > // 2 3 4 +                           > // 2 3 4 -
 7 2                                    -1 2

 (2b)  Infix: one argument is popped from the results stack; the
       other is read from the token stream
 > // 2 3 + 4                           > // 2 3 - 4
 7 2                                    -1 2

 (3a)  That is, unless the next token is ";" in which case
       the interpreter must attempt to evaluate as postfix
 > // 2 3 + ; 4                         > // 2 3 - ; 4
 4 5                                    4 -1

 (3b)  The above is equivalent to
 > // 2 3 +                             > // 2 3 -
 5                                      -1
 > 4                                    > 4
 4 5                                    4 5

 (3c)
 > // 2 + 3 4                           > // 2 - 3 4
 4 5                                    4 -1

 (4)   There must be at least one value on the results
       stack before the operator is read
 > // + 2 3 4
 error: addition requires two terms

 (5)   But the values on the results stack can be left
       over from previous operations
 > // 2
 2
 > + 3 4
 4 5
 > + 3 4
 4 7 5