[elm-discuss] Re: Elm on fully distributed back-end? Meet Elmchemy. Elm for Erlang VM

2017-04-27 Thread Evan 
Between /r/elm and slack, we came to a nice conclusion on all this :)

Just wanted to let folks know here!


On Thursday, April 27, 2017 at 1:50:30 PM UTC-7, Evan wrote:
>
> I'm not sure I understand exactly what this has to do with Elm.
>
> Based on this example  this 
> appears to be a transpiler that uses syntax *similar* to Elm.
>
> For example:
>
>1. In the pattern matches, you pattern match on tuples without the 
>open and close parens. So this is not valid Elm code. 
>2. It appears that the ffi function is allowing you to bring in impure 
>Elixir functions. So now effects are not captured in the types.
>
> The second one in particular is such a divergence from the core design of 
> Elm that I don't see how it makes sense to call it by the same name. So 
> again, this does not appear to be related to Elm except in that the syntax 
> is similar. Is that a correct assessment?
>
> On Thursday, April 27, 2017 at 1:42:38 PM UTC-7, Krzysztof Wende wrote:
>>
>> Hello there everyone
>>
>> I think my project is ready enough to share it with you all.
>>
>> I'm a diehard longtime Erlang / Elixir programmer, and I always searched 
>> for a way to write static typing for Erlang.
>> After 5th attempts to implement Hindley-Milner on Elixir's AST I decided 
>> that it's time to try something else.
>>
>> So here it is:
>>
>>
>> https://www.reddit.com/r/elm/comments/67v2so/elm_on_fully_distributed_backend_meet_elmchemy/
>>  
>> 
>>
>> Elm to Elixir compiler.
>> Please enjoy, and please contribute!
>>
>> Constructive critique welcome
>>
>> PS. Yes. I am aware of alpaca-lang and purerl. I'll gladly answer why I'm 
>> not satisfied enough with these to anyone wondering
>>
>

-- 
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] elm-css with type classes (a response to the Elm Town podcast)

2017-04-27 Thread OvermindDL1 
Yep, that is all trivial with Polymorphic Variants if you want them shared.

In essence, you know how a normal variant is, like this (in OCaml syntax 
since that is what I'm more comfortable with, but it's close enough to Elm, 
'almost' identical)
```ocaml
type Vwoop =
| Infinite
| Int of integer

type Broop =
| Infinite
| Float of float
```
And say you have some functions like (again in OCaml syntax):
```ocaml
let vloo = function
| Infinite -> "infinite"
| Int i -> string_of_integer i

let bloo = function
| Infinite -> "all"
| Float f -> string_of_float f
```
Now this will not compile, there are two Infinite's in scope and so it does 
not know which you want or mean without qualifying them by name.  If 
however we did not have the variant types above and just used polymorphic 
variants:
```ocaml
let vloo = function
| `Infinite -> "infinite"
| `Int i -> string_of_int i

let bloo = function
| `Infinite -> "all"
| `Float f -> string_of_float f
```
And this all works fine, you could use it like this no problem:
```ocaml
let whatever = String.concat [vloo `Infinite; bloo `Infinite]
```
And `whatever` will become the string "infiniteall" as expected.

