names for primitives (Was: Re: Accumulator)

[Michael Vanier <address@hidden>]

Now *here's* a deeply meaningful discussion to jump into ;-)

Personally, I dislike the word "lambda", but maybe that's been colored by
my experiences teaching scheme where I had to write the word "lambda" over
and over again on a blackboard -- it tends to mutate to "lamda" or "lamdba"
after a while.  "fn" or "fun" seems preferable to me (YMMV).  Haskell has a
nice solution using the backslash to represent lambda, BTW, but it doesn't
lend itself cleanly to s-expression syntax.

However, I *do* like "cons", "car" and "cdr".  "cons" is certainly easier
to say than "make-pair", and the terms "cons-cell" and "consing" are
sufficiently engrained that there seems no reason not to use them.  "car"
and "cdr" are not necessarily superior to "first" and "rest", but it's a
lot easier to say "cdadr" (cuh-DAD-er) than "rfrest" as is pointed out in
SICP.  Of course, you can also define "second", "third", etc. and
presumably also "third-to-end", "fourth-to-end" etc. and maybe that would
be better, at the cost of adding lots of terms to your namespace.  One
non-obvious advantage of the car/cdr system is that when the composite word
(e.g. "cadddr") becomes hard to pronounce, you're probably programming the
wrong way ;-)

In most cases, though, I prefer real words.  I like scheme's "define" over
python's "def" or goo's two-letter abbreviations ("dc", "dm", "df" etc.).
"define" also scales nicely to "define-syntax", "define-class",
"define-macro" etc. and all those words are easy to interpret.

Mike




> From: Alexander Schmolck <a.schmolck@gmx.net>
> Date: 25 May 2002 04:06:22 +0100
> 
> Paul Prescod <paul@prescod.net> writes:
> 
> > "A.Schmolck" wrote:
> > 
> > At the very least, the name of the operator is brain-dead. We might as
> > well add give functions meaningless names like "cdr" and "creat". ;)
> 
> You know, I actually think "lambda", "cons" and maybe even "car" and "cdr" are
> pretty good names (better than Paul Grahams "fn", for example -- I'd rather
> use a greek letter if shortness is that important). They are short,
> unambigious (and with the exception of cdr -- for the unitiated :)
> pronounceable. I have the feeling that programming languages need two
> fundamentally different sorts of names -- names for "primitives" (cons) and
> names for "composites" ("makeImageButton"), but that most end up
> inappropriately using mainly either one for both. By "primitive" I mean part
> of the conceptual machinery of a language -- essentially something new, that
> you have to learn from scratch in order to understand the language. Lisp's
> "cons" is a prime example. Sticking a name you can find in a dictionary on it
> (or a "phrase") doesn't help this learning process in the least, it might even
> be unhelpful, because new basic concepts need names and these names should
> either novel or *remote* enough metaphors to be unambiguous and clear.
> 
> Lispers can for example say that this implementation avoids uncessary cons'ing
> (cf. "pairing") and I doubt whether people on a future ll22 mailing list will
> ever talk of "fn"s rather than lambdas, even if Paul Grahams arc rules the
> programming world in a couple of years :)
> 
> On the other hand, I firmly belief that names for things that are not
> conceptually primitive should have good descriptive names (which may well be
> long, especially if they are not often used) because here it not only helps
> guessing what they do but also memorizing and looking them up (emacs,
> e.g. would be pretty much unusable without such naming conventions and I rely
> deplore tempnam and similar C gruft in many python modules).
> 
> 
> >[...]
> > > Yes, I agree that for many cases comprehensions can be clearer, but I also
> > > think for many they aren't, notably when you've got more than one sequence:
> > > 
> > >       map(add, xs, ys)
> > > 
> > > is, to me, better than:
> > > 
> > >     [x + y for (x,y) in zip(xs,ys)]
> > 
> > I think it's just a matter of which you learned first. zip is useful to
> > know for other contexts anyhow.
> 
> Zip is easily the python function I like best (for one thing, because it
> allows elegant uses of infinite sequences), so I would be even willing to
> sacrifice map if it would bring more people closer to the wonders of zip :)
> I'd suspect that people who like map, reduce and filter will also like zip and
> vice versa, though.
> 
> > 
> > > ...
> > > in fact, as long I have a ready-made function, I'd prefer map:
> > > 
> > >    map(str, args)
> > 
> > Given that it exists, maybe. If we were creating the language from
> > scratch? I don't think so.
> > 
> > > Also, this style of programming naturally extends to lazy sequences (if you
> > > define things like, say xzipWith etc.), dictionaries and other scenarios that
> > > you can't accommodate with comprehensions or that are awkward and ugly with
> > > loops (e.g. reduce'ing). 
> > 
> > Python will probably grow dictionary comprehensions and lazy
> > comprehensions when there is enough demand.
> 
> Well, I hope you don't take it too badly if I tell you that I remember Guido's
> latest pronouncement on lazy and dict comprehensions as something along the
> lines of: "Not needed -- but maybe I should add _macros_ to the language to
> allow people to cook them up themselves" :)
> 
> > 
> > >...
> > > clearer. Of course 'clear' also depends how used one is to a certain style of
> > > coding (e.g. do you find ``reduce(operator.getitem, pos, tree)`` clear? I
> > > certainly do).
> > 
> > I never use reduce, so no.
> > 
> > node = tree
> > for curpos in pos:
> > 	node = node[pos]
>                     ^^^ 
> Thanks for demonstrating my point :)
> [about loops being more error-prone than functional constructs]
> 
> To me, this for loop is in a way a human-compiled version of the above reduce
> expression (which maps well at least to my mental conceptualization of the
> operation), and humans just aren't very good compilers ;)
> 
> > 
> > When I write code I always have in the back of my mind whether an
> > occasional Python programmer could follow it. I will use an advanced
> > feature if it dramatically simplifies the code. Otherwise, I will avoid
> > it. Few people would agree with me that that is worth spending effort
> > on. I happen to consider both "reduce" and "operator.getitem" advanced
> > features.
> 
> Depending on the audience of the code this can certainly be a reasonable thing
> to do (if you write a symbolic math package, it's presumably not
> worthwhile). But I also think there are different kinds of "advanced" features
> -- some things are just more or less language specific shortcuts, acronyms if
> you want (and Perl is full of them). Other things are powerful *concepts* (and
> I personally think reduce qualifies as such) -- they allow you to *see* things
> differently, rather than just to write more concise code. Leaving out
> shorthands does little harm, apart from a negligible cost in time for you
> writing the code and for other expert programmers reading it. But by not using
> powerful concepts you are also depriving readers of your code of the chance to
> get smarter, so there is at least chance that you unwittingly patronize some
> of your readers, rather than doing them a favour (I was really chuffed, for
> example when I found out about zip(*foo)).
> 
> > 
> >  Paul Prescod
> > 
> > 
> 
> alex
> 
>