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

[Yuri Khan]

On Thu, Jan 2, 2014 at 9:31 PM, Emanuel Berg <embe8573@student.uu.se> wrote:
> Rustom Mody <rustompmody@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.

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


> Could the compiler perform
> optimizations if there are, for example, only integer
> (and no float) arithmetic?

Could, and can, and routinely does. It is, in fact, a form of function
overloading — just that the functions being overloaded happen to
reside in the standard library and compiled to inline code rather than
a function call.

> Or is it just a safety-net
> so you don't get overflows and truncations and thus
> bugs that are very difficult to track? Why is this not
> an issue in Lisp?

It is. The Emacs Lisp manual specifies that integers are at least 30
bits long and that overflow is not checked. The syntax parser (reader)
automatically parses integral literals bigger than the machine integer
as floats (which may lead to silent loss of precision).

Also, when a library changes the type of some variable (e.g. in v1 it
was an integer, in v2 it is *either* an integer *or* an alist mapping
mode symbols to integers), the clients of that library break at run
time, possibly in the middle of some involved operation, with half of
its side effects already applied and an obscure error message to the
end user’s face. With type checking, they would break at compile or
link time.