Skip to content

First-Class Citizens Languages in Essence

First-Class Citizens Languages, in Essence:

those have to be reified.

Imagine…

Yes, just imagine…

… imagine a modeling platform where domain-specific languages are promoted as first class citizens in the executive environment;

Imagine a modeling platform as ubiquituous as .NET on the host OS, where :
* the type system has become a language system;
* types have become persistent and uniquely named language processing tools;
* object type instances states have become the intermediary and resulting artifacts of language processing tools, serialized in the language system or the underlying type system;
* object type programs and computations have become pipelined workflows of language processing tools, as orchestrated by the modeling platform;
* older OO programs and well known helper Design Patterns can be redone by merely representing those workflows graphically, from a higher level PoV than the CTS’

Imagine a modeling platform where the very definition of a domain-specific language can give clues to processing tools about the most important features possible to occur in its phrases;

Imagine a modeling platform where those clues are just the device homologue to .NET’s metadata, that enables for loosely coupled contracts to cooperate usefully even in the absence of widely available proof checkers;

Imagine a modeling platform where those clues allow the language tools to decide about the proper workflows to follow AND about the relevant artifacts in their own execution context;

Imagine a modeling platform where the modeling logic underneath the execution environment allows for representing not just language-based models and artifacts but the .NET’s CTS itself;

Imagine a modeling platform where model repositories and namespace authorities are just as scalable as the WWW itself, no more and no less;

Imagine a modeling platform where the MS OSLO tooling chain (M, Mg, Quadrant) and its workflows is just a specific configuration of a modeling system;

Imagine a modeling platform where the MetaSharp tooling chain (Lang, Node, Template…) and its workflows is just another competing configuration of the former;

There will enter the second bit of what you will have invented then, namely Y#, with its concrete syntax (still TBD, ongoing work…); but also, and as the first required bit before laying down anything else actually, the core of a reification management and selection semantics (*) — now ready for most of it :

the REGARD URI scheme, and corresponding resource locator (likely to come as a service locator implementation on modeling authorities hosts) :

(*) for both local, in-process and remote, out-of-process liaisons / service locator delegations;

Examples — with a) : mere URI or request over a URL; b) : meaning in plain english; c) : response (in case of URL resolving) :

REGARD — REifying Gateway for Artifact Routing and Discovery

uri : <relative-uri> | <absolute-uri>

relative-uri : <modeling-system-use>

absolute-uri : <scheme> “://” <modeling-registry> <abs-modeling-system-use>

scheme : “regard”

modeling-registry : [ <modeling-system> "@" ] [ <modeling-authority> ]

modeling-system : <modeling-logic-token> [ ":" <modeling-repository-name> ]
/// e.g. “clr”, “clr:gac”, “oslo:Quadrant.3.0.1803.10.CYSA.Cyril”, …

modeling-logic-token : <dotted-identifier>
/// e.g., “clr”, “clr3.5″, “oslo”, “metasharp”, …

modeling-repository-name : <dotted-identifier>
/// e.g., “gac”, “Quadrant.3.0.1803.10.CYSA.Cyril”, …

dotted-identifier : /// e.g., “Acme.Foobar”, “System.Type”, …

modeling-authority : <ontological-self-token> | <valid-inet-hostname>

ontological-self-token : “.”

valid-inet-hostname : /// e.g., “127.0.0.1″, “localhost”, “modeling.microsoft.com”, “regard.justnbusiness.com”, …

modeling-system-use : <modeling-resource-loc> [ <reification-query> ]

abs-modeling-system-use : <abs-modeling-resource-loc> [ <reification-query> ]

abs-modeling-resource-loc : “/” <modeling-resource-loc>

modeling-resource-loc : [ <modeling-resource-path> ] [ <dotnet-type-alike-name> ]

modeling-resource-path : <modeling-resource-path> [ "/" <path-segment> ] | <path-segment>

path-segment : <dotted-identifier>

dotnet-type-alike-name : /// e.g., “System.Type”, “mscorlib,System.Object”, “Acme.dll,Acme.Foobar,Version=…,Culture=…,PublicKeyToken=…”, …

reification-query : “?” [ <reification-spec> ]

reification-spec : <reification-name> [ <reification-purpose-query> ]

reification-name : <dotted-coloned-identifier>
/// as in URNs, e.g., “urn:msil”

reification-purpose-query : “#” [ <reification-purpose-spec> ]

reification-purpose-spec : <reification-purpose-name> [ <reification-purpose-eval> ]

reification-purpose-name : <dotted-coloned-token>

dotted-coloned-token : /// e.g., “Infoset”, “XML.1.0″, “something:v2.0″, “.123.Xyz:Uvw”, …

reification-purpose-eval : “!”

(*) for both local, in-process and remote, out-of-process liaisons / service locator delegations;

Examples — with a) : mere URI or request over a URL; b) : meaning in plain english; c) : response (in case of URL resolving) :

A. Trivial examples, in type systems’ dimension :

1. (asking the authority what modeling logics impl are available, and thru which tokens)
a) => regard://localhost/?
b) what are the modeling logics supported at localhost ?
c) response, e.g. : “regard://clr@localhost/“, “regard://oslo:Quadrant.3.0.1803.10.CYSA.Cyril@localhost/“, “regard://metasharp@localhost/“, …

2. a) => regard://clr:gac@./System.Xml,System.Xml.XmlDocument,Version,Culture,PubKeyTok?
b) what are the possible representation IDs for System.Xml.XmlDocument (in the clr logic) ?
c) response, e.g. : “regard://clr:gac@./System.Xml,System.Xml.XmlDocument,Version,Culture,PubKeyTok?urn:msil

