[04:46:51] Here is a reasonable starting point for a Byte Type reader: Z22866 (re @vrandecic: Newsletter #191 [04:46:52] * From things to words [04:46:53] * Volunteers’ Corner on March 3 [04:46:55] * Recent Changes in the software [04:46:56] * Function of the Week: ...) [05:23:41] Sometimes I'm seeing something odd when I search for a type: : https://tools-static.wmflabs.org/bridgebot/8beb6163/file_68838.jpg [05:30:53] Here is my suggestion for a Byte Type display: Z22887. This one might need discussion because there are quite a few options. My suggestion is that languages without language-specific displays see a prefixed hexadecimal with two capitalised digits, e.g. "0xFF". But I can see reasons to use other defaults (e.g. a plain Arabic decimal digit string). (re @u99of9: Here is [05:30:54] a reasonable [05:30:55] starting point for a Byte Type reader: Z22866) [05:32:58] Also, it's not really the user's natural language that should configure this display. The ideal would allow users to configure their own preferences amongst the options for each type. But that's a big feature request, so is just a sidenote here. (re @u99of9: Here is my suggestion for a Byte Type display: Z22887. This one might need discussion because there are quite a [05:32:58] few options. My ...) [08:13:52] I see you’ve been busy! Thank you 🙏 And I see there’s a topic on Project Chat… 👍 Just in general, though, we should think about how to specify the applicable format within the string input to a read function. For example, “1010 1101 [binary, Arabic]” for AD (hex), 173 (decimal). Some such convention will be especially important for dates, where I can’t even agre message> [08:13:53] e the preferred format amongst myself! (re @u99of9: Here is a reasonable starting point for a Byte Type reader: Z22866) [08:20:43] At the moment I think read and display functions only get to have one extra parameter, the language. [08:21:30] I should allow for binary. That's not an option yet. (re @Al: I see you’ve been busy! Thank you 🙏 And I see there’s a topic on Project Chat… 👍 Just in general, though, we should think about ...) [08:22:05] Yes, but these options would be within the string itself 🤷‍♂️ (re @u99of9: At the moment I think read and display functions only get to have one extra parameter, the language.) [08:24:07] Oh. Like the "0x" in "0x10" to switch to hex? [08:26:23] "DMY 1/2/2025" [08:27:20] Yes, but more general and consistent across different types, so I can enter rationals in base 7 and so on. (re @u99of9: Oh. Like the "0x" in "0x10" to switch to hex?) [08:32:46] I'm not sure I'll ever have the need to do that, but if I do I would send it through Z18467 first. Consistency across unlike types sounds super hard. (re @Al: Yes, but more general and consistent across different types, so I can enter rationals in base 7 and so on.) [08:44:39] It’s just consistency of approach, really. The formats for Byte are just different bases. Whether we choose to support rationals in other bases is a separate question, but if we did have a separate type for rationals with a specified base, what would its read function look like? (re @u99of9: I'm not sure I'll ever have the need to do that, but if I do I would send it [08:44:39] through Z1 [08:44:40] 8467 first. Consistency across unlike typ...) [08:49:25] I think I've seen underscores before. Something like "FF_16". (re @Al: It’s just consistency of approach, really. The formats for Byte are just different bases. Whether we choose to support rationals...) [08:50:51] But I think dates will be much more challenging, so it's worth giving attention to that. [09:02:33] True. That’s why I thought we should include them in our thinking 😏 I’m inclined to put the format specification after the data, but so long as it is clearly delimited, I’m pretty relaxed about what the delimiter(s) should be. I think I would make them a pair, however, so that we can parse the string based on the final chatacter(s) and avoid having to escape them in the [09:02:34] [09:02:34] data. (re @u99of9: But I think dates will be much more challenging, so it's worth giving more attention to them.) [09:10:07] Personally I wouldn't want to type "1/2/2025 [DMY]". If it didn't give me instructions (according to my language preference), and I couldn't choose from a format drop down, I'd be typing in something unambiguous like "2025-02-01" (re @Al: True. That’s why I thought we should include them in our thinking 😏 I’m inclined to put the format specification after the [09:10:07] data,...) [09:14:11] That’s fine, so long as it is indeed unambiguous. But if you wanted it to mean Jan 2nd, you could easily tack “[ccyy-dd-mm]” onto the end. [09:18:52] That doesn't look so easy to me. I'd still avoid it. I also can't imagine it would become a large volume of our manual data entry as a site. [09:24:14] I’d say it would always be optional. For numbers, we might just specify the radix character, when otherwise ambiguous 🤷‍♂️ (re @u99of9: That doesn't look so easy to me. I'd still avoid it. I also can't imagine it would become a large volume of our manual data entr...) [09:30:29] But why go to the trouble of specifying it rather than typing in the format that your language configuration requests? [09:32:26] If I'm browsing in "en", and it wants a date "e.g. 12/31/2025" then it's much easier for me to comply? [09:32:54] Maybe the data is already in a particular format and I’m copying it rather than re-typing it? (re @u99of9: But why go to the trouble of specifying it rather than typing in the format that your language configuration requests?) [09:34:43] Maybe. I could imagine that being a time saver if bulk copying were possible. But then we would still have to append "[dd/mm/ccyy]" to each of the copied values? (re @Al: Maybe the data is already in a particular format and I’m copying it rather than re-typing it?) [09:46:02] It’s about avoiding typos as much as saving time. Exactly what we’d have to type for the required format would depend on the read function. It could be simplified to a single character, if we wanted to do that. For example, “d” could mean that the day comes before the month (and we rely on leniency for identifying the year, defaulting to dmy). (re @u99of9: Maybe. I could [09:46:03] [09:46:03] imagine that being a time saver if bulk copying were possible. But then we would still have to append "[dd/mm/ccy...) [10:27:32] It’s very much a work in progress, but Z22849 should already be useful. (Only the first and third arguments are active, and only the first string for the third argument.) (re @vrandecic: (doesn't mean that I don't regularly miss functions that are already there, our search needs improvement)) [10:31:02] Oh, and both are currently mandatory. (re @Al: It’s very much a work in progress, but Z22849 should already be useful. (Only the first and third arguments are active, and only...) [10:46:56] …were mandatory but are now optional 😎 (re @Al: Oh, and both are currently mandatory.) [11:41:45] Hallo. [11:42:48] There's a new WikiLambda message: "Literals and resolvers" (key `wkilambda-mode-selector-types-group-label`). [11:43:46] I think that I understand what literals are. It's generally a common word in programming, and there's even an entry for it in the glossary: https://www.wikifunctions.org/wiki/Wikifunctions:Glossary#literal [11:43:56] But what are "resolvers"? [11:44:57] …the third and fourth arguments now resolve lists. (re @Al: It’s very much a work in progress, but Z22849 should already be useful. (Only the first and third arguments are active, and only...) [11:45:33] (Oh, that’s unfortunate. I wasn’t replying to you!) (re @amire80: But what are "resolvers"?) [11:52:00] I guess it’s referring to what might be available in the “…”menu: argument reference, function call, reference… but those aren’t so much “resolvers” as “objects requiring to be resolved” 🤷‍♂️ (re @amire80: I think that I understand what literals are. It's generally a common word in programming, and there's even an entry for it in th...) [11:53:11] Also, the documentation for that message is "Label for the literals and resolvers group in the Mode Selector". What is the "Mode Selector"? [11:57:02] Yeah, I’m guessing that’s the “…” menu where you select whether you’re providing a literal object or something else. I’ve never understood why that’s separate from type selection (since that is actually what it is, technically). (re @amire80: Also, the documentation for that message is "Label for the literals and resolvers group in the Mode Selector". What is the [11:57:03] "Mode...)