Saying "latently-typed language" is making a category mistake

[Pascal Costanza]

Vesa Karvonen wrote:
> In comp.lang.functional Anton van Straaten <anton at appsolutions.com> wrote:
> [...]
>> I reject this comparison.  There's much more to it than that.  The point 
>> is that the reasoning which programmers perform when working with an 
>> program in a latently-typed language bears many close similiarities to 
>> the purpose and behavior of type systems.
> 
>> This isn't an attempt to jump on any bandwagons, it's an attempt to 
>> characterize what is actually happening in real programs and with real 
>> programmers.  I'm relating that activity to type systems because that is 
>> what it most closely relates to.
> [...]
> 
> I think that we're finally getting to the bottom of things.  While reading
> your reponses something became very clear to me: latent-typing and latent-
> types are not a property of languages.  Latent-typing, also known as
> informal reasoning, is something that all programmers do as a normal part
> of programming.  To say that a language is latently-typed is to make a
> category mistake, because latent-typing is not a property of languages.

I disagree with you and agree with Anton. Here, it is helpful to 
understand the history of Scheme a bit: parts of its design are a 
reaction to what Schemers perceived as having failed in Common Lisp (and 
other previous Lisp dialects).

One particularly illuminating example is the treatment of nil in Common 
Lisp. That value is a very strange beast in Common Lisp because it 
stands for several concepts at the same time: most importantly the empty 
list and the boolean false value. Its type is also "interesting": it is 
both a list and a symbol at the same time. It is also "interesting" that 
its quoted value is equivalent to the value nil itself. This means that 
the following two forms are equivalent:

(if nil 42 4711)
(if 'nil 42 4711)

Both forms evaluate to 4711.

It's also the case that taking the car or cdr (first or rest) of nil 
doesn't give you an error, but simply returns nil as well.

The advantage of this design is that it allows you to express a lot of 
code in a very compact way. See 
http://www.apl.jhu.edu/~hall/lisp/Scheme-Ballad.text for a nice 
illustration.

The disadvantage is that it is mostly impossible to have a typed view of 
nil, at least one that clearly disambiguates all the cases. There are 
also other examples where Common Lisp conflates different types, and 
sometimes only for special cases. [1]

Now compare this with the Scheme specification, especially this section: 
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-6.html#%25_sec_3.2

This clearly deviates strongly from Common Lisp (and other Lisp 
dialects). The emphasis here is on a clear separation of all the types 
specified in the Scheme standard, without any exception. This is exactly 
what makes it straightforward in Scheme to have a latently typed view of 
programs, in the sense that Anton describes. So latent typing is a 
property that can at least be enabled / supported by a programming 
language, so it is reasonable to talk about this as a property of some 
dynamically typed languages.



Pascal

[1] Yet Common Lisp allows you to write beautiful code, more often than 
not especially _because_ of these "weird" conflations, but that's a 
different topic.

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/