On Fri, 15 Oct 2021 08:02:54 +0000 Nicholas Clark <nick@ccl4.org> wrote: > After the call, I think I came to the conclusion that (pragmatically) > the public flags really are "implementation detail" than "public". ... Yes; the more we look at this the more it feels like the flags aren't really "private" vs "public", as a case of "private and nobody looks at them" vs "private but other people are nosey and poke about at them anyway". We don't have a proper public API to look at these - which is the intention we're aiming to fix. > The second problem we're juggling is that that Perl doesn't have a > type system (old news!) but in this context it's that it doesn't have > a *numeric* type system. Let's steal Scheme's ;) Hah - no, I joke. But I do mention it because people often comment that Perl's "type system" is broken because it doesn't distinguish numbers vs strings. But then many other languages don't distinguish integers vs. reals. Scheme in particular has a whole huge category that, for example, can represent "exact" rationals such as 1/3 as real two-integer quotients, as a fundamentally different type from "inexact" floats; the common implementation of which is an IEEE double. From Scheme's perspective almost any other type system is lacking in fine-grained detail. ... > (This doesn't matter in JavaScript because all maths *is* 64 bit IEEE > floating point. But we're faking things internally to also offer 64 > bit integer maths on 64 bit platforms. And we don't have a type > system...) This is why I understood that JSON (whose origin inspiration is JavaScript) wouldn't distinguish true integers from floats. It's simply a formatting optimisation by realising that some numerical values can be exactly expressed without a decimal point and trailing sub-unit digits. -- Paul "LeoNerd" Evans leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/Thread Previous | Thread Next