Denny,
Some feedback on this pertains to Z16 [1]. Programming languages version over the course of time and it would be useful to be able to indicate the version of the programming language of an implementation.
One could indicate the version of the programming language for the “language” property, e.g. “ES2020” or “C++20”.
A “version” property could accompany the “language” property.
Resembling MIME types or media types [2], we could use a semicolon and subsequent parameters, as per “JavaScript; version=ES2020” and “C++; version=C++20”, for the value of the “language” property.
So, options for indicating the version of a programming language include:
{
"type": "implementation",
"implements": "add",
"code": {
"type": "code",
"language": "ES2020",
"source": "K0 = Z144K1 + Z144K2"
}
}
and
{
"type": "implementation",
"implements": "add",
"code": {
"type": "code",
"language": "JavaScript",
"version": "ES2020",
"source": "K0 = Z144K1 + Z144K2"
}
}
and
{
"type": "implementation",
"implements": "add",
"code": {
"type": "code",
"language": "JavaScript; version=ES2020",
"source": "K0 = Z144K1 + Z144K2"
}
}
Best regards,
Adam
[1]
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Function_model#Z16/Code
[2] https://en.wikipedia.org/wiki/Media_type
From: Denny Vrandečić
Sent: Monday, July 27, 2020 3:43 PM
To: Abstract Wikipedia list
Subject: [Abstract-wikipedia] All work is preliminary
Hello all,
one of the things we have been discussing in the team is that we want to do as much of our work in the open. At the same time, we're a distributed team and starting to form a shared understanding of the task at hand. Due to the COVID situation,
we didn't have the opportunity to have a project kick off, where we meet for a few days and make sure that we are fully aligned and use the same words and have the same thinking.
That's both an opportunity, but also a risk, as it might lead to divergence in what we are saying and writing.
We have two possible ways forward - either we vet documents and discussions internally every time, in order to present a more unified view on the project, or we just drop that and we publish our documents and plans in the open immediately,
with the understanding that this is merely preliminary, that there might be inconsistencies. We might discuss and disagree with each other publicly in Phabricator tasks and on this mailing list and on the wiki pages - but in the end, this is also an opportunity
to together with you build a common understanding and share the process of developing the project vision and implementation.
So, in that light, we still have a small backlog of internal documents that we want to get out, and by the end of this week, most of the state of the work should be in the open, and we will move more and more of our discussions to the public,
to eventually have them all in the open.
Here is a document I have been working on for a while, it is the core model of how the evaluation and representation of data, functions, and function calls in Wikilambda may work. Again, there is no agreement on this yet. It differs from
the AbstractText prototype implementation, and there is a list of main differences at the end, and it also has not all the answers yet.
Thanks to, particularly Arthur P. Smith for many comments and rewriting of some of the sections, thanks to Lucas Werkmeister for his valuable input (and, even more important, for his work on GraalEneyj), thanks to Cyrus Omar for his advice
and pointers, and thanks to Adam Baso, James Forrester, and Nick Wilson for their internal comments.
Feedback on this would be extremely valuable, and you can see there are many open questions left.
Stay safe,
Denny