On Intl/CLDR

[Vlad GURDIGA]

Hey everybody! 👋

The other day I found myself writing a function to format numbers. The first question was: What is the right way to format a number? There should be a standard or something. 🤔 Googled a bit and found about the Unicode CLDR Project. They have a huge amount of structured data, and I surely found the data I was looking for. 🤓

Now, seeing all that data, I thought: Wow! Wouldn’t it be cool to have an Elm library that’l hold all that? elm-cldr? 🎩 Oh, it’d be enormous… What if I only need number formatting? Oh, I know: elm-cldr-numbers! and elm-cldr-dates! and elm-cldr-localenames! and… Ooooh yeah!! 🤠

Then I remember that the CLDR website was saying that they provide data for apps and operating systems. Hm… shouldn’t it be there already somewhere in the OS? 🤔 Googled a bit more and found that browsers already have that as window.Intl and MDN says it has quite good support, down to IE11. Couldn’t believe that one, so spun up my Windows VM and pasted a snippet into IE11’s console: it worked! 👽

Hm… OK… Now, it’d really be quite cool to build all those elm-cldr-* things that I imagined, wouldn’t it make more sense to reuse what’s already there? What would it be like to use that? OK, let’s go native! A couple hours later I got myself Native.Intl. 😎

Now, looking at all this I begun wondering what would it be like to have it in the Elm standard library, and inevitably found Evan’s 2 threads (one and two) about the philosophy around native in Elm, and I kind of see his point about keeping Elm high-quality, but how about cases like this where we’re not talking about JS libraries but about browser’s native APIs like Intl? 🤔

It’d probably be not that hard to get that data packaged into a few Elm libraries, hopefully not-that-large each, but it’d still end up growing the final app bundles, and probably some compilation time during the hundreds of refreshes a day that a dev does…😳 So I’m not entirely sure it’s a constructive idea. 😶

So although for my little toy-project I can just use Elm native, how about long-term? What would make more sense? I mean these two options:

1. implement Elm libraries using the CLDR data
2. hope that window.Intl will some day become part of Elm standard library

What are some pros and cons? Are there any other options people have considered? 🤔

[Ian Mackenzie]

Exposing window.Intl directly also ties Elm more tightly to the browser/JavaScript environment, which Evan mentioned in that second linked thread that he is trying to avoid:

Elm is designed to be 100% independent of JS. It happens to compile to JS now because that was the right thing to do, but in a decade, I expect we'll be compiling to something more efficient. There is a small set of "native" stuff for now, but that means supporting the entire ecosystem on a new platform is fairly easy.

So Elm could currently use window.Intl, but that would mean its functionality would have to be replicated exactly if Elm ever compiles to a non-browser environment. Even now that would make life a bit more difficult for people using Elm code within Node applications - it's possible, but you have to do things like hook up a third-party XMLHttpRequest implementation like xhr2. If it's not too hard, it's probably better to reimplement the functionality in pure Elm so that it can be used on any platform that Elm compiles to in the future.

[Mark Hamburg]

One way to maintain language portability to other environments is to make a distinction between the language and the libraries. Almost every environment is likely to have something special — that's part of what justifies being it's own thing. It is entirely reasonable to say that the Basics library should remain portable. It is, however, also entirely reasonable to expect that the people who did the browser internationalization libraries probably know more about the issues than the people likely to write an Elm internationalization library at this point in Elm's evolution. If that functionality isn't available somewhere else then the library isn't available and that's an issue for that platform not for Elm.

Mark

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.