I keep being confused about this point: What are the "functions" on AW/Wikilambda, and in which language will they be written?

When I first read the paper ( https://arxiv.org/pdf/2004.04733.pdf ), I got the impression that it will be a whole new programming language, especially from figures 1, 2, 3, and 6 in the PDF.

Then Denny wrote on Talk:Abstract Wikipedia that it will be just Lua, familiar from Scribunto modules, and also JavaScript. But this raises a few questions:
1. Will this mean the addition of JavaScript as a new engine for Scribunto, which is a very old and popular community request? See https://phabricator.wikimedia.org/T61101 . Or will this be in some other framework?
2. Will the Lua support be the same as in Scribunto, just with some more built-in methods available for module developers? Or will it be something substantially new?
3. If the answers to questions 1 and 2 is "it's basically Scribunto with new capabilities", then it's probably good, but then why are they called "functions" and not "modules"? Or are Abstract Wikipedia functions substantially different from modules?

--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
‪“We're living in pieces,
I want to live in peace.” – T. Moore‬


‫בתאריך יום ד׳, 15 ביולי 2020 ב-0:38 מאת ‪Lucas Werkmeister‬‏ <‪mail@lucaswerkmeister.de‬‏>:‬

Hi folks!

Since people have started talking about runtimes for the functions defined in Wikilambda (see: V8 Engine andor WebAssembly thread), I figured I should mention the project I’ve been working on for a few weeks: GraalEneyj.[1] It’s supposed to be(come) a GraalVM-based (re)implementation of the eneyj language/runtime[2] that Denny wrote and which is currently part of the AbstractText extension.

GraalVM,[3] for those who haven’t heard of it yet, is a Java-based project to build high-performance language implementations. There are already GraalVM-based implementations of JavaScript,[4] R,[5] Ruby,[6] LLVM,[7] WebAssembly,[8] and more,[9] and code snippets in any of these languages can run in the same (J)VM ((Java) Virtual Machine) and call each other with no performance penalty. This is of course interesting if we’re thinking about Wikilambda holding function implementations in different languages – with GraalEneyj, it should be possible to seamlessly compose functions implemented in any language for which a GraalVM implementation is available. GraalVM is also supposed to deliver highly optimized language implementations with relatively little development effort, but so far GraalEneyj is not yet at a point where I could benchmark it.

If that sounds interesting to you, please get in touch! You can also explore the code that I have so far (there’s not a ton of documentation yet, but hopefully the README[10] is at least enough to get a basic idea and run the tests), or watch the GraalEneyj walkthrough[11] that I recorded last month. (At some point I should record another one, since the code keeps changing, but for now that’s all I have to offer.)

Cheers,
Lucas Werkmeister

PS: In my day job I’m a software developer at Wikimedia Deutschland e. V., but all of this is private-time activity so far, not work related.

[1]: https://github.com/lucaswerkmeister/graaleneyj/
[2]: https://github.com/google/abstracttext/tree/master/eneyj
[3]: https://www.graalvm.org/
[4]: https://github.com/graalvm/graaljs
[5]: https://github.com/oracle/fastr/
[6]: https://github.com/oracle/truffleruby
[7]: https://github.com/oracle/graal/tree/master/sulong
[8]: https://github.com/oracle/graal/tree/master/wasm
[9]: https://github.com/oracle/graal/blob/master/truffle/docs/Languages.md
[10]: https://github.com/lucaswerkmeister/graaleneyj/#readme
[11]: https://www.youtube.com/watch?v=mQVpcBMjSaw

_______________________________________________
Abstract-Wikipedia mailing list
Abstract-Wikipedia@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia