🚀 go-pugleaf

There's at least one advantage to the lisp syntax, and that advantage
is important to lispers, although others may not find it important.
Lisp programs have a simple, logical representation as data within
lisp: a program is a list of lists, i.e., a tree.  In most programming
languages, source-to-source transformations are a pain because to do
anything general you have to parse the language into some idiosyncratic
form, manipulate it, and then translate back into the source language.
In lisp you put a single quote in front of the program and you have
data.  That's why lisp is the language of choice for building embedded
languages.  It's also why lisp has general-purpose syntax extension
that integrates neatly with the rest of the language (e.g.,
extend-syntax) while C has a crude, tacked-on macro processor
pre-pass.

For people who are interested in the semantics of new constructs as
opposed to syntax, this is a big win.  For example, for fun I once
implemented ``Icon in Scheme'', using streams with lazy evaluation to
implement generators and coexpressions.  The syntax was lisp-ish, but
it had equivalents for all the interesting Icon constructs except
string scanning.  Although I was learning Scheme at the time, it only
took me about three days to get it running.

-mike

gudeman@cs.arizona.edu (David Gudeman) writes:
> In article  <2925.UUL1.3#5129@willett.pgh.pa.us> Doug Philips writes:
> ]And just because it is a problem for the so called masses means merely
> ]that is it DIFFERENT from what they are used to.  Not wrong.  DIFFERENT.
> 
> No, WRONG.  If it is uncomfortable for people, then it is by
> definition the wrong syntax to have them program in.

Oh?  Presumably because object-oriented programming is uncomfortable and
confusing for many people, it is also by definition the wrong way to have
them write programs?

>                                             There is no great
> advantage to lisp syntax.

1. It's simple.  You can summarize all the syntax you need to know on the
   back of a postcard.

2. It's easy to implement.

3. It's flexible, in the way that (say) infix isn't.  Most of the basic
   operations (+, *, and so on) naturally extend to any number of arguments.

4. You don't have to worry about any precedence rules whatsoever.

I'm sure other people can come up with lots of advantages I've forgotten.

> It is possible (but not certain, contrary to what some lispers would
> claim) that if everyone had grown up with lisp-like syntax in math
> classes that they would all be just as happy with it as they are with
> infix syntax.  Who cares?  The fact is that they didn't grow up with
> that sort of syntax, they aren't happy with it, and they shouldn't
> have to learn a completely different syntax [...]

Ah!  You're arguing that people should be taught Lisp or RPN in schools?  I
agree wholeheartedly.  At school I devised a method of using my Casio
calculator in an RPN-like way, because I found it more straightforward.  When
I later found out about RPN and got an HP, I thought "Why didn't they teach
me this, or at least mention it, when we started using calculators?"

> ]"Tons of people don't like lisp syntax" ... Does ANYONE have any
> ]non-anecdotal, non-fictional data to back this up?  Yeah, me'n'my'buddies
> ]donna like it.  Wow, am I ever impressed.
> 
> Does anyone have any non-anecdotal, non-fictional data to back up the
> claim that the syntax of lisp is _not_ a hindrance to learning it?

You're the one making the positive assertion, that Lisp's syntax is a
hindrance to learning it.  You're the one who has to provide the evidence.

>                                                              When the
> only evidence available is anecdotal, then that is what you have to
> use to form an opinion.

When the only evidence is anecdotal, I would advise you not to form such a
strongly-held opinion.


mathew

 

In article <1991Jun26.223026.13792@watserv1.waterloo.edu>, mhcoffin@tolstoy.waterloo.edu (Michael Coffin) writes:
> There's at least one advantage to the lisp syntax, and that advantage
> is important to lispers, although others may not find it important.
> Lisp programs have a simple, logical representation as data within
> lisp: a program is a list of lists, i.e., a tree.  

Lisp has two features: an internal form for programs, and a (over:-) simple
syntax.  I think with an "infix Scheme," having a well-defined internal 
form would give you most of the power.  You'd need a "code-constant" or
"internal-form-of-this-quoted-code-fragment" construct, e.g.,

x = quote {
    function ( a, b ) {
        return a+b;
        }
    };

(That's not a lambda expression, it's a quoted lambda expression.)

> In most programming
> languages, source-to-source transformations are a pain because to do
> anything general you have to parse the language into some idiosyncratic
> form, manipulate it, and then translate back into the source language.

If the compiler (or a library routine) can do the parsing,
and there's a standard (not idiosyncratic) internal form,
and a library routine can print programs,
(or else, you don't go to ASCII, but stay in internal form),
then the situation would be pretty much the same as with Lisp.
Lisp has to be parsed and printed, too, if you're working with ASCII.  

> It's also why lisp has general-purpose syntax extension
> that integrates neatly with the rest of the language (e.g.,
> extend-syntax) while C has a crude, tacked-on macro processor
> pre-pass.

I've always wanted "semantic macros" instead of text macros, for C.

--Steve

In article <603@smds.UUCP> sw@smds.UUCP (Stephen E. Witham) suggests
adding more conventional syntax on top of a Scheme-like semantic base.

Algol-like syntax has gone with Lisp-like languages in several
different projects:

 -- Lisp 2.0 was a pretty standard Lisp inside, with Algol syntax outside.

 -- ECL (or EL/1) had an Algol-like syntax, a Lisp-like approach to
    the language environment (interpreter with compatible compiler,
    program represented as linked-list data structures available to
    other programs, dynamic scoping, ...) and an original approach to
    dynamic data typing (types as data, etc.).

 -- The Macsyma user language was fairly Algol-like on the outside,
    very Lisp-like on the inside.  (Macsyma is a large symbolic
    algebra system.)

Of course, all of this depends on what you call `Algol-like' and what
you call `Lisp-like'.  If you're not careful, you end up calling every
expression-oriented language with a tree-like internal form Lisp-like,
and every language with begin-end blocks Algol-like.

Perhaps Scheme ought to be called Algol-like for that matter, since
Algol had static scoping since the beginning, and Algol 68 even
introduced first-class closures....

And oh, yes, I agree with Witham that there's more to Lisp's syntax
than S-expressions: you've got to count all the special forms as part
of the syntax to be fair....  One of the advantages of Scheme is that
it reduces the number of these.

	-s

** I don't have bibliographies, but here are some pointers:

For Lisp 2.0: see Jean Sammet's Programming Languages: History and
	Fundamentals

For ECL: Ben Wegbreit's papers in CACM around 1970-75.

For Macsyma: Macsyma Users' Manual (I don't think the language was
	described in any detail in the published papers).

Stephen E. Witham:
> Lisp has two features: an internal form for programs, and a (over:-)
> simple syntax.  I think with an "infix Scheme," having a
> well-defined internal form would give you most of the power.  You'd
> need a "code-constant" or
> "internal-form-of-this-quoted-code-fragment" construct, e.g.,
>
> x = quote {
>     function ( a, b ) {
>         return a+b;
>         }
>     };
>
> (That's not a lambda expression, it's a quoted lambda expression.)


Why such a complicated expression?  Why not just
x =: +

Then, presumably, when you say 
   1 x 1
the answer would be
2

Or is it important to quote the thing?  You could always say
x =: '+'

(too simplistic?  what if you want to have a code constant for some
existing function, independent of its symbol?  Well, you could always
adopt a secondary quoting scheme....  Like, maybe
x =: + quoted
)

Requiring a lambda expression to express an anonymous function seems
to me to be one of LISP's flaws, not one of its advantages.  Or, put
another way, infix notation already has a clear scheme for
representing arguments, why not take advantage of it?

-- 
Raul <rockwell@socrates.umd.edu>

In article <ROCKWELL.91Jun27233537@socrates.umd.edu> rockwell@socrates.umd.edu (Raul Rockwell) writes:

   Stephen E. Witham:
   > Lisp has two features: an internal form for programs, and a
   > (over:-) simple syntax.  I think with an "infix Scheme," having a
   > well-defined internal form would give you most of the power.
   > You'd need a "code-constant" or
   > "internal-form-of-this-quoted-code-fragment" construct, e.g.,
   >
   > x = quote {
   >     function ( a, b ) {
   >         return a+b;
   >         }
   >     };
   >
   > (That's not a lambda expression, it's a quoted lambda expression.)


   Why such a complicated expression?  Why not just
   x =: +

Because he was responding to someone who was remarking upon the
usefulness of lisp code being represented as lists. Stephan was trying
to show that you could have some syntax (like 'quote') which when
given a code fragment could return a useful internal representation of
that code, the same way that, in lisp, you can slap a 'quote' around a
piece of code and get a list. He wanted the variable 'x' to be bound
to a representation of the code of the procedure, not the procedure
itself.

   Requiring a lambda expression to express an anonymous function
   seems to me to be one of LISP's flaws, not one of its advantages.

What's your alternative? You need some syntax to say that you want a
function that takes some number of arguments.

   Or, put another way, infix notation already has a clear scheme for
   representing arguments, why not take advantage of it?

I won't argue about the usefulness of infix notation, but what has
that to do with anonymous functions?

-Mark
--

Mark Friedman
MIT Artificial Intelligence Lab
545 Technology Sq.
Cambridge, Ma. 02139

markf@zurich.ai.mit.edu

In article <603@smds.UUCP> sw@smds.UUCP (Stephen E. Witham) writes:
>Lisp has two features: an internal form for programs, and a (over:-) simple
>syntax.  I think with an "infix Scheme," having a well-defined internal 
>form would give you most of the power.  You'd need a "code-constant" or
>"internal-form-of-this-quoted-code-fragment" construct, e.g.,

I would like to just interject that Hermes is a strongly-typed,
powerful, high-level modular infix distributed programming language
that has "program" as a built-in data type.  All of what *I've* seen
Lisp do with programs could be done as easily with Hermes programs.
You can even pass them around, store them in libraries, and so on.
Check it out. It's neet. :-)

Now, if only you could write a constant of any type, we'd be in great shape.
	  -- Darren

-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, FDTs -----
+=+ Nails work better than screws, when both are driven with hammers +=+

Stephen E. Witham:
      > Lisp has two features: an internal form for programs, and a
      > (over:-) simple syntax.  I think with an "infix Scheme,"
      > having a well-defined internal form would give you most of the
      > power.  You'd need a "code-constant" or
      > "internal-form-of-this-quoted-code-fragment" construct, e.g.,
      > x = quote {
      >     function ( a, b ) {
      >         return a+b;
      >         }
      >     };
      > (That's not a lambda expression, it's a quoted lambda expression.)

Raul Rockwell (me):
      Requiring a lambda expression to express an anonymous function
      seems to me to be one of LISP's flaws, not one of its advantages.

Mark Friedman:
   What's your alternative? You need some syntax to say that you want
   a function that takes some number of arguments.

Well, you can say that an infix function takes one or two arguments.
Make one argument optional (with greedy binding) and ambiguity may be
resolved when the function is used.  e.g.  x-y  vs.  -y

A less elegant solution might be to always require two arguments and
use BOTTOM a lot.

Me:   Or, put another way, infix notation already has a clear scheme
      for representing arguments, why not take advantage of it?

Mark Friedman:
   I won't argue about the usefulness of infix notation, but what has
   that to do with anonymous functions?

You can define anonymous functions using infix notation by either (a)
explicitly declaring dummy variables (similar to (lambda (x y) ...))
(b) using a pair of "standard names" for dummy variables, or (c)
tacitly defining functions without the use of any dummy variables
(just say what functions preprocess the arguments/postprocess the
results).

I expect you'd want a good variety of data-structure building
functions for something like this (otherwise you could only work with
"toy" data).  [And a good variety of meta-functions for leverage.]

Or maybe I'm missing the point of the question??

-- 
Raul <rockwell@socrates.umd.edu>