On Types, Part III: typedef

So I had some time to think about if the stuff I have written previously about types in Babel-17 makes sense. I came to the conclusion that most of it does, but that I’d like to make a couple of major changes to how I described it previously. Like before, types live within modules. Unlike before, there is no (pattern) operator :>. Also, the syntax for typedef is different. Its syntax now is:

typedef name pattern = expr

You can see that a type definition via typedef looks quite a bit like a normal definition via def. The analogy stretches even further: You can have multiple definitions for the same type:

typedef name pattern_1 = expr_1
typedef name pattern_2 = expr_2
….
typedef name pattern_n = expr_n

The semantics of the above is that a new function name is defined which allows you to create new values of type name. This new function takes an argument x and returns a value that has type name and inner value x and outer value expr_i where i is the smallest index such that pattern_i matches x. In case no pattern matches, the exception TypeError is thrown.

Note therefore that in general a value in Babel-17 has three components: a type, an outer value, and an inner value. With respect to all messages except the rank_ message, a value behaves just like its outer value.

The type name of a value v is accessible via

typeof v

Alternatively, you can test if v has type name via the pattern

v : name

Note that types are ordinary values in Babel-17. If you have such a value t which is a type, you can test if v has type t via

v : val t

The value that denotes the type name can be obtained via

(: name)

Therefore, the following two patterns are identical:

v : name
v : val (: name)

The outer value of v is accessible only indirectly via the messages that are sent to v and handled by its outer value.
The inner value of v is directly accessible, but only in the same scope in which name has been defined, via the pattern

name x

This pattern matches if the inner value of v matches x.

To make encapsulation possible, a new statement is introduced which can be used in both module and object blocks:

private name_1, … , name_n

declares the definitions name_1, …, name_n to be private to that module or object block. Note that when name_i belongs to a type definition, the type itself is also private. To make the type itself public (= non-private), use (name_i) instead.
Finally, there is the import statement, which allows to import modules and use their non-private definitions and types without the module prefix.

There is the question left on how order is handled for our new types defined via typedef.
To allow for true encapsulation, values of a type t defined via typedef are only comparable with other values of type t. The order among values of type t is the one induced by the order among their respective outer values.

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: