Introducing Muse and fxBASIC

Percolating in my mind for many a moon has been an idea of creating a language/runtime that I have called by various names; Muse has been its most recent identifier, named after the divine inspiration of Homer's great epic poem, The Odyssey. She is invoked in its first line:

"Tell me, Muse, of the man of many twists and turns, who wandered far and wide after he sacked Troy's holy citadel; he saw the cities of many men, and knew their mind."

Like any germ of an idea, it began with a high-level goal. The main idea was a middle-tier language that could "do" multiple paradigms, not unlike Mozart-Oz, but on a modern platform, in particular, .NET. In ancient Greek, the word for "man of many twists and turns" in the above translation, is polytropos... thus, Muse was to be the polytropos of .NET languages.

Lately, as I have studied trends in the industry related to concurrent development and learned a lot about how functional languages like Haskell and Erlang are impacting the .NET platform, a variation of the theme has appeared. I still plan to call the runtime Muse, but the language is going instead to be called Functional BASIC, or fxBASIC for short.

People learn what they don't know through what they do know, and considering the number of people who know BASIC in one form or another, I decided the language itself should look and feel as much like it as possible, to aid in adoption. Long term I want this new flavor of BASIC to become MultiBASIC, in recognition of its longer-term multi-paradigm ambitions. Initially I plan to focus fairly strictly on implementing the functional programming paradigm, so there's no point in false advertising at this point.

fxBASIC's goal will be to support all of the semantic capabilities of Erlang, a language that has more than proven its wares in industry--specifically, the very demanding telecommunications industry. Practically, this means that Muse is really all about building distributed applications with the following characteristics:

  • They are highly available;
  • They are widely scalable;
  • They are inherently concurrent, using a message-passing approach built into the runtime rather than the inherently and dangerously complex shared-state approach baked into most languages;
  • They are robust, exhibiting the highest levels of fault tolerance imaginable;
  • They are service-oriented.
In other words, the language exists in the service of a platform that out-of-the-box already provides these software qualities. Just add water. Or rather, in this case, just add business logic code.

One question that I'm still trying to answer for myself is "Why .NET?" Why not Java? Why not compile to the Erlang runtime? All of these are viable options.

My main motivation for .NET is simply that I prefer it and know it better over the other alternatives. BASIC has a richer history on the Windows development platform, and language interop in .NET was something that was built into it from the beginning. All of this sounds like something a wise man might want to leverage. Moreover, new developments like the functional language features and compilers creeping into .NET and new SDK's like the Concurrency and Coordination Runtime (or CCR) make it a most attractive target.

Java is also a very attractive target given its ubiquity, and someday I may create a version for the JVM. But in the Java world, enterprise development is pretty much standardized around J2EE. My idea for Muse, if it has any merit, could do more good in the .NET world, it seems to me, since the story there is less standardized, and therefore more open to new approaches.

Why not make fxBASIC a front end to Erlang, generating BEAM files instead of .NET assemblies? Again, it's a very attractive idea, and one I haven't ruled out. I'm still considering that idea as a first step.

I have another motivation for this project, which is to piece together tidbits of strategies I've learned about compiler construction and use them in this effort. I am enamored of the ideas behind the GOLD parsing system, for example, which treats parse tables as data, and TreeCC, which allows for aspect-oriented construction of ASTs. Somehow I want to try to tie these ideas together into a generic compiler-compiler project. I have christened this one the "LILO DE", as in "Light-weight, Integrated, Language-Oriented Development Environment".

In future posts I'll be describing the spec for Muse and fxBASIC, as well as relating my adventures as I attempt to design and implement them. 

Published Monday, December 31, 2007 1:53 PM by bobcalco
Filed under: , , , ,

Comments

# re: Introducing Muse and fxBASIC

Monday, January 14, 2008 1:50 PM by arunv

F# is a multi-paradigm programming language, targeting the .NET Framework, that encompasses functional programming as well as imperative object-oriented programming disciplines. It is a variant of ML and is largely compatible with the OCaml implementation.

# re: Introducing Muse and fxBASIC

Wednesday, January 23, 2008 9:59 AM by bobcalco

I am aware of, and in fact have been experimenting with, F# and Ocaml. They are both wicked cool in their own right. Ocaml in particular has a phenominally good optimizing compiler.

What I like about Erlang, in terms of my current interest in concurrent programming, is its strict adherence to the message-passing model of concurrency, and the fact that Erlang programs are written with the idea that "everything is a process".

This particular view of the world is, it seems to me, a natural way to specify concurrent behavior. I am enamored of the OTP framework for Erlang, which makes it fairly easy to stand up service-oriented applications that are simple to scale and awful hard to knock down.

BTW I have changed the name of fxBASIC to Concurrent Basic in my head, and I have decided for the time being to target "core Erlang"... a sort of intermediate Erlang that is kind of like IL in .NET. Core Erlang is a stricter subset of "normal" Erlang compiled by the erlang compiler into BEAM files after the compiler has translated the "normal" Erlang to "core".

My goal at a future point then would be to compile from "core Erlang" to IL, once enough of a runtime (Muse) exists to specify equivalent behavior.

I am not so sure this is a doable thing in the current CLR as the CLR does not support fibers (see Joe Duffy's book on this), which would be required at a minimum to model Erlang's "lightweight" threading capability. It may be possible to jig it by writing an "extensible" .NET app, in which you take control over the threading model completely, like SQL 2005 does, but this would be a non-trivial effort. Muse becomes at that point a CLR host... and a lot more work. But perhaps by that time CLR 4 will allow access to fibers directly and that won't be necessary.

My main goal with Concurrent Basic is to create a language that VB guys can begin to their head around because of nominally similar syntax and idioms, but which creates valid Erlang applications.

It's sort of the inverse of Microsoft's strategy. They are trying to introduce functional language features in VB. My strategy is to introduce VB to a functional language.