no empty (zero) string predicate in Elisp

no empty (zero) string predicate in Elisp

[Emanuel Berg]

In one of my w3m extensions [1] I have

    (defun empty-string-p (str)
      (string= str "") )

which obviously has nothing to do with w3m. Well, it's
been known to happen. I can live with having it there.

However, the next time I want to use it in some other
file the byte-compiler tells me

    In end of data: wrap-search.el:98:1:Warning: the
    function `empty-string-p' is not known to
    be defined.

OK, I get that away with

    (require 'w3m-unisearch) ; get empty-string-p

But now I have a mention of w3m, in a file that has
nothing to do with w3m, to get empty-string-p, which
has nothing to do with w3m!

Of course, I can do yet a third file -
my-string-predicate.el - and require that from both
files. But I feel I shouldn't have to. Such basic
things shouldn't have to be solved on a Joe Hacker
basis. It should be included. And not in ELPA,
in Emacs!

I'll report this as a bug unless someone presents
really convincing stuff why it shouldn't be included.
Or, if there is something equivalent - equivalent in
the syntactic sense, I mean - I am aware of

   (= (length str) 0)

and

   (equal "" str)

but it should be a binary operator.

[1] http://user.it.uu.se/~embe8573/conf/emacs-init/w3m/w3m-unisearch.el

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: no empty (zero) string predicate in Elisp

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]


Emanuel Berg writes:

> In one of my w3m extensions [1] I have
>
>     (defun empty-string-p (str)
>       (string= str "") )
>
> which obviously has nothing to do with w3m. Well, it's
> been known to happen. I can live with having it there.
>
> However, the next time I want to use it in some other
> file the byte-compiler tells me
>
>     In end of data: wrap-search.el:98:1:Warning: the
>     function `empty-string-p' is not known to
>     be defined.
>
> OK, I get that away with
>
>     (require 'w3m-unisearch) ; get empty-string-p
>
> But now I have a mention of w3m, in a file that has
> nothing to do with w3m, to get empty-string-p, which
> has nothing to do with w3m!

Hi!

You can use `string-empty-p' from subr-x.el or `seq-empty-p' from
seq.el (which works on all sequence data types).

seq.el will be included in Emacs 25.1, but in the meantime you can
install it from GNU Elpa.

Cheers,
Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: no empty (zero) string predicate in Elisp

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]


Nicolas Petton writes:

> You can use `string-empty-p' from subr-x.el or `seq-empty-p' from
> seq.el (which works on all sequence data types).
>
> seq.el will be included in Emacs 25.1, but in the meantime you can
> install it from GNU Elpa.

BTW, would it be wise to obsolete `string-reverse' and `string-empty-p'
From subr-x in favor of `seq-reverse' and `seq-empty-p' which are much
more generic?

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: no empty (zero) string predicate in Elisp

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

I'd advise against this, as my intuition would always be to search for
something starting with `string-` when dealing with strings.

On 16 May 2015 at 12:23, Nicolas Petton <nicolas@petton.fr> wrote:

>
> Nicolas Petton writes:
>
> > You can use `string-empty-p' from subr-x.el or `seq-empty-p' from
> > seq.el (which works on all sequence data types).
> >
> > seq.el will be included in Emacs 25.1, but in the meantime you can
> > install it from GNU Elpa.
>
> BTW, would it be wise to obsolete `string-reverse' and `string-empty-p'
> From subr-x in favor of `seq-reverse' and `seq-empty-p' which are much
> more generic?
>
> Nico
> --
> Nicolas Petton
> http://nicolas-petton.fr
>

[-- Attachment #2: Type: text/html, Size: 1185 bytes --]

Re: no empty (zero) string predicate in Elisp

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 843 bytes --]

Btw, `string-reverse` was already obsoleted by `reverse`.

On 16 May 2015 at 16:22, Bozhidar Batsov <bozhidar@batsov.com> wrote:

> I'd advise against this, as my intuition would always be to search for
> something starting with `string-` when dealing with strings.
>
> On 16 May 2015 at 12:23, Nicolas Petton <nicolas@petton.fr> wrote:
>
>>
>> Nicolas Petton writes:
>>
>> > You can use `string-empty-p' from subr-x.el or `seq-empty-p' from
>> > seq.el (which works on all sequence data types).
>> >
>> > seq.el will be included in Emacs 25.1, but in the meantime you can
>> > install it from GNU Elpa.
>>
>> BTW, would it be wise to obsolete `string-reverse' and `string-empty-p'
>> From subr-x in favor of `seq-reverse' and `seq-empty-p' which are much
>> more generic?
>>
>> Nico
>> --
>> Nicolas Petton
>> http://nicolas-petton.fr
>>
>
>

[-- Attachment #2: Type: text/html, Size: 1644 bytes --]

Re: no empty (zero) string predicate in Elisp

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]

And one more thing - `string-empty-p` uses string comparison (`string=`)
instead of length comparison.

On 16 May 2015 at 16:28, Bozhidar Batsov <bozhidar@batsov.com> wrote:

> Btw, `string-reverse` was already obsoleted by `reverse`.
>
> On 16 May 2015 at 16:22, Bozhidar Batsov <bozhidar@batsov.com> wrote:
>
>> I'd advise against this, as my intuition would always be to search for
>> something starting with `string-` when dealing with strings.
>>
>> On 16 May 2015 at 12:23, Nicolas Petton <nicolas@petton.fr> wrote:
>>
>>>
>>> Nicolas Petton writes:
>>>
>>> > You can use `string-empty-p' from subr-x.el or `seq-empty-p' from
>>> > seq.el (which works on all sequence data types).
>>> >
>>> > seq.el will be included in Emacs 25.1, but in the meantime you can
>>> > install it from GNU Elpa.
>>>
>>> BTW, would it be wise to obsolete `string-reverse' and `string-empty-p'
>>> From subr-x in favor of `seq-reverse' and `seq-empty-p' which are much
>>> more generic?
>>>
>>> Nico
>>> --
>>> Nicolas Petton
>>> http://nicolas-petton.fr
>>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 2137 bytes --]

Re: no empty (zero) string predicate in Elisp

[Eli Zaretskii]

> Date: Sat, 16 May 2015 16:36:18 +0300
> From: Bozhidar Batsov <bozhidar@batsov.com>
> Cc: help-gnu-emacs@gnu.org, Emanuel Berg <embe8573@student.uu.se>,
> 	emacs-devel <emacs-devel@gnu.org>
> 
> And one more thing - `string-empty-p` uses string comparison (`string=`)
> instead of length comparison. 

Are you saying that length comparison is better, or vice versa?

Re: no empty (zero) string predicate in Elisp

[Stefan Monnier]

> BTW, would it be wise to obsolete `string-reverse' and `string-empty-p'
> From subr-x in favor of `seq-reverse' and `seq-empty-p' which are much
> more generic?

string-reverse i already marked as obsolete.  As for string-empty-p, I'm
not sure, because it depends on whether you care about the fact that the
arg is a string (e.g. you care about the fact that (string-empty-p nil)
is nil rather than (seq-empty-p nil) being t).


        Stefan

RE: no empty (zero) string predicate in Elisp

[Drew Adams]

C'mon guys, please don't cc both lists.  (This belongs
in emacs-devel, IMHO, but please pick one list.)

Re: no empty (zero) string predicate in Elisp

[Emanuel Berg]

Nicolas Petton <nicolas@petton.fr> writes:

> You can use `string-empty-p' from subr-x.el or
> `seq-empty-p' from seq.el (which works on all
> sequence data types).
>
> seq.el will be included in Emacs 25.1, but in the
> meantime you can install it from GNU Elpa.
>
> Cheers, Nico

Nico is KING!

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: no empty (zero) string predicate in Elisp

[Stefan Monnier]

>>>>> "Emanuel" == Emanuel Berg <embe8573@student.uu.se> writes:

> In one of my w3m extensions [1] I have
>     (defun empty-string-p (str)
>       (string= str "") )

I do wonder, why you'd rather write

           (empty-string-p foo)
instead of
           (equal "" foo)
or
           (string= "" foo)

I mean, really, what's the gain?  It's longer, slower, and not
higher-level either.


        Stefan "yes, I know Elisp has `zerop' but that's stupid as well"

