«

Chris Smith wrote:
> Chris Uppal <> wrote:
>
>>>I'm unsure whether to consider explicitly stored array lengths, which
>>>are present in most statically typed languages, to be part of a "type"
>>>in this sense or not.
>>
>>If I understand your position correctly, wouldn't you be pretty much forced to
>>reject the idea of the length of a Java array being part of its type ?
>
> I've since abandoned any attempt to be picky about use of the word "type".

I think you should stick to your guns on that point. When people talk about
"types" being associated with values in a "latently typed" or "dynamically typed"
language, they really mean *tag*, not type.

It is remarkable how much of the fuzzy thinking that often occurs in the
discussion of type systems can be dispelled by insistence on this point (although
much of the benefit can be obtained just by using this terminology in your own
mind and translating what other people are saying to it). It's a good example of
the weak Sapir-Whorf hypothesis, I think.

--
David Hopwood <>

Pascal Costanza wrote:
> Chris Smith wrote:
>
>> Knowing that it'll cause a lot of strenuous objection, I'll
>> nevertheless interject my plea not to abuse the word "type" with a
>> phrase like "dynamically typed". If anyone considers "untyped" to be
>> perjorative, as some people apparently do, then I'll note that another
>> common term is "type-free," which is marketing-approved but doesn't
>> carry the misleading connotations of "dynamically typed." We are
>> quickly losing any rational meaning whatsoever to the word "type," and
>> that's quite a shame.
>
> The words "untyped" or "type-free" only make sense in a purely
> statically typed setting. In a dynamically typed setting, they are
> meaningless, in the sense that there are _of course_ types that the
> runtime system respects.
>
> Types can be represented at runtime via type tags. You could insist on
> using the term "dynamically tagged languages", but this wouldn't change
> a lot. Exactly _because_ it doesn't make sense in a statically typed
> setting, the term "dynamically typed language" is good enough to
> communicate what we are talking about - i.e. not (static) typing.

Oh, but it *does* make sense to talk about dynamic tagging in a statically
typed language.

That's part of what makes the term "dynamically typed" harmful: it implies
a dichotomy between "dynamically typed" and "statically typed" languages,
when in fact dynamic tagging and static typing are (mostly) independent
features.

--
David Hopwood <>

Quoth David Hopwood <>:
> Pascal Costanza wrote:
> > Chris Smith wrote:
> >
> > Types can be represented at runtime via type tags. You could insist on
> > using the term "dynamically tagged languages", but this wouldn't change
> > a lot. Exactly _because_ it doesn't make sense in a statically typed
> > setting, the term "dynamically typed language" is good enough to
> > communicate what we are talking about - i.e. not (static) typing.
>
> Oh, but it *does* make sense to talk about dynamic tagging in a statically
> typed language.

Though I'm *seriously* reluctant to encourage this thread...

A prime example of this is Perl, which has both static and dynamic
typing. Variables are statically typed scalar/array/hash, and then
scalars are dynamically typed string/int/unsigned/float/ref.

> That's part of what makes the term "dynamically typed" harmful: it implies
> a dichotomy between "dynamically typed" and "statically typed" languages,
> when in fact dynamic tagging and static typing are (mostly) independent
> features.

Nevertheless, I see no problem in calling both of these 'typing'. They
are both means to the same end: causing a bunch of bits to be
interpreted in a meaningful fashion. The only difference is whether the
distinction is made a compile- or run-time. The above para had no
ambiguities...

Ben

--
Every twenty-four hours about 34k children die from the effects of poverty.
Meanwhile, the latest estimate is that 2800 people died on 9/11, so it's like
that image, that ghastly, grey-billowing, double-barrelled fall, repeated
twelve times every day. Full of children. [Iain Banks]

