Re: why not "stripes" in: (let ((zebra 'stripes) ... ; strings vs symbols?

[Emanuel Berg]

Yuri Khan <yuri.v.khan@gmail.com> writes:

>> Couldn't you somehow annotate data: '('integer 1)
>> and then prior to assignment run an appropriate
>> test: (integerp ... )
>
> You could but it becomes unwieldy pretty soon. One
> does not simply tell programmers “instead of literal
> 1, you have to write '('integer 1)”. You also incur
> run-time tests at each use.

For sure, if anyone actually did that, just plain with
no automatizing or preprocessing, it would be
grotesque.

But let's think about how Lisp processing is often
illustrated, not as an endless list but as nested lists
that folds into a tree, with the functions (the first
element of each list) as root or parent (inner) nodes,
and with data as leaves.

If every function node was annotated with argument
types, and a return type, then the whole tree (list)
could be fed to a type checker to see if all input
types are consistent with the output types
(i.e., the return values and argument types all match).

The types of data could be checked at the leaves,
because there it is known what type is expected, so a
single check would be enough.

What would complicate matters is for example the
addition function (+), as

(floatp   (+ 1.0 1)) ; t
(integerp (+ 1   1)) ; t

So such cases would have to be replaced by one-type
equivalents unless the uncertainty could somehow be
"bounded", I suppose by "mixed" types, as in 'number'
(integer *or* float, etc.).

If I would ever use it though, I doubt. I just never
felt the need to think about types in Lisp.

>> But I still don't understand the benefit of having
>> the types explicit in code, apart from the mentioned
>> compiler type-check - is there anything else to it?
>> Could you overload functions based on types? (And:
>> do you *want* to do that?)
>
> In C++, we do that a lot. We have an operation to write
> an object into a text stream that’s written as “stream
> << object”, where stream is a special class type
> representing a file opened for text output, and object
> is anything for which operator<< is overloaded. This
> allows us to define streaming separately for each type,
> not in a single universal function with a gargantuan
> type-switch on the outermost level. (The closest lispic
> solution that springs to my mind would be to annotate
> each object with its type and then have an alist
> mapping types to functions, but this incurs the cost of
> run-time type information and the dynamic alist lookup,
> whereas C++ type-based overloading is resolved at
> compilation time.)

That's true, in C++ it is a very vivid concept. You can
have two classes and then overload the + function, and
then have to instances seemingly "added" but in fact
that operator is setup to whatever turn of events or
data change the programmer sees fit.

I remember they didn't want to allow that in Java
because they were afraid over-creative programmers
would setup all kinds of overloads that would sooner
rather than later render unreadable code. (But Java has
overload, just not down to the bare bones like C++.)

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