A Polymorphic Variant is just a 'globally scoped' variant, and it is not 
based on the name but the entire type, so ``` `Int ``` is different from 
``` `Int 42 ```, so this will *not* compile:
```ocaml
let this_does_not_compile = vloo (`Int 42.7)
```
This will give you the error (I just ran this to test):
```
Line 9, 33: Error: This expression has type [> `Int of float ]
   but an expression was expected of type [< `Infinite | `Int of int ]
   Types for tag `Int are incompatible
```
So it is trying to pass in the specific type of `Int of float, yet the 
function only accepts the closed set of polymorphic varianst of `Infinite 
or `Int of int.  It then goes on to clarify that the `Int is fine but the 
type inside the `Int is wrong/incompatible.  For further example if I try 
to past in `Blah it returns:
```
Line 9, 33: Error: This expression has type [> `Blah ]
   but an expression was expected of type [< `Infinite | `Int of int ]
   The second variant type does not allow tag(s) `Blah
```
It is type safe the whole way through.  And of course you can add types to 
it as well if you want, they are exactly as they appear in the error 
messages.


For note, `function` is a keyword in OCaml that is short for a combination 
fn and match, so these are the same:
```ocaml
let tester = function
| `Test1 -> "test1"
| `Test2 -> "test2"

let tester t = match t with
| `Test1 -> "test1"
| `Test2 -> "test2"
```

For note, polymorphic variants are just like normal variants, in the 
generated javascript they get tagged like any normal variant, just with a 
larger number due to their scope.  The above tester/bloo/vloo functions 
compile to this javascript:
```javascript
var Pervasives = require("stdlib/pervasives");

function vloo(param) {
  if (typeof param === "number") {
return "infinite";
  }
  else {
return Pervasives.string_of_int(param[1]);
  }
}

function bloo(param) {
  if (typeof param === "number") {
return "all";
  }
  else {
return Pervasives.string_of_float(param[1]);
  }
}

function tester(t) {
  if (t >= 549646208) {
return "test2";
  }
  else {
return "test1";
  }
}
```

But yes, as you can see polymorphic variants types can be open (accepting 
any) or closed (accepting a limited subset), fully typed and safe the whole 
way down.

A lot of people consider polymorphic variants existence a bit of a wart, 
but I do not see it, they are highly highly useful in specific cases (like 
DSEL's here), but I do agree they can be abused when normal variants are 
better...


On Thursday, April 27, 2017 at 2:26:10 PM UTC-6, Mark Hamburg wrote:
>
> Maybe this is covered in OCaml's polymorpic variants — I couldn't tell 
> from a quick skim — but another feature that would cover this without 
> introducing type classes is support for more arbitrary union/sum types. 
> That way, one could write something like:
>
> type Auto = Auto
>
>
> type alias LengthOrAuto = Int + Auto -- is this a type or a type alias, 
> I'm not sure
>
> margin : LengthOrAuto -> Style
>
> Handwaving type checking rules would require that a type passed to 
> something that was expecting a union type needs to cover a subset of that 
> union type. Case statements would be used to do the discrimination.
>
> The potentially interesting things that come out of something like this 
> are that one could imagine a union of Maybe and Result which would allow 
> for a value or an error or nothing. This has got to have been explored 
> somewhere before. I have no idea what sort of problems it might create for 
> the type system.
>
> Mark
>
> On Thu, Apr 27, 2017 at 10:53 AM, OvermindDL1  > wrote:
>
>> Actually this sounds to exactly like the use-case for OCaml's Polymorphic 
>> Variants.  In OCaml you could easily use just `Hidden for both of your 
>> examples, fully type checked, typ

[elm-discuss] Re: Elm on fully distributed back-end? Meet Elmchemy. Elm for Erlang VM

2017-04-27 Thread Evan 
I'm not sure I understand exactly what this has to do with Elm.

Based on this example  this 
appears to be a transpiler that uses syntax *similar* to Elm.

For example:

   1. In the pattern matches, you pattern match on tuples without the open 
   and close parens. So this is not valid Elm code. 
   2. It appears that the ffi function is allowing you to bring in impure 
   Elixir functions. So now effects are not captured in the types.

The second one in particular is such a divergence from the core design of 
Elm that I don't see how it makes sense to call it by the same name. So 
again, this does not appear to be related to Elm except in that the syntax 
is similar. Is that a correct assessment?

On Thursday, April 27, 2017 at 1:42:38 PM UTC-7, Krzysztof Wende wrote:
>
> Hello there everyone
>
> I think my project is ready enough to share it with you all.
>
> I'm a diehard longtime Erlang / Elixir programmer, and I always searched 
> for a way to write static typing for Erlang.
> After 5th attempts to implement Hindley-Milner on Elixir's AST I decided 
> that it's time to try something else.
>
> So here it is:
>
>
> https://www.reddit.com/r/elm/comments/67v2so/elm_on_fully_distributed_backend_meet_elmchemy/
>  
> 
>
> Elm to Elixir compiler.
> Please enjoy, and please contribute!
>
> Constructive critique welcome
>
> PS. Yes. I am aware of alpaca-lang and purerl. I'll gladly answer why I'm 
> not satisfied enough with these to anyone wondering
>

-- 
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] Elm on fully distributed back-end? Meet Elmchemy. Elm for Erlang VM

2017-04-27 Thread Krzysztof Wende 
Hello there everyone

I think my project is ready enough to share it with you all.

I'm a diehard longtime Erlang / Elixir programmer, and I always searched 
for a way to write static typing for Erlang.
After 5th attempts to implement Hindley-Milner on Elixir's AST I decided 
that it's time to try something else.

So here it is:

https://www.reddit.com/r/elm/comments/67v2so/elm_on_fully_distributed_backend_meet_elmchemy/

Elm to Elixir compiler.
Please enjoy, and please contribute!

Constructive critique welcome

PS. Yes. I am aware of alpaca-lang and purerl. I'll gladly answer why I'm 
not satisfied enough with these to anyone wondering

-- 
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] elm-css with type classes (a response to the Elm Town podcast)

