Lambda the Ultimate

This statement will, of course, allways continue to be true...

For example, both Perl and Python are dynamic, in the sense that you need not declare a type when first assigning to a variable. But while Perl's typing is weak -- you can just assign a date to a variable that holds a number or a string -- Python's is strong. Once a variable has a value, Python cares very deeply about what its type says that thing can or can't do.

I confess that I really don't understand this comparison. Either that, or he's just wrong:

  [dhcp107136: mmh]$ python
  Python 2.2.1 (#1, Dec  4 2002, 20:47:08) 
  [GCC 3.2.1] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import time
  >>> x = 5
  >>> x = "hello"
  >>> x = time.localtime()
  >>> x
  (2003, 8, 27, 10, 31, 18, 2, 239, 1)
>>>

Isn't this precisely what he was saying you can't do in Python? I admit that I really don't remember a single thing about perl, so maybe somebody else understands the point that he was making?

With the best intentions, it's hard not to get distracted and confused when languages are used as short-hand for some more specific idea. Language implementations are too varied and our experience of them too particular.

IDE for a Pascal-like language?
Delphi? ETHs Oberon-2 workstations? XDS Oberon-2 that compiles so fast it might-as-well-be incremental compilation?
Oh! "Pascal-like" is being used as short-hand for 1970 command-line tools. I seem to remember using a DEC 10 Lisp implementation just like that.

At least "dynamic checking" (latent typing) means something concerete. But when you simply talk about "dynmaic" languages, and discuss typing, nobody really knows if you are thinking about weak type systems, run time type checking, type systems/semantics pairs you don't like (0 is not a boolean, damn it), component technologies, or about something completely unrelated like high order languages, or interactive shells. [The list above is not meant to be comprehensive...]

I think more bits are wasted yearly due to people prefering the all too generic term "dynamic languages," than we can sustainably produce.

Compiling fast is not the point, although it is a component of the point. The point is the programmer's *overall* experience in an interactive environment. A large component of the overall experience is the unit of work supported by a language.

Strongly typed, dynamically checked, imperative, OO languages like Lisp, Smalltalk, and Python, in my experience have a different feel by being more "manipulable" in an interactive environment. For example they are easier to build and test programs by evaluating smaller expressions and creating test data more easily.

Systems like Delphi, Think Pascal, Energize (for C++), VA for Java, etc. are very useful, but have not had the same feel in my experience. I think the language design makes it more difficult on tool developers even when the tool developers have experience with the more dynamic languages. (Energize and VA are the two in this latter category I know of.)

I could go along with this terminology. More to the point.

I just noticed this statement in the introduction to Pierce's TaPL: Terms like "dynamically typed" are arguably misnomers and should probably be replaced by "dynamically checked," but the usage is standard."

IDEs that separate out the unit of work and also provide context, seem better to me as-well: working on a method rather than a file, evaluating isolated expressions rather than a file.

Perhaps statically checked languages make providing this functionality more difficult for tool developers. Certainly there are a large number of programmers who have become accustomed to larger units of work and see no particular need to change - that really makes things difficult for tool developers.

$foo is a scalar, and will always be a scalar, and will always hold a scalar value. It does not hold an integer, or a string, or a float, or a reference, or a filehandle--it holds a scalar. When taken in a particular context that scalar may provide a more restrictively typed value, but that does not mean that the scalar itself is more restrictively typed.

I could understand that if it ended with "static type system."

Maybe I don't understand Lisp, but I thought that the dynamic checking that it uses was based on labelling values with types. If that is the case, then it seems somewhat unhelpful to say that a language that relies on system of types does not have a type system.

In contrast, for example, Tcl is dynamically checked, but has no types (or one, which he already notes as equivalent to none).

If you don't allow Lisp a type system, then how do you distinguish between these two languages (Lisp and Tcl)? Is the distinction unimportant?

(When I was thinking about posting this here, I planned to add the rider that I didn't want to start a pointless argument about the pros and cons of Lisp and dynamic typing, as currently on ll1, but I see that's just been posted here, so I guess maybe I need to go looking for the signal in that noise... ;o)

Type system: A collection of type rules for a typed programming language. Same as static type system.

Ah. Thanks.

But still, how do you then distinguish between Lisp and Tcl? Maybe it's outside the scope of this paper, but it seems (to me) to be an important difference, if you're going to argue that this terminology should be used in general discussion.

I guess I'm being pointlessly pedantic now - I asked because I thought I'd misunderstood something (either Cardelli's paper, or the distinction between Lisp and Tcl). I agree that a standard - even a possibly not-quite-perfect - nomenclature is better than none.

Many recent cross-postings between comp.lang.functional & comp.lang.lisp were misunderstandings about whose definition was being used, or ownership disputes over unqualified use of 'typed' 'type system' ...

In that paper, Cardelli didn't seem particularly interested in 'untyped' languages.

how do you then distinguish between Lisp and Tcl?
What happens if you do something like "hello"/5 in Tcl?

You distinguish Lisp and TCL by their function definitions.

Lisp (and by Lisp I mean mainly Common Lisp and Scheme) define funtions on strings, others on numbers, and so on for arrays/vectors, symbols, etc. These functions were designed to expect specific types of objects and in most cases cause a failure of one kind or another if other types of objects are applied to them.

TCL-like behavior could be defined within these Lisps. Just define new functions that expect specific types of objects but provide TCL-like behavior rather than fail. Rather than fail on unexpected object types, define the rules by which those objects will be coerced to others of the expected type before applying the function.

in tcl, "foo/5" (or whatever the correct syntax is) is (i believe) an operation on two strings ("foo" and "5") that would indicate an error in some way because one of the string values cannot be handled by the function. in lisp, in contrast, the compiler/runtime distinguishes between strings and integers because they have different types (typically they are tagged; they have different internal representations). in lisp, the information that is used to avoid forbidden errors is additional to the value.

since i have used neither for more than trivial programs, i may be wrong here, but that is the difference that i feel cardelli's ontology misses.

actually, i vaguely remember something about the last version of tcl (8?) moving away from what i described above to something more like lisp, for speed.

Why do we care about the distinction you're making - is it more than an implementation detail from a 'type system' perspective? (I've no idea - this isn't a trick question).

(define saved-/ /)
(define (/ x y)
  (let ((x (if (string? x) (string->integer x) x))
        (y (if (string? y) (string->integer y) y)))
     (saved-/ x y)))

This is essentially what TCL does with types as opposed to Lisp. The difference between TCL and Lisp is / as opposed to saved-/.

Yes, I have asked myself the same question (Patrick clearly feels it's irrelevant). I've found three answers:

- An ontology should be sufficiently flexible to cover even marginal cases. The difference does exist, so we should be able to talk about it. Isn't everything "implementation detail"? How is this argument different from saying that everything is Turing complete, and/or that the halting problem means types cannot prove programs correct? In other words, whatever distinction we make is qualitative (and I think one of the good things about Cardelli's paper is that he's careful to make explicit these subjective decisions).

- This kind of detail is important. There is a difference between "5" and 5 in Lisp; there isn't in Tcl. That difference appears in programs - it's important to programmers. And it must be important to people with more theoretical concerns - how do we discuss the interaction between "types" and classes in Lisp if we don't have a vocabulary for the types? What about something like CMUCL, where type declarations are optional - isn't that interesting (and how would that work in Tcl?)?

- It doesn't matter :o)

Alternatively, I think you can say that from Cardelli's perspective it is irrelevant. He's concerned with static type systems and nothing else (as previous posts here have shown, perhaps embarassingly, I have little sympathy for the smug lisp weenies, but even I winced at the way he dismisses Lisp). But it is possibly, vaguely, relevant if we're choosing a vocabulary to use in discussions here, where wider issues are discussed.

I've found that thinking of Smalltalk as 'untyped' in Cardelli's terms is quite helpful. Maybe it's unusual to think of Smalltalk as being both 'untyped' and 'having "concrete" types' without seeing a contradiction ;-)

I think the syntax of each language is relevant. TCL's makes it easy to do string processing. Lisp's makes it easy to do more general programming in the large.

I think the distinctions that TCL and Lisp make toward, say, "5" and 5 are also relevant. But the point I want to make is that this distinction is more of a style distinction than a deep theoretical or implementation distinction.