Thank you for this enlightening discussion.
If I understand correctly, most of WikiLambda's goals could be achieved by the existing Scribunto Lua modules. 1. Being editable on wiki 2. Lowering the entry barrier compared to e.g. MediaWiki extension. 3. Being compoundable and extensible (one module could call another one). 4. [If the "global Lua modules" idea comes forward] Being shared by multiple wikis.
Additionally, WikiLambda proposes: 1. To provide multiple runtimes for the written code instead of just Lua to allow the WikiLambda functions to be evaluated easily in as many places as possible instead of just in the Scribunto Lua virtual machine. 2. Provide "pure" functions instead of modules that often make a heavy use of global state (wiki language...). This is an important step for code reusability and composability. 3. Provide a better way to document the modules/functions than Scribunto modules.
I don't see why these three goals could not be archived by an improved version of Scribunto. This version could provide the same documentation capacities like you described in the proposal (proposition 3) and provide a "pure function" kind of modules that do not rely on MediaWiki global state, while keeping (most) of the same standard library as the usual Lua modules (proposition 2). Lua VMs are fairly simple and are already available in a lot of languages, so, I am not sure using Lua would make the provided functions evaluation much harder and slower. LuaJIT is fairly well known for is versatility and its performances. I believe it would solve fairly well the proposition 1.
An other question, on WikiLambda itself:
you can see implementations in many languages, but they are often subtly different, and there's nothing in the system to avoid that.
I just have a concern here. How do you plan to mitigate the edge case differences between programming languages for the "native functions" implementations? For example Python 3 "int" type encodes arbitrary precision integers while JavaScript numbers could only encode integers that fit in a 64bits IEEE 754 float and Rust i64 have a 64bits precision limit. I am afraid that if WikiLambda wants to rely on language specific implementations for performance reasons, WikiLambda would have to deal with a lot of these discrepancies and end up in the same problems as Rosetta Code.
The other alternative I see is to not have such "native functions" and have a basic set of well defined primitives. But it means, more or less, creating a new programming language and optimizers to be able to evaluate it quickly.
@Denny Do you have a solution to this problem I do not see?
Cheers,
Thomas
Le ven. 17 juil. 2020 à 18:07, Denny Vrandečić dvrandecic@wikimedia.org a écrit :
Rosetta Code is a great example of something similar, but we also want to add more constraints and make it possible to actually call the code automatically.
If you take a look at the implementations of Conway's Game of Life in Rosetta Code - http://rosettacode.org/wiki/Conway%27s_Game_of_Life - you can see implementations in many languages, but they are often subtly different, and there's nothing in the system to avoid that. We want to avoid that divergence, and we want to allow users to enter the input data, click on a button, and run the code.
But still, Rosetta Code illustrates neatly some of the aspects of the project vision, yes, thank you for that pointer!
On Thu, Jul 16, 2020 at 11:23 AM Amirouche Boubekki amirouche.boubekki@gmail.com wrote:
Le jeu. 16 juil. 2020 à 19:50, Denny Vrandečić dvrandecic@wikimedia.org a écrit :
[...] I mean Wikilambda. The goal is to create a community project to develop a comprehensive repository of functions, a Wikipedia but for functions, so this first part is detached from any questions about natural language generation and knowledge representation.
So my first question is, do we agree on that goal?
Yes. I would add that it is something easier to get started than GitHub and it is not merely a clone of http://rosettacode.org/wiki/Rosetta_Code
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia
Abstract-Wikipedia mailing list Abstract-Wikipedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/abstract-wikipedia