2017-04-27 Thread Mark Hamburg 
Maybe this is covered in OCaml's polymorpic variants — I couldn't tell from
a quick skim — but another feature that would cover this without
introducing type classes is support for more arbitrary union/sum types.
That way, one could write something like:

type Auto = Auto


type alias LengthOrAuto = Int + Auto -- is this a type or a type alias, I'm
not sure

margin : LengthOrAuto -> Style

Handwaving type checking rules would require that a type passed to
something that was expecting a union type needs to cover a subset of that
union type. Case statements would be used to do the discrimination.

The potentially interesting things that come out of something like this are
that one could imagine a union of Maybe and Result which would allow for a
value or an error or nothing. This has got to have been explored somewhere
before. I have no idea what sort of problems it might create for the type
system.

Mark

On Thu, Apr 27, 2017 at 10:53 AM, OvermindDL1  wrote:

> Actually this sounds to exactly like the use-case for OCaml's Polymorphic
> Variants.  In OCaml you could easily use just `Hidden for both of your
> examples, fully type checked, type safe, etc... etc...  Polymorphic
> Variants are just global Variants that are unnamed.  A function can take a
> bounded or unbounded set of them and are perfectly suited for an abstract
> CSS DSL while being readable in both usage and implementation.
>
> And yes, I agree about type classes, they are extremely over-used in
> Haskell where something like OCaml's Implicit Modules would be such a
> significantly better fit for...
>
>
> On Thursday, April 27, 2017 at 6:21:22 AM UTC-6, Mitchell Rosen wrote:
>>
>> Hi Joey,
>>
>> Indeed, basic ADTs are one way to model the DSL. The problem then arises
>> when you want to reuse the name "auto" for another key.
>>
>> I may not have been clear, so I'll try to summarize my post here. How
>> might elm-css look if there were different features in Elm? As it stands,
>> the library seems to be fighting hard against the language, and the result
>> far from beginner-friendly.
>>
>> Type classes are one such extension, and I sketched out how one might
>> implement this library using them. As you mentioned, ADTs are another.
>>
>> In this particular case, type classes, as flawed as they are, seem vastly
>> superior to the row-types approach. But, I'm definitely open to having my
>> mind changed! I'm just not comfortable enough with row types as a language
>> feature to really have an intuitive understanding of when to use them, and
>> when to not.
>>
>> But, anyways, I totally agree that keeping it simple with ADTs is what
>> you should do most of the time. It's only when you're writing library code
>> to be used by the community that you should start obsessing over the
>> ergonomics.
>>
>> --
> 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] elm-css with type classes (a response to the Elm Town podcast)

2017-04-27 Thread OvermindDL1 
Actually this sounds to exactly like the use-case for OCaml's Polymorphic 
Variants.  In OCaml you could easily use just `Hidden for both of your 
examples, fully type checked, type safe, etc... etc...  Polymorphic 
Variants are just global Variants that are unnamed.  A function can take a 
bounded or unbounded set of them and are perfectly suited for an abstract 
CSS DSL while being readable in both usage and implementation.

