SABLE, a Smalltalk-Inspired Language for .NET

Posted by Abel Avram on Apr 21, 2009

Sections

Development,

Architecture & Design

Topics

Language Design ,

Language ,

.NET

Tags

SmallTalk

Keith Robertson, the founder of Kuler Software Tools, has written a Smalltalk-inspired language for the .NET platform called SABLE, a language meant to draw upon the qualities of Smalltalk’s syntax and the benefits of running on CLR.

SABLE is a general purpose, imperative, OOP language with a syntax similar to Smalltalk’s, but the object and deployment model show its affiliation to the .NET family. SABLE programs run on ECMA CLR. SABLE wants to be Smalltalk for the web, a language that preserves the high readability and type safety of the Smalltalk language but with type information included in assemblies and a smaller binary output to make it usable for web deployment.

Robertson declares that his ultimate purpose with SABLE is:

To create a fluid, flexible, Smalltalk-style environment for development, but when you are ready, the application compiles down to an ordinary assembly. … This will give you a highly dynamic development experience without requiring a dynamic runtime.

One of the key benefits of SABLE would be Smalltalk’s messaging syntax allowing for messages to be chained or cascaded. The language is supposed to do type checking at compile time and to support type casting even through message chains, but not only:

|typeDecl| := nodeStack pop.
nodeStack peek ~ {BLOCK_NODE} argumentNodes last~ {ARGUMENT_NODE} typeDeclNode: typeDecl.

The language can do bi-directional type inference, deducting the type of a variable or a method from the expression’s type (outward inference), or deducting the expression’s type from the expected type (inward inference).

SABLE uses method, class and assembly structure definitions for documentation purposes but, unlike Smalltalk, the metadata stays with the assemblies. Macros are always inline methods. An interesting use of macros is to augment existing closed libraries.

SABLE does not have reserved words, but it has a number of predefined identifiers. Other important features are: class extensions, contracts, full access to CLR features like generics, nested types, metadata attributes, etc.

A more than basic “Hello World” example looks like this:

Useful links: The SABLE Compiler (ZIP), the SABLE language web site. 

1. Back to top

   SABLE, a Smalltalk-Inspired Language for .NET

   by Tobias Findeisen

   I am not so sure that folks who haven't experienced the beauty of Smalltalk are convinced by the sample code to try it now without any further explanations. Quite the contrary, I think it will scare them away. No pun intended, just my 2c.

   Reply

2. Back to top

   Re: SABLE, a Smalltalk-Inspired Language for .NET

   by Keith Robertson

   Good point. Thanks for the feedback! I should've made the first program very simple. But then again, it wouldn't teach/show anything. Some things to keep in mind with SABLE. It's made for use in an IDE browser; there it shines! SABLE, like Smalltalk, does not excel in a linear format; there it has to show things that in a browser are displayed better or abstracted away entirely (See sable-language.com/intro/ides-and-fileins.aspx). For example, methods appear in groupings which give their "region" (static, ctor, or instance) and accessibility. This is rather heavyweight when you have only one method in each grouping. But typical apps have many methods of the same kind, and in SABLE, you don't have to repeat that info within each method definition. (BTW, the class and method grouping lines, in green and yellow background, have a more compact form, but it is not self-explanatory as this verbose form is.)
   
   The assembly definition shows referenced assemblies and namespace/class imports -- in the SABLE language. Other languages need this info too, but references often go on a compiler command line (a different language), and imports in the file they apply to. SABLE is not focused on files and lines, but on program structures; in fact, the code can live entirely in an "image" (except for the current need to use an external debugger). There are reasons the assembly def specifies the entry point (so we don't require it has a particular name) and references mscorlib and uses #System. This means for small programs like HelloWorld, it is many more lines than other languages. But 1) this information grows very slowly as the app gets bigger, and for large apps it's more compact and flexible than with other languages. 2) It's boilerplate; you copy it, change what you need, and then mostly forget it. 3) This code contains everything you need to know about how it's packaged and used. In some languages, their Hello "program" consists of ... print "Hello World" ... Okay, but how do I call that specific code from other programs? How is it packaged into an assembly? Etc.
   
   Please take this as (partial) explanation, not argument. I agree with you; my salesmanship needs much improvement.

   Reply

• Older >