[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-03)

The basic idea I had was to try using a widget-like object as a semantic building block.  After discarding the initial prototype, I now have a small set of [Snit] types that contain the definitions necessary to allow a very simplified syntax to work as a language.

As of today, the type set is (w/ methods):

   * Object (not, and, or, xor, then, else)
   * Nil (not, and, or, xor, then, else)
   * Char (pred, succ, <=>, toInteger)
   * Integer (+, -, x, /, %, **, <=>, times, pred, succ, toChar, toFloat)
   * Float (+, -, x, /, %, **, <=>, ceil, floor, round, toInteger)

The interpreter defines the objects

 Object t
 Nil nil

and the procedures

   * R (reader) : accepts a well-formed list and parses it into a list of snit objects
   * E (evaluator) : accepts a list of snit objects and evaluates them
   * getarg : plucks the next object from the list, typically called by the evaluator and the various methods in order to get expected arguments

'''Evaluation'''

The basic expression has the form R(MA?)* (where R is receiver, M is method, and A is argument), e.g.

 expression         evaluated as
 R                  R
 R M M              (R M) M
 R M A              R M A
 R M A M A          (R M A) M A

The receiver must currently be a constant, but identifiers, class names or subexpressions will be valid receivers.  An argument can be the equivalent of (a list of) the same.

----
'''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.

----
'''Examples'''

 2
 => 2

 2 + 3 x 8
 => 40

 nil then 2 else 3
 => 3
 1 then 2 else 3
 => 2

 #"A" succ
 => B

'''Note:'''
   1. I had to use x as multiplication operator because * interfers with Snit delegation
   1. There are no precedence ordering of operators, hence the 'incorrect' result in #2
   1. Every value except nil evaluates as true
   1. #"A" is the current notation for the character A, borrowed from SML

----
[Category Language]