And yes, I agree about type classes, they are extremely over-used in 
Haskell where something like OCaml's Implicit Modules would be such a 
significantly better fit for...


On Thursday, April 27, 2017 at 6:21:22 AM UTC-6, Mitchell Rosen wrote:
>
> Hi Joey,
>
> Indeed, basic ADTs are one way to model the DSL. The problem then arises 
> when you want to reuse the name "auto" for another key.
>
> I may not have been clear, so I'll try to summarize my post here. How 
> might elm-css look if there were different features in Elm? As it stands, 
> the library seems to be fighting hard against the language, and the result 
> far from beginner-friendly.
>
> Type classes are one such extension, and I sketched out how one might 
> implement this library using them. As you mentioned, ADTs are another.
>
> In this particular case, type classes, as flawed as they are, seem vastly 
> superior to the row-types approach. But, I'm definitely open to having my 
> mind changed! I'm just not comfortable enough with row types as a language 
> feature to really have an intuitive understanding of when to use them, and 
> when to not.
>
> But, anyways, I totally agree that keeping it simple with ADTs is what you 
> should do most of the time. It's only when you're writing library code to 
> be used by the community that you should start obsessing over the 
> ergonomics.
>
>

-- 
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: Moving on

2017-04-27 Thread Peter Damoc 
On Thu, Apr 27, 2017 at 1:48 PM, Rehno Lindeque 
wrote:

>
> This grey list would be backed by a clear process of getting things on the
>> list that would include a checklist of mandatory things.
>> This checklist would be like a rule list and breaking any of the rule
>> would have to happen after a serious benefits analysis done under the
>> supervision of that experienced Elm programmers group I mentioned earlier.
>>
>
> If this were the route people decide to take, I get the impression that
> this is the sort of thing elm-community does quite well. Perhaps a
> "greylist" could be simplified to https://github.com/elm-community/*.
>

Of course, that would be the optimal course.
I guess this would make the packages a very light shade of grey, closer to
something semi-official than something apocryphal. :)




-- 
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] elm-css with type classes (a response to the Elm Town podcast)

2017-04-27 Thread Mitchell Rosen 
Hi Joey,

Indeed, basic ADTs are one way to model the DSL. The problem then arises when 
you want to reuse the name "auto" for another key.

I may not have been clear, so I'll try to summarize my post here. How might 
elm-css look if there were different features in Elm? As it stands, the library 
seems to be fighting hard against the language, and the result far from 
beginner-friendly.

Type classes are one such extension, and I sketched out how one might implement 
this library using them. As you mentioned, ADTs are another.

In this particular case, type classes, as flawed as they are, seem vastly 
superior to the row-types approach. But, I'm definitely open to having my mind 
changed! I'm just not comfortable enough with row types as a language feature 
to really have an intuitive understanding of when to use them, and when to not.

But, anyways, I totally agree that keeping it simple with ADTs is what you 
should do most of the time. It's only when you're writing library code to be 
used by the community that you should start obsessing over the ergonomics.

-- 
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: Moving on

2017-04-27 Thread Rehno Lindeque 


> This grey list would be backed by a clear process of getting things on the 
> list that would include a checklist of mandatory things. 
> This checklist would be like a rule list and breaking any of the rule 
> would have to happen after a serious benefits analysis done under the 
> supervision of that experienced Elm programmers group I mentioned earlier. 
>

If this were the route people decide to take, I get the impression that 
this is the sort of thing elm-community does quite well. Perhaps a 
"greylist" could be simplified to https://github.com/elm-community/*. 

Something to keep in mind is that there's likely to be red tape required to 
fork a package on a special list. Not great if you need to fix something in 
a hurry and the author has disappeared. Elm-community provides a little bit 
of peace of mind for people like me who would like to make sure that 
packages they use have at least one active maintainer assigned to it and 
that the code has had some level of peer review.

