Re: more closed-world chatter

On May 5, 12:40 pm, "David Cressey" <cresse..._at_verizon.net> wrote:
> "Marshall" <marshall.spi..._at_gmail.com> wrote in message
> > On May 5, 8:50 am, Jon Heggland <jon.heggl..._at_idi.ntnu.no> wrote:
>
> > > > when it comes to the advantage of sub-typing in dealing with
> > > > my question.
>
> > > I don't know about "advantage"; I just don't see how you can avoid it.
>
> > It's easy to avoid: just don't put subtying in the language design.
>
> > Much of the talk in language design in the last ten years or more
> > has focused on various mechanisms for subtyping, but it's an
> > entirely optional language feature. That's easy to forget when
> > it's all anyone's talking about, but it is possible to just leave it
> > out.
> > It's also possible to leave a static type system out entirely.
>
> You've lost me here. As Bob pointed out a few days ago,
> all types can be considered subtypes of the universal supertype.
> Doesn't that mean that all typing is, in reality, subtyping?
>
> If so, how can you implement typing without
> implicitly implementing subtyping?

Be sure to distinguish between a theoretic view of a formal system that is outside the system, and the system itself. We can analyze any type system with set theory, and speak of the universal set, but that doesn't mean the universal set is a concept within that system.

Imagine a programming language with exactly two types: int and string. The language is statically typed, in that every term in a program can be categorized as having one of those two types. Functions arguments are either ints, (+ - * /) or strings (append, length.) Some functions might take one argument of each type: left("hello", 2). Any attempt to use a term of one type as an argument that requires the other type is a compile time error.

This language is statically typed, but has no subtyping whatsoever.

Now, we can certainly speak of the set of all ints and strings, but we can't express anything about that set *within* this language.

Similarly, we can imagine a typed relational language in which every attribute of every relation has a type; all types are disjoint, and any attempt to join two relations that have attributes with the same name but different types yields a compile time error. Is this the nicest thing you could do for the programmer? Probably not, but then again this language can be implemented quite easily and could produce very efficient code.

As always, it's a tradeoff. :-)

Marshall Received on Sat May 05 2007 - 22:17:35 CEST