Re: various recent ll1 threads

[Dave Long <address@hidden>]

> Generally, pretty much any function whose domain is sets or lists of
> some type can be expressed in terms of a reduction with a binary
> function.

Note that Sitaker's:
	return list + [f(item)]
is Graham's:
	(keep (f item))
and Graham's:
	(sum (f item))
would have been Sitaker's:
	return acc + f(item)

I prefer to see both (keep x) and
(sum x); a foolish parsimony might
lead us to only (keep x), since we
could then recover sum's effect by 
keep'ing scratch values and taking
the size of the resulting tree.

[But have I misinterpreted sum?  It
looks like pg may not care to count
with only the naturals]

-Dave

::::::::::::

> A good little language knows its negative space well up-front.

Good little languages don't know the value
of everything but the cost of nothing?

> This seems to contradict another unassailable bit of wisdom, which is
> that no little language stays little for too long.

More counterexamples, if they count as LL:
awk and sed.

Awk has dynamic variables, but its control
flow is so regular that it isn't meant for
making multiple passes over an input.  Sed
can reprocess inputs with wild abandon, but
its hold space isn't meant for keeping much
in the way of state.  Both have niches, and
(perhaps due to Perl?) seem to have avoided
the temptation to grow beyond them.

They are also counterexamples for Perlis:

There are many awk programs worth writing
without (explicit) loops.  There are many
sed programs worth writing without complex
variables.

::::::::::::

> ... endlessly hash old arguments about how to write 2+1 ...

I agree there are more important things in
language design.  Is arguing about how to
write 2+1 like arguing over how many angels
can dance on the head of a pin?

Put that way, both arguments sound silly.
However, the medieval argument was really
about whether one can cover a (finite) pin
with (infinitesimal) angels, and if so, an
infinite or finite number of them?  Viewed
in that manner, we can see a precursor to
the calculus.

Similarly, the origin of this 2+1 debate
lies in the assertion:

a)	little languages require macros, and
b)	macros require prefix notation

with an obvious inference, if the truth of
both can be demonstrated.  So even though
we may not recover anything as powerful as
the calculus, at least we've argued about
something more than "which end of the egg".

>                                                        I know language
> designers often don't think about 'modeling' or 'design and analysis'
> but it seems like a big loss to me.

Sometimes may not be often, but:
Hoare, "Hints on Programming Language Design"
> If a programming language is regarded as a tool to aid the programmer,
> it should give him the greatest assistance in the most difficult
> aspects of his art, namely program design, documentation, and
> debugging.