ayecue / greybel-vs

VSCode extension for GreyScript.
https://marketplace.visualstudio.com/items?itemName=ayecue.greybel-vs
MIT License
16 stars 7 forks source link

Support MiniScript files (.ms) #96

Closed juh9870 closed 1 year ago

juh9870 commented 1 year ago

It would be great to have a support for MiniScipt files too.

Grey Script is based on MiniScript, and as far as I'm aware, it has no differences compared to the 2021 version of MiniScript.

A simple change would be to include the extension to cover .ms files, but ideally, some changes to autocompletion are needed to make the extension not to suggest GreyHack-only APIs

ayecue commented 1 year ago

Hey so when it comes to syntax you are right there are no differences to GreyScript. But there are the following differences:

Additionally most of the functionality provided by this extension is pretty much focused on GreyScript and probably doesn't have any purpose for MiniScript. I mean I can just add the .ms extension but not sure how much this extension can help with actual MiniScript coding.

But I think it would be pretty "easy" to create a new extension reusing some of the packages used within this extension. Also I am not sure which of the features this extension provides you are looking for?

Olipro commented 1 year ago

Just throwing my hat in the ring here for some context:

There was a discussion about this extension on the MiniScript Discord and the conclusion was that this implementation is really cool and would actually be something awesome for the general MiniScript community to use.

If the GreyHack-specific behaviour can be/already is decoupled from the core MiniScript behaviour, I hope maintainability won't be too much of a drag.

ayecue commented 1 year ago

I see so just wondering which features specifically are we speaking about? Automcomplete, HoverDocs, Diagnostics, Interpreter etc? Just to get an idea which packages are required.

Yeah I think this is specifically the issue. I think there needs to be some decoupling done in order to make this not horrible to maintain.

Olipro commented 1 year ago

I'd frame it as "everything that isn't GreyHack specific" like the game intrinsics. The debugger is especially powerful since you can't do that with the official MiniScript implementations.

Command-line MiniScript/MiniMicro also has some additional intrinsics like File and Input - the former is a map with a bunch of native functions that let you access your computer's actual filesystem, Input is a bit like user_input. But this is also the exact sort of stuff you can decouple from the core interpreter and potentially allow mixing and matching with GreyScript intrinsics.

e.g. when firing up the interpreter/debugger, you have some options defined somewhere to tell it which intrinsics package(s) should be loaded into the script VM.

juh9870 commented 1 year ago

What is good to have:

This is not a comprehensible list, I haven't used this extension much, so I may have missed some other useful parts.

Olipro commented 1 year ago

Interpreter... Not sure, it may be useful for "raw" miniscript, but a lot of use cases are for MiniMicro or embedded environments and so it's probably not very useful

Being able to introspect your code, is tremendously useful - create a fake/mock of whatever MiniMicro function(s) you need and fire up the debugger.

ayecue commented 1 year ago

I'd frame it as "everything that isn't GreyHack specific" like the game intrinsics. The debugger is especially powerful since you can't do that with the official MiniScript implementations.

I see so that means I need to decouple the lexer, parser, transpiler and interpreter. I mean I could mix them but that would kinda make it probably confusing to work with.

Lexer, parser, transpiler and interpreter are pretty simple to decouple since I would just need to decouple import_code I believe. I also probably need to switch it's dependency order. Since right now it's greyscript-core > greybel-core. So in the future it should be more like miniscript-core > greybel-core > greyscript-core.

Command-line MiniScript/MiniMicro also has some additional intrinsics like File and Input - the former is a map with a bunch of native functions that let you access your computer's actual filesystem, Input is a bit like user_input. But this is also the exact sort of stuff you can decouple from the core interpreter and potentially allow mixing and matching with GreyScript intrinsics.

Adding intrinsics shouldn't be difficult since that part is already quite decoupled. So for that there would be just new intrinsics packages required and as you mentioned somekind of intrinsic package selection.

Syntax error detection. It's a big one

For this I would probably need to add also an option to select the diagnostics syntax. Since there are some minor differences. So GreyScript for example allows non literal default values in args (which is broken, but still supported).

Code bundling. This extension seems to have pretty good bundling capabilities, which are pretty useful outside GH too, to avoid issues with the default MiniMicro import, which behaves more like include, or for embedded environments that don't have import functionality.

For this I would probably need some input or look into on how the bundling should work for MiniMicro and MiniScript. Are there any differences?


Anyway I am up to do some decoupling if it helps the MiniScript community. I'm just not yet sure on how I am gonna do it. I may going to create a new extension if I see it becomes too much of a hassle to put it into this one. This may gonna take some time though.

ayecue commented 1 year ago

I've added .ms as an extension in the meantime https://github.com/ayecue/greybel-vs/pull/98/commits/0d712d3d79306a2e226d6ea0553982f0635905ac. Should be available as soon https://github.com/ayecue/greybel-vs/pull/98 is merged.

juh9870 commented 1 year ago

For this I would probably need some input or look into on how the bundling should work for MiniMicro and MiniScript. Are there any differences?

I tried using #import declaration, and it seems to produce a main file that is useable in native MiniScript with some polyfills (for example, exit with arguments).

ayecue commented 1 year ago

I tried using #import declaration, and it seems to produce a main file that is useable in native MiniScript with some polyfills (for example, exit with arguments).

Yeah so #import namespace from path and #include path both will be merged into where ever the original entry file was. #include is just a simple get content and put where #include is used.

#import though is treating your import as a module and adds the following boilerplate https://github.com/ayecue/greybel-transpiler/blob/master/src/boilerplates/index.ts#L15 around it. So essentially where ever you use #import it will just call __REQUIRE("dependency"). So it's a bit similar to CommonJS. Also as a sidenote it will not duplicate code as #include would. If the same file gets imported twice it will just place another __REQUIRE.

juh9870 commented 1 year ago

Yeah, seems reasonable. On the quick glance, the only thing that is not a part of standard MiniScript is exit with string argument, but that is easily resolved just by defining a polyfill.

ayecue commented 1 year ago

Yeah I am currently working on changing the transpiler to only support MiniScript as a default. Everything related to GreyScript will be decoupled into a new package.

Doing the same for the meta and parser/lexer part.

After the transpiler is decoupled I'll then also decouple the interpreter.

ayecue commented 1 year ago

Okay I've finished porting greybel-vs to miniscript-vs. It's available here https://github.com/ayecue/miniscript-vs