Re: [elm-discuss] Strange compiler error - cannot find a field that is obviously there.

['Rupert Smith' via Elm Discuss]

On Monday, September 11, 2017 at 6:39:32 PM UTC+1, Ian Mackenzie wrote:
>
> Have you added type annotations to all top-level functions/values? My 
> first guess would be some sort of type inference issue that's propagating 
> across files, which can usually be narrowed down by explicitly annotating 
> top-level stuff so that any discrepancies are caught as soon as possible.
>

Yes, there are type annotations there. It is a good point though - I'll 
have a careful check through that I didn't miss any.

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: On Intl/CLDR

[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.

On Saturday, 9 September 2017 10:49:31 UTC-4, Vlad GURDIGA wrote:
>
> 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? 樂
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [elm-discuss] Strange compiler error - cannot find a field that is obviously there.

[Ian Mackenzie]

Have you added type annotations to all top-level functions/values? My first 
guess would be some sort of type inference issue that's propagating across 
files, which can usually be narrowed down by explicitly annotating 
top-level stuff so that any discrepancies are caught as soon as possible.

On Saturday, 9 September 2017 04:54:28 UTC-4, Vlad GURDIGA wrote:
>
> Hey Rupert! 
>
> If I try to pull out just an isolated example to make an SSCCE out of... 
>> the problem goes away.
>
>
> Hm… this is interesting! 樂
>
> I’m wondering what are other factors that could lead to that issue, which 
> you have in the production context but not in SSCCE?
>
> I haven’t seen mentioned your environment: Elm version? Operating System? 
> The IDE or text editor? Could you please enumerate those? 邏
>

-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.