This looks interesting.

Interesting... What about a boo language service for VS.NET?

Class viewer, code folding, code completion and a boo interactive console. Life is good indeed!

Kudos to Daniel Grunwald.

A compiler pipeline is a named sequence of compiler steps. Pipelines are like compilation recipes: CompileToFile, CompileToMemory, Parse, ResolveExpressions, etc.

The good thing about the pipeline abstraction is that it is pretty easy to hook into the compilation process to do all sort of things (see how easy it was to implement the interactive interpreter).

The bad thing about the way pipelines are implemented today is that if you want to customize, let's say, the parser (maybe you don't like syntactically significant white space), you have to change every single pipeline your application is going to use. For a clear example of why the current pipelien architecture is bad, think of the Boo Explorer application. It uses 3 pipeline definitions:

• Parse: for the document outline view
• ResolveExpressions: code completion
• InteractiveInterpreter custom pipeline

Now imagine that you want to use your custom parser step with boox. How would you do it? See the problem? You would have to change code in a lot of places (inside and outside boox!) just to plug in your custom parser.

Another use case would be making boo case insensitive (Hi Doug!).

I was talking about this with Carl Rosenberger (db4o) and he asked me what the problem was :). He replied with something along these lines: "just use some sort of dictionary to hold all the configurable services and make the pipelines aware of it".

Simple.

Let's baptize this glorified dictionary then: Compiler Profile.

A compiler profile represents a set of services that should be used by any given compiler pipeline. Each service in a profile is identified by a well known name (it's not yet clear to me if the name will be something like a string or a System.Type reference). I see the following services right now:

• Parser - don't like to rely on white space?
• Comparer
• OverloadResolutionService - want to implement different rules for overloaded methods resolution?
• TypeSystemServices - want different builtin type names? Different type compatibility rules?

The good thing about this model is that a specific service or profile could be even specified in the command line:

	booc -profile:caseinsensitive foo.boo
	boox -service parser:MyCustomParser,MyCustomAssembly foo.boo

The way I see it it should be very easy to write a, let's say, vb.net compiler based on boo just by providing the right services.

I plan to include this profile thing in the next major refactoring when I'll translate Boo.Lang.Compiler from c# to boo. Thoughts?