[09:24:23] Apart from this bug in the code conversion, I've finally completed two implementations of Z20854 which pass all the tests I could think of. Feel free to fire more tests at it, because I think it's important that this one be robust. I made up a fair bit of the Javascript, so it's worth being extra sceptical of that. (re @Toby: I think there may be an error in Z20885, but [09:24:23] only staf [09:24:23] f can change it (ping @vrandecic ). I believe line 76 should be if...) [09:37:42] Thanks for that, Toby. Floats always make me feel unwell! [09:37:43] A zero denominator is not valid in a Rational number but we have no validator… should we get a NaN rather than an error? (re @Toby: Apart from this bug in the code conversion, I've finally completed two implementations of Z20854 which pass all the tests I coul...) [10:45:54] Z21481 is a useful function that uses eval on user input. It looks like it should only return a value if the input evaluates to a Real number. Is this adequate protection or is eval completely prohibited? @sannita for WMF [10:49:39] I don’t think it makes sense to call anything that happens after the eval call “protection” – at that point you’ve already let the attacker run arbitrary code… [10:50:26] surely Python has a safer method to parse this type? (but I’m not familiar with `Real()` in particular) [10:54:09] Okay, thanks. I’ve disconnected the implementation and all tests for now. (re @lucaswerkmeister: I don’t think it makes sense to call anything that happens after the eval call “protection” – at that point you’ve already let t...) [10:54:55] though I wonder if the evaluator should perhaps block `eval()` instead [10:55:10] I’m not sure if having all the Functioneers enforce “don’t use eval” is realistic [10:58:30] That would make sense unless we want to allow eval when the input is suitably restricted. (re @lucaswerkmeister: though I wonder if the evaluator should perhaps block eval() instead) [11:03:25] Yeah sorry, I missed that one and will probably miss others in my haste to encourage new users by connecting their creations. (re @lucaswerkmeister: I’m not sure if having all the Functioneers enforce “don’t use eval” is realistic) [11:05:47] Z20578, for example, enforces a restricted character set prior to the eval. Is that adequate? [11:11:03] I’ve checked with https://www.wikifunctions.org/w/index.php?ns0=1&ns4=1&search=%3A+Z14K3%3Aeval&searchToken=f522ywifitxygrjgqgyi2twga&title=Special%3ASearch and Z20578 is the only one that can be run at the moment. [11:20:36] Oh, yeah “infinity”, how could I forget?🥴 (re @Al: Thanks for that, Toby. Floats always make me feel unwell! [11:20:37] A zero denominator is not valid in a Rational number but we have no v...) [11:34:26] Haha. Yes, I've added Z21526 and Z21527 per your good suggestion. However it looks like 0/0 fails in code conversion somewhere, because it even blows up a simple key switching JS like Z19711 (re @Al: Oh, yeah “infinity”, how could I forget?🥴) [11:41:35] Oh good, we still have a problem for the validator to fix 😎 (re @Toby: Haha. Yes, I've added Z21526 and Z21527 per your good suggestion. However it looks like 0/0 fails in code conversion somewhere, ...) [11:44:08] Yes. I just put code into python to handle it, but both had blown up prior. The web says that Fraction(1,0) raises a zerodivision error on construction. (re @Al: Oh good, we still have a problem for the validator to fix 😎) [11:46:22] Quite right too! (re @Toby: Yes. I just put code into python to handle it, but both had blown up prior. The web says that Fraction(1,0) raises a zerodivisio...) [16:51:17] as we get closer to integrate wikifunctions with wikipedia, the abstract wikipedia team wanted to share a few suggestions to ensure that content is accessible, inclusive, and cohesive across projects. we just published this page https://www.wikifunctions.org/wiki/Wikifunctions:Design/Naming_conventions_recommendations and would love to hear your thoughts! [17:55:53] Blast from the past. (re @amire80: The glossary includes the words car, cdr, head, tail. These are important terms in computer science and functional programming, ...) [17:56:46] If I understand @vrandecic's 👎 there correctly, these terms are not necessary in Wikifunctions, so I've removed them from the Glossary: https://www.wikifunctions.org/w/index.php?title=Wikifunctions%3AGlossary&diff=156461&oldid=94445 [17:56:56] If anyone thinks that it's wrong, please revert. [18:16:20] Thanks. I’m okay with “car” and “cdr” (which we have as aliases). The labels “head” and “tail” were used for K1 and K2 in the “generic” Type produced by Z881 (according to [[Wikifunctions:Function_model#Z881/Lists]], which may just be out of date) but I don’t think we would ever see such a label, however, so I would leave it out of the glossary until someo message> [18:16:20] ne corrects me. (re @amire80: If anyone thinks that it's wrong, please revert.) [22:50:37] There are a bunch of new translatable messages for the WikiLambda API, and I have a few questions about them. [22:51:10] First, the word "renderable". It doesn't appear in the glossary. One of the new messages says: [22:51:16] ``` [22:51:17] "renderable" inputs can be Strings, Enums or types that have a parser function. [22:51:19] "renderable" outputs can be Strings or any types that have a renderer function.``` [22:51:43] This sounds like it could be a mostly good definition for the glossary. [22:52:19] However, this brings me to the next question: is it right to say "parser function" and "renderer function" here? [22:52:52] "Parser function" is especially problematic because in the MediaWiki world, "parser function" has a specific and well-established meaning, and it's probably not the one here. [22:52:56] I thought we agreed to discontinue the use of “render” and “parse” in favour of “display” and “read”. [22:53:12] Exactly. (re @Al: I thought we agreed to discontinue the use of “render” and “parse” in favour of “display” and “read”.) [22:53:34] Or, even more exactly, I'm not totally sure about "we agreed", [22:54:55] but I did see "display function" and "reading function" in other messages, and they are unambiguous, so I'd prefer those here, too. [22:56:29] (People who are more deeply involved than I am in the technical side of things should decide which terms to use. I am just humbly trying to help keep the localization manageable.) [22:58:17] Same here. Currently Z16683 (for example) has a “renderer” called “display Integer” and a “parser” called “read Integer”. (re @amire80: Or, even more exactly, I'm not totally sure about "we agreed",) [22:59:55] (And "manageable" includes striving for consistent, well-defined, and unambiguous terminology, because it makes everything easier for everyone: translators, users in English, for users in all other languages, and developers.) (re @amire80: (People who are more deeply involved than I am in the technical side of things should decide which terms to use. I am just [22:59:56] humbl...) [23:01:01] It is therefore a “renderable” type (per the definition given) or a “displayable” type (per the “agreement”). [23:09:19] Hmm... I'm actually not against the specific word "renderable" at the moment, because it appears to refer to both display/render and parse/read, so perhaps a third word that refers to two different words is not bad. [23:15:42] Maybe a third word might be appropriate, but maybe not such a misleading one 🤔 I’ve amended Z4 to use “display function” and “reading function”, in line with the Glossary. (re @amire80: Hmm... I'm actually not against the specific word "renderable" at the moment, because it appears to refer to both display/render...) [23:19:07] ``` [23:19:08] "readable" inputs can be Strings, Enums or types that have a reading function. [23:19:10] "displayable" outputs can be Strings or any types that have a display function.``` [23:19:11] (re @amire80: "renderable" inputs can be Strings, Enums or types that have a parser function. [23:19:13] "renderable" outputs can be Strings or any types...) [23:19:46] I guess… 🤷‍♂️ (re @Al: "readable" inputs can be Strings, Enums or types that have a reading function. [23:19:47] "displayable" outputs can be Strings or any types...) [23:21:09] Thanks, but the practical problem with this is that if I understand those API messages correctly, it must be one word for both things. [23:21:13] Or maybe not. I'm not sure. [23:24:16] This is the Phab task: https://phabricator.wikimedia.org/T382140 [23:24:17] I think it just means “available” or similar. That is, what the API supports. (re @amire80: Or maybe not. I'm not sure.) [23:24:49] There are some more details there, not just "available". It refers to functions that work with particular type.s [23:26:54] Or something. I'm not an expert. [23:29:59] It’s about specifying a filter so that only functions that comply with the constraints are returned (“usable” in the title). (re @amire80: There are some more details there, not just "available". It refers to functions that work with particular types.) [23:55:24] For my education, what is this existing meaning? (re @amire80: "Parser function" is especially problematic because in the MediaWiki world, "parser function" has a specific and well-establishe...) [23:57:43] https://www.mediawiki.org/wiki/Parser_functions [23:59:36] Many of them are very common, especially in the code of templates.