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

[GordonBGood]

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 OCaml 
does it is comforting, as there then is no reason that Even can't come up 
with something similar.  I'll just look into if I can help on the speed of 
the generated code from the back end, which is something for which I may be 
able to help, and which Even doesn't have time to look into currently.  It 
may turn out to be too much for me, but at least I'll know.

On Monday, 16 January 2017 10:21:28 UTC+7, Richard Feldman wrote:
>
> 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 linking.
>
>
> Considering Evan is working on asset management for the next release, I 
> doubt "compile everything to one file" will be true after it lands. (That 
> release is presumably still several months away; this is just speculation 
> on my part.)
>
> Evan also wrote C++ at Google, so avoiding long linking times is 
> definitely on his radar. ;)
>

-- 
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] YAML lib for Elm?

[fxmy wang]

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

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

[Max Goldstein]

* 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 
bold redness, reads perilously close to "no type has more than one tag".

However, I think there's some value in pointing out the legitimacy of tags 
that have no arguments: under the proposal, union tags would still have 
either one argument or none, just not more than one. One of the more 
confusing parts of union types is that different tags can be functions of 
different arities or non-function values, depending on how they are 
defined. If we wanted to eliminate this confusion, we could require an 
arity of exactly one, and tags like Up and Down would need to be Up () and 
Down ().

But that's needlessly confusing, so limiting the number of tags to one 
seems more like a restriction than a simplification. Yes, you've found a 
way to make a strictly smaller language without diminishing expressive 
power. The same is true for requiring f x y = ... to be written as f = \ x 
y -> ... but no one is advocating for that.

So, I'm sorry I misunderstood your proposal and lectured on things you may 
well have known about. And for what it's worth, I've used two-argument 
constructors before, and I've advocated for records instead of positional 
arguments before. I think this is a place where we can allow some freedom 
to the programmer.

-- 
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] Re: [Suggestion] Type values and simplifying the language still

[Janis Voigtländer]

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 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
> improve the language. Thank you.
>
> So let's look at how union types are used, what jobs they are hired to do,
> if you will. You've noticed in core that union types with one tag are used
> to hide things. Sometimes that's as an opaque type: there is one tag that's
> not exposed, and is pattern-matched easily, and the data the tag holds can
> change even in a patch release (example here
> ).
> Core also contains a rare pattern of, say *type Task x a = Task* where
> the *Task* value defined is not actually used anywhere because it's
> actually a native implementation. Serializing arbitrary union types will
> have to account for this case.
>
> A more realistic use of union types is as a finite set of labels, even if
> these labels don't carry any information along with them. For example:
>
> type Direction = Up | Down | Left | Right
>
> From this we derive pattern matches with static
> (compile-time) exhaustiveness checking, which is a huge improvement in
> reliability and refactorability over "stringly typed" conventions (instead
> of strongly typed, get it?) that you'll see in JavaScript and the like.
> Replacing the Direction type with a record including a string removes this
> huge improvement.
>
> Adding data to these tags allows for the classic use case of data that
> only makes sense in certain contexts. I remember working with a C++
> graphics library where certain fields of structs were only defined if an
> enum was set to a particular value. But this isn't really a separate use
> case from labels without data, since you can freely mix within a type. The 
> RemoteData
> type
> does
> this to great effect.
>
> More theoretically, union types and records are not the same; they are
> actually duals. Union types are referred to as "sum types" and records (and
> tuples) are "product types". Here's the reasoning: consider two types, *a*
> and *b*. Let's denote the number of values of type *a* as |a|, and
> similarly |b|. If we construct the sum type *Result a b* then there are
> |a| values for the Err case and |b| values for the Ok case. So |Result a b|
> = |a| + |b|, hence sum types. For the pair (a, b) we can pick any *a* and
> any *b* so |(a,b)| = |a|*|b|, hence produce types.
>
> If you want to produce (create) a value of sum type, such as *Result a b*,
> you can pick either case to work with. But when you consume (inspect) a
> value of that type, you must be prepared to handle all cases. For product
> types it is reversed: to produce a value of type (a,b) you must have both
> an *a* and a *b*, but when you consume such a value, you can pick out the
> one you want.
>
> So, while I appreciate the gesture, I don't think this will work.
>
> --
> 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.
>

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

[Richard Feldman]

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


Considering Evan is working on asset management for the next release, I 
doubt "compile everything to one file" will be true after it lands. (That 
release is presumably still several months away; this is just speculation 
on my part.)

Evan also wrote C++ at Google, so avoiding long linking times is definitely 
on his radar. ;)

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

[Bob Zhang]

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, but
that's almost all you need for BuckleScript dev feedback loop, in elm, it's
different, 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
linking.

I don't how much elm is performance engineered, but we are very sensitive
about performance even in nanoseconds level (
https://github.com/bloomberg/bucklescript/pull/1082), this little
engineering will add up
On Sun, Jan 15, 2017 at 9:23 PM GordonBGood  wrote:

> On Monday, 16 January 2017 02:54:17 UTC+7, Bob Zhang wrote:
>
> Hi Gordon,
>
> It is not uncommon to see 100 times slowness when building Elm vs OCaml in
> incremental build (dev time), the reason is that Elm (correct me if I am
> wrong) always need a link time, so whenever your change a file, it will
> trigger the linker, this will get significantly worse if your project is in
> not small. While BuckleScript compiles one OCaml module to one ES6 module,
> it does not need link during dev time, best for incremental build.
>
>
> Hi Hongbo, that was interesting, especially in what you way about why Elm
> may compile very much slower then OCaml.  If the difference is just link
> time (which linking for all makes it inherits from haskell) then this is
> surely fixable?  Can't Elm do the same as BucketScript - compile to ES6
> modules?
>
> In fact, I don't see why the insistence that these JS compiler languages
> compile to ES5 at all:  it made sense in 2012 with the Elm project was
> started, but now all mainline browsers and platforms have been updated to
> near 100% ES6 compatibility.  Or do the compilers such as Elm want to
> continue to support Internet Explorer (which will never be updated) forever?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elm-discuss/Um7WIBTq9xU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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: [Suggestion] Type values and simplifying the language still

[Max Goldstein]

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 
improve the language. Thank you.

So let's look at how union types are used, what jobs they are hired to do, 
if you will. You've noticed in core that union types with one tag are used 
to hide things. Sometimes that's as an opaque type: there is one tag that's 
not exposed, and is pattern-matched easily, and the data the tag holds can 
change even in a patch release (example here 
). 
Core also contains a rare pattern of, say *type Task x a = Task* where the 
*Task* value defined is not actually used anywhere because it's actually a 
native implementation. Serializing arbitrary union types will have to 
account for this case.

A more realistic use of union types is as a finite set of labels, even if 
these labels don't carry any information along with them. For example:

type Direction = Up | Down | Left | Right

>From this we derive pattern matches with static 
(compile-time) exhaustiveness checking, which is a huge improvement in 
reliability and refactorability over "stringly typed" conventions (instead 
of strongly typed, get it?) that you'll see in JavaScript and the like. 
Replacing the Direction type with a record including a string removes this 
huge improvement.

Adding data to these tags allows for the classic use case of data that only 
makes sense in certain contexts. I remember working with a C++ graphics 
library where certain fields of structs were only defined if an enum was 
set to a particular value. But this isn't really a separate use case from 
labels without data, since you can freely mix within a type. The RemoteData 
type 
does
 
this to great effect.

More theoretically, union types and records are not the same; they are 
actually duals. Union types are referred to as "sum types" and records (and 
tuples) are "product types". Here's the reasoning: consider two types, *a* 
and *b*. Let's denote the number of values of type *a* as |a|, and 
similarly |b|. If we construct the sum type *Result a b* then there are |a| 
values for the Err case and |b| values for the Ok case. So |Result a b| = 
|a| + |b|, hence sum types. For the pair (a, b) we can pick any *a* and any 
*b* so |(a,b)| = |a|*|b|, hence produce types.

If you want to produce (create) a value of sum type, such as *Result a b*, 
you can pick either case to work with. But when you consume (inspect) a 
value of that type, you must be prepared to handle all cases. For product 
types it is reversed: to produce a value of type (a,b) you must have both 
an *a* and a *b*, but when you consume such a value, you can pick out the 
one you want.

So, while I appreciate the gesture, I don't think this will work.

-- 
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] Re: [Suggestion] Type values and simplifying the language still

[Joey Eremondi]

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 *smaller*, it doesn't make it
*simpler*.

This is also currently impossible in Elm, since Tuples are encoded as
tagged-unions. I'm a heavy proponent of encoding tuples as records instead,
but in either case, it's another consideration in this debate.

On top of that, the concerns with currrying constructors others have
brought up are very valid.


> There must be a way where we have functions for constructor AND labels for
> serialization


There clearly is! Haskell has this (it has a much more
automatic-serialization capabilities than Elm currently has built-in) so
it's clearly possible.



On Sun, Jan 15, 2017 at 11:59 AM, Maxime Dantec  wrote:

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

-- 
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: [Suggestion] Type values and simplifying the language still

[Maxime Dantec]

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

[Bob Zhang]

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 modules on Mac Book Pro 13 model 
(cold start, no caching). 
It is not uncommon to see 100 times slowness when building Elm vs OCaml in 
incremental build (dev time), the reason is that Elm (correct me if I am wrong) 
always need a link time, so whenever your change a file, it will trigger the 
linker, this will get significantly worse if your project is in not small. 
While BuckleScript compiles one OCaml module to one ES6 module, it does not 
need link during dev time, best for incremental build.

> On Jan 15, 2017, at 1:07 AM, GordonBGood  wrote:
> 
> On Sunday, 15 January 2017 11:14:55 UTC+7, Richard Feldman wrote:
> I'm wondering why the Elm compiler is so slow at parsing if that is where the 
> slow-down is
> 
> Evan recently rewrote the parser to be much faster.
> 
> You can try a preview binary 
> 
>  of the new version if you're curious. :)
> 
> I saw that over on elm-dev, but haven't tried it because compilation speed 
> isn't a problem for the Elm code I have written so far.  The only reason I 
> brought it up is OvermindDL1's comment 
>  that 
> compiling a Ocaml/BucketScript code (that presumably did the same thing as 
> the Elm code) took about 0.1 seconds as compared to 40 seconds with the Elm 
> compiler - a 400 times speed-up!  We weren't given details of the code or 
> test conditions and whether one was an incremental compilation, but that 
> sounds quite serious and would affect the usability of Elm.  If that data is 
> verifiable, a speed up of double or even quadruple doesn't begin to touch the 
> difference and should be investigated.
> 
> If only there were a binary posted somewhere, based on a compiler that had 
> just been rewritten to improve build times, so that someone could post a 
> benchmark instead of speculation! ;)
> 
> Yes to that.  If someone has a concrete example of code that takes much 
> longer to compile that the same implemented in another equivalent language 
> such as BucketScript, I would like to see it.  I expect BuckleScript to 
> compile some faster due to its OCaml origins being finely tuned for 
> compilatoin speed, but i wouldn't expect it to be more than four or five time 
> faster, and as you say, Evan has done something that makes this quite a bit 
> faster.  Theoretically, Elm should be able to compile fast due to the 
> simplicity of the language syntax.
> 
> Meanwhile, I think I'll just take a look at seeing how hard it would be to 
> improve the code generation, since that doesn't really impact anything else. 
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/elm-discuss/Um7WIBTq9xU/unsubscribe 
> .
> To unsubscribe from this group and all its topics, send an email to 
> elm-discuss+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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: [Suggestion] Type values and simplifying the language still

[Richard Feldman]

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 serialization and deserialization. The compiler could 
generate a lookup table to determine not only how many arguments should be 
passed to the constructor (solving the problem mentioned in OP) but also 
their types.


Everything else is similar to the field schema used by Native modules, 
except with $ instead of _. I understand that browsers do undesirable 
things to object keys that can be parsed as integers, so it's important 
that the indices be prefixed with some non-numeric character like _ or $.


I think $ is a more human-friendly prefix than _, because it appears in the 
wild: $ followed by an index refers to regular expression capture groups in 
languages including JS, Perl, and Ruby, e.g.


"Sam Sample".replace(/(\w+)\s(\w+)/, "$2, $1" === "Sample, Sam"`


An alternative (which I like less) was proposed elsewhere 
 and 
looks like this:


{"tag": "Maybe.Just", "contents": [5]}


The idea being that if the union type holds multiple values, we just stick 
them in the heterogeneous contents array. This might look less weird to 
someone comfortable with JS, but using it would be worse. It would 
encourage iteration when iteration makes no sense, and it would have worse 
lookup performance than object fields would.

-- 
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: [Suggestion] Type values and simplifying the language still

[Richard Feldman]

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
   - The consensus is that curried is nicer than tupled for Elm functions 
   on the whole
   - Why would the opposite be true for these particular functions?

I don't have a good answer for that, which makes me lean toward the status 
quo.

That said, automatic serialization/deserialization of union types would be 
nice. :)

-- 
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: Embedding text editor in Elm

[abhinav gupta]

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 learning elm and thinking of re-implementing 
that app with elm. Should I completely replace my react + redux stack or 
just replace redux part of it? So that it will be easy to integrate this 
editor.

-- 
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] [Suggestion] Type values and simplifying the language still

[Janis Voigtländer]

> - 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 for improving the compiler.

-- 
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] [Suggestion] Type values and simplifying the language still

[Janis Voigtländer]

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

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

[Maxime Dantec]

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 automatically
- composition is made harder, but still possible for those 5%

To me, the real question is : Do we prefer to compose ctors or simplify the 
syntax and serialization ?

On Sunday, January 15, 2017 at 5:49:17 PM UTC+1, Janis Voigtländer wrote:
>
> 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  >:
>
> 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 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 :
>>
>> 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", _0: 10 }. The {type, value} part, would change that to : 
>> Nothing becomes { type: "Nothing" } and (Just 10) becomes { type : 
>> "Just", value: 10 }.
>>
>> The { ctor, _0, _1... _n } shape is, *I assume*, why we can't 
>> automatically send type values though ports. The rationale is: if it's 
>> really the reason, since we barely use more than one value in type values, 
>> why not facilitate port usage instead of larger type values. Does it makes 
>> sense at all?
>>
>> In other words, currently you can do that:
>>
>> type Foo = Foo | Bar Int Bool (String, Foo)
>> where: Bar : Int -> Bool -> (String, Foo) -> Foo
>> that you use like this in elm: Bar 1 False ("fooBar", Foo)
>> which compiles down to in js: { ctor: "Bar", _0: 10, _1: false, _2: { 
>> ctor: "Tuple2", _0: "fooBar", _1: { ctor: "Foo"} } }
>>
>> It would become impossible, because the type value Bar has 3 values.
>> Instead, you would have to give only one value to the Bar constructor :
>>
>> type Foo = Bar { id: Int, isSomething: Bool, foo: (String, Foo) }
>> where: Bar : { id: Int, isSomething: Bool, foo: (String, Foo) } -> Foo
>> that you would use like this: Bar { id = 0, isSomething = False, foo = ("
>> fooBar", Foo) }
>> would compiles down to: { type: "Bar", value: { id: 0, isSomething: 
>> false, foo: ["fooBar", { type: "Foo" }] } }
>>
>> The record could be as well replaced by a Tuple ( Int, Bool, (String, 
>> Foo) )
>>
>> I hope it's clearer enough?
>>
>> On Sunday, January 15, 2017 at 4:33:50 PM UTC+1, Duane Johnson wrote:
>>>
>>> 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 value" in a 
>>> situation like this, since the whole point of an enumeration is to allow 
>>> multiple possibilities.
>>>
>>> Duane
>>>
>>> On Sun, Jan 15, 2017 at 6:59 AM, Maxime Dantec  wrote:
>>>
 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 value has more than one value in the core repository*, with the 
 exception of Dict and Color. I have used a few types with more than 
 one value myself, but I hardly see the difference with a type value that 
 has 3 values and a type value that has a tuple3 as unique value, if you 
 except the constructor signature. Does yourself make an intensive usage of 
 this feature?

 So here is my suggestion: Why not authorize up to one value to type 
 values? If you need to bundle values, you can still use a tuple or a 
 record. The reasoning behind this, is to get rid of the _0, _1, _2 in the 
 "native" part of the type values. we could have {ctor:"Enum"} or 
 {ctor:"TypeValue", 
 value: {...}}, and why not automatic serializer/deserializers in the 
 ports thanks to this too?

 

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

[Christopher Anand]

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 << (,,)

How is  <<  (,,) easier to explain than ADTs?

ADTs are not just some syntax to be leaned, they are a powerful way to model 
data. The particular syntax is sparse, and you could argue the addition of 
labels would be an improvement, but I know many people who use elm or Haskell 
data types to document models before implementing them in other languages.  It 
is so quick, it is like type-checked pseudo-code.

> 
> 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 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 :
> 
>> 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", _0: 10 }. 
>> The {type, value} part, would change that to : Nothing becomes { type: 
>> "Nothing" } and (Just 10) becomes { type : "Just", value: 10 }.
>> 
>> The { ctor, _0, _1... _n } shape is, I assume, why we can't automatically 
>> send type values though ports. The rationale is: if it's really the reason, 
>> since we barely use more than one value in type values, why not facilitate 
>> port usage instead of larger type values. Does it makes sense at all?
>> 
>> In other words, currently you can do that:
>> 
>> type Foo = Foo | Bar Int Bool (String, Foo)
>> where: Bar : Int -> Bool -> (String, Foo) -> Foo
>> that you use like this in elm: Bar 1 False ("fooBar", Foo)
>> which compiles down to in js: { ctor: "Bar", _0: 10, _1: false, _2: { ctor: 
>> "Tuple2", _0: "fooBar", _1: { ctor: "Foo"} } }
>> 
>> It would become impossible, because the type value Bar has 3 values.
>> Instead, you would have to give only one value to the Bar constructor :
>> 
>> type Foo = Bar { id: Int, isSomething: Bool, foo: (String, Foo) }
>> where: Bar : { id: Int, isSomething: Bool, foo: (String, Foo) } -> Foo
>> that you would use like this: Bar { id = 0, isSomething = False, foo = 
>> ("fooBar", Foo) }
>> would compiles down to: { type: "Bar", value: { id: 0, isSomething: false, 
>> foo: ["fooBar", { type: "Foo" }] } }
>> 
>> The record could be as well replaced by a Tuple ( Int, Bool, (String, Foo) )
>> 
>> I hope it's clearer enough?
>> 
>> On Sunday, January 15, 2017 at 4:33:50 PM UTC+1, Duane Johnson wrote:
>> 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 value" in a 
>> situation like this, since the whole point of an enumeration is to allow 
>> multiple possibilities.
>> 
>> Duane
>> 
>> On Sun, Jan 15, 2017 at 6:59 AM, Maxime Dantec > wrote:
>> 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 value has more than one value in the core repository, with the 
>> exception of Dict and Color. I have used a few types with more than one 
>> value myself, but I hardly see the difference with a type value that has 3 
>> values and a type value that has a tuple3 as unique value, if you except the 
>> constructor signature. Does yourself make an intensive usage of this feature?
>> 
>> So here is my suggestion: Why not authorize up to one value to type values? 
>> If you need to bundle values, you can still use a tuple or a record. The 
>> reasoning behind this, is to get rid of the _0, _1, _2 in the "native" part 
>> of the type values. we could have {ctor:"Enum"} or {ctor:"TypeValue", value: 
>> {...}}, and why not automatic serializer/deserializers in the ports thanks 
>> to this too?
>> 
>> Everyone has an opinion, and it's very easy to make a suggestion while not 
>> implementing it. I'm not pretending that this is a good idea, I humbly think 
>> that it's worth mentioning given that it's in the scope of simplifying the 
>> language. Please share you opinion :)
>> 
>> Cheers!
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" 

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

[Janis Voigtländer]

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 :
> 
> 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 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 :
>>> 
>>> 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", 
>>> _0: 10 }. The {type, value} part, would change that to : Nothing becomes { 
>>> type: "Nothing" } and (Just 10) becomes { type : "Just", value: 10 }.
>>> 
>>> The { ctor, _0, _1... _n } shape is, I assume, why we can't automatically 
>>> send type values though ports. The rationale is: if it's really the reason, 
>>> since we barely use more than one value in type values, why not facilitate 
>>> port usage instead of larger type values. Does it makes sense at all?
>>> 
>>> In other words, currently you can do that:
>>> 
>>> type Foo = Foo | Bar Int Bool (String, Foo)
>>> where: Bar : Int -> Bool -> (String, Foo) -> Foo
>>> that you use like this in elm: Bar 1 False ("fooBar", Foo)
>>> which compiles down to in js: { ctor: "Bar", _0: 10, _1: false, _2: { ctor: 
>>> "Tuple2", _0: "fooBar", _1: { ctor: "Foo"} } }
>>> 
>>> It would become impossible, because the type value Bar has 3 values.
>>> Instead, you would have to give only one value to the Bar constructor :
>>> 
>>> type Foo = Bar { id: Int, isSomething: Bool, foo: (String, Foo) }
>>> where: Bar : { id: Int, isSomething: Bool, foo: (String, Foo) } -> Foo
>>> that you would use like this: Bar { id = 0, isSomething = False, foo = 
>>> ("fooBar", Foo) }
>>> would compiles down to: { type: "Bar", value: { id: 0, isSomething: false, 
>>> foo: ["fooBar", { type: "Foo" }] } }
>>> 
>>> The record could be as well replaced by a Tuple ( Int, Bool, (String, Foo) )
>>> 
>>> I hope it's clearer enough?
>>> 
 On Sunday, January 15, 2017 at 4:33:50 PM UTC+1, Duane Johnson wrote:
 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 value" in a 
 situation like this, since the whole point of an enumeration is to allow 
 multiple possibilities.
 
 Duane
 
> On Sun, Jan 15, 2017 at 6:59 AM, Maxime Dantec  wrote:
> 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 value has more than one value in the core repository, with the 
> exception of Dict and Color. I have used a few types with more than one 
> value myself, but I hardly see the difference with a type value that has 
> 3 values and a type value that has a tuple3 as unique value, if you 
> except the constructor signature. Does yourself make an intensive usage 
> of this feature?
> 
> So here is my suggestion: Why not authorize up to one value to type 
> values? If you need to bundle values, you can still use a tuple or a 
> record. The reasoning behind this, is to get rid of the _0, _1, _2 in the 
> "native" part of the type values. we could have {ctor:"Enum"} or 
> {ctor:"TypeValue", value: {...}}, and why not automatic 
> serializer/deserializers in the ports thanks to this too?
> 
> Everyone has an opinion, and it's very easy to make a suggestion while 
> not implementing it. I'm not pretending that this is a good idea, I 
> humbly think that it's worth mentioning given that it's in the scope of 
> simplifying the language. Please share you opinion :)
> 
> Cheers!
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails 

[elm-discuss] on reuse and effects/subscriptions

[Peter Damoc]

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 RandomGif or let say an autocomplete field that uses some online
service?

-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
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] [Suggestion] Type values and simplifying the language still

[Maxime Dantec]

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 elm values are not the same (tuples 
are transformed to native arrays, and maybes to nullable).

On Sunday, January 15, 2017 at 5:09:46 PM UTC+1, Janis Voigtländer wrote:
>
> 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  >:
>
> 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", _0: 10 }. The {type, value} part, would change that to : Nothing 
> becomes { type: "Nothing" } and (Just 10) becomes { type : "Just", value: 
> 10 }.
>
> The { ctor, _0, _1... _n } shape is, *I assume*, why we can't 
> automatically send type values though ports. The rationale is: if it's 
> really the reason, since we barely use more than one value in type values, 
> why not facilitate port usage instead of larger type values. Does it makes 
> sense at all?
>
> In other words, currently you can do that:
>
> type Foo = Foo | Bar Int Bool (String, Foo)
> where: Bar : Int -> Bool -> (String, Foo) -> Foo
> that you use like this in elm: Bar 1 False ("fooBar", Foo)
> which compiles down to in js: { ctor: "Bar", _0: 10, _1: false, _2: { 
> ctor: "Tuple2", _0: "fooBar", _1: { ctor: "Foo"} } }
>
> It would become impossible, because the type value Bar has 3 values.
> Instead, you would have to give only one value to the Bar constructor :
>
> type Foo = Bar { id: Int, isSomething: Bool, foo: (String, Foo) }
> where: Bar : { id: Int, isSomething: Bool, foo: (String, Foo) } -> Foo
> that you would use like this: Bar { id = 0, isSomething = False, foo = ("
> fooBar", Foo) }
> would compiles down to: { type: "Bar", value: { id: 0, isSomething: 
> false, foo: ["fooBar", { type: "Foo" }] } }
>
> The record could be as well replaced by a Tuple ( Int, Bool, (String, 
> Foo) )
>
> I hope it's clearer enough?
>
> On Sunday, January 15, 2017 at 4:33:50 PM UTC+1, Duane Johnson wrote:
>>
>> 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 value" in a 
>> situation like this, since the whole point of an enumeration is to allow 
>> multiple possibilities.
>>
>> Duane
>>
>> On Sun, Jan 15, 2017 at 6:59 AM, Maxime Dantec  wrote:
>>
>>> 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 value has more than one value in the core repository*, with the 
>>> exception of Dict and Color. I have used a few types with more than one 
>>> value myself, but I hardly see the difference with a type value that has 3 
>>> values and a type value that has a tuple3 as unique value, if you except 
>>> the constructor signature. Does yourself make an intensive usage of this 
>>> feature?
>>>
>>> So here is my suggestion: Why not authorize up to one value to type 
>>> values? If you need to bundle values, you can still use a tuple or a 
>>> record. The reasoning behind this, is to get rid of the _0, _1, _2 in the 
>>> "native" part of the type values. we could have {ctor:"Enum"} or 
>>> {ctor:"TypeValue", 
>>> value: {...}}, and why not automatic serializer/deserializers in the 
>>> ports thanks to this too?
>>>
>>> Everyone has an opinion, and it's very easy to make a suggestion while 
>>> not implementing it. I'm not pretending that this is a good idea, I humbly 
>>> think that it's worth mentioning given that it's in the scope of 
>>> simplifying the language. Please share you opinion :)
>>>
>>> Cheers!
>>>
>>> -- 
>>> 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.
>>>
>>
>> -- 
> 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 

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

[Maxime Dantec]

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 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  >:
>
> 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", _0: 10 }. The {type, value} part, would change that to : Nothing 
> becomes { type: "Nothing" } and (Just 10) becomes { type : "Just", value: 
> 10 }.
>
> The { ctor, _0, _1... _n } shape is, *I assume*, why we can't 
> automatically send type values though ports. The rationale is: if it's 
> really the reason, since we barely use more than one value in type values, 
> why not facilitate port usage instead of larger type values. Does it makes 
> sense at all?
>
> In other words, currently you can do that:
>
> type Foo = Foo | Bar Int Bool (String, Foo)
> where: Bar : Int -> Bool -> (String, Foo) -> Foo
> that you use like this in elm: Bar 1 False ("fooBar", Foo)
> which compiles down to in js: { ctor: "Bar", _0: 10, _1: false, _2: { 
> ctor: "Tuple2", _0: "fooBar", _1: { ctor: "Foo"} } }
>
> It would become impossible, because the type value Bar has 3 values.
> Instead, you would have to give only one value to the Bar constructor :
>
> type Foo = Bar { id: Int, isSomething: Bool, foo: (String, Foo) }
> where: Bar : { id: Int, isSomething: Bool, foo: (String, Foo) } -> Foo
> that you would use like this: Bar { id = 0, isSomething = False, foo = ("
> fooBar", Foo) }
> would compiles down to: { type: "Bar", value: { id: 0, isSomething: 
> false, foo: ["fooBar", { type: "Foo" }] } }
>
> The record could be as well replaced by a Tuple ( Int, Bool, (String, 
> Foo) )
>
> I hope it's clearer enough?
>
> On Sunday, January 15, 2017 at 4:33:50 PM UTC+1, Duane Johnson wrote:
>>
>> 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 value" in a 
>> situation like this, since the whole point of an enumeration is to allow 
>> multiple possibilities.
>>
>> Duane
>>
>> On Sun, Jan 15, 2017 at 6:59 AM, Maxime Dantec  wrote:
>>
>>> 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 value has more than one value in the core repository*, with the 
>>> exception of Dict and Color. I have used a few types with more than one 
>>> value myself, but I hardly see the difference with a type value that has 3 
>>> values and a type value that has a tuple3 as unique value, if you except 
>>> the constructor signature. Does yourself make an intensive usage of this 
>>> feature?
>>>
>>> So here is my suggestion: Why not authorize up to one value to type 
>>> values? If you need to bundle values, you can still use a tuple or a 
>>> record. The reasoning behind this, is to get rid of the _0, _1, _2 in the 
>>> "native" part of the type values. we could have {ctor:"Enum"} or 
>>> {ctor:"TypeValue", 
>>> value: {...}}, and why not automatic serializer/deserializers in the 
>>> ports thanks to this too?
>>>
>>> Everyone has an opinion, and it's very easy to make a suggestion while 
>>> not implementing it. I'm not pretending that this is a good idea, I humbly 
>>> think that it's worth mentioning given that it's in the scope of 
>>> simplifying the language. Please share you opinion :)
>>>
>>> Cheers!
>>>
>>> -- 
>>> 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.
>>>
>>
>> -- 
> 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.
>
>

-- 
You received this message because you are subscribed to the Google Groups "Elm 

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

[Maxime Dantec]

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", 
_0: 10 }. The {type, value} part, would change that to : Nothing becomes { 
type: "Nothing" } and (Just 10) becomes { type : "Just", value: 10 }.

The { ctor, _0, _1... _n } shape is, *I assume*, why we can't automatically 
send type values though ports. The rationale is: if it's really the reason, 
since we barely use more than one value in type values, why not facilitate 
port usage instead of larger type values. Does it makes sense at all?

In other words, currently you can do that:

type Foo = Foo | Bar Int Bool (String, Foo)
where: Bar : Int -> Bool -> (String, Foo) -> Foo
that you use like this in elm: Bar 1 False ("fooBar", Foo)
which compiles down to in js: { ctor: "Bar", _0: 10, _1: false, _2: { ctor: 
"Tuple2", _0: "fooBar", _1: { ctor: "Foo"} } }

It would become impossible, because the type value Bar has 3 values.
Instead, you would have to give only one value to the Bar constructor :

type Foo = Bar { id: Int, isSomething: Bool, foo: (String, Foo) }
where: Bar : { id: Int, isSomething: Bool, foo: (String, Foo) } -> Foo
that you would use like this: Bar { id = 0, isSomething = False, foo = ("
fooBar", Foo) }
would compiles down to: { type: "Bar", value: { id: 0, isSomething: false, 
foo: ["fooBar", { type: "Foo" }] } }

The record could be as well replaced by a Tuple ( Int, Bool, (String, Foo) )

I hope it's clearer enough?

On Sunday, January 15, 2017 at 4:33:50 PM UTC+1, Duane Johnson wrote:
>
> 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 value" in a 
> situation like this, since the whole point of an enumeration is to allow 
> multiple possibilities.
>
> Duane
>
> On Sun, Jan 15, 2017 at 6:59 AM, Maxime Dantec  > wrote:
>
>> 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 value has more than one value in the core repository*, with the 
>> exception of Dict and Color. I have used a few types with more than one 
>> value myself, but I hardly see the difference with a type value that has 3 
>> values and a type value that has a tuple3 as unique value, if you except 
>> the constructor signature. Does yourself make an intensive usage of this 
>> feature?
>>
>> So here is my suggestion: Why not authorize up to one value to type 
>> values? If you need to bundle values, you can still use a tuple or a 
>> record. The reasoning behind this, is to get rid of the _0, _1, _2 in the 
>> "native" part of the type values. we could have {ctor:"Enum"} or 
>> {ctor:"TypeValue", 
>> value: {...}}, and why not automatic serializer/deserializers in the 
>> ports thanks to this too?
>>
>> Everyone has an opinion, and it's very easy to make a suggestion while 
>> not implementing it. I'm not pretending that this is a good idea, I humbly 
>> think that it's worth mentioning given that it's in the scope of 
>> simplifying the language. Please share you opinion :)
>>
>> Cheers!
>>
>> -- 
>> 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.
>>
>
>

-- 
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] [Suggestion] Type values and simplifying the language still

[Duane Johnson]

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 value" in a
situation like this, since the whole point of an enumeration is to allow
multiple possibilities.

Duane

On Sun, Jan 15, 2017 at 6:59 AM, Maxime Dantec  wrote:

> 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 value has more than one value in the core repository*, with the
> exception of Dict and Color. I have used a few types with more than one
> value myself, but I hardly see the difference with a type value that has 3
> values and a type value that has a tuple3 as unique value, if you except
> the constructor signature. Does yourself make an intensive usage of this
> feature?
>
> So here is my suggestion: Why not authorize up to one value to type
> values? If you need to bundle values, you can still use a tuple or a
> record. The reasoning behind this, is to get rid of the _0, _1, _2 in the
> "native" part of the type values. we could have {ctor:"Enum"} or 
> {ctor:"TypeValue",
> value: {...}}, and why not automatic serializer/deserializers in the
> ports thanks to this too?
>
> Everyone has an opinion, and it's very easy to make a suggestion while not
> implementing it. I'm not pretending that this is a good idea, I humbly
> think that it's worth mentioning given that it's in the scope of
> simplifying the language. Please share you opinion :)
>
> Cheers!
>
> --
> 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.
>

-- 
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: [Suggestion] Type values and simplifying the language still

[Maxime Dantec]

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, 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: 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 value has more than one value in the core repository*, with the 
> exception of Dict and Color. I have used a few types with more than one 
> value myself, but I hardly see the difference with a type value that has 3 
> values and a type value that has a tuple3 as unique value, if you except 
> the constructor signature. Does yourself make an intensive usage of this 
> feature?
>
> So here is my suggestion: Why not authorize up to one value to type 
> values? If you need to bundle values, you can still use a tuple or a 
> record. The reasoning behind this, is to get rid of the _0, _1, _2 in the 
> "native" part of the type values. we could have {ctor:"Enum"} or 
> {ctor:"TypeValue", 
> value: {...}}, and why not automatic serializer/deserializers in the 
> ports thanks to this too?
>
> Everyone has an opinion, and it's very easy to make a suggestion while not 
> implementing it. I'm not pretending that this is a good idea, I humbly 
> think that it's worth mentioning given that it's in the scope of 
> simplifying the language. Please share you opinion :)
>
> Cheers!
>

-- 
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] [Suggestion] Type values and simplifying the language still

[Maxime Dantec]

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 value has more than one value in the core repository*, with the 
exception of Dict and Color. I have used a few types with more than one 
value myself, but I hardly see the difference with a type value that has 3 
values and a type value that has a tuple3 as unique value, if you except 
the constructor signature. Does yourself make an intensive usage of this 
feature?

So here is my suggestion: Why not authorize up to one value to type values? 
If you need to bundle values, you can still use a tuple or a record. The 
reasoning behind this, is to get rid of the _0, _1, _2 in the "native" part 
of the type values. we could have {ctor:"Enum"} or {ctor:"TypeValue", 
value: {...}}, and why not automatic serializer/deserializers in the ports 
thanks to this too?

Everyone has an opinion, and it's very easy to make a suggestion while not 
implementing it. I'm not pretending that this is a good idea, I humbly 
think that it's worth mentioning given that it's in the scope of 
simplifying the language. Please share you opinion :)

Cheers!

-- 
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] Re: Collecting use cases for File, ArrayBuffer and TypedArrays/DataViews

[Zachary Kessin]

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 small hack to the Filereader
>  library (github only because
> of the native code). I have documented this at
> https://simonh1000.github.io/2016/12/elm-s3-uploads/
>
> Meanwhile, I have a new use to register. I was looking at MessagePack
>  and noted that Elm is not included in the long list
> of supported languages. I suspect that it currently could not be because of
> the lack of ArrayBuffer support?
>
> Simon
>
>
> On Wednesday, 24 August 2016 18:06:40 UTC+2, Erik Lott wrote:
>>
>> Our primary application allows photographers to upload hundreds/thousands
>> of images for portfolio display. image delivery, etc. I guess you could say
>> that our app is generally driven by image uploads. I would love to see this
>> functionality provided by Elm, rather than having to use ports...
>>
>> On Thursday, July 28, 2016 at 5:17:51 PM UTC-4, Daniel Bachler wrote:
>>>
>>> I'd love to see support for the File and ArrayBuffer Apis, and maybe
>>> TypedArrays/DataViews as well. IMHO they are an important piece of the Web
>>> Platform that is still missing in Elm.
>>>
>>> Evan suggested collecting concrete use cases to guide the design. I
>>> would like this thread to be the starting point of this effort. I would
>>> like to ask anyone who would also like this feature or who has substantial
>>> experience using either Api to add use cases or comment here so that we can
>>> try to define the user story for both apis. From there, we could decide
>>> what we would like to see supported and what, if anything, we don't need
>>> for now and suggest Elm Apis.
>>>
>>> I have two stories from a side project of mine. It is a slideshow editor
>>> that allows the user to select photos and audio files from the local
>>> system, uploads them to a web service, let's the user arrange and
>>> manipulate photos and music and then share the result with others. For
>>> this, I have two immediate use cases plus some more ideas:
>>>
>>> *Upload local files as binary blob to AWS S3*
>>>
>>> In my current, (hacky) version, I use the FileReader api (via
>>> simonH1000's filereader library) to read the content of a file into an
>>> ArrayBuffer, (represented as Json.Value in Elm) then use a modified version
>>> of elm-http to upload the content of the ArrayBuffer to an S3 storage
>>> bucket.
>>>
>>> *Download mp3 files, decode them and play them back via the AudioApi*
>>>
>>> Currently I do this with my modified http library to download the mp3
>>> file into an arraybuffer, then pass the resulting arraybuffer through a
>>> port to some native javascript that then uses the Audio Api to decode the
>>> mp3 file into a playable audiobuffer.
>>>
>>> *Parsing or otherwise processing local text files. *
>>>
>>> For another project I would be interested in reading and parsing
>>> Swagger/OpenAPI definition files and then providing a UI to compare rest
>>> apis. Since the processing will be done on simple Strings, this would only
>>> require FileReader support (specifically the readAsText method). This would
>>> already work with the FileReader library as is (though that one is not
>>> available on package.elm-lang.org because it contains native code and
>>> is not whitelisted).
>>>
>>> *TypedArrays and DataViews*
>>>
>>> I haven't worked with these yet, but I can anticipate some cases that
>>> would be interesting:
>>>
>>> *Parsing/manipulating of binary data via the ArrayBuffer api.*
>>>
>>> One case I personally would like to do with this, is to parse the Exif
>>> header of the jpeg files the user loaded from the local file system. My
>>> slideshow could then display metadata information without roundtripping to
>>> the server.
>>>
>>> *Create geometry for WebGL in the form of Vertex Buffers*
>>>
>>> *Generating sound/music by writing raw audio samples*
>>>
>>> These could then be played back via the Web audio apis.
>>>
>>>
>>> Please add your own ideas to this thread. Once we have compiled a list
>>> of use cases, we can look at the JS Apis available under the Web Platform
>>> for Files, ArrayBuffers, Typed Arrays etc. and think how these could be
>>> exposed to Elm.
>>>
>> --
> 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.
>



-- 
Zach Kessin
SquareTarget 
Twitter: @zkessin 
Skype: zachkessin

-- 
You received this message because you are subscribed to the Google Groups "Elm 

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

[art yerkes]

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 10:43 PM, GordonBGood  wrote:

> On Sunday, 15 January 2017 11:56:18 UTC+7, Bob Zhang wrote:
>>
>> I would be very surprised if parsing is the bottle neck
>>
> In most cases, type checking and register allocations (could be quadratic)
>> takes much more time. OCaml's type checking algorithms is very clever,
>> almost linear in most practical use cases.
>>
>
> Yet Evan did some relatively minor changes to parsing which is said to
> have over doubled compilation speed.   If parsing is usually a minor part,
> that would seem to say that the other parts are even faster.
>
> It would seem that Elm does all of its type checking in the front end and
> almost nothing is done with types in the code generation.  Elm basically
> has fixed types, as even the "type" keyword can only currently be used to
> define variations of tagged unions although such new types can be nested to
> any level, and if nested deeply I suppose could take a large amount of time
> to type check the structure if not done cleverly.
>
> I don't want to dig into the front end too much other than to try to nail
> down any problems as I think it is beyond my capabilities, but I plan to
> look into the code generator in more depth this next week.  Much of my
> experience is dealing with low level code.
>
>
>> On Sat, Jan 14, 2017 at 11:14 PM Richard Feldman 
>> wrote:
>>
>>> I'm wondering why the Elm compiler is so slow at parsing if that is
>> where the slow-down is
>>
>
> Evan recently rewrote the parser to be much faster.
>
> You can try a preview binary
> 
> of the new version if you're curious. :)
>
 --
> You received this message because you are subscribed to a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/elm-discuss/Um7WIBTq9xU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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