3. a) => regard://clr:gac@./System.Xml,System.Xml.XmlDocument,Version,Culture,PubKeyTok?urn:msil#
b) what are the purposes for the representationurn:msil” of System.Xml.XmlDocument (in the clr logic) ?
c) response, e.g. : “regard://clr:gac@./System.Xml,System.Xml.XmlDocument,Version,Culture,PubKeyTok?urn:msil#class

4. a) => regard://clr:gac@./System.Xml,System.Xml.XmlDocument,Version,Culture,PubKeyTok?urn:msil#class!
b) what does the purposeclass” of the “urn:msilrepresentation of System.Xml.XmlDocument evaluate to (in the clr logic) ?
c) response, e.g. : “regard://clr:gac@./mscorlib,System.Type,Version,Culture,PubKeyTok?urn:msil#.123

5. a) => regard://clr:gac@./mscorlib,System.Type,Version,Culture,PubKeyTok?urn:msil#.123!
b) gets the artifact represented by the above URI/URL (in this case, an instance of System.Type)
c) i.e., the System.Type instance provided by the platform, in the clr logic space, for typeof(XmlDocument)

B. Trivial examples, in language/modeling systems’ dimension :

1. a) => regard://metasharp@./C:/Work/Experiments/w3.org/REC/XML.ms?
b) what are the possible representation IDs for W3C’s XML language, as defined by XML.ms (in the metasharp logic) ?
c) response, e.g. : “regard://oslo@./Repository/w3.org.XML?urn:mgraph

2. a) => regard://oslo@./Repository/w3.org.XML?urn:mgraph#
b) what are the purposes for the representationurn:mgraph” of W3C’s XML language (in the oslo logic) ?
c) response, e.g. : “regard://oslo@./Repository/w3.org.XML?urn:mgraph#Infoset

3. a) => regard://oslo@./Repository/w3.org.XML?urn:mgraph#Infoset!
b) what does the purposeInfoset” of the “urn:mgraphrepresentation of an XML phrase evaluate to (in the oslo logic) ?
c) response, e.g. : “regard://clr:gac@./System.Xml,System.Xml.XmlDocument,Version,Culture,PubKeyTok?urn:msil
(i.e., the System.Xml.XmlDocument type, in the clr logic space &, as determined by the platform, thru the reference implementation processor of XML.ms); etc, etc…

Also relevant :

REST Thesis Chap. 5

Justin’s MetaSharp on CodePlex

Y# Rationale

T1 Lemmas

Yes, I know…

Yes, I know… this has been looking dead since the last post.

The problem was two-fold :

1) it is not easy to design a computer language seriously — there, understand: a sound, practical, and friendly language, properly designed (and then, defined) to actually be capable to meet its announced purpose(s), through its use via good implementations of it;

2) and sadly, I really (… really, really) didn’t have much time left to dedicate to Y#, aside my occupation (which was especially demanding, this year) and the rest of the common, daily tasks/unexpected events one has to get done/to deal with — which, by the way, have included, though were obviously not limited to: my relocation from one continent to the other, with a shift from my first language (fr) to my second (en), my wedding, and the bliss of a new child’s arrival — my second son, four weeks ago.

But I’m now back at it, and if only as a self-encouragement, I have, indeed, started to let some other (possibly interested) people know about my current effort and progress here.

Thanks for continuing to check out where the design of Y# is at, on here, anyway. Thus, “do not worry”; I’m more than ever committing myself to it, and, as the second link above shows, I do more than welcome your volunteer help on it.

‘Soon, then & merry new year 2010 to you!

Welcome to the trip in the design of Y#

I do agree with most of the points of Dan Vanderboom’s Why Oslo is Important.

In some aspects, I can even go further than Dan did in his post about Oslo :

Thus, for instance, I anticipate one thing, not so surprising in its nature, and given what Oslo itself is aiming at.

I think we can expect with Oslo, quick after its forthcoming release, a very important, fast multiplication of domain-specific notations, be they either textual or visual (i.e., graphically rendered in the tooling), and that multiplication will bring us an issue not addressed yet, as far as I know — again, the issue is in the strict sense “just a guess”, but that I have been rather firmly concerned with / thought of a lot for some time now — fairly even before the Oslo announcement last year.

That issue is this very one point — Now, Why Y#? — DSL Breeding Issue — at the crossroads of the rationale for Y#. Read this rationale before anything else if you do not want to waste your time trying to figure “what the hell that Y# is for” — if the rationale speaks to you, then you can read on at the Y#’s resources — and if it does not (at all), well, then of course just go back to more useful things for you, with my apology.

I think the issue will need to be addressed eventually, sooner or later, for a better building upon the Oslo platform — and the sooner the better, as it is often the case. But maybe is it too early? No, I don’t think so : domain-specific languages are not new actually (just have a look at the bunch of them on an OS like Unix/Linux for example — you know… the command-line thing). So, yes, I noticed a number of interesting things over years in the way we approach them, use them, through tools (interpreters, editors, extractors, reformaters, etc). Oslo will enable a lot more of them, and fairly more abstract, sometimes, than today’s average. Hence my thinking all around of this, before figuring out the issue I want to possibly address with Y#.

But the design of a new, “non-toy” computer language is no easy matter, assuming one wants to do it properly in order to actually address what is considered (or anticipated, as it is the case here, rather) a serious concern.

No, it has never been easy to think about and design computer languages. Y# will be no exception in that respect.

This blog, that I hope to feed at the pace of one or so post every couple of days, will try to lay down before the reader my current ongoing process of designing Y# — the language — in a step-by-step, as serious as possible manner, to hopefully end up with a sound, useful, and practical language for its purpose — we will then try to provide a reference implementation for it some time later.