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ć<mailto:dvrandecic@wikimedia.org>
Sent: Monday, July 27, 2020 3:43 PM
To: Abstract Wikipedia list<mailto:abstract-wikipedia@lists.wikimedia.org>
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.
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Function_model
Feedback on this would be extremely valuable, and you can see there are many open
questions left.
Stay safe,
Denny