Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwm.edu!cs.utexas.edu!samsung!think!bbn!rochester!udel!new
From: new@udel.edu (Darren New)
Newsgroups: comp.lang.misc
Subject: Re: Anyone want to design a language?
Message-ID: <11558@nigel.udel.EDU>
Date: 19 Feb 90 21:00:49 GMT
References: <22569:05:10:24@stealth.acf.nyu.edu> <8475@wpi.wpi.edu> <4489:05:14:19@stealth.acf.nyu.edu> <1873@wrgate.WR.TEK.COM>
Sender: usenet@udel.EDU
Reply-To: new@udel.edu (Darren New)
Distribution: usa
Organization: University of Delaware
Lines: 23

Actually, I've been playing with a language that has flexibility
as its greatest goal.  Each function is compiled as it is seen
and can in turn compile other functions.  This is essentially what
FORTH and to some extent LISP do. 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. This technique allows overloaded functions,
new literals, "create-on-reference" functions (for example, it could
create a "typecast" function given the name) and so on. This would
be an especial boon if the intermediate code was standardized and 
fairly flexible, allowing optimizations to different architechures
much like the Smalltalk or Pascal PCodes do.  

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).  From that, the language can be
customized out the ptooks.  Of course, it may not be readable
when you are done, but...           :-)

		   -- Darren