Closed juh9870 closed 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?
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.
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.
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.
What is good to have:
globals
variable set by default, so our code can check for it and apply mocks for functions from embedded envimport
, which behaves more like include
, or for embedded environments that don't have import functionality.This is not a comprehensible list, I haven't used this extension much, so I may have missed some other useful parts.
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.
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.
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.
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).
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
.
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.
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.
Okay I've finished porting greybel-vs to miniscript-vs. It's available here https://github.com/ayecue/miniscript-vs
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