[01:03:26] I've raised the topic with the team, so there shouldn't be any surprise "fixes" to `Z973` anytime soon. We'll figure out a comprehensive solution for this stuff at some point, and, if we do any fixes in the near term, we'll be communicative. (re @ If map is changing, please make sure it doesn't break Z13036 too badly.) [05:15:27] so you're comfortable that the change from "tests if two lists are exactly equal" to "lists are exactly the same elements in the same order (whether or not the list is explicitly typed)" reflects both the intent and operation of the function? https://www.wikifunctions.org/w/index.php?title=Z889&diff=121272&oldid=92324 (re @wmtelegram_bot: I'm looking over some [05:15:27] of the stuf [05:15:28] f about typed lists. One thing I see is that the builtin list equality function SHOULD ...) [05:22:53] That sounds similar/alternative to https://www.wikifunctions.org/wiki/Wikifunctions:Type_proposals/configuration_of_functions_for_given_types . Can your method be achieved with the current capabilities? There are quite a few functions we need a plan for: https://www.wikifunctions.org/wiki/Wikifunctions:Catalogue#Functions_with_list_outputs (re @wmtelegram_bot: [05:22:53] someList)` [05:22:54] , where `getMapFunction` returns a `Z8` whose signature (`Z8K2`, `Z8K3`) is generated from the arguments `inpu...) [10:27:35] I kind of agree, in principle. Do we have a road map for “generics”, more generally? For me, the sequencing is more relevant than the timing, because I fully expect that we will never reach the end of the road (by the law of diminishing returns). It’s still too early for me to say what the actual pain points are, in practice, but being able to specify that a list (or [10:27:35] argume [10:27:36] nt) can be one of several Types (rather than “any”) seems likely to be a high priority. I think we already need this for Integers and Natural numbers and this will become more painful as new numeric Types are introduced. The problem is likely to be more painful for textual Types, as we move into the Natural language domain. Whether there are practical advantages to going [10:27:36] beyo [10:27:37] nd that to properly generic functions, I’m not so sure. I’m inclined to view this problem from the bottom up. An implementation may have a narrower or broader scope than its function (specification). If we can characterise that as an implicit function specification (perhaps making it explicit), then we should be able to reduce the duplication of code across [10:27:38] implementations. I [10:27:39] t would mean, for example, that we would not necessarily need a new equality function for each custom type, or a new “next” function for every type that converts to an integer. Whether implementations that are “generic” (functions) in this limited way actually benefit from being formally “generic” in the way you suggest… I’m definitely not sure! (re @wmtelegram_bo [10:27:39] [10:27:40] t: That said, your solution (wrapping the result in `Echo`) will work. As a more general comment: a lot of functions which ...) [12:25:49] I just heard about JSON web tokens. Would that be a good idea for wikifunctions to support? https://jwt.io/introduction [13:41:49] Hmm, what would the use case be?