Vesa Karvonen wrote: > In comp.lang.functional Anton van Straaten <[EMAIL PROTECTED]> 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/ -- http://mail.python.org/mailman/listinfo/python-list
