Need volunteer help/feedback from stronger academic/competent profiles (on testing T-diags expressiveness with semantics, etc)

Hello all,

I'm really not academic (I don't even have a B. Sci. :(, but I try to keep myself up to date enough on theoretical topics, and that I really care about in general, by the way.

Some background info on my current experiments relevant to this post and some rationale, is available there :

#1 http://www.ysharp.net/the.language/rationale

Not wanting to waste anyone's time, just know upfront that it's about this formerly codenamed "Oslo" and what it is, maybe, missing (as my intuition suspects) for it to scale well enough (— but, as one's own intuition is never enough to draw any useful conclusion to build upon, of course, hence my current effort at formalizing my feeling "at a minimum").

Then, as I intend to publish more about it using a specific notation, and that I leveraged for my purpose, I had to "push the envelope" further with this notation, testing my uncommon usage of it against better known topics, that have been studied for much longer(*) until today.

This is for me to see if that would lead me too easily to anything absurd/unconstructive.

Here's the result:

#2 http://www.ysharp.net/the.language/rationale/T_Party_0.html

If (and only if) this latter draft of ideas is not totally non-sensical to you and you find it interesting enough, I'd love to hear from you and about your advice on how I/we could formalize it more seriously.

Or I'd just love anyone to show me where are the biggest reasoning flaws in my statements.

Note I'm well aware it's unlikely I've found anything really new from a theoretical PoV, but I have some ideas about a hopefully useful application, to address the issue at hand.

Thank you in advance, & merry end of year holidays to all.

(*) (> 70 years or more...)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

From one non-expert...

... I have no comment on your document as of yet, but I would highly recommend you write your forum postings and your documents more clearly.

Right now, the writing style is that of a novel: in order to understand what you're trying to say, people have to read sequentially and hold a lot of details in their head. I'd recommend a newspaper column style, where you state a headline, followed by a short paragraph of the most salient summary, then the next more detailed information, and so on, so that people can instantly get the "drift" of what you're saying from the first sentence.

I hope this helps you in your quest, even though I don't understand enough about the subject matter to be able to comment on the relevance and argument in the rest of your documents.

Good luck, and happy new year.

Thanks for the frank words...

Yes, thank you, for that's indeed helpful.

Can't promise I'll have fixed my prose on all those pages (in the direction you suggest) very soon, but re-reading myself now here and there, I do agree I definitely should go for it, when on these forums.

And I will.

By the way, if that helps to get upfront a better idea of "my stuff" otherwise, here's what it is about (in a crude form maybe):

Microsoft SQL Server Modeling (formerly "Oslo") is a very appealing component and has many qualities, IMO. (Really, just IMO and from my past experience with other things...)

Problem is just for one (quite big) issue, where I believe something important is missing in the way the "M" language was defined, and the related part of M's tooling support supposed to process it, in cooperation with one's own tools.

Moreover, I have the feeling that this issue is probably rooted at a theoretical level, actually, but which doesn't seem to have been much studied before.

More specifically, to my knowledge, it's the first time we're proposed to use, as extensively, such a feature-rich DSL-oriented modeling platform that aims to enable the easiest invention and implementation of DSLs. That's indeed what this vendor is doing, there, just as they positively claim so...

However, that's also likely to come at a cost, if you bother to look at it closer (again, given what is their current state of design and implementation).

Hence, my current effort to explain/formalize the issue, evaluate more precisely what is its "cost", and try find a way to lower it.