[elm-discuss] Re: Why are unbound type variables forbidden for functions in records?

nd return > an X so the result is 'List X'. > > Or is this just a quirk the current Elm compiler implementation? > > Thanks > Martin > > On Friday, 20 January 2017 16:56:23 UTC+1, Maxime Dantec wrote: >> >> Imagine a list of `Convertor a` like this : >>

[elm-discuss] Re: Why are unbound type variables forbidden for functions in records?

Imagine a list of `Convertor a` like this : convertors : List (Convertor x) convertors = convertor1 :: convertor2 :: [] mapConvertors = List.map (\c -> c.convert "foo") convertors You can see here, that you cannot map over `Convertor::convert` if you don't know what to give to the function.

[elm-discuss] Re: External Firebase comms to Elm via ports?

The Elm-Kinto library for Mozilla Kinto is using the Http library instead of trying to wrap the JS library. I think it's smart :) On Monday, January 16, 2017 at 4:45:25 PM UTC+1, Marais Rossouw wrote: > > I have custom Firebase auth processes (Auth0 => Firebase), so I run all my > login logic

Re: [elm-discuss] Re: [Suggestion] Type values and simplifying the language still

I made a TL;DR : https://gist.github.com/Warry/ca83e06f92bfc9bd866a33ed97bbc6f8 On Monday, January 16, 2017 at 1:51:40 PM UTC+1, Maxime Dantec wrote: > > Actually, we could get rid of the keyword entierly : > > Faz = (Int, Int) > Faz : ø > > Fiz = { name : String, age : In

Re: [elm-discuss] Re: [Suggestion] Type values and simplifying the language still

})*Foo : Foo Bar : Int -> Foo Baz : String -> String -> Foo *Biz : String -> Int -> Foo**Buz : String -> Int -> Foo* *Boz : String -> Int -> FooDoo a =... * On Monday, January 16, 2017 at 1:43:02 PM UTC+1, Maxime Dantec wrote: > > Thanks for the answers, I had inde

Re: [elm-discuss] Re: [Suggestion] Type values and simplifying the language still

Thanks for the answers, I had indeed made some poor choices of word in my first email :( Just before this thread dies, and out of the blue : What if... - type alias never generates a constructor (change: records do not have ctors) - type always generate an "expanded" ctor expanded as in :

[elm-discuss] Re: [Suggestion] Type values and simplifying the language still

There must be a way where we have functions for constructor AND labels for serialization. I'm pretty sure I'm not going to find a solution, and it will not be on my laptop tomorrow anyway ;-) Just glad some people share my concerns. -- You received this message because you are subscribed to

Re: [elm-discuss] [Suggestion] Type values and simplifying the language still

type correct. And even if it were, I don't see > how it would contradict my point. The constructor wouldn't be partially > applicable. You would have to define a separate function for that. Bad for > reuse and refactorability. > > > Am 15.01.2017 um 17:15 schrieb Maxime Dantec <he

Re: [elm-discuss] [Suggestion] Type values and simplifying the language still

a reason these have curried > types. > > > Am 15.01.2017 um 17:03 schrieb Maxime Dantec <he...@warry.fr > >: > > Not really, sorry I assumed that everybody knew how elm compile values but > it was very presumptuous. Currently, all type values in Elm are converted >

Re: [elm-discuss] [Suggestion] Type values and simplifying the language still

> This would take away the possibility of partially applying the > constructors like Bar. Not a good idea. There's a reason these have curried > types. > > > Am 15.01.2017 um 17:03 schrieb Maxime Dantec <he...@warry.fr > >: > > Not really, sorry I

Re: [elm-discuss] [Suggestion] Type values and simplifying the language still

; > become... > > type Msg = { action : String, value : String } > > ? > > I'm trying to figure out how you'd "authorize up to one value" in a > situation like this, since the whole point of an enumeration is to allow > multiple possibilities. > > Duane >

[elm-discuss] Re: [Suggestion] Type values and simplifying the language still

x} it's a type value, so {type, value} feels more explicit. But that I guess is event more sensitive. On Sunday, January 15, 2017 at 2:59:56 PM UTC+1, Maxime Dantec wrote: > > Hi folks, > > The last 3 versions of elm were somewhat unusual for a young programing > language: fe

[elm-discuss] [Suggestion] Type values and simplifying the language still

Hi folks, The last 3 versions of elm were somewhat unusual for a young programing language: features were removed and it has been simplified, to the point that you can't remove anything else. Well, about that. I believe that the last thing that could be simplified still are ADT. *No type

[elm-discuss] Re: Is there a reason Date has no setters?

Another fact about to consider IMHO: Libraries can be fat in pure Elm thanks to the efficient dead-code elimination in 0.17 -- if a function is not referenced in your code, or the code you call, it will not be exported -- while the native parts of them is only left to something like closure or

Re: [elm-discuss] Re: Feature Request: Code Generation/ Macro System

; > > > Obviously people want this. People want lots of things. Making it easy for > Evan maximizes the chances of something happening. > > On Sat, Jun 11, 2016 at 7:31 PM, Maxime Dantec <he...@warry.fr > > wrote: > >> >> >> On Saturday, June 11,

Re: [elm-discuss] Re: Feature Request: Code Generation/ Macro System

On Saturday, June 11, 2016 at 10:29:05 PM UTC+2, Joey Eremondi wrote: > > elm-package could require package names to be at a certain "distance" from >> one another > > > That still doesn't resolve the problem of running arbitrary code. If our > community gets big enough that I don't know and

[elm-discuss] Re: Feature Request: Code Generation/ Macro System

Jumping in ! I said in the github issue that I was in favour of macros, but macros imply hacking the (haskell) core of the compiler. Wouldn't preprocessor be a better description ? On Saturday, June 11, 2016 at 9:39:28 PM UTC+2, Isaac Shapira wrote: > > @mgold If you