🚀 go-pugleaf

In article <18747:Jan220:02:1091@kramden.acf.nyu.edu>
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:

>Huh? Who cares? To get an unnamed function you just have to declare the
>function and not use its name. The fact that you can't write an unnamed
>function is not a problem for programmers.

	Well, it *is* a problem.  You have to invent a name.  Whether
that is a *serious* problem depends on how many of these things there
are, and on how inventive the programmers are, but having programs
liberally bespattered with f1, f2, f3, ..., f17, ..., f923, ... really
isn't very pretty.  What's more, in many languages, including C and
Pascal, the declarations of f1 and its friends cannot usually be put
close to their uses, which means that when you encounter something like

	z = 2 * sin (theta) * integral (f17, 0, pi) + ... f18, etc, ...;

in a program, you're forever scanning around trying to find out what
f17, f18, ... mean.  If declarations *can* be put close to uses, then
we get something like

	{ float f17 (float x) { return blah; },
		f18 (...),
		...;
	  z = ...; }

which is better, but why *not* allow

	z = 2 * sin (theta) * integral ((float x)(blah), 0, pi) + ...;

(or some such)?  [A quick flip through some dusty decks reveals many,
many such anonymous procedures in my own programming practice, and very
convenient they were, too, in a wide variety of applications.]

>This is just another example of why syntax is a lot less important than
>semantics.

	That's a matter of semantics! [:-)]

	Firstly, the line between the two is distinctly blurred.  For
example, is the restriction that you can't declare the same identifier
twice in the same declaration syntactic or semantic?  Are the C
pointer/array relationships syntax or semantics?  One could put forward
respectable arguments either way.

	Secondly, the syntax seriously influences the "software
engineering" quality of a language.  For example, in C, you have a
good chance of getting a procedure and everything you need to know
to understand it onto one screen;  in Pascal, this is very frequently
impossible, both because of the verbosity of Pascal and because of the
restrictions on order of declaration;  in APL, a screenful of code is
likely to be impossible to understand [:-)].

	To be effectively used, a language must be both powerful
(within its chosen problem domain) and understandable (to the
appropriate users).  Both syntax and semantics (wherever the line
is drawn) are absolutely vital for this.

-- 
Andy Walker, Maths Dept., Nott'm Univ., UK.
anw@maths.nott.ac.uk