Re: no empty (zero) string predicate in Elisp

[Pascal J. Bourguignon]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>         Stefan "yes, I know Elisp has `zerop' but that's stupid as well"

It's arguable.  Cf. the discussion abouto 1+ and 1-.

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;  and for optimization reasons on simplistic
compilers: the hardware usually HAS specific (and optimized)
instructions to test for zero and another to increment.

On the other hand, from the "highlevel" point of view, we may choose to
provide a language with only generalized operators.

And I'm asking, why stop at equal or string=?  
Why not define a equivalence class membership predicate?

(equiv-class-member-p 'abc  (string-equivalence-class "abc")) -> t
(equiv-class-member-p "123" (number-equivalence-class 123.0)) -> t
(equiv-class-member-p "" (sequence-length-class '())) --> t


So yes, if you don't want to have (zerop (length "")), then do not stop
at (= 0 (length "")), write: 
(equiv-class-member-p "" (sequence-length-class '()))




Since testing for empty sequences is something that is natural and as
often done as testing for zero, having an emptyp predicate for sequences
seems very natural, so defining:

    (defun emptyp (sequence)
      (zerop (length sequence)))

seems good:

   (list (emptyp '())
         (emptyp [])
         (emptyp "")) --> (t t t)






In the case of the emacs lisp byte compiler, it looks like using (= 0 x)
instead of (zerop x) would be more efficient, because the compiler in
emacs-version "24.3.1" seems to generate a more efficient byte code:

    (disassemble (byte-compile (defun emptyp (sequence)
                                 (= 0 (length sequence)))))
        byte code:
          args: (sequence)
        0       varref    sequence
        1       length    
        2       constant  0
        3       eqlsign   
        4       return    


    (disassemble (byte-compile (defun emptyp (sequence)
                                 (zerop (length sequence)))))
        byte code:
          args: (sequence)
        0       constant  zerop
        1       varref    sequence
        2       length    
        3       call      1
        4       return    

On the other hand, eqlsign must perform two type checks and has to
convert 0 to float when the value is float (or would have to convert a
0.0 to int when the value is int), so it's not obvious which would be
more efficient in the current implementation.

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

Re: no empty (zero) string predicate in Elisp

[Stefan Monnier]

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


        Stefan

zerop: compiler macro vs defsubst (was: no empty (zero) string predicate in Elisp)

[Nicolas Richard]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 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.

IIUC the efficiency is obtained by inlining the definition thus avoiding
a function call. What's the difference between using that compiler macro
and using defsubst ?

-- 
Nicolas

Re: zerop: compiler macro vs defsubst

[Stefan Monnier]

> a function call. What's the difference between using that compiler macro
> and using defsubst ?

The defsubst add a `let' binding.


        Stefan

Re: no empty (zero) string predicate in Elisp

[Pascal J. Bourguignon]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

This is exactly what I'm pointing to!  If you want to consider how elisp
intgers are encoded on the native machine, then you definitely want a
zerop function, because there are BEQ and SEQ instructions.


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

Not in emacs-version "24.3.1"  where I produced the disassembly
provided.  But I'm happy to see it being optimized, this is one more
reason to keep it and use it.


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

Re: no empty (zero) string predicate in Elisp

[Stefan Monnier]

> This is exactly what I'm pointing to!  If you want to consider how elisp
> intgers are encoded on the native machine, then you definitely want a
> zerop function, because there are BEQ and SEQ instructions.

But that's not the case: Elisp is compiled to Emacs's byte-code
"machine" which does not have such instructions.

> Not in emacs-version "24.3.1"  where I produced the disassembly
> provided.  But I'm happy to see it being optimized, this is one more
> reason to keep it and use it.

Indeed, the inefficiency of zerop was pointed out "recently" and has
I think it's only fixed in Emacs-25.


        Stefan

Re: no empty (zero) string predicate in Elisp

[Rusi]

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.

Re: no empty (zero) string predicate in Elisp

[Emanuel Berg]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I do wonder, why you'd rather write (empty-string-p
> foo) instead of (equal "" foo) or (string= "" foo)
> ... It's longer

I don't mind typing. It is one of my favorite
activities (in very stiff competition), especially
when it only involves common words with chars that are
close and super-fast to type: 'empty-string-p' is
definitely more pleasant to type (and read) than
'string= ""' whereas 'equal ""' should be about
"equally" pleasant to type, but still less so to read.

> slower

If that is true, which I suppose it is because it
requires an extra function call, the difference should
be close to infinitely small. I don't consider such
quantities. Actually, I don't consider speed at all
when I write Elisp. (But I never did any one big
project that could gain from optimization, either.
Still, I don't think I write slow code, in general.)

When I told the other guy the other day that
(make-string 10 ? ) is better than `dotimes' and
(insert " ") 10 times, there I focus on the code
rather than the speed - but those two (?) ways of
thinking should work to each other's advantage
most often.

> not higher-level either

I don't know the scientific definition of "high-level"
- or how it applies to these three Elisp functions.

The reason I want a binary operator is that it is more
intuitive: it refects my way of thinking - "is the
string empty?" vs. "is the string equal to another
string that is empty?" - also, because a binary
operator reduces the number of data items in the code
(with one, the empty string).

In general, I don't want the same function to be
spelled out over and over to do the same thing -
instead, I want it factored out, named, and invoked
with a "minimal", that is, sufficient, interface.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: no empty (zero) string predicate in Elisp

[Pascal J. Bourguignon]

Emanuel Berg <embe8573@student.uu.se> writes:

>> not higher-level either
>
> I don't know the scientific definition of "high-level"
> - or how it applies to these three Elisp functions.
>
> The reason I want a binary operator is that it is more
> intuitive: it refects my way of thinking - "is the
> string empty?" vs. "is the string equal to another
> string that is empty?" - also, because a binary
> operator reduces the number of data items in the code
> (with one, the empty string).

The only problem with that, is that a binary operator has 2 arguments:
    
    (binop a b)

therefore if you want a binary operator, you want:

    (string= s "")

On the other hand, if you want only one argument, then you want a unary
operator:

    (unary a)

and when this unary operator returns a boolean, you call it a predicate:

    (emptyp s)


> In general, I don't want the same function to be
> spelled out over and over to do the same thing -
> instead, I want it factored out, named, and invoked
> with a "minimal", that is, sufficient, interface.

Definitely.


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

Re: no empty (zero) string predicate in Elisp

[Emanuel Berg]

"Pascal J. Bourguignon" <pjb@informatimago.com>
writes:

> The only problem with that, is that a binary
> operator has 2 arguments:
>     
>     (binop a b)
>
> therefore if you want a binary operator, you want:
>
>     (string= s "")
>
> On the other hand, if you want only one argument,
> then you want a unary operator:
>
>     (unary a)

Indeed! You have to read what I think, not what
I write...

OK, let's try again: I want a *unary* function because
this involves a *single* argument (sounds logical,
right?) - the function's value only depends on
a property of this single argument.

In math notation:


            /  true       x = ""
    f(x) = 
            \  false        else


The implementation one the other hand may contain
everything else that is needed, including the "" for
comparison (in this case and in that implementation).

While the *implementation* can be optimized for speed,
the *function* and its interface should be formulated
for clarity and "building blockness" as to facilitate
ease of combination with other functions...

This is the building block, toolchain, bottom-up
approach which is the opposite of the fancy game of
"programming" by drawing super-ambitious UML and class
diagrams - "if you don't do it, it won't work
ultimately", which is wrong - that approach very often
fails, and when it does, instead of simply replacing
the failing link, the whole thing must be done again,
maybe with some slightly modified approach, "new
ideas", etc.

> and when this unary operator returns a boolean, you
> call it a predicate
>
>     (emptyp s)

Cool. "Predicate" is a word from the grammars of human
languages, but I don't know its exact meaning, neither
there or in programming languages (until now as for
programming).

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: no empty (zero) string predicate in Elisp

[Marcin Borkowski]

On 2015-04-26, at 20:34, Emanuel Berg <embe8573@student.uu.se> wrote:

> Cool. "Predicate" is a word from the grammars of human
> languages, but I don't know its exact meaning, neither
> there or in programming languages (until now as for
> programming).

AFAIK, "predicate" is a word from /logic/, and it means (more or less)
a function which consumes one or more arguments of any type and gives
back a truth-value.  (Not necesarily exactly that, because Russell's
paradox etc., but this is the idea.)

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: no empty (zero) string predicate in Elisp

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

>> "Predicate" is a word from the grammars of human
>> languages, but I don't know its exact meaning,
>> neither there or in programming languages (until
>> now as for programming).
>
> AFAIK, "predicate" is a word from /logic/, and it
> means (more or less) a function which consumes one
> or more arguments of any type and gives back
> a truth-value.

Doesn't all functions in logic do that?

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: no empty (zero) string predicate in Elisp

[Marcin Borkowski]

On 2015-04-26, at 21:06, Emanuel Berg <embe8573@student.uu.se> wrote:

> Marcin Borkowski <mbork@mbork.pl> writes:
>
>>> "Predicate" is a word from the grammars of human
>>> languages, but I don't know its exact meaning,
>>> neither there or in programming languages (until
>>> now as for programming).
>>
>> AFAIK, "predicate" is a word from /logic/, and it
>> means (more or less) a function which consumes one
>> or more arguments of any type and gives back
>> a truth-value.
>
> Doesn't all functions in logic do that?

First of all: IANAL (here L = logician;-)).  But...

For starters, in propositional calculus (AFAIK, also in first-order
logic) there are no "functions" per se, since there are no /sets/.
Furthermore, in the logic systems usually used by us mathematicians
there are no /types/.  AFAIK, the analogue of "type mismatch" in these
systems is just a plain old "syntax error".

What you probably refer to is the fact that in these simple logic
systems both predicates and logical connectives "generate"
truth-values.  However, there are other possibilities; analogues of
"functions" in these systems are called "terms".

Best,

-- 
Marcin Borkowski
http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski
Faculty of Mathematics and Computer Science
Adam Mickiewicz University

Re: no empty (zero) string predicate in Elisp

[Emanuel Berg]

Marcin Borkowski <mbork@mbork.pl> writes:

>>>> "Predicate" is a word from the grammars of human
>>>> languages, but I don't know its exact meaning,
>>>> neither there or in programming languages (until
>>>> now as for programming).
>>> AFAIK, "predicate" is a word from /logic/, and it
>>> means (more or less) a function which consumes one
>>> or more arguments of any type and gives back
>>> a truth-value.
>> Doesn't all functions in logic do that?
>
> First of all: IANAL (here L = logician;-)). But...
>
> For starters, in propositional calculus (AFAIK, also
> in first-order logic) there are no "functions" per
> se, since there are no /sets/. Furthermore, in the
> logic systems usually used by us mathematicians
> there are no /types/. AFAIK, the analogue of "type
> mismatch" in these systems is just a plain old
> "syntax error".
>
> What you probably refer to is the fact that in these
> simple logic systems both predicates and logical
> connectives "generate" truth-values. However, there
> are other possibilities; analogues of "functions" in
> these systems are called "terms".

I just looked it up in one of my favorite books,
namely

    @book{oxford-dictionary-of-computing,
      title      = {Oxford Dictionary of Computing},
      author     = {John Daintith and Edmund Wright (editors)},
      publisher  = {Oxford University Press},
      year       = 2010,
      ISBN       = 0199234000
    }

and your are absolutely right! A predicate is
a boolean function of n-arity: if n = 0
(i.e., no arguments) the function is called
a "statement" as the function value cannot change.

I also looked up "unary" but it wasn't included in the
"unary operator" sense, i.e. a function that accepts
a single input argument, e.g. f(x) or the suggested
zero-string predicate.

However, "unary operation" was included: a function

    f: D -> R

where the input domain equals the output range:

    f: S -> S

- which is *not* what we have here as here the input
set is all strings, while the output ditto is the mere

    { t, nil }

So all is clear, but it is error-prone and can be
confusion as well. So next time I'll just say "a
function with a single argument". Maybe.

By the way, "UNIX" (the name) is (?) a pun/joke on
this. It's predecessor was Multics, which was planned
to be a multiuser system, hence the name. But that
never materialized. UNIX, on the other hand, would
conquer the world a multiprogram, multiuser, and
time-sharing system...

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: no empty (zero) string predicate in Elisp

[Rusi]

On Sunday, April 26, 2015 at 6:01:15 PM UTC+5:30, Emanuel Berg wrote:
> Stefan Monnier  writes:
> 
> > I do wonder, why you'd rather write (empty-string-p
> > foo) instead of (equal "" foo) or (string= "" foo)
> > ... It's longer
> 
> I don't mind typing. It is one of my favorite
> activities (in very stiff competition), especially
> when it only involves common words with chars that are
> close and super-fast to type: 'empty-string-p' is
> definitely more pleasant to type (and read) than
> 'string= ""' whereas 'equal ""' should be about
> "equally" pleasant to type, but still less so to read.
> 
> > slower
> 
> If that is true, which I suppose it is because it
> requires an extra function call, the difference should
> be close to infinitely small. I don't consider such
> quantities. Actually, I don't consider speed at all
> when I write Elisp. (But I never did any one big
> project that could gain from optimization, either.
> Still, I don't think I write slow code, in general.)
> 
> When I told the other guy the other day that
> (make-string 10 ? ) is better than `dotimes' and
> (insert " ") 10 times, there I focus on the code
> rather than the speed - but those two (?) ways of
> thinking should work to each other's advantage
> most often.
> 
> > not higher-level either
> 
> I don't know the scientific definition of "high-level"
> - or how it applies to these three Elisp functions.
> 
> The reason I want a binary operator is that it is more
> intuitive: it refects my way of thinking - "is the
> string empty?" vs. "is the string equal to another
> string that is empty?" - also, because a binary
> operator reduces the number of data items in the code
> (with one, the empty string).
> 
> In general, I don't want the same function to be
> spelled out over and over to do the same thing -
> instead, I want it factored out, named, and invoked
> with a "minimal", that is, sufficient, interface.
> 
> -- 
> underground experts united
> http://user.it.uu.se/~embe8573

Rather befuddled here...
Do you want or not want empty-string-p??

Your first post said you've defined it and you want it not in ELPA but emacs.
Now you are saying you want a binary -- presumably (== "" whatever).

Re: no empty (zero) string predicate in Elisp

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

> Rather befuddled here... Do you want or not want
> empty-string-p??

Of course I want it! That's why I wrote it myself and
then suggested it be included.

> Your first post said you've defined it and you want
> it not in ELPA but emacs. Now you are saying you
> want a binary -- presumably (== "" whatever).

No, I meant *unary* - I just wrote:

    "Pascal J. Bourguignon" <pjb@informatimago.com>
    writes:

    > The only problem with that, is that a binary
    > operator has 2 arguments:
    >     
    >     (binop a b)
    >
    > therefore if you want a binary operator, you
    > want:
    >
    >     (string= s "")
    >
    > On the other hand, if you want only one
    > argument, then you want a unary operator:
    >
    >     (unary a)

    Indeed! You have to read what I think, not what
    I write...

    OK, let's try again: I want a *unary* function
    because this involves a *single* argument (sounds
    logical, right?) - the function's value only
    depends on a property of this single argument.

    In math notation:


                /  true       x = ""
        f(x) = 
                \  false        else


    The implementation one the other hand may contain
    everything else that is needed, including the ""
    for comparison (in this case and in that
    implementation).

    While the *implementation* can be optimized for
    speed, the *function* and its interface should be
    formulated for clarity and "building blockness" as
    to facilitate ease of combination with other
    functions...

    This is the building block, toolchain, bottom-up
    approach which is the opposite of the fancy game
    of "programming" by drawing super-ambitious UML
    and class diagrams - "if you don't do it, it won't
    work ultimately", which is wrong - that approach
    very often fails, and when it does, instead of
    simply replacing the failing link, the whole thing
    must be done again, maybe with some slightly
    modified approach, "new ideas", etc.

    > and when this unary operator returns a boolean,
    > you call it a predicate
    >
    >     (emptyp s)

    Cool. "Predicate" is a word from the grammars of
    human languages, but I don't know its exact
    meaning, neither there or in programming languages
    (until now as for programming).

-- 
underground experts united
http://user.it.uu.se/~embe8573