Summarizing the named-let debate

[Pavel.pa@Xerox.COM]

My responses to today's rash of suggestions on this debate:

I agree with Guy; his defense of the name ``reclet'' (that C programmers seems
to get along with the names ``fmod'' and ``modf'') is pretty weak stuff.  Yuk,
indeed.

I found David Bartlett's arguments, concerning ``let'' being a binding
construct, very convincing.  I think that Arthur Gleckler made the completing
point of this argument, though, when he pointed out that the named variety of
let is also purely a binding form; it simply gives a name to one more thing than
an unnamed one.

If one simply must change the name, then I also support Arthur's suggestion
there: ``named-let''.

I don't like MarkF's names, ``lambda-let'' (or ``let-lambda'') since I see no
mnemonic value in these.  ``lambda'' is not the only control construct in
Scheme, so it is not a good representative for all control notions.

George Springer's idea to use ``bindlet'' seems wrong to me as well, since
``bind'' and ``let'' feel almost like synonyms to me.

The main argument for any change at all, however, seems to come from educators,
who claim that the idea of adding recursion to a purely binding form is odd to
students.  This claim seems odd to me.  What can be so hard about ``let'' being
an abbreviation for

	((lambda bvl . body) . args)

and named ``let'' simply adding one more binding into the expansion:

	((rec name (lambda bvl . body)) . args)

I'm not saying that these claims of pedagogical difficulty are false, just that
I don't yet understand the details of the problem.  Could one of the educators
(George? Kent?) please explain further just what the problem is?  It just seems
that exploiting the close correspondence above should work well to make the idea
clear.

Until I can understand the difficulty better, I am forced to continue my support
of the current named ``let'' syntax.

	Pavel