[00:04:43] <[[smlckz]]> Errors by themselves, as non-local transfer of control, don't affect the purity much, insofar you accept partiality of all functions, simply that function not returning, resorting to bottom. Otherwise, how would continuations be considered functional at all. As for error _handling_ to be 'pure'r, you have Monads (e.g. Option[x](Some[x], None) and [00:04:43] <[[smlckz]]> Result[x,e](Ok[x], Err[e])) to rely on ;) [00:24:56] The main issue is that dynamic scoping makes it impossible to calculate closures effectively, which makes it impossible to implement certain other features like memoization. This is ultimately a consequence of WF as a language making so little of the program available at a time (anything could be a function, and anything could be a Z9, requiring an expensive retrieval operation). [00:36:38] What do you all think about prohibiting literal monolinguals, literal strings, and literal HTML from being entered as arguments in the AW front end? It is quite tempting for newcomers, but usually causes non-abstract single language content. For example in https://abstract.wikipedia.org/view/en/Q1400 we have a line in English about the American revolution. [00:42:28] I'm aware of a few ~valid uses, including things I've done myself, but I wonder if we should find alternatives and deprecate these kind of uses: Z32220 which has no visible output, and functions with string arguments that would be better off as another type (e.g. Z37464K2 which we are hoping to replace with a new type soon). [00:45:17] Another consequence is that we would need to truly trust our read functions for the types we should continue be allowed to enter as parameters. We might no longer be able to open them up to specify the string keys individually. [00:45:55] It contravenes [[:abstract:Abstract Wikipedia:Manual of Style#Monolingual content]] but I’m not sure we should physically block it. (re @u99of9: What do you all think about prohibiting literal monolinguals, literal strings, and literal HTML from being entered as arguments ...) [00:46:40] Do you know of cases where it's a good think to allow? (re @Al: It contravenes [[:abstract:Abstract Wikipedia:Manual of Style#Monolingual content]] but I’m not sure we should physically block ...) [00:49:41] Quotations? Formulas? I haven’t edited AW much. (re @u99of9: Do you know of cases where it's a good thing to allow?) [00:51:30] Those are good examples we'd need a system for. Perhaps a type for LaTeX Strings would solve the latter. (re @Al: Quotations? Formulas? I haven’t edited AW much.) [00:58:03] What about this? [00:58:03] second HTML fragment [00:58:05] * [00:58:06] * [00:58:08] simple cite from URL, QIDs and date (https://www.wikifunctions.org/view/en/Z38542) ("https://npgallery.nps.gov/NRHP/GetAsset/6a1e79e0-9859-41a4-a86c-153dfa92b667", [00:58:09] Skagit River Hydroelectric Project (https://www.wikidata.org/wiki/Q7533756), [00:58:11] National Register of Historic Places (https://www.wikidata.org/wiki/Q3719), [00:58:12] view date, [00:58:14] view language) (re @u99of9: Do you know of cases where it's a good thing to allow?) [00:58:59] Yes, that's a good one. A validated URL type??? [00:59:35] Clearly I have a few Type proposals to write before this could be implemented! [01:03:16] A fair number of Z6 cases seem to be literal natural languages 🤷‍♂️ [01:03:17] type [01:03:18] Function call (https://www.wikifunctions.org/view/en/Z7) [01:03:20] * [01:03:21] *function [01:03:23] paragraph from sentences (https://www.wikifunctions.org/view/en/Z33068) [01:03:24] * [01:03:26] *sentences [01:03:27] * [01:03:29] * [01:03:30] state location w/ entity & class, mono  ( [01:03:32] this article's subject, [01:03:33] sovereign state (https://www.wikidata.org/wiki/Q3624078), [01:03:35] Southern Africa (https://www.wikidata.org/wiki/Q27394), Natural language (https://www.wikifunctions.org/view/en/Z60) ("en", Typed list (https://www.wikifunctions.org/view/en/Z881) (String (https://www.wikifunctions.org/view/en/Z6)))) [01:03:36] * [01:03:38] * [01:03:39] defining role sentence (monolingual (https://www.wikifunctions.org/view/en/Z28016)) ( [01:03:41] Antananarivo (https://www.wikidata.org/wiki/Q3915), [01:03:42] capital city (https://www.wikidata.org/wiki/Q5119), [01:03:44] this article's subject, Natural language (https://www.wikifunctions.org/view/en/Z60) ("en", Typed list (https://www.wikifunctions.org/view/en/Z881) (String (https://www.wikifunctions.org/view/en/Z6)))) [01:03:45] * [01:03:47] * [01:03:48] language [01:03:50] * [01:03:52] *type [01:03:54] Natural language (https://www.wikifunctions.org/view/en/Z60) [01:03:56] * [01:03:58] *language tag [01:04:00] "en" [01:04:02] * [01:04:04] *language tag aliases [01:09:18] Those should be changed to references IMO. I've just done this at https://abstract.wikipedia.org/wiki/Q1019 (re @Al: A fair number of Z6 cases seem to be literal natural languages 🤷‍♂️ [01:09:18] type [01:09:20] Function call [01:09:21] function [01:09:23] paragraph from sentences [01:09:24] sent...) [01:09:53] So I guess I'm adding literal Natural Language to my list of prohibitions... (re @u99of9: Those should be changed to references IMO. I've just done this at https://abstract.wikipedia.org/wiki/Q1019) [01:13:23] Well, I think these are just wrong. (re @u99of9: So I guess I'm adding literal Natural Language to my list of prohibitions...) [01:15:33] Agreed. Sorry by "references" I should have said "the display language argument". (re @Al: Well, I think these are just wrong.) [01:16:49] By permitting this kind of semi-hidden problem, we set ourselves up for a lot of cleanup later. [01:18:51] I only found the Pennsylvania case because I was impressed by the sentence and wondered how it was done... [01:20:17] The “view language” argument reference 🤔 [01:20:18] A search (https://abstract.wikipedia.org/w/index.php?fulltext=1&ns0=1&profile=advanced&search=Z6&title=Special%3ASearch) (re @u99of9: Agreed. Sorry by "references" I should have said "the display language argument".) [01:23:43] Some of those search results are indeed me adding Z37464. Even without getting the new ZID type, I'd prefer to do this wrapping on WF so AW doesn't need such weird calls. (re @Al: The “view language” argument reference 🤔 [01:23:44] A search) [01:39:13] Apparently Q12345 (fun Easter Egg QID) can already count in abstract. The string is the HTML attribute. : https://tools-static.wmflabs.org/bridgebot/c0b18dd8/file_83387.jpg [01:48:02] Yes, we shouldn’t be retrofitting links into pre-generated text, as a rule. [01:48:03] I suspect the natural HTML result from NLG should have links from all its referring expressions, and the required link-styles (including no-link, no-style) are specified per referent. But it’s late, so I may not be thinking straight. 🎃 (re @u99of9: Some of those search results are indeed me adding Z37464 (e.g. at https://abstract.wikipedia.org/view/en/Q1348). Even without [01:48:03] ge...) [01:49:43] <[[smlckz]]> apine: "impossible to calculate closures effectively" hmm? you do *not* capture dynamic variables, only lexical. Pure dynamic variables are 'like' global variables. "memoization" ah, that's an issue indeed.. at least we can memoize functions that don't refer to dynamic variables. "making so little of the program available at a time" you'll benefit [01:49:43] <[[smlckz]]> from compilation (whether AOT or JIT) very much, but implementing it is a difficult matter, for the language is like one of the dynamic'est of the dynamic.. [01:53:06] At the moment almost all our links are currently injected (as HTML) after the NLG is done (in monolingual text). That was why I was pressing you for answers about the structured HTML type proposal. (re @Al: Yes, we shouldn’t be retrofitting links into pre-generated text, as a rule. [01:53:08] I suspect the natural HTML result from NLG should ...) [01:56:15] I have almost no idea what you're all talking about (which is fine by me, I'll stay out). But I think this does slightly intersect with the problem of how links display in AW articles when they move from on-AW to embedded-in-a-language-wiki. The global context could allow a context dependent linking function. But until y'all showed me there was something deeper, I [01:56:15] thought we trul [01:56:15] y had to stay pure. (re @wmtelegram_bot: <[[smlckz]]> apine: "impossible to calculate closures effectively" hmm? you do *not* capture dynamic variables, only lexical. Pu...) [02:04:50] <[[smlckz]]> u99of9: "I have almost no idea what you're all talking about" similarly with (natural lanaguage) linguistics (generative grammar etc.), I also have very little idea. So long we can work together.. [03:15:15] <[[smlckz]]> apine, as things stand, it's already has slight inclination towards JIT, with selection of implementation based on its performance. When I thought of AOT compilation, I shuddered at the thought of doing profiling and testing (in the compiler!) before choosing which one to pick.. >_<; At least allow giving some annotation to implementations, that a [03:15:15] <[[smlckz]]> certain one is of theoretical interest (such as addition implemented using incrementing), than practical (optimized for performance, in contrast to legibility).. [03:31:05] <[[smlckz]]> u99of9, another aspect, seperate from context-dependence, would be generics. Keeping the generated output as tree of the elements (of what we mean, than how it'll be presented), than serialized into any particular markup language (you DON'T want to parse HTML back..), such that the recipient can implement serializer of their own choosing.. [07:43:52] Yes. If I understand you and Al correctly, that is what is being proposed here: https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/HTML_fragment_structure (re @wmtelegram_bot: <[[smlckz]]> u99of9, another aspect, seperate from context-dependence, would be generics. Keeping the generated output as tree o...) [07:48:20] Given the recent renewed interest asking us to generate wikitext, I wonder if our render able precursor/generic should actually be pre-html? So that it can be serialised/rendered whichever way we like. But I don't really know what that should look like. [07:54:35] Yes, but I now think we want no conversion to and from code. (re @u99of9: Yes. If I understand you and Al correctly, that is what is being proposed here: https://www.wikifunctions.org/wiki/Wikifunctions...) [07:55:54] So the code implementations should just get and send back the raw objects? I think I'm fine with that. (re @Al: Yes, but I now think we want no conversion to and from code.) [07:57:17] I guess it's no problem to make an HTML precursor type because it should be reasonably straightforward to convert to or from any other precursor format? [08:01:18] I'm still a bit worried about the expectation that configs will expect their functions to return this fairly complex structure. But I hope we can write constructors that make it easy to build them from monolingual chunks and linking preferences. [08:05:03] Well, that’s the theory. Let’s just say it should be easier than going from HTML, because you don’t have to parse it. But we’d probably want to canonicalize it, which is basically just concatenating the sub-strings, as we would when serializing to HTML. Then we can define equivalence as equal canonical forms. (re @u99of9: I guess it's no problem to make an HTML precursor [08:05:03] [08:05:03] type because it should be reasonably straightforward to convert to or from any...) [08:40:45] Yes. We might make “referring expression” a separate type, but I think it can just be a subtype of pre-HTML. (re @u99of9: I'm still a bit worried about the expectation that configs will expect their functions to return this fairly complex structure. ...) [09:07:29] <[[smlckz]]> I was talking about something akin to Pandoc's ''format-neutral representation of documents'', adapted to our circumstances: see the Block and Inline data types defined here: https://hackage-content.haskell.org/package/pandoc-types-1.23.1.2/docs/src/Text.Pandoc.Definition.html#Block [09:37:02] <[[smlckz]]> However, without proper sum-types, trying to create a recursive type like this just devolves into the top type; the type system isn't expressive enough [09:38:23] The only real concern I have about backing too far away from HTML is that it introduces another set of terms for people to be familiar with. The pre-HTML proposal is just a tree-representation of HTML in which every string is represented as a list of strings. The theory is that the tree representation allows the contents to be inspected and manipulated without the need to [09:38:23] parse a [09:38:24] ny HTML. The reason for having lists of strings is to avoid the repeated overhead of joining strings when constructing the tree’s contents. A target attribute or tag name is necessarily a string in HTML, but I envisage that we shall be constructing attributes names based on object identifiers (like data-Z6091 for a QID, for example). We may not need this for tag names. [09:38:24] (re @wmt [09:38:26] elegram_bot: <[[smlckz]]> I was talking about something akin to Pandoc's ''format-neutral representation of documents'', adapted to our circu...) [09:46:38] <[[smlckz]]> You can look at the terms used in Pandoc's type definitions at that link, it should be quite familiar to HTML users, yet Pandoc supports output formats that are as far away as it could be possible from HTML (LaTeX, Org Mode, and even Mediawiki's Wikitext for that matter) [09:47:41] Function is ready: Z40161 (re @Earldridge Jazzed: I am planning to make a simple languages implementation of Z28436 (in the likes of HenkvD) with 8 languages: Indonesian, Malay, ...) [09:56:12] Yes, I did. I’m just defining “far away” in those terms, not assessing how “far away” any particular markup may be. (re @wmtelegram_bot: <[[smlckz]]> You can look at the terms used in Pandoc's type definitions at that link, it should be quite familiar to HTML users...) [15:18:46] Hey, all! I jus wan to give a heads-up that labels in a Z12 are going to be stripped out of the backend after next week's deployment (https://gitlab.wikimedia.org/repos/abstract-wiki/wikifunctions/function-orchestrator/-/merge_requests/800). If this causes any issues, please speak up! [23:17:51] 0265