Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!new
From: new@udel.edu (Darren New)
Newsgroups: comp.lang.misc
Subject: Re: Anyone want to design a language?
Message-ID: <12260@nigel.udel.EDU>
Date: 26 Feb 90 19:09:54 GMT
References: <11558@nigel.udel.EDU> <551.UUL1.3#5129@willett.UUCP>
Sender: usenet@udel.EDU
Reply-To: new@udel.edu (Darren New)
Organization: University of Delaware
Lines: 82

In article <551.UUL1.3#5129@willett.UUCP> dwp@willett.UUCP (Doug Philips) writes:
>
>>                                   However, in my language there are
>> no parsers that cannot be overridden.  That is, to parse the language,
>> each character is read and appended to a buffer. Then each entry in
>> a "parse" array is called in turn. Once one of the entries recognises
>> the token in the buffer, it outputs the object code for that token
>> and clears the buffer.
>Why aren't the parsers run in parallel (or to that effect?)  

Because I'm running on a uni-processor :-). 
Also, the programmer has control over the order of items in the list.
If you want the mention of a function to create the function, then
this could be put in front of the routine to compile the call to the
function. There are other transformations too: e.g., all functions are
upper-case only, so there is a parser that uppercases the buffer and then
claims to not recognise it. (Not really, but an example)

>I take it that
>the parsers don't have to emit anything if they don't want?  
 The parsers are functions. They return either a special null value if
 the buffer is not recognised or return the "thunk" of the object
 they recognised.

>How do you 
>do the equivalent of read-time-macros-or-functions?  (I don't remember my
>lisp well enough, but something like reader macros) (or Forth's IMMEDIATE
>words)

The parser itself reads ahead in the input stream.  For example, for the
"procedure" type, an openning left brace is recognised and then
the parser and input stream is called RECURSIVELY to compile the
executable procedure. Any sub-procedures look at the return stack
(yuck) or a special variable to see if they are inside of another
procedure and clear the "executable" bit. The "if" command goes:
  u @ 0 <
  { true part }
  { false part }
  if
and"if" takes three parameters: a condition and two procedures.
The internal coding of IF is

{ /* IF routine */
   012->120			/* ROT in FORTH */
   'true t-throw		/* goto label 'true if condition is true */
   01->1			/* swap drop */
   execute			/* execute the false part */
   'end throw			/* skip to end */
   'true label
   01->0			/* drop */
   execute
   'end label 
   } 'if define

Note that 'true is parsed by creating an entry in the symbol table if not
already there and then returning a "thunk" to it. Hence, "'true" pushes
the symbol table entry for "true" on the stack. "'true label" just pops
off 'true from the stack, but leaves a code sequence that "throw" can
find by looking in and modifying the return stack (which is of course
directly accessible). Also note that 012->120 is a function created by
a parser: if the normal lookup-in-dictionary fails, there is a parser
which will recognise a string of digits, an arrow, and a string of digits
and will build code to make the indicated transformation. Then the
name will be installed in the dictionary so other lookups will use
the same code.   I do overloaded procedures and message sends the same way.

>> I think that if you can't add new literal types, you don't have a 
>> truely new language. To do this, you must be able to define
>> internal representations of high-level structures in terms of low-level
>> structures (like bit strings).
>One of the nice things about Forth is that it is simple and transparent
>enough to allow you to do just this.  You can rewrite the interpreter or
>just NUMBER.
So's mine.  Mine is simple enough to add new parsers WITHOUT having to
rewrite the entire world. One of the advantages of this language (which
I call 2OL) is that the dynamic memory handling is much better than
in FORTH, allowing things like 012->0221 to generate functions by allocating
memory in a separate area from the procedure currently compiling.
		   -- Darren
P.S., I should make clear that the implementation, for various non-programming
related reasons, has not progressed much beyond the design phase.
I'm considering making the design and code-so-far public. -- Darren