Peter Lewerin (2004-01-26): HereTcl is intended to be an unorthodox, radical, contrastandard, and hopefully interesting (or at least entertaining) variant of Tcl.
Concept
(2004-02-02)
An expression has the form R(MA?)*, i.e. a receiver followed by a sequence of Method (and optional Argument) terms. The receiver can be a constant, an identifier, a class name, or an expression in parenthesis. An argument can be the equivalent of (a list of) operands.
Notes
(2004-02-02): HereTcl will not use postfix notation. Sorry. Seeing that experiments with postfix notation has already been done a number of times, most recently RPN again, there doesn't seem much point in doing it here.
(2004-01-29): I hadn't realized how many similar ideas were already posted on the Wiki. Having a look now.
(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.
Discussion
(Please put questions or suggestions here)
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, 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.