The Y^# Language — Rationale

DSL Breeding Issue

A Concern, Though

But now, unless I missed something, Oslo does not explicitly (or, at all) address this two-fold concern :

1 — The design consistency scalability across all those domain-specific languages to come — if there is no "formalized knowledge" available to DSL processing tools, in one form or another, about those DSLs' design intent;

2 — The ensuring that those DSLs will interoperate gracefully enough with each others, at the level of their design intent — as languages, through their respective supporting tools.

This seems to be out of Oslo's scope so far, about which the Oslo development team is of course with no doubt still very busy working at the design and implementation levels for their current priority features.

Language Design Intent

Meanwhile then, I figure an approach to address this concern above, by having us, DSL inventors / implementors, express our DSL's designed semantic "intent" — i.e., what should our DSL preferably be used for — what does an instance of it want to mean overall — with clues about how to properly give an interpretation when tools process its instances.

This is to ease, organize, the proper re-use and combining of our-DSL-based tools by / with other tools out of our direct control regarding their implementations.

Q: But, Should It Actually Be A Concern, Anyway? — A: This Concern Has A Background

Time will tell if I am right or wrong on that matter, but my feeling (intuitive, yes, but I speak with some experience, too) about domain-specific languages' design regarding their expected use cases, goes mainly like this :

While it is probably a bad idea — i.e., not really "dangerous", but rather, unrealistic and unconstructive — to try to control / restrain, organize, contractualize the semantic "openness" of general-purpose languages, it is likely to be a good idea to do it, conversely, when it comes to the more domain-specific languages.

Q: Could You Be More Specific? — A: I Know Software Dev. People, I Am One Of Them — They Will Want To Reuse And Combine DSLs And Processing Tools / Apps

Language Capability Discovery

On the constructive side of that above thinking, it is for the sake of helping to devise, build, and use more practical tools, thanks to the being informed about interesting "meta linguistic" capabilities of yet unconsidered DSLs — in respect to a given need for a specific tool, for a precise purpose.

Safer Language Reuse

And, on the more coercitive side of the thinking, it is for the sake of experiencing a lower probability in the building and use of tools that would choose to pick up and to process "the wrong" DSL for their actual purpose as tools vs. the DSL's inventor's intent for his / her DSL.

Q: How Did This Idea Come To You? — A: I Have Memory

Actually, I sort of realized "all of a sudden" that Oslo, by (hopefully) enabling an easy construction of languages and implementations, is shifting us into a new paradigm. And I don't mean it (paradigm) like someone from the marketing, just "for the hype". No, I really mean it : if Oslo has the success it is hoping for, it will really be a new paradigm. But, this shifting itself thus will have a big and unwanted side effect, "shortly" after the initial adoption and enthusiasm for Oslo (years? a decade? ... no idea there), if we don't acknowledge it and handle it, given the state of the current object-oriented paradigm we are in, and doing so properly, if possible.

Not acknowledged and not handled, that could lead Oslo to fail in its goal eventually "after a while", after a promising beginning. In my opinion, that would be a shame then because we could maybe be ending with putting the blame on a technology otherwise fairly sound and friendly, trying to replace it all with something else maybe. Who knows.

Anyway. Here it is :

This is all about the problem of transmitting the "intent" (or part of intent) of a provider towards its clients — when you have no proof system / checker to compute formally that intent.

By "intent" I think of it as a context-free generalization of the context-bound purpose : I mean, it is why the provider exists in the system we are considering, or, what for this provider is useful for the overall system's logics, and not just for a local (in time, space) utilization.

In our current object-oriented paradigm, "intent" comes from providers' implementations and is roughly a set of aspects of the providers' semantics (programs' or object-oriented type systems', as you wish).

But with Oslo's shift, which promotes languages/models as first-class objects, "intent" needs to be redefined; it is instead, I think, a set of aspects of those languages' definition itself.

The versioning problem in former paradigms was just a specific exhibition of this problem. I remembered those days where we knew "DLL Hell" — for which the versioning problem was not just about interfaces that evolve, it was also about evolving implementations behind interfaces (i.e., the so-called function "exports") that would not evolve, and then the core issue there, was then :

