unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Emanuel Berg <embe8573@student.uu.se>
To: help-gnu-emacs@gnu.org
Subject: Re: no empty (zero) string predicate in Elisp
Date: Sun, 26 Apr 2015 20:39:09 +0200	[thread overview]
Message-ID: <87618i20qa.fsf@debian.uxu> (raw)
In-Reply-To: 093d7e9f-5049-4bf0-8ebb-3c1cb1b3db2d@googlegroups.com

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


      reply	other threads:[~2015-04-26 18:39 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-25  3:44 no empty (zero) string predicate in Elisp Emanuel Berg
2015-04-25  9:26 ` Nicolas Petton
2015-05-16  9:23   ` Nicolas Petton
2015-05-16 13:22     ` Bozhidar Batsov
2015-05-16 13:28       ` Bozhidar Batsov
2015-05-16 13:36         ` Bozhidar Batsov
2015-05-16 13:46           ` Eli Zaretskii
2015-05-16 13:43     ` Stefan Monnier
2015-05-16 15:27     ` Drew Adams
     [not found] ` <mailman.1583.1429954907.904.help-gnu-emacs@gnu.org>
2015-04-25 11:22   ` Emanuel Berg
2015-04-25 13:30 ` Stefan Monnier
     [not found] ` <mailman.1591.1429968677.904.help-gnu-emacs@gnu.org>
2015-04-25 14:48   ` Pascal J. Bourguignon
2015-04-26  2:52     ` Stefan Monnier
2015-04-27 10:28       ` zerop: compiler macro vs defsubst (was: no empty (zero) string predicate in Elisp) Nicolas Richard
2015-04-27 12:19         ` zerop: compiler macro vs defsubst Stefan Monnier
     [not found]     ` <mailman.1626.1430016741.904.help-gnu-emacs@gnu.org>
2015-04-26  4:06       ` no empty (zero) string predicate in Elisp Pascal J. Bourguignon
2015-04-26 21:25         ` Stefan Monnier
2015-04-26  4:26       ` Rusi
2015-04-26 12:36   ` Emanuel Berg
2015-04-26 15:03     ` Pascal J. Bourguignon
2015-04-26 18:34       ` Emanuel Berg
2015-04-26 18:59         ` Marcin Borkowski
     [not found]         ` <mailman.1658.1430074770.904.help-gnu-emacs@gnu.org>
2015-04-26 19:06           ` Emanuel Berg
2015-04-26 20:11             ` Marcin Borkowski
     [not found]             ` <mailman.1662.1430079142.904.help-gnu-emacs@gnu.org>
2015-04-27  1:00               ` Emanuel Berg
2015-04-26 17:28     ` Rusi
2015-04-26 18:39       ` Emanuel Berg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87618i20qa.fsf@debian.uxu \
    --to=embe8573@student.uu.se \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).