Re: [elm-discuss] Re: Guidance for using "type alias" vs. single-constructor union types

2017-01-16 Thread Max Goldstein 
I did not know F# supported that, which is good news. It means that there's 
feasible, theoretically sound way of solving this problem. In Elm, it would 
require making the mathematical operations aware of units and therefore 
even more "special" that the *number* not-a-typeclass. But units still feel 
like the right abstraction for this problem, especially if strings could be 
marked as having a unit (never mix up usernames and passowrds again!), so 
I'd much rather consider adding units of measure to the language *later* than 
some weird, halfbaked idea *now.*

-- 
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] Convert String to symbol (previously `Text.fromString`, like Haskell's `read`)

2017-01-16 Thread Max Goldstein 
The function String -> a is called eval, and it's not coming to Elm because 
it would break all kinds of type guarantees. You can implement functions 
from String to a specific concrete type, although that type will have to 
have some notion of failure or emptiness if it's not wrapped in a Maybe or 
a Result. Nick gives you an example of how to do that; more simply you can 
just do a case analysis of all the strings you want (or if statements with 
regexes...).

But if at all possible, don't use string identifiers at all. Sometimes it 
can't be helped (usually JS of JSON interop) but especially if all your 
union type's tags are not functions, just pass those around within 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.

[elm-discuss] Re: YAML lib for Elm?

2017-01-16 Thread Brian Hicks 
It doesn't look like there is, unfortunately. What are you trying to 
accomplish? Maybe there's another way around. :)

On Monday, January 16, 2017 at 12:00:45 AM UTC-6, fxmy wang wrote:
>
> 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.

[elm-discuss] Re: Convert String to symbol (previously `Text.fromString`, like Haskell's `read`)

2017-01-16 Thread Josh Szmajda 
Yeah that makes sense, it's probably exactly what I want.

Still curious about direct translation of Strings to symbols though :)

On Monday, January 16, 2017 at 8:32:13 PM UTC-5, John Kelly wrote:
>
> Hey! You might want to check this out 
> http://package.elm-lang.org/packages/evancz/url-parser/latest. It's the 
> closest thing to the String -> a type signature you are after. I'm 
> personally not familiar with Haskell's read, so I can't speak much on that. 
>
> On Monday, January 16, 2017 at 3:56:43 PM UTC-8, Josh Szmajda wrote:
>>
>> Hey folks!
>>
>> This is in reference to https://github.com/elm-lang/core/issues/805
>>
>> I'm looking for a function to convert a String to an internal symbol 
>> (signature `String -> a`). Previously this was in `Text.fromString` but 
>> apparently that has been removed.
>>
>> The use-case I have in mind is this router:
>>
>> ```
>> locationUpdate : Navigation.Location -> App.Msg
>> locationUpdate location =
>>   case (String.dropLeft 2 location.hash) of
>>
>> "ViewDocList" -> ViewState ViewDocList
>>
>> "ViewDocument" -> ViewState ViewDocument
>>
>> _ -> App.NoOp
>>
>> -- Would rather code this as:
>> -- case Text.fromString msg of
>> --   Just value -> ViewState value
>> --   Nothing-> App.NoOp
>> ```
>>
>> In Haskell this would be `read`:
>>
>> ```
>> Prelude> read "4.5" :: Float
>> 4.5
>> Prelude> :t read "4.5" :: Float
>> read "4.5" :: Float :: Float
>> ```
>>
>> Any ideas on when this might come back?
>>
>> Thanks!
>> -Josh
>>
>

-- 
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] Convert String to symbol (previously `Text.fromString`, like Haskell's `read`)

2017-01-16 Thread Nick H 
I doubt such a function will be introduced any time soon, because it's not
a properly typed operation. In Haskell, you have to add the type annotation
to the function call because read's return type is ambiguous. However, Elm
doesn't have any similar ability.

For converting Strings to numeric types, there are String.toInt and
String.toFloat.

For doing what your example does, I might consider using a dictionary
mapping strings to states. Maybe Something like:

viewStates = Dict.fromList [ ("ViewDocList", ViewDocList), ("ViewDocument",
ViewDocument) ]

locationUpdate location =
  case Dict.get location viewStates of
Just state ->
  ViewState state

Nothing ->
  App.NoOp

You still need to manually associate strings with view states, but now
locationUpdate has the form you want.

On Mon, Jan 16, 2017 at 12:44 PM, Josh Szmajda  wrote:

> Hey folks!
>
> This is in reference to https://github.com/elm-lang/core/issues/805
>
> I'm looking for a function to convert a String to an internal symbol
> (signature `String -> a`). Previously this was in `Text.fromString` but
> apparently that has been removed.
>
> The use-case I have in mind is this router:
>
> ```
> locationUpdate : Navigation.Location -> App.Msg
> locationUpdate location =
>   case (String.dropLeft 2 location.hash) of
>
> "ViewDocList" -> ViewState ViewDocList
>
> "ViewDocument" -> ViewState ViewDocument
>
> _ -> App.NoOp
>
> -- Would rather code this as:
> -- case Text.fromString msg of
> --   Just value -> ViewState value
> --   Nothing-> App.NoOp
> ```
>
> In Haskell this would be `read`:
>
> ```
> Prelude> read "4.5" :: Float
> 4.5
> Prelude> :t read "4.5" :: Float
> read "4.5" :: Float :: Float
> ```
>
> Any ideas on when this might come back?
>
> Thanks!
> -Josh
>
> --
> 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: Convert String to symbol (previously `Text.fromString`, like Haskell's `read`)

2017-01-16 Thread John Kelly 
Hey! You might want to check this 
out http://package.elm-lang.org/packages/evancz/url-parser/latest. It's the 
closest thing to the String -> a type signature you are after. I'm 
personally not familiar with Haskell's read, so I can't speak much on that. 

On Monday, January 16, 2017 at 3:56:43 PM UTC-8, Josh Szmajda wrote:
>
> Hey folks!
>
> This is in reference to https://github.com/elm-lang/core/issues/805
>
> I'm looking for a function to convert a String to an internal symbol 
> (signature `String -> a`). Previously this was in `Text.fromString` but 
> apparently that has been removed.
>
> The use-case I have in mind is this router:
>
> ```
> locationUpdate : Navigation.Location -> App.Msg
> locationUpdate location =
>   case (String.dropLeft 2 location.hash) of
>
> "ViewDocList" -> ViewState ViewDocList
>
> "ViewDocument" -> ViewState ViewDocument
>
> _ -> App.NoOp
>
> -- Would rather code this as:
> -- case Text.fromString msg of
> --   Just value -> ViewState value
> --   Nothing-> App.NoOp
> ```
>
> In Haskell this would be `read`:
>
> ```
> Prelude> read "4.5" :: Float
> 4.5
> Prelude> :t read "4.5" :: Float
> read "4.5" :: Float :: Float
> ```
>
> Any ideas on when this might come back?
>
> Thanks!
> -Josh
>

-- 
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] Convert String to symbol (previously `Text.fromString`, like Haskell's `read`)

2017-01-16 Thread Josh Szmajda 
Hey folks!

This is in reference to https://github.com/elm-lang/core/issues/805

I'm looking for a function to convert a String to an internal symbol 
(signature `String -> a`). Previously this was in `Text.fromString` but 
apparently that has been removed.

The use-case I have in mind is this router:

```
locationUpdate : Navigation.Location -> App.Msg
locationUpdate location =
  case (String.dropLeft 2 location.hash) of

"ViewDocList" -> ViewState ViewDocList

"ViewDocument" -> ViewState ViewDocument

_ -> App.NoOp

-- Would rather code this as:
-- case Text.fromString msg of
--   Just value -> ViewState value
--   Nothing-> App.NoOp
```

In Haskell this would be `read`:

```
Prelude> read "4.5" :: Float
4.5
Prelude> :t read "4.5" :: Float
read "4.5" :: Float :: Float
```

Any ideas on when this might come back?

Thanks!
-Josh

-- 
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: Guidance for using "type alias" vs. single-constructor union types

2017-01-16 Thread 'Andrew Radford' via Elm Discuss 
+1, One of those awesome features in F# that does not seem to be that 
widely known. 
 

>
> I believe F# also does this quite well:
>
> https://fsharpforfunandprofit.com/posts/units-of-measure/
>

-- 
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: Guidance for using "type alias" vs. single-constructor union types

2017-01-16 Thread Duane Johnson 
On Mon, Jan 16, 2017 at 10:26 AM, Max Goldstein 
wrote:

> More concretely, say one defines type clones for Length and Width in the
> hope of avoiding accidentally adding them, which would make no sense. But
> we'd want to allow multiplying them to obtain Area. The only language I
> know that handles this well is Frink , which
> tracks physical units through all computations.
>

I believe F# also does this quite well:

https://fsharpforfunandprofit.com/posts/units-of-measure/

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[elm-discuss] Re: on reuse and effects/subscriptions

2017-01-16 Thread Rex van der Spuy 
Thanks for asking this Peter, I've been also been wondering about these 
same things lately.

-- 
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: Guidance for using "type alias" vs. single-constructor union types

2017-01-16 Thread Max Goldstein 
It's tempting to want something like

type clone Name = String
type clone Currency = Int
type alias Accounts = Dict Name Currency

These hypothetical "type clones" would act like their base type until you 
tried to use them in nonsensical ways. But trying to define their behavior 
is tricky.

The Haskell community has apparently tried this under the name "subtypes" 
and concluded they are very difficult to implement and have other 
undesirable properties, but I couldn't find anything formal.

More concretely, say one defines type clones for Length and Width in the 
hope of avoiding accidentally adding them, which would make no sense. But 
we'd want to allow multiplying them to obtain Area. The only language I 
know that handles this well is Frink , which tracks 
physical units through all computations.

All that said, it may be possible to define this well enough and simply 
enough to warrant further explanation. For example, in any correct program 
with type clones, one should be able to replace any clone with an alias and 
have identical code generated. If there's interest, I can start a new 
thread exploring these type clones further.

-- 
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: External Firebase comms to Elm via ports?

2017-01-16 Thread Maxime Dantec 
The Elm-Kinto library for Mozilla Kinto is using the Http library instead 
of trying to wrap the JS library. I think it's smart :)

On Monday, January 16, 2017 at 4:45:25 PM UTC+1, Marais Rossouw wrote:
>
> I have custom Firebase auth processes (Auth0 => Firebase), so I run all my 
> login logic using TypeScript with Svelte 
> , once I have a successful JWT token, 
> either from sessionStorage or from a fresh login, I then boot off my Elm 
> app, sending it some JWT, profile info via a Flag. I have its a SPA, with a 
> routeing and pages, all componentized and working fine. 
>
> My only real problem now is comms to firebase, sure, ElmFire exists, but 
> how do I just give it an active auth token etc... and without loading 
> Firebase for JS and ElmFire for Elm. Just seems like way to many kbs. 
>
> Is there a nice and efficient way to let Elm port out a "hey listen to 
> this ref", with a "hey Elm, I have some new data for you for this ref". 
> Ports to tell JS to listen, and subscriptions to tell Elm about new data. 
> Without having a port for every listen, and a subscription for every data 
> callback.
>
> Ideally, I'd like my update, to send off a Cmd that accepts a callback 
> Msg, the update function to call and a ref. So that way I can store that in 
> a List of some sort, and when I get a new data payload from JS, I can loop 
> over my List find the item that matches the ref, execute the update, 
> sending in the Msg with the string value, so decoding happens on the pages' 
> update.
>
> My code is currently closed source (Github), if anyone is genuinely keen 
> to help me out, with a top-notch solution, ill add you to the repo, and 
> give you some $$ for your time.
>

-- 
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] External Firebase comms to Elm via ports?

2017-01-16 Thread Marais Rossouw 
I have custom Firebase auth processes (Auth0 => Firebase), so I run all my 
login logic using TypeScript with Svelte 
, once I have a successful JWT token, 
either from sessionStorage or from a fresh login, I then boot off my Elm 
app, sending it some JWT, profile info via a Flag. I have its a SPA, with a 
routeing and pages, all componentized and working fine. 

My only real problem now is comms to firebase, sure, ElmFire exists, but 
how do I just give it an active auth token etc... and without loading 
Firebase for JS and ElmFire for Elm. Just seems like way to many kbs. 

Is there a nice and efficient way to let Elm port out a "hey listen to this 
ref", with a "hey Elm, I have some new data for you for this ref". Ports to 
tell JS to listen, and subscriptions to tell Elm about new data. Without 
having a port for every listen, and a subscription for every data callback.

Ideally, I'd like my update, to send off a Cmd that accepts a callback Msg, 
the update function to call and a ref. So that way I can store that in a 
List of some sort, and when I get a new data payload from JS, I can loop 
over my List find the item that matches the ref, execute the update, 
sending in the Msg with the string value, so decoding happens on the pages' 
update.

My code is currently closed source (Github), if anyone is genuinely keen to 
help me out, with a top-notch solution, ill add you to the repo, and give 
you some $$ for your time.

-- 
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: Guidance for using "type alias" vs. single-constructor union types

2017-01-16 Thread art yerkes 
You could try elm-generic-dict to have arbitrary keys in dicts.

On Monday, January 16, 2017 at 6:31:28 AM UTC-8, Austin Bingham wrote:
>
> Ah ha! That bit of syntax is exactly what I was looking for. That get's me 
> a lot of what I was hoping for.
>
> Regarding the use of helper functions, I agree in principle. But in my 
> particular case, at least, I think it's mostly an academic issue. I want to 
> distinguish between various "classes" of strings using the type system, but 
> mostly all I do with them is store them and use them as keys. 
>
> One interesting issue I've run into is the use of single-contructor unions 
> as e.g. the key-type in a dict. As far as I can tell, I can't do something 
> like this:
>
> type Foo = Foo String
> type alias FooDict = Dict Foo String
>
> because Foo isn't "comparable" and can't be made so. Is there some way to 
> do this, or is this just a limitation of elm?
>
> On Monday, January 16, 2017 at 2:49:46 PM UTC+1, Ian Mackenzie wrote:
>>
>> I agree with the point about adding helper functions for your data type 
>> so you can treat it as opaque in most places. For the rest, though, you can 
>> also use the slightly obscure 'as' syntax 'foo ((Foo s) as f) = ...' which 
>> allows you to use both 's' and 'f' in your function body (with the 
>> additional bonus of avoiding an extra object allocation).
>
>

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

2017-01-16 Thread Maxime Dantec 
I made a TL;DR :

https://gist.github.com/Warry/ca83e06f92bfc9bd866a33ed97bbc6f8

On Monday, January 16, 2017 at 1:51:40 PM UTC+1, Maxime Dantec wrote:
>
> Actually, we could get rid of the keyword entierly :
>
> Faz = (Int, Int)
> Faz : ø
>
> Fiz = { name : String, age : Int }
> Fiz : ø
>
> Fuz a = { a | age : Int }
> Fuz : ø
>
> Foo
>   = Foo
>   | Bar Int
>   | Baz (String, String)
> *  | Biz { name : String, age : Int }*
> *  | Buz Fiz*
>
>
> *  | Boz (Fuz { name : String })*Foo : Foo
> Bar : Int -> Foo
> Baz : String -> String -> Foo
>
> *Biz : String -> Int -> Foo**Buz : String -> Int -> Foo*
>
>
>
>
> *Boz : String -> Int -> FooDoo a =... *
> On Monday, January 16, 2017 at 1:43:02 PM UTC+1, Maxime Dantec wrote:
>>
>> Thanks for the answers, I had indeed made some poor choices of word in my 
>> first email :(
>>
>> Just before this thread dies, and out of the blue : What if...
>>
>> - type alias never generates a constructor (change: records do not have 
>> ctors)
>> - type always generate an "expanded" ctor
>>
>> expanded as in :
>>
>> type alias Faz = (Int, Int)
>> Faz : ø
>>
>> type alias Fiz = { name : String, age : Int }
>> Fiz : ø
>>
>> type alias Fuz a = { a | name : String }
>> Fuz : ø
>>
>> type Foo
>>   = Foo
>>   | Bar Int
>>   | Baz (String, String)
>> *  | Biz { name : String, age : Int }*
>>
>> *  | Buz Fiz*
>> Foo : Foo
>> Bar : Int -> Foo
>> Baz : String -> String -> Foo
>>
>>
>> *Biz : String -> Int -> FooBuz : String -> Int -> Foo*
>> On Monday, January 16, 2017 at 6:56:52 AM UTC+1, Max Goldstein wrote:
>>>
>>> * 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.

[elm-discuss] Re: Guidance for using "type alias" vs. single-constructor union types

2017-01-16 Thread Austin Bingham 
Ah ha! That bit of syntax is exactly what I was looking for. That get's me 
a lot of what I was hoping for.

Regarding the use of helper functions, I agree in principle. But in my 
particular case, at least, I think it's mostly an academic issue. I want to 
distinguish between various "classes" of strings using the type system, but 
mostly all I do with them is store them and use them as keys. 

One interesting issue I've run into is the use of single-contructor unions 
as e.g. the key-type in a dict. As far as I can tell, I can't do something 
like this:

type Foo = Foo String
type alias FooDict = Dict Foo String

because Foo isn't "comparable" and can't be made so. Is there some way to 
do this, or is this just a limitation of elm?

On Monday, January 16, 2017 at 2:49:46 PM UTC+1, Ian Mackenzie wrote:
>
> I agree with the point about adding helper functions for your data type so 
> you can treat it as opaque in most places. For the rest, though, you can 
> also use the slightly obscure 'as' syntax 'foo ((Foo s) as f) = ...' which 
> allows you to use both 's' and 'f' in your function body (with the 
> additional bonus of avoiding an extra object allocation).

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

2017-01-16 Thread 'Rupert Smith' via Elm Discuss 
On Saturday, January 14, 2017 at 1:51:39 AM UTC, GordonBGood wrote:
>
> All that this would take would be to write an Elm parser into the first 
>> stage of the OCaml pipeline? You'd also need to compile the Native modules, 
>> is there already some way to feed them into the Ocaml pipeline?
>>
>
> Elm "Native" libraries are JavaScript, and that is what BuckleScript does: 
> as well as output JS code, it also has JS FFI to allow BuckleScript code to 
> call to/receive calls from JS code.  I think this would be handled by an 
> Elm PP just as OCaml handles FFI references -  leaving FFI blanks to be 
> later "filled in" by later passes.
>

Yes, that is what I was getting at. If you compile Elm -> Ocaml -> 
Javascript, then the Native stuff in Elm just gets copied into the output 
javascript directly (unless of course passing it through Ocaml is 
worthwhile and can optimize it). But if you are going Elm -> Ocaml -> 
native x86_64 binary, then the javascript needs to be compiled through 
Ocaml. So I was just wondering if the Ocaml tool-chain already has a 
javascript front-end for it?

-- 
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: Proposal: Main.attach(node) to attach Elm to existing DOM?

2017-01-16 Thread 'Rupert Smith' via Elm Discuss 
On Thursday, January 12, 2017 at 5:02:36 PM UTC, Rupert Smith wrote:
>
> I propose to continue investigating it and write up how to modify the Elm 
> code to do it.
>

Any ideas on how to go about working on code that is in 
elm-lang/virtual-dom ? Specifically, how do I create an alternate version 
of that, but have existing code that uses elm-lang/html call it?

The normal way I use elm-lang/virtual-dom is to import elm-lang/html in my 
elm-package.json, and it pulls in the vdom code as a dependency. I don't 
see a mechanism to exclude a dependency so that I can substitute another in 
its place. I would fork the vdom code to my own github account, work on it 
till its right, and then make a pull request in the usual manner.

It seems quite awkward to develop Elm native code that is pulled in through 
elm-package.

-- 
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] Guidance for using "type alias" vs. single-constructor union types

2017-01-16 Thread Ian Mackenzie 
I agree with the point about adding helper functions for your data type so you 
can treat it as opaque in most places. For the rest, though, you can also use 
the slightly obscure 'as' syntax 'foo ((Foo s) as f) = ...' which allows you to 
use both 's' and 'f' in your function body (with the additional bonus of 
avoiding an extra object allocation).

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

2017-01-16 Thread Bob Zhang 
This will be a fundamental change to the architecture of the elm compiler,
it is cool to see elm is also moving in this direction in the next several
months!
On Mon, Jan 16, 2017 at 1:09 AM GordonBGood  wrote:

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

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

2017-01-16 Thread Maxime Dantec 
Actually, we could get rid of the keyword entierly :

Faz = (Int, Int)
Faz : ø

Fiz = { name : String, age : Int }
Fiz : ø

Fuz a = { a | age : Int }
Fuz : ø

Foo
  = Foo
  | Bar Int
  | Baz (String, String)
*  | Biz { name : String, age : Int }*
*  | Buz Fiz*


*  | Boz (Fuz { name : String })*Foo : Foo
Bar : Int -> Foo
Baz : String -> String -> Foo

*Biz : String -> Int -> Foo**Buz : String -> Int -> Foo*




*Boz : String -> Int -> FooDoo a =... *
On Monday, January 16, 2017 at 1:43:02 PM UTC+1, Maxime Dantec wrote:
>
> Thanks for the answers, I had indeed made some poor choices of word in my 
> first email :(
>
> Just before this thread dies, and out of the blue : What if...
>
> - type alias never generates a constructor (change: records do not have 
> ctors)
> - type always generate an "expanded" ctor
>
> expanded as in :
>
> type alias Faz = (Int, Int)
> Faz : ø
>
> type alias Fiz = { name : String, age : Int }
> Fiz : ø
>
> type alias Fuz a = { a | name : String }
> Fuz : ø
>
> type Foo
>   = Foo
>   | Bar Int
>   | Baz (String, String)
> *  | Biz { name : String, age : Int }*
>
> *  | Buz Fiz*
> Foo : Foo
> Bar : Int -> Foo
> Baz : String -> String -> Foo
>
>
> *Biz : String -> Int -> FooBuz : String -> Int -> Foo*
> On Monday, January 16, 2017 at 6:56:52 AM UTC+1, Max Goldstein wrote:
>>
>> * 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

2017-01-16 Thread Maxime Dantec 
Thanks for the answers, I had indeed made some poor choices of word in my 
first email :(

Just before this thread dies, and out of the blue : What if...

- type alias never generates a constructor (change: records do not have 
ctors)
- type always generate an "expanded" ctor

expanded as in :

type alias Faz = (Int, Int)
Faz : ø

type alias Fiz = { name : String, age : Int }
Fiz : ø

type alias Fuz a = { a | name : String }
Fuz : ø

type Foo
  = Foo
  | Bar Int
  | Baz (String, String)
*  | Biz { name : String, age : Int }*

*  | Buz Fiz*
Foo : Foo
Bar : Int -> Foo
Baz : String -> String -> Foo


*Biz : String -> Int -> FooBuz : String -> Int -> Foo*
On Monday, January 16, 2017 at 6:56:52 AM UTC+1, Max Goldstein wrote:
>
> * 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.

[elm-discuss] Re: Guidance for using "type alias" vs. single-constructor union types

2017-01-16 Thread Austin Bingham 
Excellent article, thanks! If their experience reflects the 
state-of-the-art in Elm, then I guess I'm on the right track. I absolutely 
agree with a key sentiment of the article: I'm looking for something with 
the compiler-orientedness of Haskell's newtype. Ignoring the mostly 
superficial wart of needing to un/repacking my types, single-constructor 
unions get me what I need.

On Monday, January 16, 2017 at 11:03:45 AM UTC+1, Magnus Rundberget wrote:
>
> Hi, 
>
> I haven't given it too much though, but I do think there is some very nice 
> benefits to using single constructor union types.
> In you case, you might avoid some of the noise by adding helper functions 
> to work on values of the type (maybe you need a mapFoo helper function).
> I found this blog post quite enlightening : 
> https://robots.thoughtbot.com/lessons-learned-avoiding-primitives-in-elm
>
> cheers
> - magnus
>
>
>
> On Monday, 16 January 2017 09:40:13 UTC+1, Austin Bingham wrote:
>>
>> I recently had to chase down a bug where I was calling a function with 
>> the arguments in the wrong order. The function's declared argument types 
>> were each an alias for string, so the compiler happily let me swap them. In 
>> order to avoid this in the future, I'm experimenting with using 
>> single-constructor union types in place of aliases, e.g. instead of "type 
>> alias Foo = String" I'm using "type Foo = Foo String". 
>>
>> This seems to work well for helping me enforce the kind of type safety 
>> I'm looking for. However, it seems to force me to do a lot more 
>> de/restructuring of function arguments, and it feels a bit graceless. For 
>> example, a (contrived) function that was originally like this:
>>
>> aFunc : Foo -> Foo
>> aFunc f = 
>> let
>> x = somethingWithAString f
>> in
>> somethingWithAFoo x f
>>
>> becomes:
>>
>> aFunc : Foo - > Foo
>> aFunc (Foo f) =
>> let
>> x = somethingWithAString f
>> in
>> -- Have to "repack" f into a Foo
>> somethingWithAFoo x (Foo f)
>>
>> That is, if I want to thread something of type "Foo" through calls while 
>> also using its data, I have to "repack" it.
>>
>> So my question is: are there better ways to do this? Are there better 
>> patterns for a) adding the type-safety I want while b) avoiding the extra 
>> noise? I know some languages (e.g. clojure) let you destructure bindings 
>> *and* bind a name to the un-destructured thing. Something like that might 
>> help.
>>
>> Any advice (including "you're doing it wrong!") would be appreciated.
>>
>> Austin
>>
>

-- 
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: Guidance for using "type alias" vs. single-constructor union types

2017-01-16 Thread Magnus Rundberget 
Hi, 

I haven't given it too much though, but I do think there is some very nice 
benefits to using single constructor union types.
In you case, you might avoid some of the noise by adding helper functions 
to work on values of the type (maybe you need a mapFoo helper function).
I found this blog post quite enlightening : 
https://robots.thoughtbot.com/lessons-learned-avoiding-primitives-in-elm

cheers
- magnus



On Monday, 16 January 2017 09:40:13 UTC+1, Austin Bingham wrote:
>
> I recently had to chase down a bug where I was calling a function with the 
> arguments in the wrong order. The function's declared argument types were 
> each an alias for string, so the compiler happily let me swap them. In 
> order to avoid this in the future, I'm experimenting with using 
> single-constructor union types in place of aliases, e.g. instead of "type 
> alias Foo = String" I'm using "type Foo = Foo String". 
>
> This seems to work well for helping me enforce the kind of type safety I'm 
> looking for. However, it seems to force me to do a lot more 
> de/restructuring of function arguments, and it feels a bit graceless. For 
> example, a (contrived) function that was originally like this:
>
> aFunc : Foo -> Foo
> aFunc f = 
> let
> x = somethingWithAString f
> in
> somethingWithAFoo x f
>
> becomes:
>
> aFunc : Foo - > Foo
> aFunc (Foo f) =
> let
> x = somethingWithAString f
> in
> -- Have to "repack" f into a Foo
> somethingWithAFoo x (Foo f)
>
> That is, if I want to thread something of type "Foo" through calls while 
> also using its data, I have to "repack" it.
>
> So my question is: are there better ways to do this? Are there better 
> patterns for a) adding the type-safety I want while b) avoiding the extra 
> noise? I know some languages (e.g. clojure) let you destructure bindings 
> *and* bind a name to the un-destructured thing. Something like that might 
> help.
>
> Any advice (including "you're doing it wrong!") would be appreciated.
>
> Austin
>

