[01:57:15] Done. Z18683 (re @Toby: Yes, we can delete this, or move it to an exact object equality.) [02:08:29] Agreed. I've made this into a test Z18688 at Z13052 (re @Al: It isn’t a timeout. The Python implementation of object equality fails for your two lists. The contains composition succeeds, bu...) [02:14:11] and as you say, both implementations fail with reversed arguments Z18689 (re @Toby: Agreed. I've made this into a test Z18688 at Z13052) [02:22:51] and to complete the set demonstrating your theory Z18690 (re @Al: It isn’t a timeout. The Python implementation of object equality fails for your two lists. The contains composition succeeds, bu...) [09:13:21] User list - Wikifunctions [09:13:21] https://www.wikifunctions.org/wiki/Special:ListUsers/functioneer [09:13:22] We now have 49 functioneers 🥳✨ [13:54:36] I'm looking over some of the stuff about typed lists. One thing I see is that the builtin list equality function SHOULD work even if the lists are of different types, so long as the provided equality function compares the objects correctly. There may be an issue with Python/JS-based equality functions if the elements of the list are themselves differently-typed lists, since that will affect the type conversion logic. [13:56:30] I do see that `Z973` unconditionally returns a list of type `Z1`, which is wrong. We have a(n imperfect) heuristic for inferring the return type of a constructed list given the types of its elements, and I see we even have a TODO to use that OR the return type of the Z873K1 to constrain the list's type. I can work on that. [13:57:04] (re @Al: It seems that Z973 returns an untyped (Z1) list.) [14:00:32] That said, your solution (wrapping the result in `Echo`) will work. As a more general comment: a lot of functions which currently return `Z1` should (in my opinion) become Generics. For example, we shouldn't just call `Map(someFunction, someList)`, because then `Map` can't reliably know the return type of `someList`. Instead, I think we should have something like `getMapFunction(inputType, outputType)(someFunction, [14:00:32] someList)`, where `getMapFunction` returns a `Z8` whose signature (`Z8K2`, `Z8K3`) is generated from the arguments `inputType`, `outputType`. If we adopted that pattern more broadly, I think it would resolve a lot of these paint points around types. What are people's thoughts on that? [14:02:24] https://phabricator.wikimedia.org/T338407 is the issue that would "fix" `Z973`. I will ask the team if it makes sense to do a small fix on this now, since the "real" fix is an upcoming piece of work. [15:46:22] Yes. I think we’re as happy as we can be that Z989 is working correctly. We’ve added some edge cases but we cannot connect these. (re @wmtelegram_bot: I'm looking over some of the stuff about typed lists. One thing I see is that the builtin list equality function SHOULD ...) [16:24:24] Your heuristic seems consistently correct to me. I’m relying on it for Z18475, on which Z18653 relies (lots of tests there). [16:24:24] We are currently relying on Map returning a Z1-list as a workaround for T370028. Please see comment at https://phabricator.wikimedia.org/T370028#10050004. The problem I have is that specifying a Z1-Typed list as the return type of a function is ambiguous. We need to be able to distinguish between the case where the returned list should have Type Z1 and the case where its [16:24:24] Type sho [16:24:25] uld depend on the Type of its elements. Currently we can make that distinction with the Typing (Z18475) and de-Typing (Z17895) functions. [16:24:27] (Please see my comment at https://www.wikifunctions.org/wiki/Wikifunctions:Project_chat#Typed_lists_now_open_beyond_Booleans_and_Strings) (re @wmtelegram_bot: I do see that `Z973` unconditionally returns a list of type `Z1`, which is wrong. We have a(n imperfect) heuristic for i...) [16:34:44] Hmmm hm. I see. I would claim (but let me know if this will break something) that declaring a function's return type as `List(Z1)`, but getting `List(Z6)` or whatever as a result, is still correct. [16:37:32] When I look at https://phabricator.wikimedia.org/T370028, I think this is just a casualty of our current in-between state with type conversion. This is a bit of a corner case where the inferential logic (which allows us to type-convert objects despite a `Z1` declaration) conflicts with the declarative logic (where we only look at the function's argument and return type declarations). [16:39:05] We will be looking at this in later quarters, so I don't think it's something we can fix right now. One question surrounds the usefulness of the latter case you mentioned. Under what conditions, currently, do we absolutely need a function to infer the return type from its value? And would those conditions still hold if we shifted to a stricter, more declarative type calculus, including broader use of generics? [16:41:42] On the heuristic: it is mostly correct, but, because we allow arbitrary function calls in any part of a ZObject, the problem of type comparison becomes undecidable: it's always possible to construct a Type that requires us to apply a Function in order to calculate it (e.g., with Abstract/Reify). The more we rely on that heuristic, the more chances there are for something very bad and surprising to happen 😅 [16:46:38] Yes, it’s a transitional problem. Currently basic list operations (like reverse, append, nth element etc) fail for lists that are correctly Typed but succeed for Z1-Typed lists (with Python or JavaScript implementations). (re @wmtelegram_bot: Hmmm hm. I see. I would claim (but let me know if this will break something) that declaring a function's return type as [16:46:38] ...) [17:08:14] I’m sure you’re right. But the question of whether type conversion is required or, more generally, the level to which conversion is required should be determined by the function being called. Then we can pass our list of Italian masculine singular nouns as a list of strings to a general string function, or as a list of objects to a general list function, or as a list of [17:08:15] Ital [17:08:15] ian texts to some function that is specific to Italian text but not specific to nouns… etc. (re @wmtelegram_bot: When I look at https://phabricator.wikimedia.org/T370028, I think this is just a casualty of our current in-between stat...) [18:25:54] It’s a rather profound question, isn’t it? Are types useful and how strict should they be? [18:25:55] My inclination is towards stricter type-checking, so I would rather say that prepending an Integer to a Z6-list (for example) should fail, rather than automatically converting to Z1. But that approach is more challenging with “generic” types where, realistically, you have to infer some common supertype of the List’s type and the element’s Type (which might ultimately be Z [18:25:56] [18:25:57] 1)… or not 🤷‍♂️ (re @wmtelegram_bot: We will be looking at this in later quarters, so I don't think it's something we can fix right now. One question surroun...) [20:28:30] Yes, completely agreed. Beyond the issue of correctness (as in the masculine singular noun example), there's an issue of reliability: we currently don't have any controls or versioning around the implementations of functions that use a type and the type converters for that type. So a single type converter change can break tons of functions for a very silly reason. [20:29:01] So it should be determined by the function (or at least implementation) being called, for sure. I'll make sure this is captured somewhere. (re @Al: should be determined by the function being called) [21:06:41] Yes. Please don’t do that! 🫣 (re …break tons of functions for a very silly reason.) (re @wmtelegram_bot: Yes, completely agreed. Beyond the issue of correctness (as in the masculine singular noun example), there's an issue of...) [23:41:32] If map is changing, please make sure it doesn't break Z13036 too badly. I don't anticipate a problem based on what you are planning, but that is an important dependency IMO (re @wmtelegram_bot: I do see that `Z973` unconditionally returns a list of type `Z1`, which is wrong. We have a(n imperfect) heuristic for i...)