Can violent-es be rewritten in haxe language

[zaxebo1]

I came to this language from your link at https://community.haxe.org/t/haxe-like-language-in-development/3687

I see that innumerable fully-featured scripting languages have been written javascript (or typescript) or in C/C++ or rust etc languages.
But none of the scripting language written in haxe itself is matured full-featured.
The result is that haxe language apps scripting capabilities are very target(platform) specific.

May I humbly suggest that atleast violent-es be written in haxe language as embeddable programming language, so that it can find real world exclusive niche usecase by haxe written programs

[hydroper]

So far, this language has superficial reference and working parser/AST (written in TypeScript), but it might be interesting to rewrite it in Haxe (because it's more robust than TypeScript). The language is statically typed, so I'm still working on the symbol solver (aka. verifier). Unfortunately the runtime and bytecode aren't also done.

[zaxebo1]

Thanks for considering it.
If you rewrite in haxe, then in any case through haxe/javascript target, one can run it on javascript platform. So 'writing it in typescript usecase' will already be covered by 'writing it in haxe' usecase.

and through haxe/C++ or haxe/java I may use this embeddable scripting language for my CLI programs written for native or jvm as REPL.

The real issue is that hscript ( https://github.com/HaxeFoundation/hscript ) is an incomplete programming language. No class etc is possible.

Currently there is no option for multiplatform embeddable scripting language via single implementation.

[hydroper]

Just gave a look at Haxe situation.

Positive points:

• String is UTF-16 both on .NET, HashLink and JavaScript targets. There are also code point iterators.
• File system API (in sys packages) work on all targets.

Negative points:

• It would be a bit painful where destructuring patterns are used, like {node, semicolonInserted} = parseStatement(...);. Haxe seems to lack these.
• Virtual properties (getters/setters) are a bit more indirect to write: var x(get, set):T; function get_x():Int {...} function set_x(v:Int):Void {}

Hmm, gotta think if it's worth...

[zaxebo1]

may be some "haxe macros" can be written to ease the pain which you see to be lacking in haxe.

you can see some powerful haxe macros written by others which ease haxe a lot
for example: https://github.com/haxetink/tink_macro (very important)
https://github.com/haxetink/tink_lang
https://haxetink.github.io/tink_lang/#/

similarly some 'haxe macros' for use case may also be written to facilitate those things in haxe

===

some other utilities written in haxe regarding parsers etc
https://haxetink.github.io/#/?id=parsers-writers
https://github.com/haxetink/tink_typecrawler

[hydroper]

What if you could execute bytecode that is outputted from esc from Haxe? Like I said I still need to implement that part, but one can try generating some dynamically-typed version of the bytecode from the AST generated from the working parser.

You could even try that with simpler languages that are already dynamically-typed, like JavaScript, using esprima to generate some bytecode.

[zaxebo1]

then "violent-es" will be one of the million other languages which have been implemented in other platforms and its use case may die sooner or later.
there is none 'full scale' programming language on haxe multi platform for integrating haxe classes with the scripting REPL.
It should fill this real world gap, for finding its sustainable niche use case.
IMHO.

---

What if you could execute bytecode that is outputted from esc from Haxe?

Then classes written in haxe and exposing it for scripting in violent-es REPL will need binding it once in haxe/jvm target , binding again once in in haxe/js target , binding again once in haxe/C++ target and so on.

BUT if violent-es written fully in haxe, may mean better integration of violent-es scripting language REPL with haxe. That means haxe classes can be exposed to violent-es for once in haxe&violent-es glue source code (written in haxe) - and then it will be available for scripting in violent-es in haxe/jvm, haxe/js, haxe/C++ , ... - all for implementation just once in haxe glue

[hydroper]

But do you want its parser/AST in Haxe, or everything in Haxe (parser + AST + verifier (model + symbol solver + type checker) + bytecode + runtime)? If it's the latter, then it'll take undetermined time because so far only the parser and AST are done... (I mean, there is no verifier + bytecode + runtime written in TypeScript yet.)

[zaxebo1]

I was just humbly requesting "everything in Haxe (parser + AST + verifier (model + symbol solver + type checker) + bytecode + runtime) + REPL" - whenever you implement them.
But obviously finally its your wish buddy