From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: Rationale behind conversion of a nil prefix arg to numeric 1 Date: Tue, 6 Sep 2016 08:22:53 -0700 (PDT) Message-ID: References: <87y437c0qg.fsf@bertrandrussell.Speedport_W_723V_1_40_000> <83oa43d9r8.fsf@gnu.org> <06d4a7f1-f116-fb5c-9bd2-c4d1f98934c9@easy-emacs.de> <83k2ercy5u.fsf@gnu.org> <83bn02cs54.fsf@gnu.org> <83ed1411-dbc1-2fe1-5fe9-4fdc7a4d1b21@online.de> <83shteb26t.fsf@gnu.org> <20160906071015.GB15537@tuxteam.de> <87inu98ipz.fsf@bertrandrussell.Speedport_W_723V_1_40_000> <87oa41yx8l.fsf@bertrandrussell.Speedport_W_723V_1_40_000> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1473175911 2729 195.159.176.226 (6 Sep 2016 15:31:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Sep 2016 15:31:51 +0000 (UTC) To: florian@fsavigny.de, help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Sep 06 17:31:45 2016 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhILb-00080U-H1 for geh-help-gnu-emacs@m.gmane.org; Tue, 06 Sep 2016 17:31:39 +0200 Original-Received: from localhost ([::1]:34406 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhILZ-0002vi-9m for geh-help-gnu-emacs@m.gmane.org; Tue, 06 Sep 2016 11:31:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhIDM-0003yN-5w for help-gnu-emacs@gnu.org; Tue, 06 Sep 2016 11:23:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhIDG-0002m5-3K for help-gnu-emacs@gnu.org; Tue, 06 Sep 2016 11:23:07 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:48692) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhIDF-0002lL-Pm for help-gnu-emacs@gnu.org; Tue, 06 Sep 2016 11:23:02 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u86FMu0O020436 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2016 15:22:56 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u86FMunw032655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Sep 2016 15:22:56 GMT Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u86FMtXP004472; Tue, 6 Sep 2016 15:22:55 GMT In-Reply-To: <87oa41yx8l.fsf@bertrandrussell.Speedport_W_723V_1_40_000> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:111292 Archived-At: > > IIUC `prefix-numeric-value' is a more complex thing than providing a > > repeat counter - which it does for lower p. >=20 > 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)= ) >=20 > Or, alternatively, (defun foo (counter) (interactive "p") ...) >=20 > 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. >=20 > 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: >=20 > Most Emacs commands can use a "prefix argument", a number > specified before the command itself. >=20 > 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.) >=20 > 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. >=20 > 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.