From: Marco Antoniotti
Subject: Re: Why we must somtimes have lisp/scheme after all. (WAS: What other experimental languages connect to a windowing system?)
Date: 
Message-ID: <MARCOXA.94Aug1093006@mosaic.nyu.edu>
In article <··········@world.std.com> ·······@world.std.com (Joseph H Allen) writes:

   In article <···············@tahoe.cs.brown.edu>,
   rodrigo vanegas <··@cs.brown.edu> wrote:

   >Finally, this long thread has reached the heart of what i believe to
   >be the principal reason why we can't do without lisp.

   >In article <··········@world.std.com>, ·······@world.std.com
    (Joseph H Allen) writes: 
   >> The major semantic paradigms present in scheme/lisp are:
   >
   >> 1  Closures
   >> 2  Loops through tail-recursion and lambda functions
   >> 3  Type inference
   >> 4  Self-representation through common list syntax

   >> 1 is the most important one, and is syntacticly possible with other
   >> languages.  Most functional languages have closures.  Other
   >> static languages 
   >> don't have them because they do not sit well with stack-based local
   >> variables.  For a non-lisp and non-functional language with
   >> closures, try my 
   >> language Ivy.

   >1) ML also meets this criteria.  It is an impure functional language
   >(meaning it has assignment which is all you need to program as you
   >would in C), and has a pleasant non-lisp syntax.

   Yeah, ML's pretty nice.

Except when you FORGET parenthesis! :-) The operator precedence rules
are so contrived that you end up stuffing the code with parenthesis
just to play it safe. :-)

   >> 2 and 3 are not necessary, hurt readability and can be
   >> considered semantic 
   >> sugar.

	...

   IMHO, loop structures should be used in place of tail recursion for
   readability.  Recursion should, of course, still be possible.

It is the nature of data that makes recursion more suitable than loops
and vice versa.

	...

   I should have said 'nearly redundant' :-)

   Simple macros can be more powerful in lisp than in any other language and
   rather easily lead to parameterized classes and other syntax augmentations.

   You can also do neat things like easily take the derivatives of mathematical
   functions expressed in lisp.  But then I don't want to express my functions
   in lisp :-) A simple precidence parser is only about a hundred lines long in
   any other language, so it's not that big of a deal to use lists for
   representation, and infix/prefix for data entry and display.

Have you tried the 'infix.lisp' package from the AI-repository?

   >Even so, i will concede without prompting,that if one is not
   >interested in either higher-order functions or language
   >experimentation, the lisp parentheses become only a nuisance and
   >Common Lisp's size just an obstacle to delivery.

   Lisp is a neat idea, but to gross to use in practice.

As is ML, Haskell, Miranda, Prolog and I would add FORTRAN, COBOL,
PL/I and, last but not least, C/C++.

So much for the daily religion wars :)

Happy Lisping
--
Marco Antoniotti - Resistente Umano
-------------------------------------------------------------------------------
Robotics Lab		| room: 1220 - tel. #: (212) 998 3370
Courant Institute NYU	| e-mail: ·······@cs.nyu.edu

...e` la semplicita` che e` difficile a farsi.
...it is simplicity that is difficult to make.
				Bertholdt Brecht