Objectified Intermediate Language

Abstraction - Core

2011-09-17T10:07:00.001-05:00

After a few years of working on a side project, aimed at replacing the simpler Code Generation Framework named the Objectified Intermediate Language, I've finally started to get to the point where the functional parity between the two is equivalent. The newer OIL framework allows more and understands the concepts behind true generic typing. The initial tests of constant folding, type-parameter

Build: Refresh

2009-09-04T16:17:00.006-05:00

Well, After two years in the project, I decided a few days ago to start a major overhaul of the compiler's build code. In these two years I learned the basic structure of NFA, DFA, recognizers vs. transducers, look-ahead determination, creating a state-machine which can figure out the look-ahead of the langauge at any given point; however, in all of this, the code has become quite cluttered and

LL(∞)

2009-08-28T18:54:00.011-05:00

Finally,I have the parser compiler somewhere that I can say is progress, and with that, comes knowing that the class of parser I'm writing a compiler for: LL(∞). This still places it in the LL parser category (top-down, left-most derivative); however, it means that the lookahead for the grammars is unbound to any specific k.I've written a very simplistic recognizer (below) to go with the

C♯ Parser

2009-07-25T22:40:00.002-05:00

Well,It's taken a long time and a lot of research but I'm finally making headway on the C♯ parser I've been writing (well writing the parser compiler to write...).Previously, I decided to attempt a backtrack-less, left-most derivation, recursive descent parser. In the end, all the research told me: it's not worth it. Other LL(*) implementations, such as ANTLR, that use recursive descent and

Language Integrated Query - Manual or Aided Objectified Building

2009-06-14T22:58:00.006-05:00

Well,Today's project was implementing an objectified representation of Language Integrated Query. Even before I started, I knew that I wanted it to be as seamless as the original, so I decided to create two variants of the structure: your standard AST form, and a 'builder' form. Where the builder takes responsibility for selecting the proper body type (select, group, select into, group into),

Lambda Expressions - Hoisting

2009-05-22T23:17:00.003-05:00

Just musing over the concept of lambda expressions, AKA. anonymous methods. If what I understand is correct, the entire method of hoisting involves a simple analysis of the scopes involved within the hoist. You'd merely have to create a scope dependency chain within each scope. If a scope depends on another scope, you evaluate the associated variables, and move them forward. This process

Building a framework for compilers...

2009-05-22T01:38:00.016-05:00

I'm taking a break from the Parser Compiler madness to work on some functionality that would be useful for a compiler. It's what I call an AssemblyWorkspace. It's basically a large scale wrapper around the concept of an INamespaceParent (which is also a type parent). In creating an AssemblyWorkspace, you provide it with the assembly that's its 'core' assembly. Typical examples would be the

DFA - Behind the Scenes

2009-04-02T16:08:00.005-05:00

Just posting for anyone interested. Something I learned while handling a large part of the finite state automation code was working with subsets, full sets, and so on. In order to ease the pain of working with a large series of characters, I created a 'RegularLanguageBitArray' which originally wrapped the Systems.Collections.BitArray. One thing I found with using it is with the frequency at

LL(k) Parser - Tail Ambiguity

2009-03-30T20:05:00.004-05:00

One of the fun things of doing it yourself is you learn of some annoying hurdles, the hard way. The most recent of which is what I'm calling 'Tail ambiguity', which is basically a lock created by the required part of a rule after the parsing rule exits. A lock exists with the optional aspect of the parsing rule and the required aspect of (one of) the calling rule(s).A simple example is if you

Look ahead exploration - LL(k)

2009-03-22T18:01:00.004-05:00

Well about a week later, and a few dozen failures, I've learned a thing or two.The initial attempt at a 'syntax tree' yielded a system wherein I had a true tree of the syntax, but the problem was, it didn't do a damn bit of good for a Recursive Descent parser. Extracting the information about which rule was related to what look-ahead was difficult and hackish, at best a guess. Which doesn't

Language Data Analysis and Syntactical Analysis

2009-03-14T15:26:00.004-05:00

Well, presently I'm working on two aspects of the language analysis phase, data dependencies (what it exports in the form of a Concrete Syntax Tree) and Syntactical analysis. Both are turning out to be harder than expected, though the data analysis is a lot easier by comparison than the syntactical aspect. Below is a small snippet from the console (reformatted for reading) that describes the

Context Awareness for Simple Lexical analysis

2009-03-09T06:29:00.009-05:00

