RE: Rationale behind conversion of a nil prefix arg to numeric 1

[Drew Adams <drew.adams@oracle.com>]

>   > IIUC `prefix-numeric-value' is a more complex thing than providing a
>   > repeat counter - which it does for lower p.
> 
> I thought I had understood that
>   (interactive (list (prefix-numeric-value current-prefix-arg)))
> was exactly the same as
>   (interactive "p")

It is.  You understand correctly.

> Or isn't it? Then I am really confused. (But a test I just ran seems
> to confirm that it is.)

+1 for testing.

>   > But let's go back to the simplest case of lower p in interactive spec:
>   > What is easier to read/grasp
>   > (setq counter (or arg 1)) or (setq counter (prefix-numeric-value arg))
> 
> Or, alternatively, (defun foo (counter) (interactive "p") ...)
> 
> But IIHUC, one would normally do it the way I have just sketched, and
> the idea of the "numeric prefix arg" was probably to supply an easy
> (i.e. short) way to use the prefix arg as a repeat counter. And if my
> example is correct, that solution isn't that bad.
> 
> BTW, I have just understood another interesting detail: That there
> ALWAYS is a prefix arg, even if the user does not supply one, and you
> do not have to say (defun foo (&optional counter) (interactive "p") ... )
> in the specific case where your optional arg is the prefix arg.

Correct.  Similarly for "P" (raw prefix arg), in which case the
value is nil if a user provided no prefix arg.

The point of &optional is for Lisp code.  With &optional you can
use (foo); without &optional you must use (foo nil) to get the
same effect.  (You can also use (foo 1) if "p" is the `interactive'
arg.)

Most functional (or nearly functional) languages do not allow
for an arbitrary number of arguments.  Instead, for the same
behavior as &rest, a function just accepts a list argument (in
effect, an explicit list of arguments).  Not a big difference,
really. Admittedly, the use of &optional and &rest arguments
can be surprising, and hence perhaps confusing at first.

> That, arguably, also adds idiosyncrasy.

I don't think this has anything to do with a prefix argument.
It's about &optional.  If you do not use &optional then the
argument is required.  If you use &optional it defaults to nil.
That's all.

>   > IOW: in favor of avoiding these complex, tricky things.
>   > Let's have the code as explicit as possible.

Whatever that means.  Pretty general/vague.

> I totally agree, but as Eli has pointed out, Elisp was designed the
> way it was designed a long while back.  I guess prefix args have been
> around almost since the very beginnings.  Changing something about very
> fundamental things like that would mean having to change A LOT OF very
> fundamental code, without breaking anything. The question then would
> simply be: Who is up for this job?

I don't think that was Eli's point.  I think his point was (and
at least it is my point) that the design is a good one.  It is
preferable to anything that's been suggested here and now.

> In other words, even though I like Emacs a lot, I think it is only
> fair to call Elisp idiosyncratic in some ways.

What do you mean by idiosyncratic, here?  The fact that Elisp has
some features that didn't know about or might not have dreamed up
yourself?

Emacs is different from other editors and UIs in many ways.  Does
that make it idiosyncratic?  Sure.  "Idiosyncratic" just means
individual, single, particular to the individual.  Anything with
original features is individual, a "special snowflake".  The same
is true of Elisp - or any Lisp: it is not what many people are
used to in a programming language.

