Thomas,

Yes, that's true. A wise selection of types and how exactly they are defined will help a lot with these issues.

This is not exactly a new problem, fortunately - ProtoBufs, WebIDL, XML Schema Datatypes, and good old CORBA already had to deal with these issues before, so we have a bit of former work to look at and learn from. Also, one good thing is, we don't have to agree on a single integer type, but can have several - most of the complexity can, in most cases, be transferred to the type conversion, so that the individual functions remain reasonably simple.

To give one example: a type such as integers from 0 to 10,000, which we could define, would have really easy implementations in native Python, JavaScript and C++, even though the underlying addition does not behave exactly the same in edge cases - but we would basically remove the edge cases from the type. Arthur described that already better than I could.

But yes, if one of our types extends beyond a native type, then basically we would need to reimplement the logic instead of reusing native mechanisms. That would loose some of the efficiency.

The other topic you talked about was reusing Scribunto. We will take a very good luck at Scribunto, in order to reuse parts of the code and to build on top of the valuable experiences gained.

Thanks for raising that important point!
Denny

On Fri, Jul 17, 2020 at 2:32 PM Thomas Pellissier Tanon <thomas@pellissier-tanon.fr> wrote:
Le ven. 17 juil. 2020 à 22:54, Arthur Smith <arthurpsmith@gmail.com> a écrit :
>
>
> On Fri, Jul 17, 2020 at 1:50 PM Thomas Pellissier Tanon <thomas@pellissier-tanon.fr> wrote:
>>
>>
>>
>> > 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.
>>
>
> I think this is relatively trivial: Python3 "int"s are simply a different type of entity from IEEE 754 floats and 64-bit or 32-bit or whatever limited integer examples there are. We already translate between types within single languages (string to int, int to float, big int to little int, unsigned int to signed, etc.) so all that's required here is being a little more exact about these variable types from the start. IEEE 754 floats have a rather precisely defined definition that should be met by all implementing languages, for instance.

Yes, we could definitely do that. But, if we choose a specific
definition then some implementations might become very complex.
To continue the example, if we define a "64 bits signed 2 complements
integer", the JavaScript implementation will probably have to use
BigInt and a modulus operator to emulate this, the Python
implementation a modulus operator...
If we define a "number of unicode code points in a string" the
JavaScript implementation could not use String.length but have to fire
more complex code...
It is fine if we only implement in the "native language" very simple
functions (addition, string length...), but if, for performance
reasons, people start to write more complex functions in native
languages, I believe it will be very hard to not get discrepancies
between the implementations because it would require the
implementations to take care of all these details to keep a perfect
interoperability.

Thomas


>   Arthur
> _______________________________________________> 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