-- 
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: Moving on

2017-04-27 Thread Peter Damoc 
On Thu, Apr 27, 2017 at 12:59 PM, Wojciech Piekutowski <
w.piekutow...@gmail.com> wrote:

> Peter, did you mean https://github.com/gdotdesign/elm-github-install for
> installing packages with missing Web APIs?
>

No.  elm-github-install allows for too much freedom.

What I had in mind was more like a grey-list and something similar to
elm-github-install but constrained to this grey-list.
This grey list would be backed by a clear process of getting things on the
list that would include a checklist of mandatory things.
This checklist would be like a rule list and breaking any of the rule would
have to happen after a serious benefits analysis done under the supervision
of that experienced Elm programmers group I mentioned earlier.





-- 
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] Re: Moving on

2017-04-27 Thread Wojciech Piekutowski 
Peter, did you mean https://github.com/gdotdesign/elm-github-install for
installing packages with missing Web APIs?

On 27 April 2017 at 07:48, Peter Damoc  wrote:

> On Thu, Apr 27, 2017 at 2:08 AM, Oliver Searle-Barnes 
> wrote:
>
>> At a practical level I see two parts to this:
>>
>> 1) Better javascript interop to allow the community to provide the
>> missing web APIs and effect managers (task ports have been mooted on
>> several occasions)
>>
>> 2) A development process that encourages the use of packages from the
>> wider community _before_ they've had sufficient design attention and
>> matured to the point where they may be considered gold standard.
>>
> [...]
>
> I don't want to be too prescriptive here but one suggestion might be to
>> introduce the concept of a quality or status metric for each package e.g.
>> exploratory, draft, candidate, ready (those were chosen purely for
>> illustrative purposes). This would allow the community to benefit from each
>> other's work without requiring any compromise in standards. Versus forcing
>> every team to reimplement the same things with ports this seems like a
>> distinct improvement (IMHO). Potentially packages could even be kept in an
>> entirely different package site until they'd graduated to
>> http://package.elm-lang.org/. (this would allow beginners to be kept in
>> a safer environment until they needed to reach into the community packages)
>>
>
> The current elm compiler allows this and if there is enough developer
> desire, this can be done through tooling without requiring any change to
> the compiler or the core.
> By going the apocryphal way we could, in theory, even implement the
> missing SemVer and make the apocryphal Kernel libraries start with a 0
> further emphasizing that it is experimental code.
>
> There is danger in this approach BUT, if a good enough process is put
> behind it and there are a group of experienced Elm programmers monitoring
> it, I think that it can provide a lot of value for people who want to move
> in areas that are currently unsupported by Elm.
>
>
> --
> 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.
>

-- 
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: Moving on

2017-04-27 Thread 'Rupert Smith' via Elm Discuss 
This Week, in April 2017:
>
> Elm, potential BDFL and community friction...
>

Just wanted to chip in my 2 cents. I think Evan as BDFL is working for Elm, 
and I understand and respect his desire to go slow and get it right for the 
long term. Its very hard to maintain that position when people are 
clamouring for features. But it is also a tough job maintaining the vision 
for a language that aims to maintain its functional purity - so every piece 
of design takes time and careful thought and there is only so fast one guy 
can go whilst also holding down a day job.

I do think that support for binary data is something that is constantly 
being asked for and needs to be addressed by the core Elm language though. 
As a community, perhaps the best thing we could do is to discuss the 
options here? What does it look like in code? How is binary data handled in 
ML, OCaml, Haskell etc.

Also Elm aims to cover the whole of the web platform and there is plenty 
outside of the core language. As a community we can get involved by 
identifying area of the platform that the libraries do not cover (well) and 
working on those. I seem to have picked typed-svg for my sins, but it is a 
necessary part of the platform and open to the community to build. We could 
helpfully draw up a list of similar areas requiring work that are outside 
of the kernel and the language itself.

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