Re: names for primitives (Was: Re: Accumulator)

[Alexander Schmolck <address@hidden>]

Michael Vanier <mvanier@cs.caltech.edu> writes:

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

Exactly, somehow this list hasn't been sufficiently anal so far ;)

> 
> 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"

Don't you think your students might have forgiven you, had you just written a
greek letter? (lamda, BTW, although not legal in scheme is at least a valid
alternative transliteration :)


> after a while.  "fn" or "fun" seems preferable to me (YMMV).  Haskell has a

Apart from the fact that I'd rather use "fn" as a variable name, it just seems
to me that a letter to sound mapping "fn->lambda" is a bit too much, even for
someone accustomed to the perversities of English orthography.  But maybe the
correct pronounciation really is "fun" (only Paul knows...)?

"Many Java programmers are unconfortable with the many funs characteristic of
arc code." :)

> nice solution using the backslash to represent lambda, BTW, but it doesn't
> lend itself cleanly to s-expression syntax.

Yep, the backslash notation is nice and seems to amortize the cost of a
special character, although an even better solution might be to have the
editor take care of the lambdas (apart from the obvious possibility of using
unicode, (X)emacs's x-symbol mode allows mapping ascii identifiers to fancy
symbols, which I think might be quite handy for a couple of programming
applications (read: doing math)).

> 
> 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

Well, not in Common lisp maybe, but if I don't have 7 or so namespaces, I'd
rather stick to car and cdr and not write:

(let ((fst ...)
      (rst ...) 
      ...)
  ...)

If anything sticks out a bit by looking slightly funny, it should surely be
the "primitives" rather than user defined names, that have been mutilated in
order to work around the fact that all natural options were already taken by
builtins or keywords.

> 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

well, even better still -- how about a slicing notation? :)

> 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 ;-)

I see -- no wonder that many lispers (like many japanese) seem to feel that
the subtleness of their ways is just beyond the comprehension of all outsiders
;)

> 
> 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.
> 

>From def(-)macro, def(-)struct etc., it would seem to me that "def" scales
just as fine as "define" :) 

I have no particular troubles with define, either, given that it is relatively
short, pronouncable and doesn't encroach on "user namespace" (unlike "from",
"end", "list", "first" etc.).

"dc", "df" etc. don't scale all that well in a 26 letter alphabet, but at
least unlike maybe "fn" and certainly "stpcpy" (and C's other horrors) you
don't suffer cognitive damage from the fact that it is utterly impossible to
map the jumble of letters to any meaningful vocalization.

OK, how about the following criteria for naming "primitives" then: 

Pronouncable, short, unambiguous to use in normal speech, scaleable (where
applicable) and not something that clashes with what users would very probably
like to use as a names for their own stuff?


alex

> 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
> > 
> > 
> 
> 

-- 
Alexander Schmolck     Postgraduate Research Student
                       Department of Computer Science
                       University of Exeter
A.Schmolck@gmx.net     http://www.dcs.ex.ac.uk/people/aschmolc/