-- 
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] Guidance for using "type alias" vs. single-constructor union types

2017-01-16 Thread Austin Bingham 
I recently had to chase down a bug where I was calling a function with the 
arguments in the wrong order. The function's declared argument types were 
each an alias for string, so the compiler happily let me swap them. In 
order to avoid this in the future, I'm experimenting with using 
single-constructor union types in place of aliases, e.g. instead of "type 
alias Foo = String" I'm using "type Foo = Foo String". 

This seems to work well for helping me enforce the kind of type safety I'm 
looking for. However, it seems to force me to do a lot more 
de/restructuring of function arguments, and it feels a bit graceless. For 
example, a (contrived) function that was originally like this:

aFunc : Foo -> Foo
aFunc f = 
let
x = somethingWithAString f
in
somethingWithAFoo x f

becomes:

aFunc : Foo - > Foo
aFunc (Foo f) =
let
x = somethingWithAString f
in
-- Have to "repack" f into a Foo
somethingWithAFoo x (Foo f)

That is, if I want to thread something of type "Foo" through calls while 
also using its data, I have to "repack" it.

So my question is: are there better ways to do this? Are there better 
patterns for a) adding the type-safety I want while b) avoiding the extra 
noise? I know some languages (e.g. clojure) let you destructure bindings 
*and* bind a name to the un-destructured thing. Something like that might 
help.

Any advice (including "you're doing it wrong!") would be appreciated.

Austin

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