O.I.L. - Scripting Language Foundation
Greetings,
I'm just posting to ask the users here what would be some good ideas for the scripting language foundation I'm writing would be. The framework is written for languages targeting the Microsoft .NET Common Language Infrastructure (ECMA-335). The project's name is the Objectified Intermediate Language, or OIL for short.
The framework I'm writing differs from a single language in that it's the core that drives the language(s) that use it.
Here's a bit more background information, it's a lot, so if I lose anyone, please ask questions. I've been researching parts of this on my own for a number of years, so if I use terminology you're not familiar with, let me know. So far I'm planning for the following features:
Lambda Expressions/Statements
Anonymous Types - You define the properties and the type of each property is inferred from the values provided, the immutability of each property is also defined either explicitly (Visual Basic, key keyword) or implied by the language (in C# the properties are immutable, always)
Anonymous Quick Drafts - Defining simple types that implement equally simple interfaces, you define the methods/properties they implement inline using lambda-derived syntax and standard assignment operators. The idea is to have a modified lambda expression syntax, except instead of omitting the name you merely define the name to relate back to the interface member. One benefit to this is really the scope awareness your AQD has, which is derived directly from Lambda Expressions/Anonymous Methods/Closures.
State Based Enumerator Generator
Type-Parameters with constructor constraints, validation of the type-parameters is handled upon type-initialization. The core framework also does pre-compilation validation for languages that utilize the framework for verification.
Short-circuiting for logical operators in expressions.
Extension Methods
Language Integrated Query
The bulk of these features come from the fact that I'm implementing a code generation system, and one of the languages in this generation system is the Common Intermediate Language (formerly Microsoft Intermediate Language, or MSIL). Since the CIL is the bare bones language that defines all others on the CLI, I have to make all of the features already to support the language. So I figured why not just take it a step further, and make a intermediary framework that will sit atop the framework I'm already making that will handle the work necessary to restructure the code from its 'high level' down to the level the CIL works at.
Utilizing a structure that defines a language's innate support information, relative to the features I've described, the base implementation of the Code Translator can emit code on a given language and rewrite the code it emits to the language's specifications. The main idea is to allow for cases where you want a compiler for your language, you'd use the standard CIL translator that would tune the results to your language and then to the limitations of the CIL (the things it can do and the things it needs help with).
Naturally there are limitations to this, features that cannot be rewritten because you either support things like pointers, or you don't; however, things like Anonymous Methods and otherwise can be restructured for any language to support so long as the code follows bare limitations of the core language, CIL.
Since the core of the project focuses around code generation, I'm going to write another framework to support the FSA concepts necessary to write a parser and Concrete Syntax Tree builder for a given language. The actual code will be emitted in one of the supported translators.
The end goal of the project will be to allow someone to write their parser in their own language, and have it compile its next incarnation. I haven't researched production grammars enough to know if a standard language description grammar will be enough to generate the translator and parser for any given language. I figure by the time I get most of this done, I'll be able to do so with little difficulty.
The progress level of the project is pretty low. I understand a lot of the concepts and the necessary transformations that will be necessary for the system to work. I'm presently still fleshing out the primary AST, OIL itself. I'm nearly 80% complete with the OIL framework, and once it's able to emit non-transformation necessary languages, I'll be able to work on the CIL translator. Once it's finished, I can focus on the Parser generator (of which I've made a simpler version in the past that was fairly successful, functionality wise, it was just a research project that got a bit unsightly).
Hopefully some people here can give further insight into what might be interesting to see the foundation be capable of. It's ... beyond ambitious; however, it's something I enjoy, so it's not likely to die off any time soon (eight months and counting so far).
Have you looked at Microsoft's Dynamic Language Runtime? It sound very similar to what you are talking about, and is used by the IronPython (Python on .Net) and IronRuby (Ruby on .Net) teams. You may want to either see if they will let you contribute to their project, or see how your project fills a different niche than the DLR.
Quite, the project is very similar to the Dynamic Language Runtime; however, it's also different in its underlying structure (and goal). Since the primary focus of the OIL infrastructure itself is to aid in code generation, it'll be geared towards that end, but it will also double as the AST for other common languages that would like to utilize common language structures outlined by the foundation.
The actual parser builder and other language building functionality is part of a project larger than the OIL infrastructure, called the Scripting Language Foundation (SLF).
The DLR's goal from what I can tell is strikingly similar, yet, at the same time, different. It's more geared towards dynamically typed languages, while mine's more geared towards statically typed languages; however, it's hard to say if it'll maintain such focus for its entire development. It depends on how plausible it is for me to implement such features, and whether the trade-off is worth it (refer to how the DLR handles dynamic typing in a static type core).
The primary reason I mentioned a large set of the scripting language functionality in a topic titled 'OIL' is due to the fact that the project's Common Intermediate Language translator will require a large portion of the features mentioned to be implemented.
The actual parser builder and other language building functionality is part of a project larger than the OIL infrastructure, called the Scripting Language Foundation (SLF).
The DLR's goal from what I can tell is strikingly similar, yet, at the same time, different. It's more geared towards dynamically typed languages, while mine's more geared towards statically typed languages; however, it's hard to say if it'll maintain such focus for its entire development. It depends on how plausible it is for me to implement such features, and whether the trade-off is worth it (refer to how the DLR handles dynamic typing in a static type core).
The primary reason I mentioned a large set of the scripting language functionality in a topic titled 'OIL' is due to the fact that the project's Common Intermediate Language translator will require a large portion of the features mentioned to be implemented.
True; however, I doubt there'll be confusion considering the differences between the names. OiL and OIL mean ORB in Lua and Objectified Intermediate Language, respectively. It's pretty hard to confuse the two.
There's also already oil in large quantities around the world, as a fossil fuel. I doubt people would confuse OIL for it, either.
There's also already oil in large quantities around the world, as a fossil fuel. I doubt people would confuse OIL for it, either.
It sounds like an interesting project. It would be lovely not to have to go into the nitty-gritty of code generation when targeting a new language for .NET (and if one can get away with using it for multiple targets through your framework, it's even better). I don't see why you're limiting it to scripting languages in particular though, since it seems static typing is more prevalent in programming languages that don't call themselves scripting languages.
Is there any support for structural typing (aka. static duck typing)? It would make anonymous types that much more useful.
In any case, I just wanted to know how's progress on it?
PS. I'd also like to know if you know of any similar projects.
Is there any support for structural typing (aka. static duck typing)? It would make anonymous types that much more useful.
In any case, I just wanted to know how's progress on it?
PS. I'd also like to know if you know of any similar projects.
Would it support monkeypatching for a static-typed language across assemblies? Or even a dynamic typed language?
During runtime I have assembly 1 loaded and have an instance of class Door, I then load assembly 2 which has code that calls Knock(). I can now call knock on the same instance. Then I unload assembly 2.
egAssembly 1:class Door void Ring()Assembly 2:class Door void Knock()
During runtime I have assembly 1 loaded and have an instance of class Door, I then load assembly 2 which has code that calls Knock(). I can now call knock on the same instance. Then I unload assembly 2.
Umbrae, that would be useless! You could never call Knock, since it can't be guaranteed statically that the method is available.
This requires dynamic typing (or a way to escape static typing, such as reflection).
(correct me if I'm wrong)
This requires dynamic typing (or a way to escape static typing, such as reflection).
(correct me if I'm wrong)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement