Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Richard and Hongbo, I'm relieved to know that others are aware of the long compilation times = linking times for big projects and that it will likely get fixed in the next several months. I'm not going to worry about it in that case, and Hongbo's information on how little time it can take as

[elm-discuss] YAML lib for Elm?

Hello guys, Is there any yaml parser existing for Elm? Cherrs. -- 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

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

* rereads * Janis, you are incredibly good at telling people that they're wrong. Ah, I got caught up in the third paragraph about the native representation, and thought that those were Elm records, not JavaScript objects. Also, the phrase "No type value has more than one value", for all of its

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

Max, apparently you didn’t understand what Maxime’s proposal is *at all*. For example, he didn’t propose anything that would change the existence of this type: type Direction = Up | Down | Left | Right ​ 2017-01-15 23:47 GMT+01:00 Max Goldstein : > First, I appreciate

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

> > you need recompile that module and regenerate a monolithic js file, the > larger project it gets , the worse compilation time you get in elm mode. If > you have experience in C++, you know the bottle neck used to be linking, it > is quite common for a c++ project to spend 20minutes in

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Sorry, I didn't mean es6 module, I meant map one ocaml (or elm) module to one runnable js module(amdjs, commonjs, or es6) so you get separate compilation. This is just my observation , please take it with a grain of salt: in general, it takes 20ms-80ms for BuckleScript to compile a single file,

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

First, I appreciate that this proposal is being made in the spirit of Elm: seeking to simplify the language, with reference to existing usage (red sentence in the first post), and trying to solve an existing problem (serialization of union types). It's clear that Maxime wants to learn and

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

I don't think this would actually make the language simpler, for the following reason: *Flat is Better than Nested* When you only allow one value per tag, you end up having records/tuples nested inside of tagged-union types. Your nesting gets deeper and more complex. So while it clearly makes

[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] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

Hi Gordon, In case you are interested, this is a link I made to show the excellent compile time performance of BuckleScript (https://twitter.com/bobzhang1988/status/810508070350680066 ) It takes around 0.58s to do a clean build: 55

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

Just to chime in about automatic serialization/deserialization, reading other threads, it seems the big question is what the JSON would look like. I propose this: {"tag": "Maybe.Just", "$0": 5} The tag field contains the constructor name, fully-qualified to prevent ambiguities between

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

I agree that automatic serialization/deserialization of union types is orthogonal to this idea, but I am default interested in any language simplification! Ignoring ctor implications, here are my initial thoughts on that idea on its own merits: - These union type constructors are functions

[elm-discuss] Re: Embedding text editor in Elm

Is this process still applicable with the release of elm 0.18.0? I want to use collaborative features of prosemirror , with changing as little code as possible. I have it implemented inside react.js, without changing much code. As I am

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

> - the 5% seems to be why we can't serialize values automatically I'm sure this is wrong. It's possible to improve the compiler such that ADTs are automatically serializable. It just hasn't been done yet. Wanting this feature is no justification for changing the language. It is justification

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

> > yeah, it should be Bar << (,,) (there are no compile errors in the mail > client). > No, that's still not type correct. -- 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

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

yeah, it should be Bar << (,,) (there are no compile errors in the mail client). I'm sorry to insist, but I am well aware of what it means to limit type values' size, that's the reason of this thread. - 95% of my types have 0 or 1 value - the 5% seems to be why we can't serialize values

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

I use constructors with multiple values a lot, so please don’t take them away. > On Jan 15, 2017, at 11:15 AM, Maxime Dantec wrote: > > Not really, take this example : > > type Foo = Bar ( Int, Bool, (String, Foo) ) > > foo : Int -> Bool -> (String, Foo) -> Foo > foo = Foo <<

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

Your example is not even 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

[elm-discuss] on reuse and effects/subscriptions

How could one implement the old RandomGif example using the latest recommendations from: https://guide.elm-lang.org/reuse/more.html ? The examples from the link do not require any side-effects or subscriptions. How should one approach the contexts where one needs side-effects like the above

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

I had to explain two concepts lately: ADTs and ports. It's not that it's _that_ complicated, but it's not self explanatory neither. The key point of ADTs is polymorphism, holding a finite number of heterogeneous values seems to be tuples' or records' job. It's also weird that port values and

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

Not really, take this example : type Foo = Bar ( Int, Bool, (String, Foo) ) foo : Int -> Bool -> (String, Foo) -> Foo foo = Foo << (,,) And again, it seems to be the exception to have multiple values. On Sunday, January 15, 2017 at 5:09:46 PM UTC+1, Janis Voigtländer wrote: > > This would take

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

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 in Javascript values in the { ctor, _0, _1... _n } shape. For example, Nothing becomes { ctor: "Nothing" } and (Just 10) becomes { ctor : "Just",

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

I'm trying to see if I understand your suggestion correctly. So would an enumeration like this: type Msg = ClickedButton | EnteredAge value | EnteredHeight value become... type Msg = { action : String, value : String } ? I'm trying to figure out how you'd "authorize up to one

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

Sorry! Forgot to mention... The automatic serializer/deserializers in the ports is assuming that the main reason behind not serializing ADTs in the first place was this { _0, _1... _n } shape. The "native" object could also swap ctor to type: {type:"TypeValue", value: xx} it's a type value,

[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

Re: [elm-discuss] Re: Collecting use cases for File, ArrayBuffer and TypedArrays/DataViews

I have an app I am working on that has to upload a file to a server for server side processing Zach ᐧ On Wed, Jan 11, 2017 at 10:49 AM, Simon wrote: > Hi all, > thought it might be worth updating this thread on my progress with S3, > which I have now solved by adding one

Re: [elm-discuss] Re: Elm "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

After working with the elm compiler just a bit from the outside, I think there might be build time improvements to be had by improving the build info dropped in elm-stuff. I think reducing the number of graph.dat and .elmi files read during the build process might help. On Sat, Jan 14, 2017 at