[00:32:50] I take it there was some confusion at the VC about Z861. I've marked it with a (#) to show that it doesn't work because it currently calls a broken built-in. I'm still not really sure why we need this as a built-in anyway, because we have two easy compositions which work. (re @u99of9: Why do we need a built-in Z861? Since the built-in implementation didn't work on the [00:32:50] first tes [00:32:50] t, I made a composition just swit...) [00:34:26] "It is confusing to have parallel built-in and community functions." (re @Al: Could be. I wonder whether we should explore the option of having built-in implementations for community functions rather than w...) [11:44:48] I made a leaner implementation of “nth element” (Z28697). It had bound-checking originally but I’ve removed that because establishing the length of a list uses a fair chunk of available resources, causing a time out for statements from the United States item, for example. I could re-instate lower-bound checking but I’m inclined to the view that we should generally add new [11:44:48] [11:44:49] “safer” functions rather than adding new implementations to existing “unsafe” functions. We could decide separately for each case, but built-ins would always need a separate function and it seems sensible to apply the same approach for compositions of built-ins (like “second element”). This function is a hard case, so I’ll take discussion to its talk page (eventual [11:44:49] [11:44:50] ly). (re @u99of9: Sounds good, thanks.) [11:47:39] That procedure makes sense to me. (re @Al: I made a leaner implementation of “nth element” (Z28697). It had bound-checking originally but I’ve removed that because establi...) [21:40:14] There is a spammer running amok on the mailing list [21:44:40] I banned him, again [21:44:46] I hope it worked this time