This post originated from an RSS feed registered with .NET Buzz
by Jonathan Crossland.
Original Post: A Language Abstraction Layer
Feed Title: Jonathan Crossland Weblog
Feed URL: http://www.jonathancrossland.com/syndication.axd
Feed Description: Design, Frameworks, Patterns and Idioms
By the next turn, our industry will be largely focused on functional requirements, modelling and specific languages for specific tasks. However, having 5 different code files for 5 different languages, and having the spec# /*! !*/ syntax is fair enough, but we are setting ourselves up for a much messy, file managing, experience. Take web projects, where we have CSS, HTML, Javascript, ASP-like tags, code behinds, inline code and more. A typical site could have 4 or 5 different languages and technologies, sometimes different environments to edit and so on.
Towards this, I wrote a post on abstracting the code file from the language which is the idea that you don't need to have a physical file that you edit, which contains code, but rather a file that contains xml metadata, modelling, code and everything together which is the input into a "View". The view could be textual code editing, a model or I believe more importantly "any". We should be able to code CSS in a VB like syntax if that is our understanding, and it should not matter to the developer, or the developers of CSS, because the SAL (see below) would help the interpretation.
The language is not important, because I should be able to write vb syntax and have it spit out c# into my file, but I always see it as vb. This can be achieved with this abstraction, I mentioned. If like me, you prefer C#, you can open the file and see it as c#, by simply clicking a language menu option. Likewise, if I only want to see properties, I should be able to toggle this on/off, or if I want to see base class methods of the superclass 'merged' into my current class (grey-code),it should all possible through this abstraction layer, together with other filtering and language oriented viewing features.
The Language Abstraction Layer - LAL
Just like the Hardware Abstraction Layer, which attempts to take details of the underlying hardware away, and just like the Common Language Runtime and Java Virtual Machine, which makes the underlying software platform irrelevant. We need a LAL, that provides "views" (code editor, model) and abstracts the code files away to some lessor human importance. Although you still write code, that code is quickly absorbed into the AST. Although you can model code, its is absorbed into the AST
The Software Language Family Syntax (SLFS) is now needed, as we move into Domain Specific Languages to standardize the syntax family. A DSL should be able to be awarded a family status.
So a DSL created for process flow, and is based on the standards of basic, would then become Family-Name as in BASIC[Pflow] could be written in VB.NET or C[PFlow] in C#.
Family Compliance
The DSL should then be awarded a family, if the conditions of the family have been met. Further a level of which that family has been implemented. So let's say Cascading Style Sheets, is of the C family. It only passes one of the C Family requirements, the {} and ;
Level 1: {} ;
Level 2: keywords, variables, operators assignment
Level 3: functions, parameters
and so on.
For each Family such a Compliance test could be automated with a compliance tool.
Parsers, semantics, interpreter
In fact, the compliance can be implemented as part of the SAL, and therefore certain information could be understood, by the SAL. The Family Syntax and level would enable the SAL to conduct certain semantic checks, perhaps even with the correct level, build an Abstract Syntax Tree, available for tools such as the Editor, which inserts the code from the AST, and not from a file on disk. Such a thing could be especially useful and reachable within the .NET, Visual Studio environment, as an AST can be built from the code, and presented in your editor. This would now spit out the language of your choice to the disk. Your need for the code file to be in a certain language is minimized if not redundant. You would also be able to view the same code in Visual Basic, while I view it in C#, and under the hood it could always be C#, or MSIL or something else entirely.
The semantics of a language family, and the parsers for each language would work in conjunction with each other to provide a single view.
Power of the IDE
So throwing the language away as a first class asset, and replacing it with a View, generated by the Development Tool. Our Integrated Development Environments, should be more powerful, and the code file, less powerful. The interpretation of the code file, the metadata and so on, need not be visible in notepad at all. In fact, its dangerous. So just like Visual Studio protects us from breaking a variable name that is in use, by offering refactoring tools to rename it everywhere, so to must our environment stop us from breaking other things, higher up. To get to a level where Visual Studio, fxcop, unit tests, languages, references, versioning and all of these things are more tightly managed, and more freely exchangeable without breaking things.
So if a change a Class, Visual Studio, refactors reachable code. That is if it can find the class you renamed in your solution. But it cannot go further and tell you that there are 4 projects on the drive that require this refactoring too! For Visual Studio to get to the "Next Generation", it must understand more, increase its scope, and powers. Having a SAL, is part of that solution.
User Stories
User Story - Language
You write code in your editor, it looks and feels exactly the same. A colleague comes over who is VB.NET oriented, you switch your editor View, to show VB.NET. In your discussions you want clarity on the base class, and less cluttered window, so you toggle the properties and fields off, and click the base class visible toggle, which now makes all the base class methods and code, visible within your current editor window. You can edit the base class method right there, and it will change. (its not actually there anyway, but Visual Studio knows where it is).
Now your colleague asks you to paste in a function that he found on the internet. It is useful for this class even though it was written in Visual J# for .NET. You quickly change your view to Visual J# and paste the code in. The code, although it was written by someone else in a totally different coding standard, as you paste it in, visual studio alters it to suit your current settings for J#, when you then switch back to c#, the standard is changed according to your c# settings.
In fact you will never see other formatted code in your editor, unless you disable your code formatting toggle button.
User Story - Speculative design
I now would like to view my code at a higher level, and I want to experiment with some code changes. We have design-time and run-time, I would like to introduce a better "design-time" (perhaps named something else). I view a class diagram, and zoom out, I now see Assemblies, I zoom in, I see classes, I see links and references between my classes outlining the relationships. I now hold alt-key and drag one of the classes, which like mitosis, creates a ghost clone. I now edit this class, changing methods, and it refactors the names as I am doing it, throughout the project. But it is never committed. I can run the code, it will run and work with this new ghost clone, but it does not actually exist. This is outlined a little more in What I want from a modelling tool. If I want it, I can 'bake' it. I click a button and it is now the new replacement class. The older class is checked in before the new one, thus I still get versions and can still roll back.
User Story - Debugging and seeing the larger picture
So you are debugging code, and it steps into many levels. You step from class to class following the call chain.
What you need is the entire call chain, method after method, in one code file, one function below the other. It is not the entire code file or functions of all classes or a physical file. Rather in your editor, you simple see the functions all lined up in one code view, temporarily, while you debug. Stepping into each function debugs you through the same window. It would never leave that particular window. You now decide to step over a method. If you do, you can remove that method from your editor window. Finally you are left with one function that is the culprit in your window. You now click a "show in class" button, which seamlessly, you see the method, but within the class it actually belongs with all the other code. You never load a new file. It simple fades in. Your current cursor line is unchanged, with no disruption to your editing of that function.
User Story - CodeGen and Injection
I have a new project in front of me. I know I need some person class, login, profile of some kind, and a list of books they can check out to read. I would like to build this quickly, but I also want it to be done properly. So I write the following code-like syntax, it converts it (generates) the code, however it has round trip, as it comes back to the template.
[code:c#]
class Person
{
private string _Name;
/*left out other fields*/
public Person() { }
public string Name
{
get
{
return _Name;
}
set
{
_Name = value;
}
}
public string Surname
{
get
{
return _Surname;
}
set
{
_Surname = value;
}
}
public string FullName
{
get
{
return _FullName;
}
internal set
{
_FullName = value;
}
}
public DateTime DateOfBirth
{
get
{
return _DateOfBirth;
}
internal set
{
_DateOfBirth = value;
}
}
public void Create(Person person)
{
}
public Person Read()
{
}
public void Update(Person person)
{
}
public void Delete(Person person)
{
}
}
//changes the template
[/code]
So if I now had a new property to the class, it will add a new %prop% command in the template. If I add custom code, it will add the custom code to a <%code{ //code here }%> command in the template. Think of the commands as compatible with code snippets. Now in the class itself, I can add a <%logException%> command, which when baked, becomes code that is injected in, and add to the template. You can then build up templates from code and vice versa all day.
[code:c#]
class Person
{
private string _Name;
/*left out other fields*/
/*left out other properties*/
public void Create(Person person)
{
%logException%
}
public Person Read()
{
}
public void Update(Person person)
{
}
public void Delete(Person person)
{
}
}
//which changes the template
%CRUD(Create(%LogException%))%
[/code]
This means that a generator could generate the class in vb.net instead of c#, easily using the template.
Software Factories
What I am speaking of here is not Software factories, but a tool for software factories and the developer to use interchangeably. You dont need the Factory to create these templates, to view code in an abstracted form, but a Factory can put a Domain spin onto it. A Factory would be a source of the Person class. The factory would have the blueprints, the Framework repository and things of that relational metadata to generate and use this abstraction layer.
Conclusion, of some sort
DSL's will provide us with even more to learn, more to manage and its still all going to be textual. We need this sort of abstraction to take DSL's and modeling and everything else into the next generation of software editing (not code editing).
Previous Topic
