help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: no empty (zero) string predicate in Elisp


From: Rusi
Subject: Re: no empty (zero) string predicate in Elisp
Date: Sat, 25 Apr 2015 21:26:26 -0700 (PDT)
User-agent: G2/1.0

On Sunday, April 26, 2015 at 8:22:22 AM UTC+5:30, Stefan Monnier wrote:
> > Both for fundamental reasons, cardinals are built from a zero and a
> > successor relationship, therefore a predicate for zero is not stupid,
> > and a 1+ function neither;
> 
> I know that you can model natural numbers from 0 and successor, but
> Elisp integers have very little to do with it and are not encoded in
> this way, and there isn't much code around that looks at them this way.
> So, as much as I like this way to look at the world, I don't find it
> helpful for Elisp.
> 
> > and for optimization reasons on simplistic
> > compilers: the hardware usually HAS specific (and optimized)
> > instructions to test for zero and another to increment.
> 
> C-h f zerop RET says:
> 
>    zerop is a compiled Lisp function in `subr.el'.
>    [...]
>    This function has a compiler macro `zerop--anon-cmacro'.
>    
> and if you look at this mysterious zerop--anon-cmacro, you'll see that
> it optimizes `zerop' by rewriting it to (= 0 ...), which is implemented
> more efficiently.

In this case - zero test in elisp - I guess there is not much to argue against
Stefan's argument.
However in general can be cases where a specialized (curried) test is neat
[eg from python]
In python 'is' is pointer-equality (eq of lisp)
And it is generally recognized that noobs confuse themselves by using 'is' 
rather than ==  just as in Lisp equal is usually a safer option than eq.

However in some arcane cases 'is' is recommended over ==  in particular 
'x is None' is preferable to 'x == None'
[None is like Lisp Nil]
With the result that noobs have to use is in that context and confuse 
themselves.

If there were a 'None?' predicate like lisp-null one major source of noob 
confusion would be avoided.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]