New CLR Language: Boo

This project is very interesting: a CLR-based language with Python-esque syntax, optional type declarations, open compilation pipeline, and some interesting ideas about generators and class attributes. There are some unique ideas about running a dynamic language atop the CLR, as well, like syntax to declare "duck" typing for individual objects, which lets you use them as dynamic proxies for COM objects, web services, etc.

It's definitely a bit green, but if even a significant fraction of the features discussed in the "manifesto" are there, it looks like an impressive effort, regardless.

Comment viewing options

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

Compared to Python


Thanks for the summary, Ian.

Optional dynamic ("duck") typing

Occasionally I see a language where the default typing is dynamic but you can optionally specify types, usually for optimization (i.e Common Lisp). But in Boo, there's the opposite: static typing by default with dynamic if need be (COM is a good example).

What other languages have this capability? Objective-C is the only one I can think of (with its "id" type). I wish I saw it more often.

Optional dynamic ("duck") typing

Clean has this capability in the context of a Haskellish type system. It is used for persistence and dynamic code loading.
What mystifies me is that in spite of a larger, richer featureset than Haskell, most functional coders don't seem to consider Clean at all. But maybe I'm missing something (my knowledge of both languages could be stronger).

licence confusion? i think i

licence confusion? i think it used to have a more restrictive licence. even now, it's lgpl, which *i* think means i can use it but have to supply source if i extend the language. but reading the clean site they imply i have to supply source to code i develop with the language.

boo is business friendly

but reading the clean site they imply i have to supply source to code i develop with the language.

Where did you get that impression from? Just let me know and I'll update the website.

The current license allows you to do pretty much whatever you want with boo. The main restriction is that if you want to redistribute a modified boo version you must also share your changes (improvements/fixes/whatever) with the community. At least that's my reading of it.

The next version will be under BSD to leave less room for confusion.

they started talking about "Clean"

They stopped talking about Boo and started talking about Clean and the Clean website.

Uops... Thanks :)

Uops... Thanks :)

He wasn't the only one confused...

From Don Box's Spoutlet:

Rodrigo Barreto de Oliveira just went live with a CLI-based language called Boo.

From looking at the Boo Manifesto, I was happy to see static type inferencing and duck typing (both features I've been wanting in my daily programming life). Also cool is the integration with the compilation pipeline.

Unfortunately, no license was to be found, so I stopped at the manifesto.

re: licence confusion

The LGPL does not require you to provide the source of the program that you develop with a compiler. Actually, there are several compilers using the GPL (wich is more restrictive than the LGPL) and you can use whatever license you like for the programs that you develop using them.

"larger, richer featureset than Haskell"

Does it also have a larger featureset than GHC? I am in the middle of my first Haskell project, and I'm finding I'm using a bunch of extensions that I'm sure I would miss if Clean didn't have them (Scrap your Boilerplate, undecidable instances, multi-parameter type classes, functional dependencies, implicit parameters . . . )

Re: Optional dynamic ("duck") typing

Depends on what you call Haskell.

Clean has more features than Haskell 98 but many people use extensions (for example in ghc). Some of these are present in Clean, whilst others are not.

Perhaps the foremost reason that Clean is not widely used is that it's sufficiently different from Haskell to be annoying. Personally, I'd like Clean to move towards Haskell: be the same were we can, and different were we have to. Library compatibility, for example, would be a huge gain. However, the unification costs would be quite large too, so we'll have to see if we can justify them.

Our implementation is distributed under the LGPL, so (I hope) that's not an issue anymore.


Ronny Wichers Schreur

Clean Object I/O library

A couple of years back, there was talk of porting the Clean Object I/O libraries to Haskell. Did that effort ever get anywhere? From what I gather, the libraries for I/O are much better in Clean than similar Haskell offerings.

Re: Clean Object I/O library

Krasimir Andreev continued from Peter and Simon's initial work. I don't know the current status, but the Haskell ObjectIO website hasn't been updated for a while.

He's Created a New Binding

Krasimir decided the existing ObjectIO design was too inefficient when ported to GTK, and so has been working on a more callback-based binding called