some more about Re: Why not LISP (was: HLL and misa)

[Billy Tanksley]

On Tue, 20 Jun 1995, Frank DiCostanzo wrote:

> granted, as a matter of taste, s-expr as a language syntax is not for all. 

I have to admit here that I'm one of the all for which s-expr is 
abhorrent.  :)  I simply can't stand the parentheses, and it's stopped me 
from learning an otherwise excellent language three times now.

> > > this allows for 
> > > things like lisps macro facility, etc in which the program can write code 
> > > itself in a (fairly) easy and straightforward way.
> >    Macros and extensions to a language's grammar can be done not only in
> > Lisp. Why restrict to s-exp ?

> i see no restriction to s-expr... however it certainly, as i mentioned above,
> is a great deal easier for the programmer to extend to language in complex
> ways.  i would like to know of another language that would allow me to
> write programs that can extend the language interactively with the
> compiler, within the same environment, and not use s-expr.  in lisp, i can
> add to the compiler itself to dynamically alter and add to the language 
> using the full power of the language to do so.  sorry for the 
> evangilizing but i just don't see how that could be done using an 
> arbitrary syntax (perhaps i don't need to know)

Forth.  Forth has no syntax at all, and it's  interpretive-compiled, and 
fully modifiable within the compiler.  Of course, it becomes easier to 
modify your code if you can be certain of the format of the code-- that's 
one reason most Forths use threaded code, in which a word is defined by a 
sequence of addresses representing its component words.

I think that in limited cases it would be handy to be able to represent a 
word or a portion of a word this way.  I propose the idea of "frames", a 
section of code delimited from other code, within which there is a 
guranteed one-to-one correspondance between a mention of a word and its 
index in the array/list/whatever.  Thus, code within a frame can be 
patched easily.

Here's what this might look like in Forth:

: frame-test   ." Preparing to frame: "
		<< 3 . ."  shall be the number of your counting" >>
	;

: countdown negate 1 swap ( count from -n to 1) do I abs . ." ..." loop ;

' frame-test 1 >frame  2 >component
' countdown swap !

That's enough for now; I just patched the . (display number) into 
countdown.  Note again that this 1-to-1 correspondance would only be 
requred withing the frame, and possibly the optimiser would be free to 
monkey with it even there.

> i agree that a good structural editor would be damn spiffy.  however the
> errors i had in mind could not really be caught by such a editor.  i
> misnamed them when i said syntax errors, because these errors can be
> perfectly legal - i'm thinking about errors due to precedence such as * vs
> + and other operators where the programmer has to remember what happens
> first..  these kind of syntacically correct errors are the thing that
> cause me the most grief.

You can get completely rid of those errors in a conventional language by 
putting parenthesis around everything, too.  Or, you can switch to RPN 
and not ever worry about precedence, because everything is placed in the 
order it'll be executed.

> again, agree about the implementation thing but thats not what i had in 
> mind. i was suggesting that the parser could be part of the language.  
> this would allow individuals to create their own syntaxes. as long as 
> the grammer were around to reflect on the syntax, that language would be 
> fully portable and integratable with eveyone elses syntax. that way, you 
> can program with your syntax and i'll use s-expr :)

That's how Forth programmers woprk right now.  The problem is, after just 
a while you've made so many small changes to the way your system works 
that making someone else's system work the same way is a pain.

> frank

-Billy