Pascal Costanza wrote:
> Rob Thorpe wrote:
>> Pascal Costanza wrote:
>>> Matthias Blume wrote:
>>>> Pascal Costanza <> writes:
>>>>
>>>>> (slot-value p 'address) is an attempt to access the field 'address in
>>>>> the object p. In many languages, the notation for this is p.address.
>>>>>
>>>>> Although the class definition for person doesn't mention the field
>>>>> address, the call to (eval (read)) allows the user to change the
>>>>> definition of the class person and update its existing
>>>>> instances. Therefore at runtime, the call to (slot-value p 'adress)
>>>>> has a chance to succeed.
>>>>
>>>> I am quite comfortable with the thought that this sort of evil would
>>>> get rejected by a statically typed language.
>>>
>>> This sort of feature is clearly not meant for you. ;-P
>>
>> To be fair though that kind of thing would only really be used while
>> debugging a program.
>> Its no different than adding a new member to a class while in the
>> debugger.
>>
>> There are other places where you might add a slot to an object at
>> runtime, but they would be done in tidier ways.
>
> Yes, but the question remains how a static type system can deal with
> this kind of updates.

It's not difficult in principle:

- for each class[*], define a function which converts an 'old' value of
that class to a 'new' value (the ability to do this is necessary anyway
to support some kinds of upgrade). A default conversion function may be
autogenerated if the class definition has changed only in minor ways.

- typecheck the new program and the conversion functions, using the old
type definitions for the argument of each conversion function, and the
new type definitions for its result.

- have the debugger apply the conversions to all values, and then resume
the program.

[*] or nearest equivalent in a non-OO language.

--
David Hopwood <>

genea wrote:
> [...] NOW that being said, I think
> that the reason I like Haskell, a very strongly typed language, is that
> because of it's type system, the language is able to do things like
> lazy evaluation, [...]

Lazy evaluation does not depend on, nor is it particularly helped by
static typing (assuming that's what you mean by "strongly typed" here).

An example of a non-statically-typed language that supports lazy evaluation
is Oz. (Lazy functions are explicitly declared in Oz, as opposed to Haskell's
implicit lazy evaluation, but that's not because of the difference in type
systems.)

--
David Hopwood <>

Marshall wrote:
> Joe Marshall wrote:
>
>>They *do* have a related meaning. Consider this code fragment:
>>(car "a string")
>>[...]
>>Both `static typing' and `dynamic typing' (in the colloquial sense) are
>>strategies to detect this sort of error.
>
>
> The thing is though, that putting it that way makes it seems as
> if the two approaches are doing the same exact thing, but
> just at different times: runtime vs. compile time. But they're
> not the same thing. Passing the static check at compile
> time is universally quantifying the absence of the class
> of error; passing the dynamic check at runtime is existentially
> quantifying the absence of the error. A further difference is
> the fact that in the dynamically typed language, the error is
> found during the evaluation of the expression; in a statically
> typed language, errors are found without attempting to evaluate
> the expression.
>
> I find everything about the differences between static and
> dynamic to be frustratingly complex and subtle.

Let me add another complex subtlety, then: the above description misses
an important point, which is that *automated* type checking is not the
whole story. I.e. that compile time/runtime distinction is a kind of
red herring.

In fact, automated type checking is orthogonal to the question of the
existence of types. It's perfectly possible to write fully typed
programs in a (good) dynamically-checked language.

In a statically-checked language, people tend to confuse automated
static checking with the existence of types, because they're thinking in
a strictly formal sense: they're restricting their world view to what
they see "within" the language.

Then they look at programs in a dynamically-checked language, and see
checks happening at runtime, and they assume that this means that the
program is "untyped".

It's certainly close enough to say that the *language* is untyped. One
could also say that a program, as seen by the language, is untyped.

But a program as seen by the programmer has types: the programmer
performs (static) type inference when reasoning about the program, and
debugs those inferences when debugging the program, finally ending up
with a program which has a perfectly good type scheme. It's may be
messy compared to say an HM type scheme, and it's usually not proved to
be perfect, but that again is an orthogonal issue.

Mathematicians operated for thousands of years without automated
checking of proofs, so you can't argue that because a
dynamically-checked program hasn't had its type scheme proved correct,
that it somehow doesn't have types. That would be a bit like arguing
that we didn't have Math until automated theorem provers came along.

These observations affect the battle over terminology in various ways.
I'll enumerate a few.

1. "Untyped" is really quite a misleading term, unless you're talking
about something like the untyped lambda calculus. That, I will agree,
can reasonably be called untyped.

2. "Type-free" as suggested by Chris Smith is equally misleading. It's
only correct in a relative sense, in a narrow formal domain which
ignores the process of reasoning about types which is inevitably
performed by human programmers, in any language.

3. A really natural term to refer to types which programmers reason
about, even if they are not statically checked, is "latent types". It
captures the situation very well intuitively, and it has plenty of
precedent -- e.g. it's mentioned in the Scheme reports, R5RS and its
predecessors, going back at least a decade or so (haven't dug to check
when it first appeared).

4. Type theorists like to say that "universal" types can be used in a
statically-typed language to subsume "dynamic types". Those theorists
are right, the term "dynamic type", with its inextricable association
with runtime checks, definitely gets in the way here. It might be
enlightening to rephrase this: what's really happening is that universal
types allow you to embed a latently-typed program in a
statically-checked language. The latent types don't go anywhere,
they're still latent in the program with universal types. The program's
statically-checked type scheme doesn't capture the latent types.
Describing it in these terms clarifies what's actually happening.

5. Dynamic checks are only part of the mechanism used to verify latent
types. They shouldn't be focused on as being the primary equivalent to
static checks. The closest equivalent to the static checks is a
combination of human reasoning and testing, in which dynamic checks play
an important but ultimately not a fundamental part. You could debug a
program and get the type scheme correct without dynamic checks, it would
just be more difficult.

So, will y'all just switch from using "dynamically typed" to "latently
typed", and stop talking about any real programs in real programming
languages as being "untyped" or "type-free", unless you really are
talking about situations in which human reasoning doesn't come into
play? I think you'll find it'll help to reason more clearly about this
whole issue.

Thanks for your cooperation!!

Anton

David Hopwood wrote:
> Pascal Costanza wrote:
>> Rob Thorpe wrote:
>>> Pascal Costanza wrote:
>>>> Matthias Blume wrote:
>>>>> Pascal Costanza <> writes:
>>>>>
>>>>>> (slot-value p 'address) is an attempt to access the field 'address in
>>>>>> the object p. In many languages, the notation for this is p.address.
>>>>>>
>>>>>> Although the class definition for person doesn't mention the field
>>>>>> address, the call to (eval (read)) allows the user to change the
>>>>>> definition of the class person and update its existing
>>>>>> instances. Therefore at runtime, the call to (slot-value p 'adress)
>>>>>> has a chance to succeed.
>>>>> I am quite comfortable with the thought that this sort of evil would
>>>>> get rejected by a statically typed language.
>>>> This sort of feature is clearly not meant for you. ;-P
>>> To be fair though that kind of thing would only really be used while
>>> debugging a program.
>>> Its no different than adding a new member to a class while in the
>>> debugger.
>>>
>>> There are other places where you might add a slot to an object at
>>> runtime, but they would be done in tidier ways.
>> Yes, but the question remains how a static type system can deal with
>> this kind of updates.
>
> It's not difficult in principle:
>
> - for each class[*], define a function which converts an 'old' value of
> that class to a 'new' value (the ability to do this is necessary anyway
> to support some kinds of upgrade). A default conversion function may be
> autogenerated if the class definition has changed only in minor ways.

Yep, this is more or less exactly how CLOS does it. (The conversion
function is called update-instance-for-redefined-class, and you can
provide your own methods on it.)

> - typecheck the new program and the conversion functions, using the old
> type definitions for the argument of each conversion function, and the
> new type definitions for its result.

The problem here is: The program is already executing, so this typecheck
isn't performed at compile-time, in the strict sense of the word (i.e.,
before the program is deployed). It may still be a syntactic analysis,
but you don't get the kind of guarantees anymore that you typically
expect from a static type checker _before_ the program is started in the
first place.

(It's really important to understand that the idea is to use this for
deployed programs - albeit hopefully in a more structured fashion - and
not only for debugging. The example I have given is an extreme one that
you would probably not use as such in a "real-world" setting, but it
shows that there is a boundary beyond which static type systems cannot
be used in a meaningful way anymore, at least as far as I can tell.)

> - have the debugger apply the conversions to all values, and then resume
> the program.

In CLOS, this conversion is defined as part of the language proper, but
this is mostly because Common Lisp doesn't make a sharp distinction
between debugging capabilities and "regular" language features. (I think
it's a good thing that there is no strong barrier against having
debugging capabilities in a deployed program.)


>[*] or nearest equivalent in a non-OO language.


Pascal

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

David Hopwood wrote:
>
> Oh, but it *does* make sense to talk about dynamic tagging in a statically
> typed language.

It even makes perfect sense to talk about dynamic typing in a statically
typed language - but keeping the terminology straight, this rather
refers to something like described in the well-known paper of the same
title (and its numerous follow-ups):

Martin Abadi, Luca Cardelli, Benjamin Pierce, Gordon Plotkin
Dynamic typing in a statically-typed language.
Proc. 16th Symposium on Principles of Programming Languages, 1989
/ TOPLAS 13(2), 1991

Note how this is totally different from simple tagging, because it deals
with real types at runtime.

- Andreas

"Rob Thorpe" <> writes:

> Andreas Rossberg wrote:
>
> > No, variables are insignificant in this context. You can consider a
> > language without variables at all (such languages exist, and they can
> > even be Turing-complete) and still have evaluation, values, and a
> > non-trivial type system.
>
> Hmm. You're right, ML is no-where in my definition since it has no
> variables.

That's not true. ML has variables in the mathematical sense of
variables -- symbols that can be associated with different values at
different times. What it doesn't have is mutable variables (though it
can get the effect of those by having variables be immutable
references to mutable memory locations).

What Andreas was alluding to was presumably FP-style languages where
functions or relations are built by composing functions or relations
without ever naming values.

Torben

Darren New wrote:

[me:]
> > Personally, I would be quite happy to go there -- I dislike the idea
> > that a value has a specific inherent type.
>
> Interestingly, Ada defines a type as a collection of values. It works
> quite well, when one consistantly applies the definition.

I have never been very happy with relating type to sets of values (objects,
whatever). I'm not saying that it's formally wrong (but see below), but it
doesn't fit with my intuitions very well -- most noticeably in that the sets
are generally unbounded so you have to ask where the (intentional) definitions
come from.

Two other notions of what "type" means might be interesting, both come from
attempts to create type-inference mechanisms for Smalltalk or related
languages. Clearly one can't use the set-of-values approach for these purposes
One approach takes "type" to mean "set of classes" the other takes a
finer-grained approach and takes it to mean "set of selectors" (where
"selector" is Smalltalk for "name of a method" -- or, more accurately, name of
a message).

But I would rather leave the question of what a type "is" open, and consider
that to be merely part of the type system. For instance the hypothetical
nullability analysis type system I mentioned might have only three types
NULLABLE, ALWAYSNULL, and NEVERNULL.

It's worth noting, too, that (in some sense) the type of an object can change
over time[*]. That can be handled readily (if not perfectly) in the informal
internal type system(s) which programmers run in their heads (pace the very
sensible post by Anton van Straaten today in this thread -- several branches
away), but cannot be handled by a type system based on sets-of-values (and is
also a counter-example to the idea that "the" dynamic type of an object/value
can be identified with its tag).

([*] if the set of operations in which it can legitimately partake changes.
That can happen explicitly in Smalltalk (using DNU proxies for instance if the
proxied object changes, or even using #becomeA, but can happen anyway in less
"free" languages -- the State Pattern for instance, or even (arguably) in the
difference between an empty list and a non-empty list).

-- chris