I've been working on the project quite a bit lately, the major thing of late is context awareness for state machines. Unlike the much older hack attempt from a year+ ago, which used a radix tree structure or something similar, this uses a proper DFA implementation.Most of the Compiler Compilers I've used seem to use a series of state transition tables (a series of integers that relates to what

NFA - DFA - and so on

2009-03-06T07:55:00.002-06:00

I'd like to say I've been super busy, but the reality is quite the opposite.My job's entered work-share, which means the hours I was working (60+) were cut into less than half.In other news, I decided to use the extra time to focus on some other areas of language research, namely NFA->DFA->Minimal state state machines. So far it's going very well. The next step, since for the scope of the

Duck Typing in a Static Core

2008-09-07T12:47:00.004-05:00

I was reading an interesting blog post that described duck typing and how it helps dynamic languages, and how it works in theory. I'm thinking of a few ways on how this might be feasible to implement, and I think I have one. I'm going to do a few whiteboards on the idea and post back when I get a chance.The basic idea involves use of generics. The full idea will take some time to just map out,

Light Refactoring turns into Major Refactoring

2008-07-26T10:13:00.008-05:00

Well,As much as I'd like to keep the project simple, it hasn't been simple from day one. Due to the features I'm planning on, I figured it best if I restructured the project, the Scripting Language Foundation, into a series of projects. There's the primary Type System, the CLI Type system, and the OIL (Intermediate) Type System. These three systems are best kept separate to help simplify

Light Refactoring

2008-07-03T18:34:00.010-05:00

After a short delay, due to work, I'm back working on this.I'm doing a little clean up work on the core type system and rewriting the assist methods that are associated to the functionality, that's presently broken. This will greatly assist in streamlining the code and reduce the dependency on internal components that were used before. I also hope to be able to open up the type system a little

Constructor Arguments on Generic Type Parameters

2008-05-14T13:55:00.004-05:00

This is something I've wanted on Generics since they first introduced them. It didn't come in version 3.0 or 3.5; however because I'm writing my own Objectified Intermediate Language with the goal of translating the objects into Common Intermediate Language, I can add features similarly to how C#'s compiler adds support for lambda expressions, anonymous methods, closures, and so on.I decided to

Type-Inference - Part 1

2008-05-12T12:50:00.012-05:00

Well,I finally got to a point where I can start the fun challenging aspects involved in the new languages. Smart type inference. I'm just posting a few notes about it for others to either laugh about or reply to. First I'll start with Lambda expressions and how to properly discern a good match from a not-so-good match.Figure 1Basically a lambda signature type, if encountered as a parameter of

C♯ - Fast Array Initialization

2008-05-11T11:13:00.004-05:00

I've been researching the .NET Common Intermediate Language (CIL) lately, and I noticed a few funny things in how C♯ exports array initializers.If you use a primitive type, such as Int32, Int64, Byte, SByte, and so on, instead of creating a new array and initializing each element individually, it merely creates a new array and pushes a RuntimeFieldHandle of a static field stored privately.Now to

Compiled Types - Part II

2008-05-11T11:09:00.000-05:00

Finished the limited load aspect of the Compiled types. Now even if you access a property like so:console.Members["WindowHeight"] <-- the 'Members' will only encapsulate the WindowHeight property. The difference there is the indexer on the Members returns a MasterDictionaryEntry instance instead of a property. The reason for this is in order to make the members dictionary work, I used

Expressions - Primitive Reduction

2008-05-11T11:05:00.003-05:00

Just thought I'd post on the latest changes to the OIL framework, part of the Abstraction framework.Recently I wrote a mini evaluator for the primitive expressions inside the system. This way if you had a statement that, for whatever reason, utilized literal mathematical expressions, it would properly reduce them in such a way that the resulted code would contain the least possible execution to

Compiled Type Optimization

2008-05-11T10:59:00.001-05:00

I was going through the Compiled Type system and was irritated because the system auto-loaded every member, always, whenever you merely accessed the property associated to them.For example, if I have a reference to Console, if I accessed its 'Properties'; before, it would load all the properties (which is fine) and then encapsulate every member with the framework's equivalent. While that's fine,

Introduction

2008-05-11T10:44:00.000-05:00

The Objectified Intermediate Language is a framework I'm writing to help people generate code in three of the .NET's primary target languages. That is:Visual BasicVisual C♯Common Intermediate Language (CIL)To do this, there are a few things I must do, such as provide functionality for the transitory steps necessary to generate CIL for operator overloads, short circuiting, extension methods,