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