IRC channel logs
2023-03-27.log
back to list of logs
<tonyg>tsyesika: if you would like to chat with me about anything about preserves, I'm totally up for that <tonyg>Zarutian_iPad: thanks for the mention in your most recent comment :-) <tonyg>i've also done some thinking about serialization formats that preserve ordering, like mark was talking about, but my tentative conclusion is that it's not worth doing <tonyg>having canonical forms (= equivalence of serialized form is equivalent to equivalence of deserialized form) seems good enough <tonyg>but it's also, actually, a little deeper, kind of a red herring, because it's a property of the encoding, not the data model itself <Zarutian_iPad>I have started to be more on the opinion that floats have no business to be a native datum type in serialization formats <tonyg>yep. only there because they are common and because they have an interesting ordering relation <tonyg>well, let me say, they're in the *data model*, and they happen to have various serialized forms <tonyg>the rough yardstick for what's in the preserves data model and what isn't is: is it socially valuable? and, does it have an important ordering/equivalence relation? <tonyg>that's why symbols are in there, for example <tonyg>and why dictionaries and sets are in there (interesting relations) <tonyg>for that matter, why *strings* are in there. otherwise they could be just lists of codepoints, like erlang <tonyg>(and ints, which could be lists of booleans, etc.) <Zarutian_iPad>I do not mind floats being in the data model, so to speak. I am more inclined to go the route that E wanted to with serialization and have well known builder names or what have you and build sets, maps, tuples, and such compound datums from serialized calls that use an array of arguments <Zarutian_iPad>same with IEEE 754 floats, dec64s, posits, and other number types like that