The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-09-27
--
Serializers and deserializers for types
Last week, we discussed our plans to add renderers and parsers for types
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-09-20>.
This week, we will continue the theme of how to make types easier to use,
by discussing serializers and deserializers, and their role in
Wikifunctions.
If you have the appropriate type, writing a native code function can be
really easy: for example, since we already have types for Booleans
<https://www.wikifunctions.org/wiki/Z40> and Strings
<https://www.wikifunctions.org/wiki/Z6>, and we translate them in the
system to the native concepts of Booleans and Strings in Python and
JavaScript, this means that writing the code implementation for a function
such as the boolean conjunction (and)
<https://www.wikifunctions.org/view/en/Z10174> or joining strings
<https://www.wikifunctions.org/wiki/Z10000> is rather straightforward and
just a single line of code packaged in a function:
- And in Python <https://www.wikifunctions.org/view/en/Z10175>
- And in JavaScript <https://www.wikifunctions.org/view/en/Z10202>
- Join strings in Python <https://www.wikifunctions.org/view/en/Z10004>
- Join strings in JavaScript
<https://www.wikifunctions.org/view/en/Z10005> (and alternatives using
concat <https://www.wikifunctions.org/view/en/Z10621> or join
<https://www.wikifunctions.org/view/en/Z10622>)
On Wikifunctions Beta, we already have seen the creation of a few types,
such as for numbers <https://wikifunctions.beta.wmflabs.org/view/en/Z10015>
or dates <https://wikifunctions.beta.wmflabs.org/view/en/Z10438>. But the
implementations for similarly basic functions such as addition
<https://wikifunctions.beta.wmflabs.org/view/en/Z10118> or squaring a
number are nowhere as simple, and have far more than a single line of code:
- Addition in Python
<https://wikifunctions.beta.wmflabs.org/view/en/Z10874>
- Addition in JavaScript
<https://wikifunctions.beta.wmflabs.org/view/en/Z10119>
Why is that so?
Here’s the implementation of the addition function in Python in the Beta
Cluster version:
def Z10118(Z10118K1, Z10118K2): def deserialize(x): return
int(x.Z10015K1) def serialize(x): return ZObject({"Z1K1":"Z9",
"Z9K1":"Z10015"}, Z10015K1=str(x)) left = deserialize(Z10118K1)
right = deserialize(Z10118K2) result = left + right return
serialize(result)
And here’s how the implementation should look:
def Z10118(Z10118K1, Z10118K2): return Z10118K1 + Z10118K2
In the core of the implementation above, that’s exactly what it does: in
line 11 you can see that the Python + operator is being called. But in
addition to all that, we also need code that deserializes the input
arguments, and serializes the output. In other words, we need to turn the
ZObject that Wikifunctions works with into values of Python’s int type
(that happens in line 3) and back into a ZObject (that happens in line 6).
If Wikifunctions knew that the positive integer type can be fully
represented by the int type of Python 3, we could have automatically made
that conversion inside the system. But we want types to be flexible, and to
eventually be fully community-controlled on-wiki. And that also means that
we shouldn’t build in any magic into the Wikifunctions system that does
such conversions, or that requires the system to know types.
The way we plan to tackle this is as follows (and now is the right time for
comments):
We will introduce two new types of special objects: serializers and
deserializers. A deserializer is attached to a specific programming
language and Wikifunctions source type, and has code attached that takes a
ZObject of the source type and turn it into a value of the target native
type in that programming language. A serializer is the inverse of that.
For example, you might have a deserializer that turns a Wikifunctions
Integer type when used with Python into a native BigNum (even if it might
fit into an int), and the serializer from Python understands how to convert
both native Python ints and BigNums to Wikifunctions Integer type instances.
Now, whenever we want to run native code, the evaluator - the piece of code
responsible for running native code - will also need to run the code
associated with the serializers and deserializers. That is, all the extra
code that makes up the difference between the two implementations above
would be handled automatically by Wikifunctions.
For each type and language, there would be exactly one deserializer and
serializer. Then, when a native implementation for a function is being
written, we look up the types on the function, and find the right
serializer and deserializer for those types in that programming language.
Let us know if you have ideas or comments on these plans!
October Volunteer Corner
The volunteer corner for next month will be next week Monday, October 2nd.
We are playing a bit with the times, so that different people may attend.
Also, because of repeated issues with Jit.si, we are shifting for now to
Google Meet again.
Please give us feedback on the time and on the platform, so we can continue
to improve.
We are meeting on October 2nd, 2023, at 13:30 UTC
<https://zonestamp.toolforge.org/1696253400> at Google Meet
<https://meet.google.com/xuy-njxh-rkw?authuser=0&hs=122>.
The agenda for the meeting is to take any questions that arise, followed by
working on a function together.
Recording of September Volunteer Corner
We also uploaded a recording of the September edition of the Volunteer
Corner
<https://commons.wikimedia.org/wiki/File:Abstract_Wikipedia_Volunteer_Corner_2023-09.webm>
to
Commons. We were working together on a function to check if a string is a
valid positive integer <https://www.wikifunctions.org/view/en/Z11129>. It
was great fun to build a function on Wikifunctions together, to have folks
create testers, and to discuss the function and its limits live!