* Re: Why is booleanp defined this way? [not found] <mailman.946.1429302909.904.help-gnu-emacs@gnu.org> @ 2015-04-17 20:55 ` Pascal J. Bourguignon 2015-04-17 23:20 ` Barry Margolin 2015-04-18 2:01 ` Rusi 2 siblings, 0 replies; 33+ messages in thread From: Pascal J. Bourguignon @ 2015-04-17 20:55 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski <mbork@mbork.pl> writes: > Hi all, > > this is what I found in subr.el: > > ,---- > | (defun booleanp (object) > | "Return t if OBJECT is one of the two canonical boolean values: t or nil. > | Otherwise, return nil." > | (and (memq object '(nil t)) t)) > `---- > > Seemingly, it doesn't make much sense: what is the purpose of saying > > (and (whatever) t) > > instead of just > > (whatever) > > for a predicate? Of course, this "normalizes" any "truthy" value to > "t", but is it really needed for anything (except perhaps being > elegant)? There's a difference between a boolean and a generalized boolean. Also notice how the docstrings give the SPECIFICATION of the function: (defun booleanp (object) "Return t if OBJECT is one of the two canonical boolean values: t or nil. Otherwise, return nil." (and (memq object '(nil t)) t)) (defun generalized-booleanp (object) "Return t if OBJECT is a generalized boolean, otherwise return nil" t) ; all the lisp objects are generalized booleans, by definition! (defun truep (generalized-boolean) "Return t if GENERALIZED-BOOLEAN is true, nil otherwise." (and generalized-boolean t)) (defun falsep (generalized-boolean) "Return t if GENERALIZED-BOOLEAN is false, nil otherwise." (null generalized-boolean)) Obviously, the last three functions are idiotic, given that almost all the boolean lisp operators actually take generalized boolean, and that there is already NULL and NOT doing the same job as the last. You don't write: (if (truep (member fruit '(apple banana))) 'fruit 'vegetable) you write: (if (member fruit '(apple banana)) 'fruit 'vegetable) Also a little trick to obtain a boolean from a generalized boolean, instead of (and … t), is to use the double negation: (not (not …)). Arguably, not being a function it could be slower, but a sufficiently smart compiler should be able to generate the same code, or in the case of emacs lisp virtual machine, produce actually shorter byte code, since not is a virtual machine instruction: (defun f (x) (and x t)) (disassemble (byte-compile 'f)) byte code: args: (x) 0 varref x 1 goto-if-nil-else-pop 1 4 constant t 5:1 return (defun g (x) (not (not x))) (disassemble (byte-compile 'g)) byte code: args: (x) 0 varref x 1 not 2 not 3 return But this is really nit-picking. -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? [not found] <mailman.946.1429302909.904.help-gnu-emacs@gnu.org> 2015-04-17 20:55 ` Why is booleanp defined this way? Pascal J. Bourguignon @ 2015-04-17 23:20 ` Barry Margolin 2015-04-17 23:30 ` Emanuel Berg 2015-04-18 2:01 ` Rusi 2 siblings, 1 reply; 33+ messages in thread From: Barry Margolin @ 2015-04-17 23:20 UTC (permalink / raw) To: help-gnu-emacs In article <mailman.946.1429302909.904.help-gnu-emacs@gnu.org>, Marcin Borkowski <mbork@mbork.pl> wrote: > Hi all, > > this is what I found in subr.el: > > ,---- > | (defun booleanp (object) > | "Return t if OBJECT is one of the two canonical boolean values: t or nil. > | Otherwise, return nil." > | (and (memq object '(nil t)) t)) > `---- > > Seemingly, it doesn't make much sense: what is the purpose of saying > > (and (whatever) t) > > instead of just > > (whatever) > > for a predicate? Of course, this "normalizes" any "truthy" value to > "t", but is it really needed for anything (except perhaps being > elegant)? I guess they felt that the result of booleanp should *be* booleanp. :) While it probably doesn't matter when you're using it in a program, since you'll usually be using it as part of a conditional operator (if, cond, when), they might have felt it would be confusing when people used it interactively: (booleanp nil) => (nil t) (booleanp t) => (t) (booleanp something-else) => nil As a general convention, predicates usually just return t or nil, unless there's a useful non-nil value to return when it's true. In the case of memq, returning the tail of the list starting with the match was felt to be useful. But it's hard to see how returning those little lists instead of t would be helpful to anyone calling booleanp. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-17 23:20 ` Barry Margolin @ 2015-04-17 23:30 ` Emanuel Berg 2015-04-18 0:43 ` Pascal J. Bourguignon 2015-04-18 3:12 ` Barry Margolin 0 siblings, 2 replies; 33+ messages in thread From: Emanuel Berg @ 2015-04-17 23:30 UTC (permalink / raw) To: help-gnu-emacs Barry Margolin <barmar@alum.mit.edu> writes: > (booleanp nil) => (nil t) > (booleanp t) => (t) > (booleanp something-else) => nil Really? This is what I get: (booleanp nil) ; t (booleanp t) ; t (booleanp 1) ; nil And they are not lists: (listp (booleanp nil)) ; nil (listp (booleanp t)) ; nil -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-17 23:30 ` Emanuel Berg @ 2015-04-18 0:43 ` Pascal J. Bourguignon 2015-04-18 3:13 ` Barry Margolin 2015-04-18 3:12 ` Barry Margolin 1 sibling, 1 reply; 33+ messages in thread From: Pascal J. Bourguignon @ 2015-04-18 0:43 UTC (permalink / raw) To: help-gnu-emacs Emanuel Berg <embe8573@student.uu.se> writes: > Barry Margolin <barmar@alum.mit.edu> writes: > >> (booleanp nil) => (nil t) >> (booleanp t) => (t) >> (booleanp something-else) => nil And even if that was true, that would still be a valid implementation, since both (nil t) and (t) are generalized booleans that are true! But it is probably better that (booleanp (booleanp object)) be true too. -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 0:43 ` Pascal J. Bourguignon @ 2015-04-18 3:13 ` Barry Margolin 0 siblings, 0 replies; 33+ messages in thread From: Barry Margolin @ 2015-04-18 3:13 UTC (permalink / raw) To: help-gnu-emacs In article <87k2xamfkg.fsf@kuiper.lan.informatimago.com>, "Pascal J. Bourguignon" <pjb@informatimago.com> wrote: > Emanuel Berg <embe8573@student.uu.se> writes: > > > Barry Margolin <barmar@alum.mit.edu> writes: > > > >> (booleanp nil) => (nil t) > >> (booleanp t) => (t) > >> (booleanp something-else) => nil > > And even if that was true, that would still be a valid implementation, > since both (nil t) and (t) are generalized booleans that are true! That's what I said in my post. When used in a boolean context, a generalized boolean is fine. But it would be confusing when used in a REPL. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-17 23:30 ` Emanuel Berg 2015-04-18 0:43 ` Pascal J. Bourguignon @ 2015-04-18 3:12 ` Barry Margolin 1 sibling, 0 replies; 33+ messages in thread From: Barry Margolin @ 2015-04-18 3:12 UTC (permalink / raw) To: help-gnu-emacs In article <87lhhqnxip.fsf@debian.uxu>, Emanuel Berg <embe8573@student.uu.se> wrote: > Barry Margolin <barmar@alum.mit.edu> writes: > > > (booleanp nil) => (nil t) > > (booleanp t) => (t) > > (booleanp something-else) => nil > > Really? This is what I get: > > (booleanp nil) ; t > (booleanp t) ; t > (booleanp 1) ; nil I know. I was showing what you would get if it didn't use (and ... t) to canonicalize the value. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? [not found] <mailman.946.1429302909.904.help-gnu-emacs@gnu.org> 2015-04-17 20:55 ` Why is booleanp defined this way? Pascal J. Bourguignon 2015-04-17 23:20 ` Barry Margolin @ 2015-04-18 2:01 ` Rusi 2015-04-18 2:23 ` Emanuel Berg 2015-04-18 3:50 ` Pascal J. Bourguignon 2 siblings, 2 replies; 33+ messages in thread From: Rusi @ 2015-04-18 2:01 UTC (permalink / raw) To: help-gnu-emacs On Saturday, April 18, 2015 at 2:05:11 AM UTC+5:30, Marcin Borkowski wrote: > Hi all, > > this is what I found in subr.el: > > ,---- > | (defun booleanp (object) > | "Return t if OBJECT is one of the two canonical boolean values: t or nil. > | Otherwise, return nil." > | (and (memq object '(nil t)) t)) > `---- > > Seemingly, it doesn't make much sense: what is the purpose of saying > > (and (whatever) t) > > instead of just > > (whatever) > > for a predicate? Of course, this "normalizes" any "truthy" value to > "t", but is it really needed for anything (except perhaps being > elegant)? > > Best, Elisp does not have a proper boolean type; unlike say symbols with symbolp, strings with stringp, numberp -- some union of numeric types etc. However programmers need boolean in their ontology even if (and even more if) the language does not support it. I'd say booleanp is a hesitant step towards supporting boolean in the ontology without supporting it in the language. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 2:01 ` Rusi @ 2015-04-18 2:23 ` Emanuel Berg 2015-04-18 2:33 ` Rusi 2015-04-18 3:50 ` Pascal J. Bourguignon 1 sibling, 1 reply; 33+ messages in thread From: Emanuel Berg @ 2015-04-18 2:23 UTC (permalink / raw) To: help-gnu-emacs Rusi <rustompmody@gmail.com> writes: > Elisp does not have a proper boolean type; unlike > say symbols with symbolp, strings with stringp, > numberp -- some union of numeric types etc. > However programmers need boolean in their ontology > even if (and even more if) the language does not > support it. I never used `booleanp' and I never experienced that the boolean built-in type was missing from my "ontology". I think one asset with Lisp compared to for example C is that you don't have to bother with types. The predicates aren't types in the sense stating the types in declarations and function definition argument lists etc. as in C. That's just tedious and it makes you focus on details of technology rather than solving your problem. (But I like C as well.) Rather the predicates add the flexibility to be able to do different thing depending on the nature of the data. One can see many applications... Compare this to the generic classes of C++ where it would instantly turn into a jungle, not to mention the C pointers. But no one said you should do "Lisp" in C. If you did "C" in Lisp, even Lisp wouldn't be good. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 2:23 ` Emanuel Berg @ 2015-04-18 2:33 ` Rusi 2015-04-18 2:55 ` Emanuel Berg 2015-04-18 4:09 ` Pascal J. Bourguignon 0 siblings, 2 replies; 33+ messages in thread From: Rusi @ 2015-04-18 2:33 UTC (permalink / raw) To: help-gnu-emacs On Saturday, April 18, 2015 at 7:48:56 AM UTC+5:30, Emanuel Berg wrote: > Rusi writes: > > > Elisp does not have a proper boolean type; unlike > > say symbols with symbolp, strings with stringp, > > numberp -- some union of numeric types etc. > > However programmers need boolean in their ontology > > even if (and even more if) the language does not > > support it. > > I never used `booleanp' and I never experienced that > the boolean built-in type was missing from my > "ontology". If you how to write (and grok) an 'if' you have boolean in your ontology. That you dont know that you know is ok; most programmers dont get that their 'thinking language' is a superset of their programming language. eg When we were students we learnt flowcharts (or flawcharts) Most today's kids think thats irrelevant but then they think UML is relevant. The Dijkstra school would tout logic The FP school will tout lambda calculus (or dependent types) Even the box-and-arrow diagrams of classic data structures books goes beyond the language the book claims to be using ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 2:33 ` Rusi @ 2015-04-18 2:55 ` Emanuel Berg 2015-04-18 3:11 ` Barry Margolin ` (2 more replies) 2015-04-18 4:09 ` Pascal J. Bourguignon 1 sibling, 3 replies; 33+ messages in thread From: Emanuel Berg @ 2015-04-18 2:55 UTC (permalink / raw) To: help-gnu-emacs Rusi <rustompmody@gmail.com> writes: >> I never used `booleanp' and I never experienced >> that the boolean built-in type was missing from my >> "ontology". > > If you how to write (and grok) an 'if' you have > boolean in your ontology. That you dont know that > you know is ok I know what a *boolean* is, just not why I would need a built-in data type to express it. > most programmers dont get that their 'thinking > language' is a superset of their > programming language. Meanwhile, most university people don't get that programming languages are tools that should be employed to do useful things, not runes to be analyzed like some Noam Chomsky/Indiana Jones would the paleo-Etruscan from half-disintegrated tomb stones! > Most today's kids think thats irrelevant but then > they think UML is relevant. The Dijkstra school > would tout logic The FP school will tout lambda > calculus (or dependent types) Even the box-and-arrow > diagrams of classic data structures books goes > beyond the language the book claims to be using The worst part of all that is that if you do it enough you start to like it. It is sneaky. Then you can never move on. If kids think UML is relevant all hope is gone. But I don't think they do - not those with style. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 2:55 ` Emanuel Berg @ 2015-04-18 3:11 ` Barry Margolin 2015-04-18 3:35 ` Rusi 2015-04-18 21:24 ` Emanuel Berg 2015-04-18 7:52 ` Marcin Borkowski [not found] ` <mailman.997.1429343558.904.help-gnu-emacs@gnu.org> 2 siblings, 2 replies; 33+ messages in thread From: Barry Margolin @ 2015-04-18 3:11 UTC (permalink / raw) To: help-gnu-emacs In article <87d2322li0.fsf@debian.uxu>, Emanuel Berg <embe8573@student.uu.se> wrote: > Rusi <rustompmody@gmail.com> writes: > > >> I never used `booleanp' and I never experienced > >> that the boolean built-in type was missing from my > >> "ontology". > > > > If you how to write (and grok) an 'if' you have > > boolean in your ontology. That you dont know that > > you know is ok > > I know what a *boolean* is, just not why I would need > a built-in data type to express it. It's not a built-in type. It's a conceptual type, like "list". -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 3:11 ` Barry Margolin @ 2015-04-18 3:35 ` Rusi 2015-04-18 4:56 ` Barry Margolin 2015-04-19 23:00 ` Emanuel Berg 2015-04-18 21:24 ` Emanuel Berg 1 sibling, 2 replies; 33+ messages in thread From: Rusi @ 2015-04-18 3:35 UTC (permalink / raw) To: help-gnu-emacs On Saturday, April 18, 2015 at 8:41:19 AM UTC+5:30, Barry Margolin wrote: > Emanuel Berg wrote: > > > Rusi writes: > > > > >> I never used `booleanp' and I never experienced > > >> that the boolean built-in type was missing from my > > >> "ontology". > > > > > > If you how to write (and grok) an 'if' you have > > > boolean in your ontology. That you dont know that > > > you know is ok > > > > I know what a *boolean* is, just not why I would need > > a built-in data type to express it. > > It's not a built-in type. It's a conceptual type, like "list". Ha! Ha!! What a fantastic one-line summary-example of what I was trying to say! I always marvel at how Lisp puns on the word 'list': - Sometimes 'normal' lists -- like arrays in other languages - Sometimes heterogeneous -- like structs - Sometimes recursive structured -- aka trees - Sometimes homoiconic -- code=data - And yet at bottom they are just s-expressions -- the barest possible binary tree -- each internal node containing nothing but subtrees And so -- to expand a little on what you are saying: -- Getting lisp limited to the formal language definition is nothing more than getting the defs of car/cdr/null/nil/cons -- Getting lisp as a lisp programmer means getting all the above and more, making Eric Raymond's mystical sounding quote quite literal: | Lisp is worth learning for the profound enlightenment experience you will | have when you finally get it; that experience will make you a better | programmer for the rest of your days, even if you never actually use Lisp | itself a lot. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 3:35 ` Rusi @ 2015-04-18 4:56 ` Barry Margolin 2015-04-19 23:08 ` Emanuel Berg 2015-04-19 23:00 ` Emanuel Berg 1 sibling, 1 reply; 33+ messages in thread From: Barry Margolin @ 2015-04-18 4:56 UTC (permalink / raw) To: help-gnu-emacs In article <b006075a-9af5-4624-ab5b-c31e8e29f627@googlegroups.com>, Rusi <rustompmody@gmail.com> wrote: > On Saturday, April 18, 2015 at 8:41:19 AM UTC+5:30, Barry Margolin wrote: > > Emanuel Berg wrote: > > > > > Rusi writes: > > > > > > >> I never used `booleanp' and I never experienced > > > >> that the boolean built-in type was missing from my > > > >> "ontology". > > > > > > > > If you how to write (and grok) an 'if' you have > > > > boolean in your ontology. That you dont know that > > > > you know is ok > > > > > > I know what a *boolean* is, just not why I would need > > > a built-in data type to express it. > > > > It's not a built-in type. It's a conceptual type, like "list". > > Ha! Ha!! What a fantastic one-line summary-example of what I was trying to > say! > > I always marvel at how Lisp puns on the word 'list': > - Sometimes 'normal' lists -- like arrays in other languages > - Sometimes heterogeneous -- like structs > - Sometimes recursive structured -- aka trees > - Sometimes homoiconic -- code=data > - And yet at bottom they are just s-expressions -- the barest possible binary > tree -- each internal node containing nothing but subtrees > > And so -- to expand a little on what you are saying: > -- Getting lisp limited to the formal language definition is nothing more > than > getting the defs of car/cdr/null/nil/cons > -- Getting lisp as a lisp programmer means getting all the above and more, > making Eric Raymond's mystical sounding quote quite literal: > > | Lisp is worth learning for the profound enlightenment experience you will > | have when you finally get it; that experience will make you a better > | programmer for the rest of your days, even if you never actually use Lisp > | itself a lot. Indeed. I remember when I first learned Lisp. After having programmed mainly in BASIC and Assembly until then, it forced me to learn entirely new levels of abstraction. But once it clicked, I was forever changed. I don't think it's saying too much to say that going through that process has made it easier for me to learn all the new languages since then. It's kind of related to Greenspun's Rule that any sufficiently complicated program contains an ad hoc implementation of Lisp. If you take a look at most modern programming languages (Perl, PHP, Python, C++), you can see all the Lisp influences (closures and lexical scope, object references) -- the only thing they refuse to adopt are Lisp-style macros and of course the parenthesized Polish notation. -- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 4:56 ` Barry Margolin @ 2015-04-19 23:08 ` Emanuel Berg 0 siblings, 0 replies; 33+ messages in thread From: Emanuel Berg @ 2015-04-19 23:08 UTC (permalink / raw) To: help-gnu-emacs Barry Margolin <barmar@alum.mit.edu> writes: > If you take a look at most modern programming > languages (Perl, PHP, Python, C++) Lisp - 1958 C++ - 1983 Perl - 1987 Python - 1991 PHP - 1995 -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 3:35 ` Rusi 2015-04-18 4:56 ` Barry Margolin @ 2015-04-19 23:00 ` Emanuel Berg 1 sibling, 0 replies; 33+ messages in thread From: Emanuel Berg @ 2015-04-19 23:00 UTC (permalink / raw) To: help-gnu-emacs Rusi <rustompmody@gmail.com> writes: > Eric Raymond's ... quote ... > > Lisp is worth learning for the profound > enlightenment experience you will have when you > finally get it; that experience will make you > a better programmer for the rest of your days, > even if you never actually use Lisp itself > a lot. That is true because there is a hierarchy of tool power (perhaps Rusi would call it "expressioness" or something like that). When you have to some extent acquired what is at the top of the food-chain then what is below is easy. But it cannot be *too* down below because then you will just be frustrated that you are so hampered. Also, I don't agree Lisp is more difficult to learn. On the contrary, I think Elisp in particular is easy to acquire because of the dynamic nature of the editor and what you do with it. You do small things which you can evaluate instantly so not to waste time on huge recompilations, Makefiles, and such (to correct small bugs), you just do small things the worth of which can be "evaluated" instantly. The success story of computers - you use the computer to improve your use of the computer - which is the reason for its exponential growths just as much as cheap sand to make transistors - this is undoubtedly there in compiled C in principle just as much, but in Elisp it is super-tangible. So try the new Elisp Ultra. Probably about 25% more efficient :) -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 3:11 ` Barry Margolin 2015-04-18 3:35 ` Rusi @ 2015-04-18 21:24 ` Emanuel Berg 1 sibling, 0 replies; 33+ messages in thread From: Emanuel Berg @ 2015-04-18 21:24 UTC (permalink / raw) To: help-gnu-emacs Barry Margolin <barmar@alum.mit.edu> writes: >>>> I never used `booleanp' and I never experienced >>>> that the boolean built-in type was missing from >>>> my "ontology". >>> If you how to write (and grok) an 'if' you have >>> boolean in your ontology. That you dont know that >>> you know is ok >> I know what a *boolean* is, just not why I would >> need a built-in data type to express it. > It's not a built-in type. It's a conceptual type, > like "list". You misunderstand. I said what I thought the function to be: type predicate, not normalizer of booleans. Then I hear there is a general need for the boolean type in programming. I also hear that the type predicate is a way, the first step, to bridge that hole in Elisp. I say there is no need for a boolean type. Now Mr. Adams have impressed us all by his practical resourcefulness by greping the Emacs source for the function and found that this type predicate is used very rarely and for a likewise small domain of tasks. Conclusion: Counter-intuitive the seemingly general purpose of the predicate, there is no corresponding implementation field, so the statement that it is a patch for a missing cornerstone in programming in general is incorrect. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 2:55 ` Emanuel Berg 2015-04-18 3:11 ` Barry Margolin @ 2015-04-18 7:52 ` Marcin Borkowski [not found] ` <mailman.997.1429343558.904.help-gnu-emacs@gnu.org> 2 siblings, 0 replies; 33+ messages in thread From: Marcin Borkowski @ 2015-04-18 7:52 UTC (permalink / raw) To: help-gnu-emacs On 2015-04-18, at 04:55, Emanuel Berg <embe8573@student.uu.se> wrote: > Meanwhile, most university people don't get that > programming languages are tools that should be > employed to do useful things, not runes to be analyzed > like some Noam Chomsky/Indiana Jones would the > paleo-Etruscan from half-disintegrated tomb stones! I guess whether (a) this "most university people" stuff was some kind of irony towards me (and if yes, I guess it's mistaken: I'm just a student of Emacs, and a curious one, too, so I wanted to understand; in fact, Drew's answer was one of the very few on-topic ones! And what I'm actually doing is my "university stuff" is mathematical analysis/fixed point theory) and whether (b) this "half-disintegrated tomb stones" stuff was some kind of irony towards Emacs itself. ;-P Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <mailman.997.1429343558.904.help-gnu-emacs@gnu.org>]
* Re: Why is booleanp defined this way? [not found] ` <mailman.997.1429343558.904.help-gnu-emacs@gnu.org> @ 2015-04-18 12:43 ` Rusi 0 siblings, 0 replies; 33+ messages in thread From: Rusi @ 2015-04-18 12:43 UTC (permalink / raw) To: help-gnu-emacs On Saturday, April 18, 2015 at 1:22:40 PM UTC+5:30, Marcin Borkowski wrote: > On 2015-04-18, at 04:55, Emanuel Berg wrote: > > > Meanwhile, most university people don't get that > > programming languages are tools that should be > > employed to do useful things, not runes to be analyzed > > like some Noam Chomsky/Indiana Jones would the > > paleo-Etruscan from half-disintegrated tomb stones! > > I guess whether (a) this "most university people" stuff was some kind of > irony towards me Nah! Mea Culprit. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 2:33 ` Rusi 2015-04-18 2:55 ` Emanuel Berg @ 2015-04-18 4:09 ` Pascal J. Bourguignon 2015-04-18 5:00 ` Rusi 1 sibling, 1 reply; 33+ messages in thread From: Pascal J. Bourguignon @ 2015-04-18 4:09 UTC (permalink / raw) To: help-gnu-emacs Rusi <rustompmody@gmail.com> writes: >> I never used `booleanp' and I never experienced that >> the boolean built-in type was missing from my >> "ontology". > > If you how to write (and grok) an 'if' you have boolean in your > ontology. Not exactly. There's something magical occuring in if. if takes an expression that is _used_ _as_ a condition. Often, that expression is a boolean, but that depends on the language. For example, in C, the expression is any expression, and it is tested against 0 to define the (negation of the) condition. You could define a language without ANY predefined types, and then you would have to declare the mapping between the values of some user-defined type and the condition used by any "conditional" instruction or operator. (deftype booleen () `(member vrai faux)) (declare-if-conditions :then (eql vrai) :else (eql faux)) (if t 'yes 'no) --> #<error t is not a valid condition value> (if 'vrai 'yes 'no) --> yes (declare-if-conditions :else (function zerop)) (if 'vrai 'yes 'no) --> #<error vrai is not a valid condition value> (let ((a 2)) (if (- a 2) 'yes 'no)) --> yes (Of course, it is not too useful to have such things in lisp, we're happy with generalized booleans, but once upon a time, I fancied a language with no predefined types, as a way to achieve better portability. Like C is "good" for I/O by reason of having no I/O operator (compared to eg. Pascal), a typeless static language would be good for portability, because it would have no implicit dependence on the processor data types such as int32 or int64; you'd declare your own integer ranges and the compilers would ensure it works everywhere. (deftype my-int () `(integer -20 1000000)) (let ((a 0)) (declare (type (my-int a))) (incf a)) But again, for lisp or any other non-statically typed programming language, this is mute. Actually, any solution to any programming problem is silly, because lisp doesn't even need such a solution because it doesn't have the problem to begin with. > That you dont know that you know is ok; most programmers dont get that their > 'thinking language' is a superset of their programming language. > > eg When we were students we learnt flowcharts (or flawcharts) > Most today's kids think thats irrelevant but then they think UML is relevant. > The Dijkstra school would tout logic > The FP school will tout lambda calculus (or dependent types) > Even the box-and-arrow diagrams of classic data structures books goes beyond the > language the book claims to be using And that's where lisp excells, for the reason that we don't write code, but actually, we write data. S-exprs are a syntax for lisp data structures. (Lisp code was intended to be written as M-expr, and they indeed were used in early papers and documentations, cf. eg. LISP 1.5 Programmer's Manual). Since we write DATA, we can denote any superset of programming languages we need. We can represent flowcharts, UML diagrams (some UML tools actually used S-exps to store the diagrams, before the XML mode), or box-and-arrow diagrams, and so on... Then you just write the data describing the glue macros and functions needed to "interpret" the "data" you write to solve your problem. So, yes, "most" programmers don't get that their 'thinking language' is a superset of their programming language, but that's not the case of (reasoned) lispers. Again, see above, any problem is ALREADY inexistant or solved in lisp. -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 4:09 ` Pascal J. Bourguignon @ 2015-04-18 5:00 ` Rusi 0 siblings, 0 replies; 33+ messages in thread From: Rusi @ 2015-04-18 5:00 UTC (permalink / raw) To: help-gnu-emacs On Saturday, April 18, 2015 at 9:47:41 AM UTC+5:30, Pascal J. Bourguignon wrote: > Rusi writes: > > >> I never used `booleanp' and I never experienced that > >> the boolean built-in type was missing from my > >> "ontology". > > > > If you how to write (and grok) an 'if' you have boolean in your > > ontology. > > Not exactly. There's something magical occuring in if. > > if takes an expression that is _used_ _as_ a condition. > > Often, that expression is a boolean, but that depends on the > language. For example, in C, the expression is any expression, and it is > tested against 0 to define the (negation of the) condition. > > You could define a language without ANY predefined types, and then you > would have to declare the mapping between the values of some > user-defined type and the condition used by any "conditional" > instruction or operator. > > (deftype booleen () `(member vrai faux)) > > (declare-if-conditions :then (eql vrai) > :else (eql faux)) > > (if t 'yes 'no) --> #<error t is not a valid condition value> > (if 'vrai 'yes 'no) --> yes > > > (declare-if-conditions :else (function zerop)) > > (if 'vrai 'yes 'no) --> #<error vrai is not a valid condition value> > (let ((a 2)) (if (- a 2) 'yes 'no)) --> yes > > (Of course, it is not too useful to have such things in lisp, we're > happy with generalized booleans, but once upon a time, I fancied a > language with no predefined types, as a way to achieve better > portability. Like C is "good" for I/O by reason of having no I/O > operator (compared to eg. Pascal), a typeless static language would be > good for portability, because it would have no implicit dependence on > the processor data types such as int32 or int64; you'd declare your own > integer ranges and the compilers would ensure it works everywhere. > > (deftype my-int () `(integer -20 1000000)) > (let ((a 0)) > (declare (type (my-int a))) > (incf a)) > > But again, for lisp or any other non-statically typed programming > language, this is mute. <irony> I know very little CL so dont really get what you are saying. Can you say it in scheme? (ironical on this thread!) </irony> ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 2:01 ` Rusi 2015-04-18 2:23 ` Emanuel Berg @ 2015-04-18 3:50 ` Pascal J. Bourguignon 2015-04-18 5:03 ` Stefan Monnier 1 sibling, 1 reply; 33+ messages in thread From: Pascal J. Bourguignon @ 2015-04-18 3:50 UTC (permalink / raw) To: help-gnu-emacs Rusi <rustompmody@gmail.com> writes: > Elisp does not have a proper boolean type; unlike say symbols with > symbolp, strings with stringp, numberp -- some union of numeric types etc. > However programmers need boolean in their ontology even if (and even more if) > the language does not support it. Well, if you go this way, elisp doesn't have proper types at all!!! deftype, typep, subtypep are all defined in cl.el and as such, "frowned upon" by the PTB. > I'd say booleanp is a hesitant step towards supporting boolean in the ontology > without supporting it in the language. Let's go boldly where no other elispers has ever gone: (deftype boolean () `(member t nil)) (defun booleanp (x) (typep x 'boolean)) -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 3:50 ` Pascal J. Bourguignon @ 2015-04-18 5:03 ` Stefan Monnier 0 siblings, 0 replies; 33+ messages in thread From: Stefan Monnier @ 2015-04-18 5:03 UTC (permalink / raw) To: help-gnu-emacs >> Elisp does not have a proper boolean type; unlike say symbols with >> symbolp, strings with stringp, numberp -- some union of numeric types etc. >> However programmers need boolean in their ontology even if (and even more if) >> the language does not support it. > Well, if you go this way, elisp doesn't have proper types at all!!! I think he was alluding to the difference between the types that `typeof' might recognize and those that are more like unions of other types. > deftype, typep, subtypep are all defined in cl.el and as such, "frowned > upon" by the PTB. cl-deftype, cl-typep, ... are alive and well and not frowned upon. Stefan ^ permalink raw reply [flat|nested] 33+ messages in thread
* Why is booleanp defined this way? @ 2015-04-17 20:34 Marcin Borkowski 2015-04-17 20:49 ` Jorge A. Alfaro-Murillo ` (3 more replies) 0 siblings, 4 replies; 33+ messages in thread From: Marcin Borkowski @ 2015-04-17 20:34 UTC (permalink / raw) To: Help Gnu Emacs mailing list Hi all, this is what I found in subr.el: ,---- | (defun booleanp (object) | "Return t if OBJECT is one of the two canonical boolean values: t or nil. | Otherwise, return nil." | (and (memq object '(nil t)) t)) `---- Seemingly, it doesn't make much sense: what is the purpose of saying (and (whatever) t) instead of just (whatever) for a predicate? Of course, this "normalizes" any "truthy" value to "t", but is it really needed for anything (except perhaps being elegant)? Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-17 20:34 Marcin Borkowski @ 2015-04-17 20:49 ` Jorge A. Alfaro-Murillo [not found] ` <mailman.962.1429303822.904.help-gnu-emacs@gnu.org> ` (2 subsequent siblings) 3 siblings, 0 replies; 33+ messages in thread From: Jorge A. Alfaro-Murillo @ 2015-04-17 20:49 UTC (permalink / raw) To: help-gnu-emacs Marcin Borkowski writes: > Seemingly, it doesn't make much sense: what is the purpose of > saying > > (and (whatever) t) > > instead of just > > (whatever) > > for a predicate? Of course, this "normalizes" any "truthy" > value to "t", but is it really needed for anything (except > perhaps being elegant)? Perhaps so that it returns t instead of whatever, if whatever is not nil. -- Jorge. ^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <mailman.962.1429303822.904.help-gnu-emacs@gnu.org>]
* Re: Why is booleanp defined this way? [not found] ` <mailman.962.1429303822.904.help-gnu-emacs@gnu.org> @ 2015-04-17 23:06 ` Emanuel Berg 2015-04-18 0:41 ` Pascal J. Bourguignon 0 siblings, 1 reply; 33+ messages in thread From: Emanuel Berg @ 2015-04-17 23:06 UTC (permalink / raw) To: help-gnu-emacs jorge.alfaro-murillo@yale.edu (Jorge A. Alfaro-Murillo) writes: >> Of course, this "normalizes" any "truthy" value to >> "t", but is it really needed for anything (except >> perhaps being elegant)? > > Perhaps so that it returns t instead of whatever, if > whatever is not nil. Yes, I think this is what the OP means by "normalizes". Normalization is a university buzzword for example in linear algebra where two vectors are normalized to a common coordination system so they can be compared. But... (booleanp t) ; t (booleanp nil) ; t (booleanp 1) ; nil! To me it looks like t and nil as arguments evaluate to t, and everything else nil - everything else that isn't evaluated first to either of t or nil, of course. The "normalization" of which you speak should rather look something like this: (defun normalize-boolean (obj) (if obj t) ) ; implicit (if obj t nil) (normalize-boolean 1) ; t (normalize-boolean nil) ; nil Or do you mean that `and' normalizes? It can, but that would depend on the order: (and 1 t) ; t (and t 1) ; 1 So I think `booleanp' shouldn't be thought of as a normalizer but rather as a type predicate, much like them `stringp', `integerp', and so on. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-17 23:06 ` Emanuel Berg @ 2015-04-18 0:41 ` Pascal J. Bourguignon 2015-04-18 1:06 ` Emanuel Berg 0 siblings, 1 reply; 33+ messages in thread From: Pascal J. Bourguignon @ 2015-04-18 0:41 UTC (permalink / raw) To: help-gnu-emacs Emanuel Berg <embe8573@student.uu.se> writes: > The "normalization" of which you speak should rather > look something like this: > > (defun normalize-boolean (obj) > (if obj t) ) ; implicit (if obj t nil) > > (normalize-boolean 1) ; t > (normalize-boolean nil) ; nil You may want to compare: (defun normalize-boolean (obj) (if obj t)) (disassemble (byte-compile 'normalize-boolean)) byte code: args: (obj) 0 varref obj 1 goto-if-nil-else-pop 1 4 constant t 5:1 return with: (defun g (x) (not (not x))) byte code: args: (x) 0 varref x 1 not 2 not 3 return (disassemble (byte-compile 'f)) > So I think `booleanp' shouldn't be thought of as > a normalizer but rather as a type predicate, much like > them `stringp', `integerp', and so on. Of course. That's what the "p" in "booleanp" means! -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 0:41 ` Pascal J. Bourguignon @ 2015-04-18 1:06 ` Emanuel Berg 2015-04-18 1:23 ` Pascal J. Bourguignon ` (2 more replies) 0 siblings, 3 replies; 33+ messages in thread From: Emanuel Berg @ 2015-04-18 1:06 UTC (permalink / raw) To: help-gnu-emacs "Pascal J. Bourguignon" <pjb@informatimago.com> writes: > You may want to compare: > > (defun normalize-boolean (obj) > (if obj t)) > (disassemble (byte-compile 'normalize-boolean)) > byte code: > args: (obj) > 0 varref obj > 1 goto-if-nil-else-pop 1 > 4 constant t > 5:1 return > > with: > > (defun g (x) (not (not x))) > byte code: > args: (x) > 0 varref x > 1 not > 2 not > 3 return > > (disassemble (byte-compile 'f)) ... you mean 'g? Are you saying (not (not x)) generates more efficient byte-code? I hate to break it to you, but the Commodore 64 demo era is long gone :) >> So I think `booleanp' shouldn't be thought of as >> a normalizer but rather as a type predicate, much >> like them `stringp', `integerp', and so on. > > Of course. That's what the "p" in "booleanp" means! If that is "of course" then what are we talking about? -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 1:06 ` Emanuel Berg @ 2015-04-18 1:23 ` Pascal J. Bourguignon 2015-04-18 7:44 ` Marcin Borkowski 2015-04-18 8:37 ` Stefan Nobis 2 siblings, 0 replies; 33+ messages in thread From: Pascal J. Bourguignon @ 2015-04-18 1:23 UTC (permalink / raw) To: help-gnu-emacs Emanuel Berg <embe8573@student.uu.se> writes: > Are you saying (not (not x)) generates more efficient > byte-code? I hate to break it to you, but the > Commodore 64 demo era is long gone :) That's what I'm saying, in the case of a lisp VM (emacs lisp, clisp). In the case of a not too dumb native compiler, both should generate the same native code. >>> So I think `booleanp' shouldn't be thought of as >>> a normalizer but rather as a type predicate, much >>> like them `stringp', `integerp', and so on. >> >> Of course. That's what the "p" in "booleanp" means! > > If that is "of course" then what are we talking about? I'm just stating that you are stating the obvious. Obviously :-) -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 1:06 ` Emanuel Berg 2015-04-18 1:23 ` Pascal J. Bourguignon @ 2015-04-18 7:44 ` Marcin Borkowski 2015-04-18 8:37 ` Stefan Nobis 2 siblings, 0 replies; 33+ messages in thread From: Marcin Borkowski @ 2015-04-18 7:44 UTC (permalink / raw) To: help-gnu-emacs Hi all, I love how I inadvertently start these huge threads... Really, I didn't mean it! On 2015-04-18, at 03:06, Emanuel Berg <embe8573@student.uu.se> wrote: > "Pascal J. Bourguignon" <pjb@informatimago.com> > writes: > >> You may want to compare: >> >> (defun normalize-boolean (obj) >> (if obj t)) >> (disassemble (byte-compile 'normalize-boolean)) >> byte code: >> args: (obj) >> 0 varref obj >> 1 goto-if-nil-else-pop 1 >> 4 constant t >> 5:1 return >> >> with: >> >> (defun g (x) (not (not x))) >> byte code: >> args: (x) >> 0 varref x >> 1 not >> 2 not >> 3 return >> >> (disassemble (byte-compile 'f)) Fascinating. Really, I'm serious. > > ... you mean 'g? > > Are you saying (not (not x)) generates more efficient > byte-code? I hate to break it to you, but the > Commodore 64 demo era is long gone :) I love to break it to you, but the C64 demoscene seems to be alive and kicking. Best, -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Faculty of Mathematics and Computer Science Adam Mickiewicz University ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 1:06 ` Emanuel Berg 2015-04-18 1:23 ` Pascal J. Bourguignon 2015-04-18 7:44 ` Marcin Borkowski @ 2015-04-18 8:37 ` Stefan Nobis 2015-04-19 23:15 ` Emanuel Berg 2 siblings, 1 reply; 33+ messages in thread From: Stefan Nobis @ 2015-04-18 8:37 UTC (permalink / raw) To: help-gnu-emacs Emanuel Berg <embe8573@student.uu.se> writes: > I hate to break it to you, but the Commodore 64 demo era is long > gone :) I don't think so: http://trixter.oldskool.org/2015/04/07/8088-mph-we-break-all-your-emulators/ -- Stefan. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-18 8:37 ` Stefan Nobis @ 2015-04-19 23:15 ` Emanuel Berg 0 siblings, 0 replies; 33+ messages in thread From: Emanuel Berg @ 2015-04-19 23:15 UTC (permalink / raw) To: help-gnu-emacs Stefan Nobis <snobis@gmx.de> writes: >> I hate to break it to you, but the Commodore 64 >> demo era is long gone :) > > I don't think so: > > http://trixter.oldskool.org/2015/04/07/8088-mph-we-break-all-your-emulators/ and Marcin Borkowski writes: > I love to break it to you, but the C64 demoscene > seems to be alive and kicking. I stand corrected. -- underground experts united http://user.it.uu.se/~embe8573 ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: Why is booleanp defined this way? 2015-04-17 20:34 Marcin Borkowski 2015-04-17 20:49 ` Jorge A. Alfaro-Murillo [not found] ` <mailman.962.1429303822.904.help-gnu-emacs@gnu.org> @ 2015-04-18 2:37 ` Drew Adams 2015-04-18 6:13 ` Tassilo Horn 3 siblings, 0 replies; 33+ messages in thread From: Drew Adams @ 2015-04-18 2:37 UTC (permalink / raw) To: Marcin Borkowski, Help Gnu Emacs mailing list If you grep for `booleanp' in the Emacs Lisp sources you will see that it is used pretty much exclusively as the value of property `safe-local-variable'. IOW, it is used (only) to declare that the value of this or that variable can be considered "safe" if it is `t' or `nil'. That's all. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Why is booleanp defined this way? 2015-04-17 20:34 Marcin Borkowski ` (2 preceding siblings ...) 2015-04-18 2:37 ` Drew Adams @ 2015-04-18 6:13 ` Tassilo Horn 3 siblings, 0 replies; 33+ messages in thread From: Tassilo Horn @ 2015-04-18 6:13 UTC (permalink / raw) To: Marcin Borkowski; +Cc: Help Gnu Emacs mailing list Marcin Borkowski <mbork@mbork.pl> writes: Hi Marcin, > Of course, this "normalizes" any "truthy" value to "t", but is it > really needed for anything (except perhaps being elegant)? It's just as you say and the others already explained. And then have a look where and `booleanp` is actually used. Basically all usages in emacs itself are (put 'some-variable 'safe-local-variable 'booleanp) So some-variable is safe as a file-local variable only if it is either nil or t but it is not safe when its value is (eval (shell-command "rm -rf ~/")). Another use-case is when you are talking to some external service that wan't "real" (aka, non-generalized booleans) and use some marshalling code which automatically converts nil to false and t to true. Bye, Tassilo ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2015-04-19 23:15 UTC | newest] Thread overview: 33+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <mailman.946.1429302909.904.help-gnu-emacs@gnu.org> 2015-04-17 20:55 ` Why is booleanp defined this way? Pascal J. Bourguignon 2015-04-17 23:20 ` Barry Margolin 2015-04-17 23:30 ` Emanuel Berg 2015-04-18 0:43 ` Pascal J. Bourguignon 2015-04-18 3:13 ` Barry Margolin 2015-04-18 3:12 ` Barry Margolin 2015-04-18 2:01 ` Rusi 2015-04-18 2:23 ` Emanuel Berg 2015-04-18 2:33 ` Rusi 2015-04-18 2:55 ` Emanuel Berg 2015-04-18 3:11 ` Barry Margolin 2015-04-18 3:35 ` Rusi 2015-04-18 4:56 ` Barry Margolin 2015-04-19 23:08 ` Emanuel Berg 2015-04-19 23:00 ` Emanuel Berg 2015-04-18 21:24 ` Emanuel Berg 2015-04-18 7:52 ` Marcin Borkowski [not found] ` <mailman.997.1429343558.904.help-gnu-emacs@gnu.org> 2015-04-18 12:43 ` Rusi 2015-04-18 4:09 ` Pascal J. Bourguignon 2015-04-18 5:00 ` Rusi 2015-04-18 3:50 ` Pascal J. Bourguignon 2015-04-18 5:03 ` Stefan Monnier 2015-04-17 20:34 Marcin Borkowski 2015-04-17 20:49 ` Jorge A. Alfaro-Murillo [not found] ` <mailman.962.1429303822.904.help-gnu-emacs@gnu.org> 2015-04-17 23:06 ` Emanuel Berg 2015-04-18 0:41 ` Pascal J. Bourguignon 2015-04-18 1:06 ` Emanuel Berg 2015-04-18 1:23 ` Pascal J. Bourguignon 2015-04-18 7:44 ` Marcin Borkowski 2015-04-18 8:37 ` Stefan Nobis 2015-04-19 23:15 ` Emanuel Berg 2015-04-18 2:37 ` Drew Adams 2015-04-18 6:13 ` Tassilo Horn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).