Thorn is

a dynamically-typed concurrent language in which lightweight isolated processes communicate by message passing. Thorn includes powerful aggregate data types, a class-based object system, first-class functions, an expressive module system, and a variety of features supporting the gradual evolution of prototype scripts into robust programs.

Thorn is implemented by a compiler targeting the JVM and a Java interpreter, and syntactically resembles Scala, at least superficially.

One of those "features" is a unique (as far as I know) soft type system:

In Thorn, the type dyn (for dynamic) is assumed as default (and never written explicitly). At the other extreme, Thorn supports concrete types, as used in statically typed programming languages. A variable of a concrete type T is guaranteed to refer to a value of that type (or a subtype). [...] While concrete types help with performance and correctness, they introduce restrictions on how software can be used and make rapid development more difficult; scripting languages do not favor them.

As an intermediate step between the two, we propose like types, getting some of the safety of concrete types while retaining the flexibility of dynamic types. Concrete types for var x:T or fun f(x:T) are used in two main places. At a method call x.m(), a static type check ensures that x actually has an m method. At a binding or assignment, like x := y; or f(y), a static type check can ensure that y's value makes sense to assign to x, can reject it entirely, or can inspire a dynamic check. Like types, var x: like T or fun f(x:like T), give the expressive power of concrete type checks on method calls, but do not constrain binding or
assignment. They do require runtime checks and thus may cause programs to fail with runtime type errors: sometimes fewer and never more than dynamic types do.

Concurrency is also a little odd:

Every component (marked by the keyword spawn) runs in a different JVM. Component handles contains sufficient information to identify the node and port on which the component runs.

A couple of papers are linked to the home page; "Thorn - Robust, Concurrent, Extensible Scripting on the JVM", by Bard Bloom, et. al., is a general description of the language, from which come the quotes above; and "Integrating Typed and Untyped Code in a Scripting Language", by Tobias Wrigstad, et. al., with more information about like types.

I have not seen Thorn here before. Apologies if I have just missed it.

Comment viewing options

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


Does anyone have some more information about the open source version mentioned in the article?

Don't think so

In the paper, they say that they'll have an open-source implementation in 2009 on the website. But something seems to have prevented them from bothering to release anything but an online demo and a binary release. I can't find the release anywhere. They must be embarrassed about messy code, or having licensing issues with IBM or something. Either way, the lack of a free, open-source implementation destroys any chance of this language--which sounds well-designed and useful--from gaining any kind of popularity. And popularity is essential for the language becoming useful, because the more popular it is, the more libraries it will have which have an API idiomatic for Thorn, rather than Java.

is critical mass critical?

also you need enough people using it to flush out more (never all) of the bugs and thinkos, and to perhaps drive the tool ecosystem. e.g. things like shen/qilisp2 are great but i'm suspecting their debugging story will be even more sad than that of, say, haskell.

"like types" precedent

The "Integrating Typed and Untyped Code in a Scripting Language" paper cites Cormac Flanagan's "ValleyScript" paper:

which dates from the ES4 heyday (Cormac is on Ecma TC39). Examples at

But we never implemented "like" in the ES4 reference implementation before the ECMAScript 4th Edition work folded.