Scala Native support

[XVilka]

To be able to run Kaitai without JVM:

https://github.com/scala-native/scala-native

Note - it is probably a long term goal.

See https://github.com/scala-native/scala-native/issues/233 to track Scala 2.12 features support in Scala Native.

[GreyCat]

I've thought that this request was already there, but given that I can't find anything, probably not, so here it is.

The overall picture is more or less the same as with running ksc with JavaScript in command-line (see https://github.com/kaitai-io/kaitai_struct/issues/224) — we need all the dependencies buildable for scala-native. The core problem right now is YAML parser — there's no pure Scala YAML parsers available, so we aiming to write our own — https://github.com/kaitai-io/kaitai_struct/issues/229.

[abitrolly]

Is it a very bad idea to rewrite compiler to Kotlin, which probably has a wider library support as an official Android flavour?

[KOLANICH]

rewrite compiler to Kotlin

The idea is no better than rewriting the compiler in <any another language>. I mean that if it was written in Scala, there is a reason for it. Likely it was just convenient for @GreyCat to develop in this lang.

Everyone is free to develop an impl of KSC in any other lang. But it is probably a terrible idea if you are not going to overcome the original KSC and are not going to start a "feature race" and win it. I mean - it's either a compatible fork, and you have to constantly monitor KSC patches and reimplement them in your impl of KSC, or you have to overcome the original KSC in popularity and features and it is it that has to implement your features, or you state that your fork is incompatible and the lang it implements is not KS.

And all the issues and waste of effort are for what? For not having a JVM? For not having to deal with Scala? IMHO - all of it doesn't worth the effort required.

In other words - just do that, if you want, but don't expect project authors to do that. If they have chosen Scala - they are OK with that. (Disclaimer: I am not OK with Scala and especially sbt, so I usually don't touch developing KSC, even though there are some pretty large things I wanna implement there).

[abitrolly]

I am not aware of Scala features. I see that Kotlin is also JVM based. If JVM is the target and majority of work is done with 3rd party libs, then a transpiler can potentially do the majority of the work. Or reversing bytecode can help to get from one language to another. Just a speculation.

[dgelessus]

Is it a very bad idea to rewrite

Yes 🙂

More seriously though, what advantage would you have from ksc being written in Kotlin rather than Scala? You say that Kotlin

probably has a wider library support as an official Android flavour?

but I'm not sure how that's relevant to ksc - I don't think ksc has any problems with a lack of support libraries.

Besides, this issue is about making ksc compatible with Scala Native, so that it can be compiled into a native binary that isn't based on the JVM. Kotlin supports something similar with Kotlin Native, but it will almost certainly be more difficult to rewrite ksc in pure Kotlin than to make the existing Scala codebase work with Scala Native, so that isn't very useful for ksc.

[abitrolly]

The core problem with making ksc compatible with Scala Native is the lack of YAML support. I thought that Kotlin may have better YAML support.

[dgelessus]

Ah, thanks - I somehow missed that part of the discussion above >.>

I did some quick searching, and even in Kotlin the most popular solution for YAML parsing seems to be to use SnakeYAML (either directly, or indirectly through Jackson). I also found a pure Kotlin YAML library, but it explicitly says that it's in alpha, and based on the number of stars it's probably not used by many people. And even if that library was stable and had many users, it would probably still easier to write a custom pure Scala YAML parser (as suggested in #229) than to rewrite all of ksc in Kotlin (and replace all other dependencies, like the parser engine, with Kotlin equivalents).

[abitrolly]

New version is released - https://scala-native.readthedocs.io/en/v0.4.0/changelog/0.4.0.html

And I opened an issue upstream - https://github.com/scala-native/scala-native/issues/2174