CoreLang Introduction

There is a common thread throughout this site (although some of the content pre-dates this thinking) which is that concise languages (domain specific languages) should be used to describe business logic, processes, business aims and architectural solutions. Pictures are great to communicate high-level concepts but detailed thinking needs an exact textual description - we do not use flow charts to design programs, not in the last 30 years anyway.

The Domain Specific Language (DSL) section of this site explores different languages and ​uses - but a key concept is that they will have a common metaphor / style and will be modular - will allow a new language to be build using pre-built DSL sub-languages.

Moreover the common compute technology (a common bytecode interpretor) will also support some of the more detailed system architecture - a common compute machine will support distributed computing, for example supporting thin clients and distributed BPM processing.​

​To achieve this we need to define a superset language - if you like a grand unified language which will show what the common syntax will look like. This will provide the ground rules for the different DSL languages we will define and implement - it will provide the common syntax metaphor that will allow developers to feel that the DSL have a common heritage. It will also allow us to define the superset bytecode and assembler language needed for the runtime.

​This language is called CoreLang.

Will CoreLang ever be implemented? I believe the answer is yes in time ... but subset specific DSLs will be implemented first, each a step in the overall CoreLang implementation.​

So the key initial CoreLang deliverable are:​

  • The overall language syntax and draft reference
  • The CoreLang parser
  • The draft bytecode (CLBC) and assembler (CLAL) definition and implementation.

This will provide a firm foundation for early developments of our DSL languages ​and distributed compute capability.

​