the "intent" brought by the new implementation (new version) — or, semantics, if you like — could not "breathe" / be exhibited to the clients — because there was no "signal" to alert the latters (i.e., not even an interface change).

And it has been pretty much the same problem later on with COM, though the paradigm in context was different (object-oriented, binary components-based, etc).

Today, things are fairly better with .NET (even without widespread use of software proof systems) precisely thanks to possible metadata, available to client implementations to adapt their behaviour according to those "markers" bound to, or queryable at-, their providers' implementations. Thus .NET's metadata allow us to transmit a part of the provider's intent. And in the metadata-equipped .NET, the use of metadata for that is critical in many layers, for transmitting this (partial) intent from providers to clients. We don't really want to go back in a state, where metadata would not be available for frameworks and applications, given the way we are now designing systems. It's too late : we are too much familiar with the use of it, for our analyzing problems and finding/designing solutions for them, in our brains.

Q: And So What? — A: The Stake Is To Have Oslo Scale Well — Just Like .NET Did

Now, Oslo moves us forward : in addition to the runtime type system present in .NET itself, we will have to deal with an abstract, "intangible", language system the objects of which are abstract and intangible because they are (domain-specific-)languages / models. But still, we will use them through DSL processing tools implemented with Mg and the likes. There, if we do nothing "by default" we will not allow those languages' clients to have clues about how (what) the languages are intended to be used (for) in the context of the client that is using them (i.e., processing an instance of them). Therefore, if we want to provide such clues (metadata) at their nature's level, we may need to do it through an object of the same nature : an instance (phrase) of a language — hence, Y#, to investigate for a solution accordingly to this idea.

The Proposal

Idea

I want to allow the DSL's designer to provide somewhere (formalized in Y#) what he/she considers to be the most important facets of his/her language's design intent, should the language be re-used or "extended" through the "looking glass" of processing tools other than the language's reference implementation(s).

I do not try to implement a semantic check / proof system of any kind. The simpler and easier plan I follow — for now — is just to provide means of expression of intended semantics' "clues" about the DSL at hand through annotations / metadata.

Scope

The use of metadata is not new to anyone, of course, be it even in the context of a meta language like Y# the domain of which is about help for the design and implementation of actual domain-specific languages.

The only one unusual aspect of Y# — as far as I know — as a meta language, is there, actually :

for its purpose, Y# doesn't need just to use the kind of (meta) language definition constructs we can encounter in Mg to define a language, for example — instead, Y# needs to use even higher level metadata-like constructs that "talk" about properties of the language (definition) itself (usually expressed in a Mg specification for most of it, but not exclusively).

Rather unusual, since we are talking here about attaching a form of "metadata" to / about the language itself, to express its intent (that you can also roughly see as the action of looking at the whole set of incompletely defined language's semantics — a rather "horrible" thing to look at, I do reckon — but still bringing, I think, useful information).

Purpose

Bear in mind that Y# is for now a lot less interested in formalizing the exact, comprehensive intended semantics' definition of the subject language (which is, granted, not easy, to say the least) — than, instead, just expressing a set of well-chosen^(*), discrete, high-level annotations about the language definition's relevant properties regarding its design intent. That's what I called "meta linguistic" knowledge earlier, that Y# wants to provide to DSL processing tools and their users.

^(*) that the DSL's inventor "picked up" from his/her point of view

Thus, Y# is obviously not able to automatically enforce the respect to such facets about the DSL's intended semantics in processing tools for that DSL. And, tool implementors will remain free to make profit or to just ignore that metadata exposed from that DSL's design statement thus expressed. But of course, when such information is available, I would strongly encourage them not to ignore it.

While I am aware that the last point can be seen as a weakness in the proposal, I would also say there that it is not as regretable as it seems. For, again, the idea is to be able at least — before doing hopefully better later(?) — to provide a set of formalized clues about the DSL's design intent — and instead of just doing nothing at all.

I believe that this "weaker" path chosen here for both practical and theoretical reasons is still useful enough to be followed.

"Conclusion"

By the Oslo's paradigm shift :

the DSL/model (design) intent is to the language/model's client (that is, the program/component that accepted the language/model and interprets it)

what

the .NET type's metadata usage is to the type's client — (that is, the program/component that loaded the type and invokes it)