Lambda the Ultimate

There is an API for introducing a new typeloader that the compiler can work against, so you can generate types from whatever resource you like (e.g. xml files) and gosu can access them in a statically typed manner.

The docs are shitty on this part because our customers would never use it, but we'll be improving them going forward. You can see a bit of it here:

http://wiki.jvmlangsummit.com/images/9/97/McKinney-Gosu2.pdf

and in this post on our user group:

http://groups.google.com/group/gosu-lang/browse_thread/thread/e690c686e3ebb91e

Again, Gosu isn't for everyone, but I thought you guys might find some stuff in it interesting.

Cheers,
Carson

Some of the links say something about pluggable type system. Does that mean I can add uniqueness typing or dependent typing if I want to? The linked code looks more like an API for generating class/record structures, but I could be missing something.

Still confused.

All it really lets you do is, given a name, return a type. But you can use that tool to do whatever you like, within the constraints of the syntax of the language.

Cheers,
Carson

All it really lets you do is, given a name, return a type.

Does it return a prototypical object too, or just a type? Can one add (type) arguments to the hook? Maybe you should just give an example.

So, in Java, you implement an interface ITypeLoader which has a method getType( String )

Assuming your typeloader understands (i.e. resolves) the given name, it returns something that implements another interface, IType.

IType interface has all the metadata necessary to compile against (e.g. a collection of IMethodInfos). So the object returned defines the static structure of the type and is used by the gosu parser when parsing Gosu code, allowing Gosu classes (which have their own TypeLoader) to access your ITypes features.

As a concrete example, consider a type loader that produced types for java-style properties files. It would map the name to a given properties file (probably using the directory-filename convention prevalent in java and gosu) and then, for the given properties file, generate a type with accessors for the data in the file.

The point here is that Gosu is agnostic towards how you produce your type information: you can plug in whatever sorts of data you like. This turns out to have a lot of applications for us.

Another example might be examining a db schema reflectively, and generating types off of it.

Hope that clarifies. It's certainly not rocket science, just a formalized way to do metaprogramming.

Cheers,
Carson

So if I get this right then the "type system" is not pluggable or extensible in the normal sense of those phrases. The core type system's judgement rules are fixed. Type constructors aren't usable as types, type parameters are covariant, etc.

What you do have is the ability to plug in the compile time creation of class structures, typically based on external resources. A Java programmer might write a code generator to do the equivalent, but this is cleaner and easier.

Is that about right?

When you put it that way, it sounds so pedestrian... :)

So, it is extensible in that you get to determine the behavior of your types via your implementation of various methods (e.g. IType#isAssignableFrom() ) but, yes, the core of the language is fixed. This mechanism is flexible enough, for example, to support a DynamicType as a bolt on TypeLoader, even though the core language is statically typed.

I've also implemented a protocol typeloader, where objects must simply satisfy the type shape to be assigned to a protocol type, using nothing but the type system.

So, no, it isn't a general extensible type system, in that you can add new rules and/or syntax (although you can certainly have your own syntax in your own resources, I do for my protocol typeloader) but the implementation is flexible enough to support some interesting applications beyond slightly-cleaner-code-gen.

Cheers,
Carson

Ah, now it's a lot more clear. Thanks!

Gosu is a simpler language than Scala. For example, we sacrifice typesafe variance for simplicity with generics. Our hope is to compete with Groovy for the "scala seems too complicated" crowd.

The comparison table is largely a joke, just an intro to the language, with some gratuitous shots at other perfectly fine languages.

It isn't for everybody, and certainly not for most of the LtU crowd, but I thought some guys might see some interesting ideas in there.

Cheers,
Carson

By that metric, it looks like you've done a fine job. If you can bring even a glimmer of civilization's light to those lost in the wild by their own stubborn choice, then I salute you; good luck and godspeed.