[01:12:17] I see Al has made great progress on Z28243. I had a brief peek and can't see why Z28245 fails the first test Z28244. When I run each step manually it seems to give broadly the correct answer, but maybe it's some kind of reference/type/string/object conflation just for this type?? We now have other good implementations, so I'm not particularly worried, except that [01:12:17] maybe there's a [01:12:18] n issue with Z803 or my understanding of it. [08:47:37] There’s nothing wrong with the composition. It just returns a reference to Z60 for that case, rather than the equivalent Z4 object that the function expects. That’s simply a case of T389183. Until that’s fixed, we either need to specify the function as returning a Z1, or ensure that any resulting Z9 is de-referenced to the Z4 it references. Though less correct in theory, [08:47:37] ex [08:47:37] pecting a Z1 is the more efficient solution. (re @u99of9: I see Al has made great progress on Z28243. I had a brief peek and can't see why Z28245 fails the first test Z28244. When I run ...) [08:59:54] When selecting a function, the list usually contains only those functions that return an appropriate type of object. I don’t know why it doesn’t do that at the top level. I thought it did, but apparently not 🤷‍♂️ (re @sNappy_ml: Thank you! It worked. So, it's strict, fine. (Then, I don't know if it is the best way to implement, and many other things that ...) [10:53:55] Ah yes, something I knew full well in March... Maybe that's why I moved away from dealing with Types until now! (re @Al: There’s nothing wrong with the composition. It just returns a reference to Z60 for that case, rather than the equivalent Z4 obje...) [11:01:10] I tried to modify the composition to de-reference the Z9 by wrapping it in Z28373, but I didn't get it working. Is that what you mean by de-referencing? (re @Al: There’s nothing wrong with the composition. It just returns a reference to Z60 for that case, rather than the equivalent Z4 obje...) [11:11:02] Yeah, Z29420 is already de-referencing, logically the same as Z28375. (re @u99of9: I tried to modify the composition to de-reference the Z9 by wrapping it in Z28373, but I didn't get it working. Is that what you...) [18:15:08] Apparently Z104 does the job… can’t think why I didn’t think of trying that sooner 😳 (re @u99of9: I tried to modify the composition to de-reference the Z9 by wrapping it in Z28373, but I didn't get it working. Is that what you...) [19:33:21] Still a bit odd but it might be a caching issue… Z29450 shouldn’t need a Z104 wrapper because Z29449 already has one. (re @Al: Apparently Z104 does the job… can’t think why I didn’t think of trying that sooner 😳) [21:00:23] Is Z29446 a duplicate of Z16360? [21:33:35] It’s specifically for a composition of the two builtins so that Z16360 can have custom error handling and Z29446 can have the better performance. (re @u99of9: Is Z29446 a duplicate of Z16360?) [21:38:27] Ok, fair, we may want this distinction for a few core functions. I suggest we name them both the same (here "second element") with either "(performance)" or "(error handling)". Then list the other ZID in the description (or even alais?). [22:52:06] I don’t think there will be many cases because the builtins protect themselves when not composed. It’s not always about performance, though. For example, a properly recursive implementation needs its own function to avoid switching to the preferred implementation when it recurses. I’d generally try to link similar functions by implementations or in test cases. Shared [22:52:06] aliase [22:52:07] s are good but I’m not so keen on unlinked ZIDs anywhere, especially in function descriptions. I’m not unduly concerned, however 😎 (re @u99of9: Ok, fair, we may want this distinction for a few core functions. I suggest we name them both the same (here "second element") w...)