Why is booleanp defined this way?

Why is booleanp defined this way?

[Marcin Borkowski]

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

Re: Why is booleanp defined this way?

[Jorge A. Alfaro-Murillo]

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.

Re: Why is booleanp defined this way?

[Pascal J. Bourguignon]

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

Re: Why is booleanp defined this way?

[Emanuel Berg]

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

Re: Why is booleanp defined this way?

[Barry Margolin]

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

Re: Why is booleanp defined this way?

[Emanuel Berg]

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

Re: Why is booleanp defined this way?

[Pascal J. Bourguignon]

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

Re: Why is booleanp defined this way?

[Pascal J. Bourguignon]

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

Re: Why is booleanp defined this way?

[Emanuel Berg]

"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

Re: Why is booleanp defined this way?

[Pascal J. Bourguignon]

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

Re: Why is booleanp defined this way?

[Rusi]

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.

Re: Why is booleanp defined this way?

[Emanuel Berg]

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

Re: Why is booleanp defined this way?

[Rusi]

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

RE: Why is booleanp defined this way?

[Drew Adams]

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.

Re: Why is booleanp defined this way?

[Emanuel Berg]

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

Re: Why is booleanp defined this way?

[Barry Margolin]

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

Re: Why is booleanp defined this way?

[Barry Margolin]

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

Re: Why is booleanp defined this way?

[Barry Margolin]

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

Re: Why is booleanp defined this way?

[Rusi]

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. 

Re: Why is booleanp defined this way?

[Pascal J. Bourguignon]

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

Re: Why is booleanp defined this way?

[Pascal J. Bourguignon]

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

Re: Why is booleanp defined this way?

[Barry Margolin]

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

Re: Why is booleanp defined this way?

[Rusi]

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>

Re: Why is booleanp defined this way?

[Stefan Monnier]

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

Re: Why is booleanp defined this way?

[Tassilo Horn]

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

Re: Why is booleanp defined this way?

[Marcin Borkowski]

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

Re: Why is booleanp defined this way?

[Marcin Borkowski]

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

Re: Why is booleanp defined this way?

[Stefan Nobis]

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.

Re: Why is booleanp defined this way?

[Rusi]

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.

Re: Why is booleanp defined this way?

[Emanuel Berg]

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

Re: Why is booleanp defined this way?

[Emanuel Berg]

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

Re: Why is booleanp defined this way?

[Emanuel Berg]

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

Re: Why is booleanp defined this way?

[Emanuel Berg]

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