Gosu Released

It isn't for purists, but there are some interesting features, like the open type system.

http://gosu-lang.org

Cheers,
Carson

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Confused

Would love some more explanation of the strange phrase "supports custom type loaders that dynamically inject types into the language".

The documentation is less than helpful.

Basically

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

Still confused

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.

It's a compiler hook

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

I.e., no type inference.

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.

Sure

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

Wording

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?

Heh

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

Clear now

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

What's the point?

At first glance, I'm not seeing any plausible use cases for something like this. If I were going to use a static-typed JVM language with direct Java interop that's not Java, what does this offer over Scala?

Nor does it help that the "comparison" table proudly announces at least two outright misfeatures, includes the questionable assertion that transitioning to Scala is difficult, and the close ties to Java makes me expect that "type safe" isn't accurate either.

My best guess is that the design concept of this language was basically "here's the best Java-like language we can create for people who are frightened by Scala"... in which case I wish you the best, but is there really a market in "new languages for people terrified of novelty"?

Yeah

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

Fair enough!

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.