🚀 go-pugleaf

It's true that Prolog handles programs-as-data nicely, but I don't
think it's true that Prolog has a conventional syntax.  Other than
using infix notation, it looks nothing like any of the popular
languages.  That's not surprising; Prolog almost entirely lacks
explicit control structures, which are everywhere in conventional
languages. 

And unless you are willing to give up explicit control structures,
things are much more difficult than Prolog.  You have to devise ways
to represent not just infix notation, which has a fairly natural tree
representation, but while statements, case statements, for loops,
blocks, procedures, exit statements, ---the list goes on.  This has in
fact been done; I once saw a proposal for a Pascal-like language that
allowed programs as data.  Each control construct had an internal
format that amounted to a record with fields for each piece.  Most of
the fields, were, of course pointers to other records.  The result
was, in my opinion, a mess.

By the way, I think we ought to keep in mind that there are several
Lisps.  Common Lisp has a rather complicated syntax, as has been
pointed out.  Scheme, on the other hand, has a syntax that will fit on
a single page and leave room for comments.

-mike

gudeman@cs.arizona.edu (David Gudeman) writes:
> In article  <2Xc8415w164w@mantis.co.uk> Giving C News a *HUG* writes:
> ]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?
> 
> Two answers: (1) there is presumably some other advantage to oriented
> programming that gives incentive to go through the discomfort -- the
> same does not apply to lisp syntax.

That's your opinion.  A lot of people see great advantages in the syntactic
flexibility and simplicity of Lisp.

> ]1. It's simple.  You can summarize all the syntax you need to know on the
> ]   back of a postcard.
> 
> Not true.  You have to specify the special syntax of defun, let,
> protect-unwind, do (which is worse than anything I have ever seen in
> an algol-like language), etc.

Sorry?  What "special syntax" are you referring to here with your examples? 
I'm not entirely sure I understand what you mean by a "special" syntax as
opposed to the standard one.

>                             You have to specify what operators take
> more than the normal number of parameters.

You're applying a concept which doesn't fit the language.  Lisp functions
like + and cond don't have a "normal number of parameters".  (+ 2 3 5) isn't
a special version of + with an abnormal number of parameters; it's the same +
which you find in (+ 2 3).

>                                          And for non-associative
> operations you have to specify what multiple parameters mean.

You have to specify what the parameters mean for other sorts of syntax as
well.

> ]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.
> 
> The fact is that you seem to believe that lisp syntax does not cause
> problems.

Untrue.  I believe that Lisp syntax does cause problems, I just don't believe
that Lisp syntax is a hindrance to learning the language -- at least, not to
those who are actually prepared to try and learn the language.

>                             I can even rephrase your stand as a
> positive assertion: "lisp syntax is just as good as algol-like
> syntax".

That isn't what I'm saying at all.  You haven't re-phrased my stand, you have
re-defined it.

My opinion is: (not (believe (syntax-hinders-learning Lisp))).

If it were (believe (not (syntax-hinders-learning Lisp))) then you could
indeed re-phrase it as a positive assertion.  But as it stands I am not
making an assertion; I am simply doubting an assertion you have made.

> ]When the only evidence is anecdotal, I would advise you not to form such a
> ]strongly-held opinion.
> 
> You have no idea how strongly I hold this opinion.

Clearly you hold it fairly strongly, or you wouldn't go on about it so much.


mathew

 

Michael Coffin:
   Prolog almost entirely lacks explicit control structures, which are
   everywhere in conventional languages.

   And unless you are willing to give up explicit control structures,
   things are much more difficult than Prolog.  You have to devise
   ways to represent not just infix notation, which has a fairly
   natural tree representation, but while statements, case statements,
   for loops, blocks, procedures, exit statements, ---the list goes
   on.

There is no reason these things can't be expressed as functions and/or
meta-functions.  For example, a case statement may be represented as a
meta-function which takes two arguments:  (1) a list of function
representations and (2) a selection argument.

Blocks are even simpler -- use the same notation you use to describe
data and pass the results to a meta-function which returns a usable
function.

There are a number of ways to construct for/while loops, ranging from
repeated application of a function to some data (similar to
"foreach"), to a more explicit iteration where you supply a predicate
to determine when the loop is complete.

I'll agree (in advance) that you'll want some sort of meta-function
syntax so that you can take functions as arguments, but that need not
be complex.

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

