Rubberduck programming language

[rkapka]

I have a silly thought that I would like to share 😀

I remember reading somewhere around here that RD will eventually provide its own code panes, which will enable, among other things, squiggly lines indicating code issues. This sounds great - maybe there will even be a setting that disallows running VBA code in RD code panes if there are any inspection errors? If such a thing is possible, then maybe it would even be possible to have a separate RD programming language?

Right now RD discourages a lot of VBA constructs through inspections and uses ANTLR to scan through VBA code. Instead of this, maybe RD could have a language of its own with its own grammar? Initially this grammar would be a subset of the VBA grammar, without all the unwanted constructs. ANTLR would check the code inside RD code panes against this grammar, then RD would transpile the code to VBA code (initially 1:1 correspondence) and then the resulting VBA code would run. If there are any errors in the RD language's code, then the transpilation wouldn't be allowed. A lot of problems and inspections would go away because you can't use anything that's not included in the grammar. And in the future the RD language could be extended to have its own constructs that would be transpiled to VBA.

I have close to zero knowledge about designing programming languages. I'm also not aware to what extent can the VBE be tampered with. If this rant doesn't make sense, just let me know. I expect that my idea is not realistic, but I just couldn't resist getting it out here.

[PeterMTaylor]

No worries, any idea is a good idea. They do get a chance for evaluation and contemplation though.
On reflection about new grammar of RD for VBA wouldn’t be possible due to dependency of host libraries as I recall this conversation had mentioned.
Even if we reach a stage of confidence branching out, it’s like making our own compiler.

[bclothier]

FWIW, this might be relevant.

[rkapka]

I agree that this is probably a stupid thing to do. What I was hoping for is that you could remove the parts of the grammar that you don't need and treat the code in RD code panes as VBA, which wouldn't require literally designing a new programming language.

[bclothier]

I'm not sure I follow the idea. The grammar is for VBA with some additional elements to support RD's annotations which are embedded in VBA code as comments. Exactly what would get removed? To do what?

I originally read the suggestion as to write a transpiler (e.g. same thing that TypeScript does for JavaScript). If that's not what you were thinking of, can you provide some examples?

[rkapka]

Exactly what would get removed? To do what?

All the VBA constructs that are obsolete, confusing or not useful. Maybe #3486 or #3308 could be such examples? I see a benefit of not having to write inspections for all such constructs because they will just not compile. RD would document what constructs were removed and why. And if the programmer really needs to use a removed construct, they can switch back to VBA.

I originally read the suggestion as to write a transpiler

Yes, I was talking about a transpiler, although initially this "transpiler" would not make any changes to the RD language's code because all of it would be valid VBA code. Real transpilation would be necessary if there are any non-VBA constructs in the RD language.

[bclothier]

Ok, I think I see what you mean -- it sounds more like you want something equivalent to JavaScript's 'use strict';? Force all obsolete constructs to be compile-time errors?

Consider that one goal of Rubberduck is to enable developers to take a legacy hand-me-down codebase with all wrong stuff and crappy constructs and be able to maintain it... especially without breaking it. Enabling a strict mode would not help in the initial stage but as the cleanup progressing, I can see enabling strict mode on a per-module basis and so forth. Is that what you were envisioning?

[retailcoder]

I think that's an interesting idea... but well out of scope =)

[rkapka]

@bclothier Yes, exactly.

@retailcoder Fair enough :-)