If you think of "idiosyncratic" as "odd", then consider that
your (one's) notion of "odd" has a lot to do with what you are
used to.  If you are not used to recursion, anonymous functions,
functional-style, structural macros, etc. then Lisp is a very
odd animal.  If you are more used to a language like Lisp, SQL,
or Haskell then Fortran is a very odd animal.

> But if it is worth fixing these, I think, is simply what Eli
> might call a question for a rainy day.

I didn't see Eli suggesting that there was something here that
would benefit from "fixing" or "improving".  But perhaps I just
missed that.  In any case, I don't see such benefit.

There has been some hand-waving about "idiosyncrasy", but that
doesn't hold much water.

> I presume that the things that seem so idiosyncratic or somewhat
> obscure about Elisp (e.g. not only prefix args, but also the way lists
> are constructed, the reason why there are several kinds of sequences,
> obarrays) were not deliberately designed to be hard to understand (or
> to make Emacs privy to the initiated only), but that all had a lot to
> do with the technical limitations at the time.

No.  But it's not clear just what you have in mind.  Very few such
things are limited by the specific design/implementation of Elisp.
You will find them (but not prefix args, which have to do with
commands) in other Lisps as well.

> (Meaning there was perhaps not even a real alternative.)

Don't assume so.  But again, it's not clear just what you're
referring to.

> So now they are there, and changing them now would have very
> different consequences than deciding on a feature when you
> design a language anew has.

Be specific about which features you are talking about, please.

Sure, Emacs and Emacs Lisp have a fair amount of baggage -
vestigial thingies - for hysterical raisins.  But my impression
is that the things that you have mentioned so far, and find odd,
are not among them.  They are _not_ just a bunch of vestiges that
users would love to get rid of but which would require a lot of
work to do.

There are such things in the Emacs implementation, no doubt.
But I don't see any such having been brought up in this thread.

Don't fall into the trap of assuming that just because either:

1) Something is new to you, or
2) Something has been around for a long time in Emacs, and is
   different from what you see elsewhere,

that that something is just an unfortunate vestige that Emacs
users and developers would love to get rid of if it were easy
to do so.

More likely, it is a fine feature that you might do well to
learn more about.  The Emacs prefix argument is a case in point.
Or it might just be a so-so choice that has little positive or
negative consequence - nothing special, nothing awful.

> (FWIW, I think this is precisely the reason why Larry Wall decided to
> break compatibility between Perl 5 and Perl 6, making Perl 6 simply a
> new language. Accidently, one of the design goals of Perl 6 was: being
> more intuitive than Perl 5.)

Getting too vague.

> On the other hand, when I read the node "Command Loop -> Prefix
> Command Arguments" in the Elisp Manual, I wonder how anyone CANNOT be
> confused about prefix args, because this node starts out with the
> unfortunate sentence:
> 
>     Most Emacs commands can use a "prefix argument", a number
>     specified before the command itself.
> 
> If I am not mistaken, this promotes precisely the misunderstanding
> that I had fallen prey to.

The presentation in the manual stresses the numeric prefix arg
a bit too much, for my taste.  A first reading can give the
impression that that's all there is to it.  The Elisp manual
does not have this problem (IMO).

But if you have concrete suggestions for the manuals, consider
offering them via `M-x report-emacs-bug'.  Sometimes Emacs Dev
will agree with your suggested change.  Sometimes you will learn
that the current text is in fact better than what you thought.
And sometimes you will agree to disagree.  ("You win some; you
lose some; and some are rained out.")

> In contrast, other unintuitive features of Elisp

It's not about intuition (ever).  It's about something new.
Or sometimes it's about something cumbersome or inconvenient.

> are quite well explained in the manual. (List construction --
> the cons cell stuff -- and sequences are two things I remember
> understanding quite readily from reading it, and in both cases
> it would never have occurred to me to intuitively assume they
> worked like that.)
> 
> Maybe it would be a good idea if somebody simply rewrote some of the
> /documentation/ on prefix args, such that the innocent, naive user
> understands the point of the two representations? Because that is
> something that can be easily rewritten without breaking any code.
> 
> I'll volunteer for the job if somebody checks!

Please do!  `M-x report-emacs-bug'.  You can suggest alternative
text to use or any other changes you see fit.  You can even
provide doc patches.  Suggestions are always welcome.  A report
need not propose a solution (alternative text).  Just letting
Emacs developers know that you found a particular passage unclear
can help.  And if you can say why, so much the better.