pop@cs.umass.edu ( Robin Popplestone ) writes:
> Date: 15 Dec 92 14:00:38 GMT
> Organization: University of Massachusetts, Amherst
> .....
> Another thing I would like is a neat, concise syntax for anonymous
> functions. The old LAMBDA .......END construct was painful enough, without
> being replaced by procedure.....endprocedure. ML's fn <patt> => <body> is
> neat.
I think neatness (which includes conciseness and syntactic economy)
is the last thing that programming language designers should go for
if they are designing a language that is to be used for production
code on software projects where many thousands of lines of code are
to be produced by large and changing teams of programmers and
maintained over many years.
Any language to be used for that purpose should have a highly
redundant syntax that is easily parsed by human brains, including
people who are non-mathematicians.
ML is notoriously difficult for human brains to parse because it
uses an extraordinarily economical syntax requiring people to
remember precedences in order to read any expression going over more
than a few lines.
Lisp is nearly as bad - though at least the parentheses remove the
problem of grouping. But the shortage of keywords, especially
keywords in the middle of constructs, makes it difficult for people
to parse long expressions. E.g.
(( .... ) (....))
could mean all sorts of different things in different contexts and
is therefore far more ambiguous and liable to cause errors than
elseif .... then .....
> On a more radical note, I have been doing some C programming recently. Now
> as far as the semantics of C go, it feels rather like wiring one's house
> with bare copper. But one has to admit that the syntax has a certain
> concise elegance.
A similar objection can be made to C syntax: but it's not as bad as
Lisp or ML because what you can do in it is far more restricted, and
therefore the syntactic poverty matters less!
Try out a CPOP (Popsie is already spoken for)
>
> maplist(x,f) { x=[]?[]:f(x)::maplist(tl(x),f)}
This sort of compact definition is lovely for mathematicians, but
has the kind of conciseness that I think is dangerous in a language
to be used for large software projects.
> An interesting point is whether there is any way of getting rid of the
> distinction between application and partial application, which is not a
> fundamental distinction of the lambda calculus, but is only (there) an
> implementation issue.
Presumably because in lambda calculus application is itself just a
matter of textual substitution. As soon as one allows, in addition,
the notion of invoking an opaque sub-routine via its name plus some
input values, then surely the distinction between application and
partial application is unavoidable?
I'll leave it to others to comment on Robin's other comments!
Aaron
---
--
Aaron Sloman, School of Computer Science,
The University of Birmingham, B15 2TT, England
EMAIL A.Sloman@cs.bham.ac.uk OR A.Sloman@bham.ac.uk
Phone: +44-(0)21-414-3711 Fax: +44-(0)21-414-4281
|