Lambda the Ultimate

inactiveTopic Creating types at run time?
started 9/28/2002; 2:36:42 AM - last post 9/30/2002; 9:23:34 AM
Michael Vanier - Creating types at run time?  blueArrow
9/28/2002; 2:36:42 AM (reads: 774, responses: 11)
Has anyone ever heard of a computer language where data types can be created at run time? I'm thinking of a case where you don't know what types you will need until your program runs, and then the program creates those types. Ideally it should also be able to do type checking on these newly-created types at run time. I don't have a specific application in mind, but it struck me as curious that I'd never thought of this possibility before; another example of how computer languages put you into conceptual boxes that make you unaware of alternative possibilities.

Ehud Lamm - Re: Creating types at run time?  blueArrow
9/28/2002; 4:06:48 AM (reads: 794, responses: 0)
I actually thought about this myself. I even asked several people about what I called languages with first-class types.

I was then rebuked (by Felleisen or Friedman, I think) for not realizing that not only does this make static typing a bit of a problem, it is almost certain to lead you to undecidable type systems.

The important distinction is between the static universe of types, and the dynamic universe of values (see sk lecture notes).

However, I'd guess that typed languages with rich macro facilities (Ocaml), must provide mechanisms that allow you to do something similiar to what you had in mind.

Michael Vanier - Re: Creating types at run time?  blueArrow
9/28/2002; 4:22:39 AM (reads: 785, responses: 1)
Well, that's good, because that's exactly the context in which the question occurred to me ;-)

Ocaml has a notion of "polymorphic variants" which, in very sharply limited ways, appear to be something like extensible types. This is not run-time extensibility, though. It's more of a modularity issue; when you define a new type you can add constructors to a previously existing variant type (or so I think; the documentation is not easy to understand).

I see what you mean about decidability. However, if you're willing to allow some runtime type errors, you can get away with a lot (he says, not really understanding all the issues involved...).

Ehud Lamm - Re: Creating types at run time?  blueArrow
9/29/2002; 12:52:17 PM (reads: 794, responses: 0)
It seems to me that in most cases, the minute you allow run time types, your type system becomes undecidable. Essentially, when you are doing typechecking you don't want to have to rely on control flow analysis.

Dan Shappir - Re: Creating types at run time?  blueArrow
9/29/2002; 1:17:29 PM (reads: 775, responses: 1)
JavaScript types are defined at runtime. Even the built-in types can be modified at runtime. As Ehud points out, this indeed precludes the ability to perform static typechecking and can thus result in errors that can only be detected using control flow analysis.

OTOH this highly dynamic environment makes it possible to more accurately model some domains, e.g. XML objects. That is, a domain that contains objects whose structure is also only known at runtime. While other languages do provide tools to model such domains, such as associative arrays, the JavaScript approach makes it very natural.

Ehud Lamm - Re: Creating types at run time?  blueArrow
9/29/2002; 1:30:04 PM (reads: 869, responses: 0)
So what's the most amazing hack you could do with run time types?

(Hack n - Something cool. Not a vague reference to the Curry-Howard isomorphism)

Noel Welsh - Re: Creating types at run time?  blueArrow
9/30/2002; 3:33:35 AM (reads: 752, responses: 1)
Scheme allows types to be created at runtime. In fact you can have as many runtimes as you like, thanks to macros. Scheme also supports multiple-dispatch, which may or may not be related to the intent behind the question :-)

The definition of a type is an interesting one. The historical meaning is something like "an interpretation of a bunch of bits". Hence we can say Scheme is strongly typed: you can only provide one interpretation to a bunch o' bits. To the static typing guys types only exist at compile time, so Scheme is untyped. In this framework you can't talk about generating types at runtime.

Ehud Lamm - Re: Creating types at run time?  blueArrow
9/30/2002; 7:14:14 AM (reads: 781, responses: 0)
Types: Not how many bits, but rather what is allowed to do with these bits. I don't advocate this, but can see how this approach can be given meaning in the context of runtime types.

Chris Rathman - Re: Creating types at run time?  blueArrow
9/30/2002; 7:35:23 AM (reads: 744, responses: 0)
As long as we're talking about dynamic types, I'd suggest Smalltalk provides excellent facilities for creating new classes on the fly. Compile is, after all, just another method of the Class meta-class. Creating a type on the fly, though, is only one part of the trick. As important, if not more-so, is the ability to manipulate the new type - reflection and meta facilities make the difference.

From a Smalltalk perspective, types are not defined as bits of data. Rather the type of an object is defined by the messages that it can process. Need to create a new type? Just create a new object and attach message receivers to it - simple as that.

Dan Shappir - Re: Creating types at run time?  blueArrow
9/30/2002; 7:43:23 AM (reads: 828, responses: 1)
I don't know if these constitute hacks, but I can think of some applications for the ability to define types at runtime. Mostly they have to do with representing objects whose structure is only known at runtime or whose structure changes over time.

One example is an object that represents a database records. Most languages and libraries I'm familiar with (ODBC, JDBC, OLEDB, ADO, etc) utilize some sort of standard record container that exposes generic facilities to get at fields (BTW such facilities often invalidate the static type checking of the host language because the field type can only be tested at runtime). VB goes as far as to introduce a special operator to access field content:


With JavaScript you can simply access fields as properties on a record object:




Another scenario I can think of is an object that models a state machine. The object exposes methods that match the functions available at the current state. As the state changes, so do the methods. This is especially compelling if the structure of the state machine is only known at runtime.

Obviously there are solutions for these types of problems using statically typed languages. But many such solutions in effect mimic the dynamic types that JavaScript has (using such constructs as variant containers and associative maps).

BTW I've done my share of hacks in JavaScript (BeyondJS is case-in-point :) Many of these hacks had to do with self-modifying code and code generated on the fly.

Another BTW, some intrinsically static environments let you generate types on the fly, although it's a lot more work.

Ehud Lamm - Re: Creating types at run time?  blueArrow
9/30/2002; 8:08:26 AM (reads: 873, responses: 0)
Objects that represent database records are a cool idea. But the state machine idea I don't get. This amounts to raising an excpetion when an operation is invalid in the current state. So what do I gain by using the type system?

Dan Shappir - Re: Creating types at run time?  blueArrow
9/30/2002; 9:23:34 AM (reads: 800, responses: 0)
I was actually thinking about a scenario where someone with a priory knowledge, such as a user, activates operations on the object via some UI. In any event JavaScript (and I assume other languages that provide runtime type definition) provides facilities for performing queries on an object's capabilities (reflection). In JavaScript accessing obj.prop does indeed generate an error when prop is undefined. obj["prop"] OTOH returns the undefined value. You also have the in operator and the hasOwnProperty method that you can use to determine if a specific property is available for a specific object.

I'm currently also hacking a new module in the Beyond library that implements multiple-dispatch. Its allows you to dispatch on an arguments "type" (its basic type or constructor function), prototype and the availability and type of a property. While this is obviously not the same as static type checking, it does assist in the sense that it makes it easier to write code so that at a specific point you know the object provides the required functionaility.

BTW here is a hack that utilizes self-modifying objects for a bit of improved performance:

X.prototype.calcValue = function() {
    var value = some complex calculation;
    X.prototype.calcValue = function() {
        return value;
    return value;