Amir, when I say function I mean a computation that accepts an input and returns an output. That differs, for example, from Lua modules, which are basically a small library of functions and helpers. We're also starting with no side-effects and referential
transparency, because we're boring, and leave that for a bit later.
But you see, that's exactly the problem: This may be clear to people who learned about side effects, composition, and referential transparency in the university for their Computer Science or Mathematics degrees, but I strongly suspect that most editors
of Wikimedia projects didn't learn about these things.
If the project only wants contributors with CS degrees or comparable knowledge, then it's fine to do it completely differently from a wiki, and more like a software development project: with Git, with rigorous code review, and so on. Maybe the eventual
result will be better if it's done this way. But don't expect the size and the diversity of the Wikimedia community, and don't expect that it will be easy to integrate the functions' output into Wikipedia. Maybe it will _possible_, but it won't be easy.
But if the intention is to let the large and diverse Wikimedia community edit it, then from the outset, this project needs to speak in terms that this large community understands.
This community understands the following things:
* what is an encyclopedia, and what are notability, reliability, original research, etc.
* wiki pages and wikitext (links, headings, categories, references, files)
* a relatively large part of this community understands structured data in the form of Wikidata
* a relatively large part of this community understands templates (at least how to add them to pages, though not necessarily how to create them)
* a smaller, but still relatively large and multi-lingual group understands Scribunto modules
It's totally fine to introduce new concepts or to upgrade existing ones, but it has to start from something familiar. Jumping straight into composition, side effects, and Z objects is too cryptic.
So, there will be wikipages that represent such a function. So on one page we would say, "so, there's this function, in English it is called concatenate, it takes two strings and returns one, and it does this". Admittedly, not a very complicated function,
but quite useful.
Sorry, but I still don't understand how is this different from making the following Scribunto module:
local p = {}
function p.concat(frame)
return frame.args[1] .. frame.args[2]
end
return p
Then we might have several implementations for this function, for example in different programming languages, we also might have tests for this function. All implementations should always behave exactly the same. An evaluation engine decides which implementations
it wants to use (and, for the result it shouldn't matter because they all should behave the same), but some engines might prefer to run the JavaScript implementations, others might run Python, others might decide "oh, wait, I am composing two different functions
together in order to get to a result, maybe it is smarter if I pick two implementations with the same language, as I actually can compile that into a single call beforehand", etc. There are plenty of possibilities to improve and optimize evaluation engines,
and if you were asking me to dream I'd say I am seeing a vibrant ecosystem of evaluation engines from different providers, running in vastly different contexts, from the local browser to an open source peer-to-peer distributed computing project.
But Scribunto can also support multiple programming languages. In practice it supports only Lua at the moment, but in theory more languages like JavaScript and Python could be added. (It's an old and pretty popular community wish.)
So, is a conceptually new infrastructure really needed, and are functions really different from modules? "Scribunto is not scalable for such an ambitious project" would be an acceptable answer, but I'd love to know whether this was at least considered.