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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia