[00:14:32] I'm not suggesting wrapping. I mean your later approach, with the "discourse frame" included as an argument in the new function's signature. (re @Al: I’m not sure that I’d pass anything. I’m trying to avoid wrapping the whole function, but if we assume we’d have to, the way we’...) [06:57:09] welcome unkreativiteit [07:00:01] Hello, I'm `[[smlckz]]` from IRC. [07:04:21] After looking around a little, I came across that long dreadful RfC.. goodness! It's like this project is facing an existential crisis or something. I hope you're well. [07:06:06] Certainly there are some from other projects who don't think our objectives are possible. [07:09:28] But when I see that the article on Australia renders better in Japanese than in English right now, it gives me even more confidence that a global community can work together to do big things. [07:10:32] I am planning to make a simple languages implementation of Z28436 (in the likes of HenkvD) with 8 languages: Indonesian, Malay, Afrikaans, Papiamento, Vietnamese, Tagalog/Filipino, Igbo, and Kapampangan. [07:11:07] I am also considering making a function for simple SOV languages (currently Japanese and Korean). [07:11:16] I don't want to say anything about opinions. I wonder whether (and how much) can they affect the fate of this project, how much power can they wield. [07:12:54] I don't know the political answer. But I know that the way we prove it can work is to make it work... (re @smlckz: I don't want to say anything about opinions. I wonder whether (and how much) can they affect the fate of this project, how much ...) [07:14:04] Many of the other languages I checked need lexeme handling or other functions (usually because of case and/or gender). How do I make functions for them? Should they be individual, or I can considate languages with similar grammar? (re @Earldridge Jazzed: I am also considering making a function for simple SOV languages (currently Japanese and Korean).) [07:14:28] Start individually with a language you know well. (re @Earldridge Jazzed: Many of the other languages I checked need lexeme handling or other functions (usually because of case and/or gender). How do I ...) [07:15:05] Tagalog needs lots, so maybe that's best. Let us know if you get stuck or want help. [07:33:15] How should I consolidate the functions w.r.t. cases/suffixes that are based on gender, gendered articles, cases/suffixes that are based on the last letter/vowel? [07:38:43] Break them into small helper functions that can later be composed. The latter group seem like the easiest starting point. So you could start with something like "string ends in vowel" (if we don't have that already). (re @Earldridge Jazzed: How should I consolidate the functions w.r.t. cases/suffixes that are based on gender, gendered articles, cases/suffixes that [07:38:43] ar...) [07:40:58] Actually, we have Z11961. Is that the list you would test for, or does Tagalog have a different set? [07:46:36] For lexemes we have quite a few functions to test or find the gender of lexemes or their forms. And quite a few ways to get from an item to its lexemes. So, a composition may be possible already if the logic works out. Let us know if you can't find a helper function that you need. [09:11:51] I confess that I have actually read every word, because there are kernels of truth within much of the critique, as well as much misunderstanding. The RfC itself relates specifically to Abstract Wikipedia rather than Wikifunctions, but it is hard to disentangle the two. [09:11:52] My own view is that the Abstract Wikipedia community itself should articulate its own vision of the project’s future, so I have opened this topic on-wiki (https://abstract.wikipedia.org/wiki/Abstract_Wikipedia:Project_chat#How_should_Abstract_Wikipedia_work?). Perhaps that has a more technical focus; my broader view is outlined here (https [09:11:52] //meta.wikimedia.org/wiki/Requests_for [09:11:54] _comment/The_future_of_Abstract_Wikipedia#Developing_the_Abstract_Wikipedia_community). [09:11:55] But I think we are well, thank you. I have been involved in Abstract Wikipedia for over six years and, disregarding the RfC, it is heartening to see it finally nearing its true beginning, when meaningful content can actually be found on participating Wikipedias. [09:11:57] Welcome to the Telegram experience! (re @smlckz: After looking around a little, I came across that long dreadful RfC.. goodness! It's like this project is facing an existential ...) [10:30:26] Hmm.. while I can't help much with AW for now, I look forward to Wikifunctions as a platform becoming more stable and performant. I'll see if I can get articles on math and CS topics into AW then. [11:11:42] Just a quick question: what topic on maths will interest you ? For CS, I have been working on documentation of software and programming languages (re @smlckz: Hmm.. while I can't help much with AW for now, I look forward to Wikifunctions as a platform becoming more stable and performant...) [11:14:00] Good luck! You know where we are… My inclination would be to focus on links rather than text. Feel free to prove me wrong, but I think Wikifunctions is currently more expressive for assertions than for explanations. (re @smlckz: Hmm.. while I can't help much with AW for now, I look forward to Wikifunctions as a platform becoming more stable and performant...) [11:25:27] All of math, I wish! Let's begin at the beginning, the foundations of math, from logic and move upwards from there. After that I'll see how much I can bear. I can bear with formal, symbolic side of things somewhat, insofar I could study programming language theory. I dread analysis, whether real, or complex, and so on. [11:25:27] After dealing with computability theory, I'll look into the usual boring CS stuff, data structures and algorithms. And move up the stack from electronics, hardware architecture, to networking, to UI. There's a lot to cover. (re @jsamwrites: Just a quick question: what topic on maths will interest you ? For CS, I have been working on documentation of software and [11:25:27] prog...) [11:33:31] > links rather than text [11:33:33] Can you expand some more about this? Links as in ...? (re @Al: Good luck! You know where we are… My inclination would be to focus on links rather than text. Feel free to prove me wrong, but I...) [11:56:30] Speaking of maths, how should we plan to display equations? They are not dependent on getting NLG Types right. But we don't have any functions for them yet. Should we be putting in phabricator tasks for LaTeX equation renderers/plugins, or do we need to try to construct them in html ourselves? [12:01:20] If you choose the latter, see [[w:MathML]]. [12:06:30] Perhaps this might be something you want to work on too? As you know, we have some numerical data types that might need functions that can represent them in mathML. (re @smlckz: If you choose the latter, see [[w:MathML]].) [12:14:29] Wikilinks for the appropriate Wikidata items in some relation. For example the P527 relation for Q21199 [12:14:30] relates it to Q16317911 [12:14:31] and to Q28920052, but none of those items on Wikidata themselves relate to Q7632653 or to Q204. I imagine you would want to express S(0) = 1 and S(n) = n + 1, in which case “S” is the surface form of a link to Q7632653 and 0 is the surface form of a link to Q204. But that’s just the “Western” convention, so the surface forms themselves may be the result of an NLG functi [12:14:31] [12:14:33] on, or refer to P7235 statements, either on Wikidata or within the article. Sorry, I’m sure that sounds more complicated than it really is! (re @smlckz: > links rather than text [12:14:34] Can you expand some more about this? Links as in ...?) [12:17:24] Which numerical data types? [12:17:25] In general, I'd rather take the conversion to MathML already implemented by [[w:Typst]] or [[w:Pandoc]] and port it to compositions, than implementing from scratch. (re @u99of9: Perhaps this might be something you want to work on too? As you know, we have some numerical data types that might need function...) [12:24:33] Sigh. If you want to, you can make it even more complicated. So long it isn't complicated like this: https://en.wikipedia.org/wiki/File:Principia_Mathematica_54-43.png 🙂 [12:27:49] I’m relying on you (and others) to keep it simple enough for me! 👍 (re @smlckz: Sigh. If you want to, you can make it even more complicated. So long it isn't complicated like this: https://en.wikipedia.org/wi...) [12:29:37] Got it. We'll see how that turns out. [12:45:01] Natural number, integer, sign, float64, complex128 (re @smlckz: Which numerical data types? [12:45:03] In general, I'd rather take the conversion to MathML already implemented by [[w:Typst]] or [[w:Pando...) [12:57:41] Where do we stand with [[:abstract:Abstract Wikipedia:Notability]]? Yesterday, I noticed an article on AW about a living person with doubtful notability. The statements on Wikidata seem to have been added by the same contributor, but there is no linked Wikipedia page. Naturally, I’m assuming good faith… [13:02:18] Good question. My trigger finger was tempted but I never got around to looking into that one. Please nominate for deletion if there are insufficient verifiable sources. Even before we have policy, we can have consensus. (re @Al: Where do we stand with [[:abstract:Abstract Wikipedia:Notability]]? Yesterday, I noticed an article on AW about a living person ...) [13:03:04] It was the 26 year old polymath right? [13:03:33] Allegedly 😎👍 (re @u99of9: It was the 26 year old polymath pharmacist right?) [13:04:38] It's good to see that polymaths are capable of using AW. It can't be that hard then? [13:05:36] If he’s a polymath then he can construct functions here (re @u99of9: It's good to see that polymaths are capable of using AW. It can't be that hard then?) [13:06:12] Hahaha, you people.. [13:07:41] Which reminds me, in electronics _context_, the imaginary number identity will appear as `j`, elsewhere as `i`. How will you represent this? (re @u99of9: Natural number, integer, sign, float64, complex128) [13:08:36] Complex128? What? (re @u99of9: Natural number, integer, sign, float64, complex128) [13:09:42] The type `complex128` consists of two `float64`s, so total 128 bits in length. (re @cvictorovich: Complex128? What?) [13:09:55] We can make multiple stringifying functions that go both ways, and a read function that accepts both. The electronics sentences can call the j stringifying version. (re @smlckz: Which reminds me, in electronics _context_, the imaginary number identity will appear as j, elsewhere as i. How will you represe...) [13:11:56] We will have to pick one for each language's display function, which shows in the WF interface. I believe i is proposed for that. (re @u99of9: We can make multiple stringifying functions that go both ways, and a read function that accepts both. The electronics sentences ...) [13:15:22] Oh, the boring way. I was wondering that there'll be some kind of dynamic "context" that the stringifier can look up and know if it's in an Electronics one and adjust accordingly. I was imagining too much. [13:18:25] Maybe. I expect we will be increasingly using context. [13:41:48] Which reminds me, you should find [[w:Scope_(computer_programming)#Dynamic_scope]] helpful, should Wikifunctions implement them. I remember hearing here about forgetting to pass a language parameter, requiring quite a bit of refactoring. You can have such commonly used, important variables placed in dynamic scope. [13:49:53] I don't expect to get that any time soon. We have to pass in everything we want available to the function. [14:25:41] We do… but AW doesn’t. When we use the default values, the persisted object contains Z18 objects referencing the appropriate keys of Z825, like this [14:25:42] { [14:25:43] "qid": "Q1997", [14:25:45] "sections": { [14:25:46] "Q8776414": { [14:25:48] "index": 0, [14:25:49] "fragments": [ [14:25:51] "Z89", [14:25:52] { [14:25:54] "Z1K1": "Z7", [14:25:55] "Z7K1": "Z38355", [14:25:57] "Z38355K1": { [14:25:58] "Z1K1": "Z18", [14:26:00] "Z18K1": "Z825K1" [14:26:01] }, [14:26:03] "Z38355K2": { [14:26:04] "Z1K1": "Z18", [14:26:06] "Z18K1": "Z825K2" [14:26:07] } [14:26:09] }, [14:26:10] { [14:26:12] "Z1K1": "Z7", [14:26:13] "Z7K1": "Z33068", [14:26:15] "Z33068K1": [ [14:26:16] "Z1", [14:26:20] { [14:26:22] "Z1K1": "Z7", [14:26:24] "Z7K1": "Z34282", [14:26:26] "Z34282K1": { [14:26:28] "Z1K1": "Z18", [14:26:30] "Z18K1": "Z825K1" [14:50:50] Ah, although it really is dynamic scoping, it's still limited to function arguments.. for arbitrary variable, detached from any particular function, we'd need an equivalent of [[w:Let expression]], approximated by (ugh) a certain function that takes a map of variables to its values, then down the call stack, doing a lookup into this map for a certain variable... A [14:50:50] little more, th [14:50:51] is would veer into esolang territory 🙃 [14:57:20] Yes. But passing the map between functions is the real sticking point, I think. (re @smlckz: Ah, although it really is dynamic scoping, it's still limited to function arguments.. for arbitrary variable, detached from any ...) [14:59:48] Between functions? [15:01:00] Between function calls, I should say, so the result from one call is available to a subsequent one. (re @smlckz: Between functions?) [15:04:42] Ah, "changing" the values of variables will be tricky.. [15:09:02] Changing for down the stack would be fine, but propagating back upwards, the map (or at least the diff of changes to it, or a closure that'd make the update) has to be returned.. [15:10:23] Unless we have... continuations. Sigh. [15:39:27] Please try not to rely on dynamic scoping-like behavior; we're doing everything we can to eliminate it 🙃. [15:56:51] 🤔 Is that a specific ticket? (re @wmtelegram_bot: Please try not to rely on dynamic scoping-like behavior; we're doing everything we can to eliminate it 🙃.) [16:19:30] I’ve reconnected Z14403, although it fails Z40026. I’m inclined to disconnect Z40026 for the time being but I may get a chance to fix the JavaScript later this evening. [19:59:02] I’ve applied a fix to Z14403 and created a map-based implementation: Z40135. (re @Al: I’ve reconnected Z14403, although it fails Z40026. I’m inclined to disconnect Z40026 for the time being but I may get a chance t...) [20:12:42] It's not something we can feasibly capture in a ticket, unfortunately. (re @AI: 🤔 Is that a specific ticket? ) [20:30:43] That said, if you know of a way we can communicate that general principle, I'd be very happy to hear it! [21:05:53] If you have particular examples of where the principle is not currently adhered to, I’d be happy to try to articulate what the principle might be. I thought all community functions were essentially pure, with some uncertainty around error handling. 🤷‍♂️ (re @wmtelegram_bot: That said, if you know of a way we can communicate that general principle, I'd be very [21:05:53] happy to hear it!) [23:51:25] <[[smlckz]]> apine, why eliminate dynamic scoping, which I suppose was accidentally available, instead of formally introducing it? Otherwise, to alleviate the issue of passing many variables, they should be collected into a structure or record (perhaps extensible) whose keys could be given multilingual labels. Or introduce keywords (like Common Lisp, Erlang [23:51:25] <[[smlckz]]> (called atom), Elixir, Clojure, JS (called Symbol) etc.), similarly 'label'able, to continue using with ordinary map.