On Types, Part I: Identity and Modules

So, off to the first part of my ramblings about types in Babel-17.  I am not sure how many parts there are going to be, and they are definitely not polished pieces of writing; I am just writing down stuff that is going through my head concerning types in Babel-17.

There seem to be two main aspects of types: identity and functionality. Identity, because the type of a value tells me what this value IS. For example, a type could tell me that some value really represents a poker card. Functionality, because the type of a value tells me what I can DO with a value. For example, given two poker cards, there could be the functionality to compute the odds that I’d have winning with these cards against two random cards in a preflop all-in Hold’em situation.

There are schools that say that the identity of a type is not important, but that we just need to know its functionality.  Proponents of “Duck Typing” usually belong to this school. I do not agree. The identity of a type is crucial when structuring a program. The first thing we know about a type is its identity, we know it often long before we know the final functionality of a type.

The identity of a type seems to me most useful when it has a global quality. An iPod made in Asia remains an iPod after having been shipped to Germany. Therefore it seems natural to embed types into a system of static packages and modules, for example somewhat like this:

module potsized
  typedef pokercard
end

The identity of the defined type would then simply be
potsized.pokercard.
Modules are basically just like user-defined objects in Babel-17, but with a static name and able to contain type definitions. Modules can be nested:

module com
  module potsized
    typedef pokercard
  end
end

would lead to a type with identity com.potsized.pokercard. Above code can be written equivalently, but shorter:

module com.potsized
  typedef pokercard
end

If there are N >= 2 module definitions with the same module name, then they must be compatible. This means that only one of them, the main module, may contain more than just further nested module definitions. This one is always loaded before the other remaining N-1 module definitions. The only messages that the N modules may have in common must belong to nested modules. Nested modules that correspond to the same message must be compatible.

I think that the identity of types in Babel-17 will be simple. For example, there is a type set, and there is a type int, but there won’t be a type set of int. I also think that there will be no subtyping going on in Babel-17: there will for example be a type real, but this type will be neither a supertype nor a subtype of the type int.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: