[TYPES] Types of expressions in dynamic languages: "un-typed" or "uni-typed"?

Laurence Tratt laurie at tratt.net
Wed Jan 8 12:29:36 EST 2014


Sam Tobin-Hochstadt wrote:

> In the general case, the implementation of a language like Python must be
> implemented so that there's exactly one "type" internally, and all Python
> values fit into that type. You can see this if you look at the Python C API
> -- there's the `PyObject` type, and it represents anything in Python [3]. 

In CPython (and at least a couple of other VMs whose internals I know), the
full description of what's going on can give one a different impression. It's
not that the above is wrong but there's more than one way of looking at this.

In essence, such VMs use C's type system to implement a sort of structural
typing system, so that different primitive thingies (e.g. ints, floats, file
handles, network sockets etc.) can be dealt with [1]. The basic property of C
that makes this work is that elements in a struct are never reordered.
PyObject has a corresponding macro PyObject_HEAD which expands to the same
struct elements as PyObject. You can therefore make a subtype / extend
PyObject [use whichever language makes you most happy!] with the following
idiom:

  typedef struct {
      PyObject_HEAD
      // Everything after here is the extra information of the subtype
      int blah;
  } New_Type;

So, yes, every "user object in memory" can be referenced as a PyObject*; but
the object may have extra data in it (of differing sizes) which means it can
also be referenced as a New_Object* (users have to know when to cast things
appropriately). This could be taken to mean there are two different static
types. The fact that this gives a subtyping flavour to things muddies the
waters considerably: is there one static type or an arbitrary number of them
in the VM? does the fact that this is semi-hidden from the end-programmer
effect how we should count things? do FFIs which enable the user to deal with
arbitrary chunks of memory mean that they can add primitive types, and that,
even dynamically, the number of types isn't fixed? I don't know that there
are good clean answers to these questions.

In summary, I'm not sure this gives any weight for or against the uni-typed
argument. And since no-one can enforce a specific terminology on others, I,
and many others, will continue to use the terms "statically typed" and
"dynamically typed" to try and sidestep ambiguity. Either way, I'm reasonably
sure that the world will keep turning, programs will keep running, and this
debate will reappear on an annual basis.


Laurie

[1] There are various other ways VMs could implement the same behaviour as
    the above; this is merely one way, albeit a convenient and efficient
    one.
--
Personal                                             http://tratt.net/laurie/
Software Development Team                                http://soft-dev.org/
   https://github.com/ltratt              http://twitter.com/laurencetratt



More information about the Types-list mailing list