My opinions on this discussion highly favor the all-is-data, syntax-is-simple,
memory-is-managed, ... languages.

gudeman@cs.arizona.edu writes:
>> 1. It's simple.  You can summarize all the syntax you need to know on the
>>    back of a postcard.
>
> Not true.  You have to specify the special syntax of defun, let,
> protect-unwind, do (which is worse than anything I have ever seen in an
> algol-like language), etc.  You have to specify what operators take more than
> the normal number of parameters.  And for non-associative operations you have
> to specify what multiple parameters mean.  Lisp syntax is _not_ trivial.

Make the distinction between SYNTAX and SEMANTICS.  In a description of Lisp's
semantics, one should introduce the notions of macros and read-time evaluation.
The semantics of the special forms can then be described in a straightforward
fashion, for example, by noting the equivalence of the following:

    (let ((variable-1 value-1)     ((lambda (variabl-1 ... variable-N)
          ...                         form-1
          (variable-N value-N))       ...
      form-1                          form-M)
      ...                            value-1
      form-M)                        ...
                                     value-N)

I tend to agree with you that the SEMANTICS of some `do's are much too hairy,
so I never use it.  Nonetheless, this degenerate case works the same as the
others, just a matter of degree.

>> 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.
>
> A very minor advantage, and probably the only real one.

The ability to handle variable numbers of arguments is a big win.  Seriously
affects readability and usability.  This feature should be provided by a clean
(hell, transparant) syntax.

>> 4. You don't have to worry about any precedence rules whatsoever.
>
> The same is true of infix syntax.  If you don't know the precedence you can
> always use parens (and the result is no worse than lisp).  The difference is
> that with infix syntax you have the choice.

YOU can insert the parens, but the next bloke might not.  And you may have to
play with his code someday.  And when you do, you better remember that C's
bitwise-and operator `&' is of higher precedence than the bitwise-xor operator
`^'.  The regular syntax eliminates this type of error even if I'm not fond of
expressiong *every* expression in prefix notation.

Note that I've conveniently sidestepped the issue.  Because programs are data,
I know that I can write an infix expression macro within the bounds of the
language.  Experience has shown it to be relatively straightforward.  (However,
I never use the critter because I am comfortable with prefix notation.)
Extending this toy to handle new operators with a given precedence and
associativity is relatively easy.  In fact, I'd say that it does infix better
than most imperative languages because it is so easy to manipulate programs as
data in Lisp.

>> 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.
>
> The fact is that you seem to believe that lisp syntax does not cause
> problems.  This is a real opinion.  It is different from having no opinion on
> the matter, and is just as subject to the need for evidence as is the
> opposite opinion.  I can even rephrase your stand as a positive assertion:
> "lisp syntax is just as good as algol-like syntax".  There, now you have to
> give evidence and I don't.

Well said.  But let's dispense with the meta-arguments for the moment.  I have
never had a problem teaching Lisp.  I've invariably gotten faster results with
Lisp than with imperative languages like C and Pascal.  The major issue was one
of syntax.  Once we struggled through a formal discussion of the general syntax
and the low-level semantics, they had no problem learning the individual
special forms.

The key words here are simplicity and genericity.

Regards, [Ag]

In article <1991Jun28.133708.3776@watserv1.waterloo.edu>, mhcoffin@tolstoy.waterloo.edu (Michael Coffin) writes:
> It's true that Prolog handles programs-as-data nicely, but I don't
> think it's true that Prolog has a conventional syntax.

Prolog syntax is (extensible) operator-precedence.  That's about as
conventional as you can get.

> Other than
> using infix notation, it looks nothing like any of the popular
> languages.  That's not surprising; Prolog almost entirely lacks
> explicit control structures, which are everywhere in conventional
> languages. 

Prolog has sequence and if->then;else.  What's missing?  Assignment
and `obvious' while-loops, which go together.

-- 
I agree with Jim Giles about many of the deficiencies of present UNIX.

A. Gaynor:
   The ability to handle variable numbers of arguments is a big win.
   Seriously affects readability and usability.  This feature should
   be provided by a clean (hell, transparant) syntax.

Note that LISP's ability to handle a variable number of arguments is
equivalent to an ability to handle one argument of arbitrary
complexity.  Further, it is (or should be) trivial to extend a
function which is associative, and takes two arguments, to a function
which takes an arbitrary number of arguments [or takes one argument
which is a list of arguments...].

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