[elm-discuss] Re: Unit Types : A Radical Proposal

[Max Goldstein]

Just be careful with (:::) in particular. Some other libraries already define 
it, and there's currently no good way to resolve conflicts. 

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

[OvermindDL1]

I am curious what people's thoughts are about Elmx?  I looked at it, seemed 
useful, however it seemed lacking due to the fact that it was not quite 
'first class' (and no brunch plugin so I have to run its converter 
manually, though if I did end up using it more I'd probably make such a 
plugin).  Consequently I've been avoiding it but I really like how its 
syntax works as it makes for significantly less work for describing the 
site to our designers here (who look at the Elm syntax and glaze over).  >.>

-- 
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: Multiple uses of `Elm.Xyzzy.embed` in a Phoenix app

[OvermindDL1]

See my answer to just this specific question 
at 
https://elixirforum.com/t/bootstrap-show-hide-operations-do-nothing-in-phoenix-app/1212/21?u=overminddl1
 
if anyone else happens to come by this thread.  :-)

On Friday, July 29, 2016 at 3:42:36 PM UTC-6, Brian Marick wrote:
>
> (A Phoenix newbie here, and an *extreme* Elm newbie.)
>
> There are several Elm + Phoenix examples out there (though most of them 
> for 0.16). However, I haven't found any that should more than one use of 
> `embed`. Just to get started, I'm trying to embed Elm on two pages. On one 
> page, it's just this:
>
>  module FrontPage4Us exposing(..)
>  
>  import Html
>  
>  main : Html.Html a
>  main =
>  Html.text "Consider this text a promise of future beauty"
>
> On a different one, I want to use `Bogdanp/elm-datepicker` with a text 
> field. I can get both to work, sometimes, but never without javascript 
> errors like "There are two Elm modules called DatePicker4Us on this page! 
> Rename one of them".
>
> Any good examples? If not, I will try to both make 
> https://github.com/marick/eecrit an example people can follow, and 
> document the gotchas. 
>
> Thanks.
>

-- 
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] Multiple uses of `Elm.Xyzzy.embed` in a Phoenix app

[Brian Marick]

(A Phoenix newbie here, and an *extreme* Elm newbie.)

There are several Elm + Phoenix examples out there (though most of them for 
0.16). However, I haven't found any that should more than one use of 
`embed`. Just to get started, I'm trying to embed Elm on two pages. On one 
page, it's just this:

 module FrontPage4Us exposing(..)
 
 import Html
 
 main : Html.Html a
 main =
 Html.text "Consider this text a promise of future beauty"

On a different one, I want to use `Bogdanp/elm-datepicker` with a text 
field. I can get both to work, sometimes, but never without javascript 
errors like "There are two Elm modules called DatePicker4Us on this page! 
Rename one of them".

Any good examples? If not, I will try to both 
make https://github.com/marick/eecrit an example people can follow, and 
document the gotchas. 

Thanks.

-- 
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] Compiler fails on port module name in sub-directory

[Duane Johnson]

Hi Gabor, did you ever get this worked out? I'm curious if it's an elm bug.

On Fri, Jul 22, 2016 at 9:40 AM, Gábor Varga  wrote:

> Hello guys,
>
> I have a pretty standard elm project: all my source files are in src and
> under src there are several sub directories for each feature.
> One of those is called Login and it has a Model/Update/View.elm files in
> it as well as 2 port modules: InputPorts and OutputPorts. Now I cannot
> name those port modules in a way the compiler would not complain:
>
> $ elm-make src/main.elm --output build/elm.js --yes --warn
> The module name is messed up for .\./src\Login\OutputPorts.elm
>
> According to the file's name it should be Login.OutputPorts
> According to the source code it should be OutputPorts
>
> Which is it?
>
> *## after renaming it in the "source code" *
> $ elm-make src/main.elm --output build/elm.js --yes --warn
> The module name is messed up for .\./src/Login\OutputPorts.elm
>
> According to the file's name it should be OutputPorts
> According to the source code it should be Login.OutputPorts
>
> Which is it?
>
>
> Any ideas what I am missing?
>
>
> Thanks,
>
> Gabor
>
> --
> 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] How to test JSON decoding when you need a raw Json Value?

[Paul Blair]

Thanks, Duane; that looks promising. I'll try that out.

On Jul 29, 2016, 4:54 PM -0400, Duane Johnson , wrote:
> I wonder if the `json-to-elm` project includes what you're looking for. I see 
> a Types.elm (http://Types.elm) file that includes a toValue function:
>
> > toValue : String -> Json.Value
> > toValue =
> > Native.Types.toValue
>
> And in the Native.Types (http://Native.Types) module, a definition of toValue 
> that uses native javascript:
>
> > var toValue = function(text){
> > try {
> > return JSON.parse(text);
> > } catch (e) {
> > return {};
> > }
> > };
>
>
>
>
> On Fri, Jul 29, 2016 at 2:33 PM, Paul Blair  (mailto:cir...@phobot.net)> wrote:
> > Duane, the dictionary has string keys; its values are just values of a 
> > union type--they are not modules in themselves, but just tags that the case 
> > statement can key on in order to decide on which module to send the message 
> > to.
> >
> > On the second point, the top-level component knows enough about the 
> > incoming message to get the value from the message_type key. The type of 
> > the data field is opaque to the top-level; the top-level just sees it as 
> > Json.Value. This does in fact work; it's just hard to test.
> >
> >
> > On Fri, Jul 29, 2016 at 3:47 PM, Duane Johnson  > (mailto:duane.john...@gmail.com)> wrote:
> > >
> > > On Fri, Jul 29, 2016 at 12:52 PM, Paul Blair  > > (mailto:psfbl...@gmail.com)> wrote:
> > > > toMessage : FromServer -> Message
> > > > toMessage incoming =
> > > > case Dict.get incoming.message_type componentDictionary of
> > > > Just MyInnerComponent ->
> > > > InnerComponentModule.toMessage incoming |> 
> > > > MyInnerComponentMessageWrapper
> > > > Nothing ->
> > > > ...
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > I'm still learning Elm, so forgive that this is not necessarily going to 
> > > be expert advice :)
> > >
> > > My first question is, what is the type of `componentDictionary`? It looks 
> > > to me like it has `String` type keys, but then I don't understand what 
> > > the type signature of the value is. `Maybe type`? How can you match on 
> > > `Just MyInnerComponent`?
> > >
> > > Second question: it seems like the top-level component *must* know 
> > > something about the messages in order to route to subcomponents. Can you 
> > > include a list of json keys in that routing information, so that you can 
> > > pass a narrower scope of data into each subcomponent? It seems like if 
> > > you can, that would make your testing story a lot easier.
> > >
> > > Duane
> > >
> > >
> > >
> > > --
> > > 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/fwDl6deEC1Q/unsubscribe.
> > > To unsubscribe from this group and all its topics, send an email to 
> > > elm-discuss+unsubscr...@googlegroups.com 
> > > (mailto: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 
> > (mailto:elm-discuss+unsubscr...@googlegroups.com).
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> 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/fwDl6deEC1Q/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> elm-discuss+unsubscr...@googlegroups.com 
> (mailto: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] How to test JSON decoding when you need a raw Json Value?

[Duane Johnson]

I wonder if the `json-to-elm` project includes what you're looking for.  I
see a Types.elm file that includes a toValue function:

toValue : String -> Json.Value
> toValue =
> Native.Types.toValue
>

And in the Native.Types module, a definition of toValue that uses native
javascript:

var toValue = function(text){
> try {
> return JSON.parse(text);
> } catch (e) {
> return {};
> }
> };
>




On Fri, Jul 29, 2016 at 2:33 PM, Paul Blair  wrote:

> Duane, the dictionary has string keys; its values are just values of a
> union type--they are not modules in themselves, but just tags that the case
> statement can key on in order to decide on which module to send the message
> to.
>
> On the second point, the top-level component knows enough about the
> incoming message to get the value from the message_type key. The type of
> the data field is opaque to the top-level; the top-level just sees it as
> Json.Value. This does in fact work; it's just hard to test.
>
>
> On Fri, Jul 29, 2016 at 3:47 PM, Duane Johnson 
> wrote:
>
>>
>> On Fri, Jul 29, 2016 at 12:52 PM, Paul Blair  wrote:
>>
>>> toMessage : FromServer -> Message
>>> toMessage incoming =
>>>   case Dict.get incoming.message_type componentDictionary of
>>> Just MyInnerComponent ->
>>>   InnerComponentModule.toMessage incoming |>
>>> MyInnerComponentMessageWrapper
>>> Nothing ->
>>>   ...
>>>
>>
>>
>> I'm still learning Elm, so forgive that this is not necessarily going to
>> be expert advice :)
>>
>> My first question is, what is the type of `componentDictionary`? It looks
>> to me like it has `String` type keys, but then I don't understand what the
>> type signature of the value is. `Maybe type`? How can you match on `Just
>> MyInnerComponent`?
>>
>> Second question: it seems like the top-level component *must* know
>> something about the messages in order to route to subcomponents. Can you
>> include a list of json keys in that routing information, so that you can
>> pass a narrower scope of data into each subcomponent? It seems like if you
>> can, that would make your testing story a lot easier.
>>
>> Duane
>>
>> --
>> 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/fwDl6deEC1Q/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.
>

-- 
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] How to test JSON decoding when you need a raw Json Value?

[Paul Blair]

Duane, the dictionary has string keys; its values are just values of a
union type--they are not modules in themselves, but just tags that the case
statement can key on in order to decide on which module to send the message
to.

On the second point, the top-level component knows enough about the
incoming message to get the value from the message_type key. The type of
the data field is opaque to the top-level; the top-level just sees it as
Json.Value. This does in fact work; it's just hard to test.


On Fri, Jul 29, 2016 at 3:47 PM, Duane Johnson 
wrote:

>
> On Fri, Jul 29, 2016 at 12:52 PM, Paul Blair  wrote:
>
>> toMessage : FromServer -> Message
>> toMessage incoming =
>>   case Dict.get incoming.message_type componentDictionary of
>> Just MyInnerComponent ->
>>   InnerComponentModule.toMessage incoming |>
>> MyInnerComponentMessageWrapper
>> Nothing ->
>>   ...
>>
>
>
> I'm still learning Elm, so forgive that this is not necessarily going to
> be expert advice :)
>
> My first question is, what is the type of `componentDictionary`? It looks
> to me like it has `String` type keys, but then I don't understand what the
> type signature of the value is. `Maybe type`? How can you match on `Just
> MyInnerComponent`?
>
> Second question: it seems like the top-level component *must* know
> something about the messages in order to route to subcomponents. Can you
> include a list of json keys in that routing information, so that you can
> pass a narrower scope of data into each subcomponent? It seems like if you
> can, that would make your testing story a lot easier.
>
> Duane
>
> --
> 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/fwDl6deEC1Q/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: How to test JSON decoding when you need a raw Json Value?

[Paul Blair]

Yes, I can see that. What I was looking for is instead a function that says 
"take the string you give me and give me a Json.Value." 

It looks like my only alternative is instead to create the Json.Value out 
of a complex nested structure of Json.Encode.object, and corresponding Elm 
tuples, lists and primitives. This isn't ideal, since what I want to test 
is the real-world scenario of how my code handles the Json strings that are 
going to be coming in, rather than how it handles an involved construct 
that I hope corresponds to those strings.


On Friday, July 29, 2016 at 3:53:36 PM UTC-4, Joey Eremondi wrote:
>
> To be clear, the problem is that "Json.Encode.string" isn't saying "take 
> the string you give me and parse it into JSON", it's saying "take the 
> string you gave me and make it a JSON String".
>
> On Fri, Jul 29, 2016 at 12:51 PM, Nick H  > wrote:
>
>> You are on the right track with looking in the Json.Encode module. What 
>> you tried in the REPL is almost correct. Try this instead:
>>
>> > foo = Json.Encode.list []
>> > bar = Json.Decode.decodeValue (Json.Decode.list Json.Decode.string)
>>
>> On Fri, Jul 29, 2016 at 12:29 PM, Paul Blair > > wrote:
>>
>>> Spoke too soon; that doesn't work.  For example:
>>>
>>> > foo = Json.Encode.string "[]"
>>> "[]" : Json.Encode.Value
>>>
>>> > bar = Json.Decode.decodeValue (Json.Decode.list Json.Decode.string) 
>>>  foo
>>> Err "Expecting a List but instead got: \"[]\""
>>> : Result.Result String (List String)
>>>
>>>
>>> On Friday, July 29, 2016 at 3:10:01 PM UTC-4, Paul Blair wrote:

 To answer my own question -- it looks like Native.Json has an identity 
 function which does just what I want, but which I can't import. However, 
 it 
 also looks like many of Json.Encode's functions just call 
 Native.Json.identity. So this works:

 data = Encode.string complicatedNestedJson



 On Friday, July 29, 2016 at 2:52:32 PM UTC-4, Paul Blair wrote:
>
> I'm using the nested Elm architecture pattern in an application. The 
> nested components respond to messages coming in on a port. The messages 
> are 
> handled by the top-level component before being handed on to the nested 
> components. So the outer data structure looks something like this:
>
> type alias FromServer =
>   { message_type: MessageType
>   , data: Json.Decode.Value 
>   }
>
> The data field is a Json.Decode.Value because the top-level component 
> doesn't know about the message types defined by the nested components; it 
> does a lookup on the incoming message type and decides to which inner 
> component it will forward the message. So the top level looks like this:
>
> subscriptions : Model.Model -> Sub Message
> subscriptions model =
>   theIncomingPort toMessage
>
>
> toMessage : FromServer -> Message
> toMessage incoming =
>   case Dict.get incoming.message_type componentDictionary of
> Just MyInnerComponent ->
>   InnerComponentModule.toMessage incoming |> 
> MyInnerComponentMessageWrapper
> Nothing ->
>   ...
>
> The inner component's toMessage function also uses the message_type 
> field to choose the decoder to apply to the Json.Decode.Value in the data 
> field.
>
> I want to test the inner component's toMessage function. This means 
> that I need to create a FromServer record with the data contained in a 
> Json.Decode.Value -- ideally created from a Json string.
>
> However, from what I can tell the only way to create this kind of raw 
> Json.Decode.Value is by passing the string in through a port. This seems 
> like a pretty complicated way to set up a test. Is there some other way 
> to 
> accomplish this?
>
> -- 
>>> 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 
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: Collecting use cases for File, ArrayBuffer and TypedArrays/DataViews

[Job van der Zwan]

On Thursday, 28 July 2016 23:17:51 UTC+2, Daniel Bachler wrote:
>
> *TypedArrays and DataViews*
> 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. 
>

Hi, I'm not using Elm yet but thinking about it because I'm bitten by 
undefined variables way to often currently and miss my statically typed 
languages. 

I'm developing for a research group to build a data browser for their 
growing RNA database. Basically, we'll be dealing thousands of cells with a 
arrays of thousands of genes each, and for each gene have an integer value 
representing how much RNA activation was measured, plus a bunch of metadata 
per cell. This data itself is immutable of course, but the plan is to 
on-the-fly render the datavisualisations (with as little rendering as 
possible - we'll probably use  for this).

So a compact way of storing and a fast way of accessing these gene values 
is important. TypedArrays would probably help here.

(also, suggestions on how to best use the canvas element in Elm are 
welcome, since elm-graphics appears more-or-less deprecated, but maybe I 
should open a separate topic for that?)

-- 
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: How to test JSON decoding when you need a raw Json Value?

[Joey Eremondi]

To be clear, the problem is that "Json.Encode.string" isn't saying "take
the string you give me and parse it into JSON", it's saying "take the
string you gave me and make it a JSON String".

On Fri, Jul 29, 2016 at 12:51 PM, Nick H  wrote:

> You are on the right track with looking in the Json.Encode module. What
> you tried in the REPL is almost correct. Try this instead:
>
> > foo = Json.Encode.list []
> > bar = Json.Decode.decodeValue (Json.Decode.list Json.Decode.string)
>
> On Fri, Jul 29, 2016 at 12:29 PM, Paul Blair  wrote:
>
>> Spoke too soon; that doesn't work.  For example:
>>
>> > foo = Json.Encode.string "[]"
>> "[]" : Json.Encode.Value
>>
>> > bar = Json.Decode.decodeValue (Json.Decode.list Json.Decode.string)  foo
>> Err "Expecting a List but instead got: \"[]\""
>> : Result.Result String (List String)
>>
>>
>> On Friday, July 29, 2016 at 3:10:01 PM UTC-4, Paul Blair wrote:
>>>
>>> To answer my own question -- it looks like Native.Json has an identity
>>> function which does just what I want, but which I can't import. However, it
>>> also looks like many of Json.Encode's functions just call
>>> Native.Json.identity. So this works:
>>>
>>> data = Encode.string complicatedNestedJson
>>>
>>>
>>>
>>> On Friday, July 29, 2016 at 2:52:32 PM UTC-4, Paul Blair wrote:

 I'm using the nested Elm architecture pattern in an application. The
 nested components respond to messages coming in on a port. The messages are
 handled by the top-level component before being handed on to the nested
 components. So the outer data structure looks something like this:

 type alias FromServer =
   { message_type: MessageType
   , data: Json.Decode.Value
   }

 The data field is a Json.Decode.Value because the top-level component
 doesn't know about the message types defined by the nested components; it
 does a lookup on the incoming message type and decides to which inner
 component it will forward the message. So the top level looks like this:

 subscriptions : Model.Model -> Sub Message
 subscriptions model =
   theIncomingPort toMessage


 toMessage : FromServer -> Message
 toMessage incoming =
   case Dict.get incoming.message_type componentDictionary of
 Just MyInnerComponent ->
   InnerComponentModule.toMessage incoming |>
 MyInnerComponentMessageWrapper
 Nothing ->
   ...

 The inner component's toMessage function also uses the message_type
 field to choose the decoder to apply to the Json.Decode.Value in the data
 field.

 I want to test the inner component's toMessage function. This means
 that I need to create a FromServer record with the data contained in a
 Json.Decode.Value -- ideally created from a Json string.

 However, from what I can tell the only way to create this kind of raw
 Json.Decode.Value is by passing the string in through a port. This seems
 like a pretty complicated way to set up a test. Is there some other way to
 accomplish this?

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

-- 
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: How to test JSON decoding when you need a raw Json Value?

[Nick H]

You are on the right track with looking in the Json.Encode module. What you
tried in the REPL is almost correct. Try this instead:

> foo = Json.Encode.list []
> bar = Json.Decode.decodeValue (Json.Decode.list Json.Decode.string)

On Fri, Jul 29, 2016 at 12:29 PM, Paul Blair  wrote:

> Spoke too soon; that doesn't work.  For example:
>
> > foo = Json.Encode.string "[]"
> "[]" : Json.Encode.Value
>
> > bar = Json.Decode.decodeValue (Json.Decode.list Json.Decode.string)  foo
> Err "Expecting a List but instead got: \"[]\""
> : Result.Result String (List String)
>
>
> On Friday, July 29, 2016 at 3:10:01 PM UTC-4, Paul Blair wrote:
>>
>> To answer my own question -- it looks like Native.Json has an identity
>> function which does just what I want, but which I can't import. However, it
>> also looks like many of Json.Encode's functions just call
>> Native.Json.identity. So this works:
>>
>> data = Encode.string complicatedNestedJson
>>
>>
>>
>> On Friday, July 29, 2016 at 2:52:32 PM UTC-4, Paul Blair wrote:
>>>
>>> I'm using the nested Elm architecture pattern in an application. The
>>> nested components respond to messages coming in on a port. The messages are
>>> handled by the top-level component before being handed on to the nested
>>> components. So the outer data structure looks something like this:
>>>
>>> type alias FromServer =
>>>   { message_type: MessageType
>>>   , data: Json.Decode.Value
>>>   }
>>>
>>> The data field is a Json.Decode.Value because the top-level component
>>> doesn't know about the message types defined by the nested components; it
>>> does a lookup on the incoming message type and decides to which inner
>>> component it will forward the message. So the top level looks like this:
>>>
>>> subscriptions : Model.Model -> Sub Message
>>> subscriptions model =
>>>   theIncomingPort toMessage
>>>
>>>
>>> toMessage : FromServer -> Message
>>> toMessage incoming =
>>>   case Dict.get incoming.message_type componentDictionary of
>>> Just MyInnerComponent ->
>>>   InnerComponentModule.toMessage incoming |>
>>> MyInnerComponentMessageWrapper
>>> Nothing ->
>>>   ...
>>>
>>> The inner component's toMessage function also uses the message_type
>>> field to choose the decoder to apply to the Json.Decode.Value in the data
>>> field.
>>>
>>> I want to test the inner component's toMessage function. This means that
>>> I need to create a FromServer record with the data contained in a
>>> Json.Decode.Value -- ideally created from a Json string.
>>>
>>> However, from what I can tell the only way to create this kind of raw
>>> Json.Decode.Value is by passing the string in through a port. This seems
>>> like a pretty complicated way to set up a test. Is there some other way to
>>> accomplish this?
>>>
>>> --
> 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] How to test JSON decoding when you need a raw Json Value?

[Duane Johnson]

On Fri, Jul 29, 2016 at 12:52 PM, Paul Blair  wrote:

> toMessage : FromServer -> Message
> toMessage incoming =
>   case Dict.get incoming.message_type componentDictionary of
> Just MyInnerComponent ->
>   InnerComponentModule.toMessage incoming |>
> MyInnerComponentMessageWrapper
> Nothing ->
>   ...
>


I'm still learning Elm, so forgive that this is not necessarily going to be
expert advice :)

My first question is, what is the type of `componentDictionary`? It looks
to me like it has `String` type keys, but then I don't understand what the
type signature of the value is. `Maybe type`? How can you match on `Just
MyInnerComponent`?

Second question: it seems like the top-level component *must* know
something about the messages in order to route to subcomponents. Can you
include a list of json keys in that routing information, so that you can
pass a narrower scope of data into each subcomponent? It seems like if you
can, that would make your testing story a lot easier.

Duane

-- 
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: How to test JSON decoding when you need a raw Json Value?

[Paul Blair]

Spoke too soon; that doesn't work.  For example:

> foo = Json.Encode.string "[]"
"[]" : Json.Encode.Value

> bar = Json.Decode.decodeValue (Json.Decode.list Json.Decode.string)  foo
Err "Expecting a List but instead got: \"[]\""
: Result.Result String (List String)


On Friday, July 29, 2016 at 3:10:01 PM UTC-4, Paul Blair wrote:
>
> To answer my own question -- it looks like Native.Json has an identity 
> function which does just what I want, but which I can't import. However, it 
> also looks like many of Json.Encode's functions just call 
> Native.Json.identity. So this works:
>
> data = Encode.string complicatedNestedJson
>
>
>
> On Friday, July 29, 2016 at 2:52:32 PM UTC-4, Paul Blair wrote:
>>
>> I'm using the nested Elm architecture pattern in an application. The 
>> nested components respond to messages coming in on a port. The messages are 
>> handled by the top-level component before being handed on to the nested 
>> components. So the outer data structure looks something like this:
>>
>> type alias FromServer =
>>   { message_type: MessageType
>>   , data: Json.Decode.Value 
>>   }
>>
>> The data field is a Json.Decode.Value because the top-level component 
>> doesn't know about the message types defined by the nested components; it 
>> does a lookup on the incoming message type and decides to which inner 
>> component it will forward the message. So the top level looks like this:
>>
>> subscriptions : Model.Model -> Sub Message
>> subscriptions model =
>>   theIncomingPort toMessage
>>
>>
>> toMessage : FromServer -> Message
>> toMessage incoming =
>>   case Dict.get incoming.message_type componentDictionary of
>> Just MyInnerComponent ->
>>   InnerComponentModule.toMessage incoming |> 
>> MyInnerComponentMessageWrapper
>> Nothing ->
>>   ...
>>
>> The inner component's toMessage function also uses the message_type field 
>> to choose the decoder to apply to the Json.Decode.Value in the data field.
>>
>> I want to test the inner component's toMessage function. This means that 
>> I need to create a FromServer record with the data contained in a 
>> Json.Decode.Value -- ideally created from a Json string.
>>
>> However, from what I can tell the only way to create this kind of raw 
>> Json.Decode.Value is by passing the string in through a port. This seems 
>> like a pretty complicated way to set up a test. Is there some other way to 
>> accomplish this?
>>
>>

-- 
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: How to test JSON decoding when you need a raw Json Value?

[Paul Blair]

To answer my own question -- it looks like Native.Json has an identity 
function which does just what I want, but which I can't import. However, it 
also looks like many of Json.Encode's functions just call 
Native.Json.identity. So this works:

data = Encode.string complicatedNestedJson



On Friday, July 29, 2016 at 2:52:32 PM UTC-4, Paul Blair wrote:
>
> I'm using the nested Elm architecture pattern in an application. The 
> nested components respond to messages coming in on a port. The messages are 
> handled by the top-level component before being handed on to the nested 
> components. So the outer data structure looks something like this:
>
> type alias FromServer =
>   { message_type: MessageType
>   , data: Json.Decode.Value 
>   }
>
> The data field is a Json.Decode.Value because the top-level component 
> doesn't know about the message types defined by the nested components; it 
> does a lookup on the incoming message type and decides to which inner 
> component it will forward the message. So the top level looks like this:
>
> subscriptions : Model.Model -> Sub Message
> subscriptions model =
>   theIncomingPort toMessage
>
>
> toMessage : FromServer -> Message
> toMessage incoming =
>   case Dict.get incoming.message_type componentDictionary of
> Just MyInnerComponent ->
>   InnerComponentModule.toMessage incoming |> 
> MyInnerComponentMessageWrapper
> Nothing ->
>   ...
>
> The inner component's toMessage function also uses the message_type field 
> to choose the decoder to apply to the Json.Decode.Value in the data field.
>
> I want to test the inner component's toMessage function. This means that I 
> need to create a FromServer record with the data contained in a 
> Json.Decode.Value -- ideally created from a Json string.
>
> However, from what I can tell the only way to create this kind of raw 
> Json.Decode.Value is by passing the string in through a port. This seems 
> like a pretty complicated way to set up a test. Is there some other way to 
> accomplish this?
>
>

-- 
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] How to test JSON decoding when you need a raw Json Value?

[Paul Blair]

I'm using the nested Elm architecture pattern in an application. The nested 
components respond to messages coming in on a port. The messages are 
handled by the top-level component before being handed on to the nested 
components. So the outer data structure looks something like this:

type alias FromServer =
  { message_type: MessageType
  , data: Json.Decode.Value 
  }

The data field is a Json.Decode.Value because the top-level component 
doesn't know about the message types defined by the nested components; it 
does a lookup on the incoming message type and decides to which inner 
component it will forward the message. So the top level looks like this:

subscriptions : Model.Model -> Sub Message
subscriptions model =
  theIncomingPort toMessage


toMessage : FromServer -> Message
toMessage incoming =
  case Dict.get incoming.message_type componentDictionary of
Just MyInnerComponent ->
  InnerComponentModule.toMessage incoming |> 
MyInnerComponentMessageWrapper
Nothing ->
  ...

The inner component's toMessage function also uses the message_type field 
to choose the decoder to apply to the Json.Decode.Value in the data field.

I want to test the inner component's toMessage function. This means that I 
need to create a FromServer record with the data contained in a 
Json.Decode.Value -- ideally created from a Json string.

However, from what I can tell the only way to create this kind of raw 
Json.Decode.Value is by passing the string in through a port. This seems 
like a pretty complicated way to set up a test. Is there some other way to 
accomplish this?

-- 
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: Unit Types : A Radical Proposal

[John Bugner]

Btw, when using (:::) this way, it's nice to set the operator precedence to 
something lower than 9 so you can say `2 * 5 + 3 ::: radians` without 
having to put brackets around the numbers. I think `infix 5 :::` gives the 
right precedence; Looking at the core docs ( 
https://github.com/elm-lang/core/blob/master/src/Basics.elm ), (+) and (-) 
are 6, and (==), (/=), etc are 4.

On Friday, July 29, 2016 at 12:50:24 PM UTC-5, John Bugner wrote:
>
> I like the clever use of the (:::) function to make its function argument 
> (somewhat) look like a type.
>
> On Friday, July 29, 2016 at 11:48:26 AM UTC-5, Anton Lorenzen wrote:
>>
>> I just created a small library for this:
>> https://github.com/anfelor/elm-units
>>
>> It allows for time to be used like this:
>> Units.Time.every (30 ::: milliseconds) Tick
>>
>> Am Donnerstag, 28. Juli 2016 20:42:44 UTC+2 schrieb John Bugner:
>>>
>>> In the time library ( 
>>> package.elm-lang.org/packages/elm-lang/core/4.0.3/Time ), there are 
>>> many functions under the "Units" heading. Under the function `millisecond`, 
>>> it says:
>>> >Units of time, making it easier to specify things like a half-second 
>>> (500 * millisecond) without remembering Elm’s underlying units of time.
>>> I find this underwhelming, because nothing forces me to use these unit 
>>> functions. I could write `every 5 toMsg` and the compiler will not stop me. 
>>> How long of a time am I actually specifying? Probably 5 milliseconds, 
>>> because I infer that it's probably using the same unit as JavaScript, but I 
>>> can't know for sure. A beginner might think 5 seconds, because it's the 
>>> unit that has no prefixes, or 5 minutes if 5 minutes seems appropriate to 
>>> what the application does. This is very bad; There should never be doubt 
>>> about what unit is being used, and the compiler should enforce this unit 
>>> correctness. Currently, Elm can't do this, because `Time` is just an alias 
>>> for `Float`.
>>>
>>> To prevent this kind of error, I propose a new language construct that I 
>>> call a "unit type". It would have the following properties:
>>> (1) A definition that would look (very roughly) like this:
>>> ```
>>> type unit Time as Float
>>> = Second
>>> | Millisecond == Second 0.0001
>>> | Nanosecond == Millisecond 0.0001
>>> | Minute == Second 60
>>> | Hour == Minute 60
>>> | Day == Hour 24
>>> | Year == Day 365
>>> ```
>>>
>>> The point of the definition is to:
>>> (a) Provide an easy way to define different units that measure the same 
>>> thing (in this case, time, but you could do the same thing for 
>>> length/height/depth in either metric or US imperial units) as constructors.
>>> (b) Tell how they are related to eachother. (A minute is 60 seconds, an 
>>> hour is 60 minutes, etc.) The compiler would check that all relations of 
>>> the constructors eventually flow to a single base unit (in this case, 
>>> `Second`). A cycle would be disallowed.
>>> (c) Tell what type the unit is based on (in this case, `Float`). 
>>> (Perhaps non-number types would be disallowed.)
>>>
>>> (2) Given that `every` still has the same signature: `Time -> (Time -> 
>>> msg) -> Sub msg`, `every 5 toMsg` would cause a compile-time error, because 
>>> the types don't match; The function expects a number with a `Time` unit, 
>>> but receives `5`, which is just a raw number (a number without any unit).
>>> (3) When writing a function that has a parameter of type `Time`, pattern 
>>> matching only matches the base unit constructor, not every constructor like 
>>> a normal (data/enum) type. The compiler would automatically convert the 
>>> other units to the base unit with the conversions that the programmer 
>>> provided in the definition.
>>> (4) Comparison, addition, and subtraction would be automatically 
>>> implemented for the type, so two times of any combination of constructors 
>>> could be compared, added, or subtracted with ease. `(Minute 5) - (Second 
>>> 20) == (Millisecond 28)` would "just work". "Time + Float" (or "Time + 
>>> Length") would cause a compile-time error.
>>> (5) Perhaps compound unit types like "Time^2" would be supported, so a 
>>> "Time * Time" would yield "Time^2", "Time * Float" would yield "Time", and 
>>> "Time * Length" would yield just that: "Time * Length". ("Force" would be 
>>> an alias of "Mass * Length / (Second^2)".)
>>>
>>> I know that this is a very radical proposal, (I don't know of any 
>>> language that has a feature like this.) but I bring it up anyways, because 
>>> although it's been 18 years since the mars probe crashed because of a unit 
>>> error (one module assumed that the number it was getting was in metric 
>>> units, and another assumed that it was getting it in US imperial units) ( 
>>> https://en.wikipedia.org/wiki/Mars_Climate_Orbiter ), I'm amazed that 
>>> since then, programming languages have done nothing to prevent this kind of 
>>> error from happening again, besides just admonishing programmers to be 
>>>

[elm-discuss] Re: Unit Types : A Radical Proposal

[John Bugner]

I like the clever use of the (:::) function to make its function argument 
(somewhat) look like a type.

On Friday, July 29, 2016 at 11:48:26 AM UTC-5, Anton Lorenzen wrote:
>
> I just created a small library for this:
> https://github.com/anfelor/elm-units
>
> It allows for time to be used like this:
> Units.Time.every (30 ::: milliseconds) Tick
>
> Am Donnerstag, 28. Juli 2016 20:42:44 UTC+2 schrieb John Bugner:
>>
>> In the time library ( 
>> package.elm-lang.org/packages/elm-lang/core/4.0.3/Time ), there are many 
>> functions under the "Units" heading. Under the function `millisecond`, it 
>> says:
>> >Units of time, making it easier to specify things like a half-second 
>> (500 * millisecond) without remembering Elm’s underlying units of time.
>> I find this underwhelming, because nothing forces me to use these unit 
>> functions. I could write `every 5 toMsg` and the compiler will not stop me. 
>> How long of a time am I actually specifying? Probably 5 milliseconds, 
>> because I infer that it's probably using the same unit as JavaScript, but I 
>> can't know for sure. A beginner might think 5 seconds, because it's the 
>> unit that has no prefixes, or 5 minutes if 5 minutes seems appropriate to 
>> what the application does. This is very bad; There should never be doubt 
>> about what unit is being used, and the compiler should enforce this unit 
>> correctness. Currently, Elm can't do this, because `Time` is just an alias 
>> for `Float`.
>>
>> To prevent this kind of error, I propose a new language construct that I 
>> call a "unit type". It would have the following properties:
>> (1) A definition that would look (very roughly) like this:
>> ```
>> type unit Time as Float
>> = Second
>> | Millisecond == Second 0.0001
>> | Nanosecond == Millisecond 0.0001
>> | Minute == Second 60
>> | Hour == Minute 60
>> | Day == Hour 24
>> | Year == Day 365
>> ```
>>
>> The point of the definition is to:
>> (a) Provide an easy way to define different units that measure the same 
>> thing (in this case, time, but you could do the same thing for 
>> length/height/depth in either metric or US imperial units) as constructors.
>> (b) Tell how they are related to eachother. (A minute is 60 seconds, an 
>> hour is 60 minutes, etc.) The compiler would check that all relations of 
>> the constructors eventually flow to a single base unit (in this case, 
>> `Second`). A cycle would be disallowed.
>> (c) Tell what type the unit is based on (in this case, `Float`). (Perhaps 
>> non-number types would be disallowed.)
>>
>> (2) Given that `every` still has the same signature: `Time -> (Time -> 
>> msg) -> Sub msg`, `every 5 toMsg` would cause a compile-time error, because 
>> the types don't match; The function expects a number with a `Time` unit, 
>> but receives `5`, which is just a raw number (a number without any unit).
>> (3) When writing a function that has a parameter of type `Time`, pattern 
>> matching only matches the base unit constructor, not every constructor like 
>> a normal (data/enum) type. The compiler would automatically convert the 
>> other units to the base unit with the conversions that the programmer 
>> provided in the definition.
>> (4) Comparison, addition, and subtraction would be automatically 
>> implemented for the type, so two times of any combination of constructors 
>> could be compared, added, or subtracted with ease. `(Minute 5) - (Second 
>> 20) == (Millisecond 28)` would "just work". "Time + Float" (or "Time + 
>> Length") would cause a compile-time error.
>> (5) Perhaps compound unit types like "Time^2" would be supported, so a 
>> "Time * Time" would yield "Time^2", "Time * Float" would yield "Time", and 
>> "Time * Length" would yield just that: "Time * Length". ("Force" would be 
>> an alias of "Mass * Length / (Second^2)".)
>>
>> I know that this is a very radical proposal, (I don't know of any 
>> language that has a feature like this.) but I bring it up anyways, because 
>> although it's been 18 years since the mars probe crashed because of a unit 
>> error (one module assumed that the number it was getting was in metric 
>> units, and another assumed that it was getting it in US imperial units) ( 
>> https://en.wikipedia.org/wiki/Mars_Climate_Orbiter ), I'm amazed that 
>> since then, programming languages have done nothing to prevent this kind of 
>> error from happening again, besides just admonishing programmers to be 
>> careful. (As if the NASA programmers at the time weren't already trying to!)
>>
>> Letting `5` be a legal unitless `Time` value is just as silly and 
>> dangerous as letting `bool a = 2;` be a legal statement in C. data/enum 
>> types prevent this from happening to `Bool` in Elm, and unit types could 
>> prevent the same kind of thing from happening to `Time`.
>>
>> Questions, comments, related thoughts, etc are welcome.
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To

Re: [elm-discuss] Re: Unit Types : A Radical Proposal

[Duane Johnson]

On Fri, Jul 29, 2016 at 10:48 AM, Anton Lorenzen  wrote:

> I just created a small library for this:
> https://github.com/anfelor/elm-units
>
> It allows for time to be used like this:
> Units.Time.every (30 ::: milliseconds) Tick
>


Neat! I'm surprised at what can be done with existing syntax and types.

-- 
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: Unit Types : A Radical Proposal

[Anton Lorenzen]

I just created a small library for this:
https://github.com/anfelor/elm-units

It allows for time to be used like this:
Units.Time.every (30 ::: milliseconds) Tick

Am Donnerstag, 28. Juli 2016 20:42:44 UTC+2 schrieb John Bugner:
>
> In the time library ( 
> package.elm-lang.org/packages/elm-lang/core/4.0.3/Time ), there are many 
> functions under the "Units" heading. Under the function `millisecond`, it 
> says:
> >Units of time, making it easier to specify things like a half-second (500 
> * millisecond) without remembering Elm’s underlying units of time.
> I find this underwhelming, because nothing forces me to use these unit 
> functions. I could write `every 5 toMsg` and the compiler will not stop me. 
> How long of a time am I actually specifying? Probably 5 milliseconds, 
> because I infer that it's probably using the same unit as JavaScript, but I 
> can't know for sure. A beginner might think 5 seconds, because it's the 
> unit that has no prefixes, or 5 minutes if 5 minutes seems appropriate to 
> what the application does. This is very bad; There should never be doubt 
> about what unit is being used, and the compiler should enforce this unit 
> correctness. Currently, Elm can't do this, because `Time` is just an alias 
> for `Float`.
>
> To prevent this kind of error, I propose a new language construct that I 
> call a "unit type". It would have the following properties:
> (1) A definition that would look (very roughly) like this:
> ```
> type unit Time as Float
> = Second
> | Millisecond == Second 0.0001
> | Nanosecond == Millisecond 0.0001
> | Minute == Second 60
> | Hour == Minute 60
> | Day == Hour 24
> | Year == Day 365
> ```
>
> The point of the definition is to:
> (a) Provide an easy way to define different units that measure the same 
> thing (in this case, time, but you could do the same thing for 
> length/height/depth in either metric or US imperial units) as constructors.
> (b) Tell how they are related to eachother. (A minute is 60 seconds, an 
> hour is 60 minutes, etc.) The compiler would check that all relations of 
> the constructors eventually flow to a single base unit (in this case, 
> `Second`). A cycle would be disallowed.
> (c) Tell what type the unit is based on (in this case, `Float`). (Perhaps 
> non-number types would be disallowed.)
>
> (2) Given that `every` still has the same signature: `Time -> (Time -> 
> msg) -> Sub msg`, `every 5 toMsg` would cause a compile-time error, because 
> the types don't match; The function expects a number with a `Time` unit, 
> but receives `5`, which is just a raw number (a number without any unit).
> (3) When writing a function that has a parameter of type `Time`, pattern 
> matching only matches the base unit constructor, not every constructor like 
> a normal (data/enum) type. The compiler would automatically convert the 
> other units to the base unit with the conversions that the programmer 
> provided in the definition.
> (4) Comparison, addition, and subtraction would be automatically 
> implemented for the type, so two times of any combination of constructors 
> could be compared, added, or subtracted with ease. `(Minute 5) - (Second 
> 20) == (Millisecond 28)` would "just work". "Time + Float" (or "Time + 
> Length") would cause a compile-time error.
> (5) Perhaps compound unit types like "Time^2" would be supported, so a 
> "Time * Time" would yield "Time^2", "Time * Float" would yield "Time", and 
> "Time * Length" would yield just that: "Time * Length". ("Force" would be 
> an alias of "Mass * Length / (Second^2)".)
>
> I know that this is a very radical proposal, (I don't know of any language 
> that has a feature like this.) but I bring it up anyways, because although 
> it's been 18 years since the mars probe crashed because of a unit error 
> (one module assumed that the number it was getting was in metric units, and 
> another assumed that it was getting it in US imperial units) ( 
> https://en.wikipedia.org/wiki/Mars_Climate_Orbiter ), I'm amazed that 
> since then, programming languages have done nothing to prevent this kind of 
> error from happening again, besides just admonishing programmers to be 
> careful. (As if the NASA programmers at the time weren't already trying to!)
>
> Letting `5` be a legal unitless `Time` value is just as silly and 
> dangerous as letting `bool a = 2;` be a legal statement in C. data/enum 
> types prevent this from happening to `Bool` in Elm, and unit types could 
> prevent the same kind of thing from happening to `Time`.
>
> Questions, comments, related thoughts, etc are welcome.
>
>

-- 
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: Search Selection widget

[Zeljko Nesic]

Sorry, for being unclear and imprecise. 

I have tried to implement that behavior, but it seems that there is no neat 
way to do it. I have searched elm-discuss, and even though many wanted 
feature that will enable this kind of things, it seems there is no clear 
way to do it.

I can imagine some workarounds, but I believe anything would be wonky with 
out ability to dynamically pass event options. 

Again, sorry for being miss leading :)

-- 
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: Unit Types : A Radical Proposal

[Max Goldstein]

Here's another piece of prior art, Frink:

http://futureboy.us/frinkdocs/

Also, have you considered that floating point arithmetic might totally screw 
things up, especially with angles where irrational numbers are involved?

+1 for experimenting with the types we already have. 

-- 
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: Unit Types : A Radical Proposal

[OvermindDL1]

Yep, that is why I like the style that you can do with current code.  :-)

On Friday, July 29, 2016 at 6:35:46 AM UTC-6, John Bugner wrote:
>
> Also, thinking about this further, any definition of conversions between 
> types is probably best expressed as a function, because a conversion is not 
> always a simple multiple (like 1 yard = 3 feet). Take, for example, the 
> conversion between degrees celsius and degrees fahrenheit. (Note that if 
> `Temp` was a unit type, it's "base" unit should be Kelvin (or Rankine, I 
> suppose.), because Kelvin starts at 0, which lets multiplying temperatures 
> by a raw number make sense.)
>
> On Friday, July 29, 2016 at 7:11:19 AM UTC-5, John Bugner wrote:
>>
>> >This would be a nice fix to the Radians / Degrees issue too. Every 
>> language seems to settle on one or the other as "the base unit" but 
>> newcomers have to learn the assumption or face bad accidental outputs.
>> Yes, `degrees`, `radians`, and `turns` in `Basics` suffer the same 
>> problem.
>>
>> >F# is kind of radical in that it has units.
>> I didn't know this! (I have heard of F#, but I had never used or read 
>> some of its code.) It pleases me to know that I'm not the only one to think 
>> that is a problem, and that it can be solved by this solution! (F#'s 
>> implementation seems slightly different from what I am imagining, but close 
>> enough.)
>>
>> I'm curious though, does F# use its unit/measure types widely? or do 
>> common library functions (like those about time, angles, etc) still take a 
>> raw float type where it could take a unit/measure float type? How often do 
>> common 3rd-party libraries use this feature? How often do average-joe 
>> programmers use this feature?
>>
>> >Could possible do it 'now' with
>> >...
>> >If you do not expose the constructor of the type then it should be a 
>> fully opaque type, only able to be constructed via things like 
>> `milliseconds 500` or so.
>> As a work-around that uses only current features, I like this. It's an 
>> improvement over the current system of just having `Time` be an alias of 
>> `Float`. (Heck, `Angle` isn't even an alias! The angle functions' 
>> signatures are just `Float -> Float`!)
>>
>> On Thursday, July 28, 2016 at 3:13:27 PM UTC-5, OvermindDL1 wrote:
>>>
>>> Could possible do it 'now' with
>>>
>>> ```elm
>>> type Time
>>>   = Time_Value Float
>>>
>>> milliseconds m = seconds <| m/1000
>>>
>>> seconds s = Time_Value s
>>>
>>> minutes m = seconds <| m*60
>>>
>>> from_json json =
>>>   Json.Decode.decodeString Json.Decode.float json |> Result.map (\t -> 
>>> Time_Value t)
>>>
>>> to_seconds (Time_Value t) = t
>>>
>>> to_minutes t = 60 * (to_seconds t)
>>>
>>> to_json t = Json.Encode.float <| to_seconds t
>>> ```
>>>
>>> If you do not expose the constructor of the type then it should be a 
>>> fully opaque type, only able to be constructed via things like 
>>> `milliseconds 500` or so.
>>>
>>>
>>> On Thursday, July 28, 2016 at 12:42:44 PM UTC-6, John Bugner wrote:

 In the time library ( 
 package.elm-lang.org/packages/elm-lang/core/4.0.3/Time ), there are 
 many functions under the "Units" heading. Under the function 
 `millisecond`, 
 it says:
 >Units of time, making it easier to specify things like a half-second 
 (500 * millisecond) without remembering Elm’s underlying units of time.
 I find this underwhelming, because nothing forces me to use these unit 
 functions. I could write `every 5 toMsg` and the compiler will not stop 
 me. 
 How long of a time am I actually specifying? Probably 5 milliseconds, 
 because I infer that it's probably using the same unit as JavaScript, but 
 I 
 can't know for sure. A beginner might think 5 seconds, because it's the 
 unit that has no prefixes, or 5 minutes if 5 minutes seems appropriate to 
 what the application does. This is very bad; There should never be doubt 
 about what unit is being used, and the compiler should enforce this unit 
 correctness. Currently, Elm can't do this, because `Time` is just an alias 
 for `Float`.

 To prevent this kind of error, I propose a new language construct that 
 I call a "unit type". It would have the following properties:
 (1) A definition that would look (very roughly) like this:
 ```
 type unit Time as Float
 = Second
 | Millisecond == Second 0.0001
 | Nanosecond == Millisecond 0.0001
 | Minute == Second 60
 | Hour == Minute 60
 | Day == Hour 24
 | Year == Day 365
 ```

 The point of the definition is to:
 (a) Provide an easy way to define different units that measure the same 
 thing (in this case, time, but you could do the same thing for 
 length/height/depth in either metric or US imperial units) as constructors.
 (b) Tell how they are related to eachother. (A minute is 60 seconds, an 
 hour is 60 minutes, etc.) The compiler would check that all relatio

[elm-discuss] Re: Unit Types : A Radical Proposal

[John Bugner]

Also, thinking about this further, any definition of conversions between 
types is probably best expressed as a function, because a conversion is not 
always a simple multiple (like 1 yard = 3 feet). Take, for example, the 
conversion between degrees celsius and degrees fahrenheit. (Note that if 
`Temp` was a unit type, it's "base" unit should be Kelvin (or Rankine, I 
suppose.), because Kelvin starts at 0, which lets multiplying temperatures 
by a raw number make sense.)

On Friday, July 29, 2016 at 7:11:19 AM UTC-5, John Bugner wrote:
>
> >This would be a nice fix to the Radians / Degrees issue too. Every 
> language seems to settle on one or the other as "the base unit" but 
> newcomers have to learn the assumption or face bad accidental outputs.
> Yes, `degrees`, `radians`, and `turns` in `Basics` suffer the same problem.
>
> >F# is kind of radical in that it has units.
> I didn't know this! (I have heard of F#, but I had never used or read some 
> of its code.) It pleases me to know that I'm not the only one to think that 
> is a problem, and that it can be solved by this solution! (F#'s 
> implementation seems slightly different from what I am imagining, but close 
> enough.)
>
> I'm curious though, does F# use its unit/measure types widely? or do 
> common library functions (like those about time, angles, etc) still take a 
> raw float type where it could take a unit/measure float type? How often do 
> common 3rd-party libraries use this feature? How often do average-joe 
> programmers use this feature?
>
> >Could possible do it 'now' with
> >...
> >If you do not expose the constructor of the type then it should be a 
> fully opaque type, only able to be constructed via things like 
> `milliseconds 500` or so.
> As a work-around that uses only current features, I like this. It's an 
> improvement over the current system of just having `Time` be an alias of 
> `Float`. (Heck, `Angle` isn't even an alias! The angle functions' 
> signatures are just `Float -> Float`!)
>
> On Thursday, July 28, 2016 at 3:13:27 PM UTC-5, OvermindDL1 wrote:
>>
>> Could possible do it 'now' with
>>
>> ```elm
>> type Time
>>   = Time_Value Float
>>
>> milliseconds m = seconds <| m/1000
>>
>> seconds s = Time_Value s
>>
>> minutes m = seconds <| m*60
>>
>> from_json json =
>>   Json.Decode.decodeString Json.Decode.float json |> Result.map (\t -> 
>> Time_Value t)
>>
>> to_seconds (Time_Value t) = t
>>
>> to_minutes t = 60 * (to_seconds t)
>>
>> to_json t = Json.Encode.float <| to_seconds t
>> ```
>>
>> If you do not expose the constructor of the type then it should be a 
>> fully opaque type, only able to be constructed via things like 
>> `milliseconds 500` or so.
>>
>>
>> On Thursday, July 28, 2016 at 12:42:44 PM UTC-6, John Bugner wrote:
>>>
>>> In the time library ( 
>>> package.elm-lang.org/packages/elm-lang/core/4.0.3/Time ), there are 
>>> many functions under the "Units" heading. Under the function `millisecond`, 
>>> it says:
>>> >Units of time, making it easier to specify things like a half-second 
>>> (500 * millisecond) without remembering Elm’s underlying units of time.
>>> I find this underwhelming, because nothing forces me to use these unit 
>>> functions. I could write `every 5 toMsg` and the compiler will not stop me. 
>>> How long of a time am I actually specifying? Probably 5 milliseconds, 
>>> because I infer that it's probably using the same unit as JavaScript, but I 
>>> can't know for sure. A beginner might think 5 seconds, because it's the 
>>> unit that has no prefixes, or 5 minutes if 5 minutes seems appropriate to 
>>> what the application does. This is very bad; There should never be doubt 
>>> about what unit is being used, and the compiler should enforce this unit 
>>> correctness. Currently, Elm can't do this, because `Time` is just an alias 
>>> for `Float`.
>>>
>>> To prevent this kind of error, I propose a new language construct that I 
>>> call a "unit type". It would have the following properties:
>>> (1) A definition that would look (very roughly) like this:
>>> ```
>>> type unit Time as Float
>>> = Second
>>> | Millisecond == Second 0.0001
>>> | Nanosecond == Millisecond 0.0001
>>> | Minute == Second 60
>>> | Hour == Minute 60
>>> | Day == Hour 24
>>> | Year == Day 365
>>> ```
>>>
>>> The point of the definition is to:
>>> (a) Provide an easy way to define different units that measure the same 
>>> thing (in this case, time, but you could do the same thing for 
>>> length/height/depth in either metric or US imperial units) as constructors.
>>> (b) Tell how they are related to eachother. (A minute is 60 seconds, an 
>>> hour is 60 minutes, etc.) The compiler would check that all relations of 
>>> the constructors eventually flow to a single base unit (in this case, 
>>> `Second`). A cycle would be disallowed.
>>> (c) Tell what type the unit is based on (in this case, `Float`). 
>>> (Perhaps non-number types would be disallowed.)
>>>
>>> (2) Given that `every` 

[elm-discuss] Re: Unit Types : A Radical Proposal

[John Bugner]

>This would be a nice fix to the Radians / Degrees issue too. Every 
language seems to settle on one or the other as "the base unit" but 
newcomers have to learn the assumption or face bad accidental outputs.
Yes, `degrees`, `radians`, and `turns` in `Basics` suffer the same problem.

>F# is kind of radical in that it has units.
I didn't know this! (I have heard of F#, but I had never used or read some 
of its code.) It pleases me to know that I'm not the only one to think that 
is a problem, and that it can be solved by this solution! (F#'s 
implementation seems slightly different from what I am imagining, but close 
enough.)

I'm curious though, does F# use its unit/measure types widely? or do common 
library functions (like those about time, angles, etc) still take a raw 
float type where it could take a unit/measure float type? How often do 
common 3rd-party libraries use this feature? How often do average-joe 
programmers use this feature?

>Could possible do it 'now' with
>...
>If you do not expose the constructor of the type then it should be a fully 
opaque type, only able to be constructed via things like `milliseconds 500` 
or so.
As a work-around that uses only current features, I like this. It's an 
improvement over the current system of just having `Time` be an alias of 
`Float`. (Heck, `Angle` isn't even an alias! The angle functions' 
signatures are just `Float -> Float`!)

On Thursday, July 28, 2016 at 3:13:27 PM UTC-5, OvermindDL1 wrote:
>
> Could possible do it 'now' with
>
> ```elm
> type Time
>   = Time_Value Float
>
> milliseconds m = seconds <| m/1000
>
> seconds s = Time_Value s
>
> minutes m = seconds <| m*60
>
> from_json json =
>   Json.Decode.decodeString Json.Decode.float json |> Result.map (\t -> 
> Time_Value t)
>
> to_seconds (Time_Value t) = t
>
> to_minutes t = 60 * (to_seconds t)
>
> to_json t = Json.Encode.float <| to_seconds t
> ```
>
> If you do not expose the constructor of the type then it should be a fully 
> opaque type, only able to be constructed via things like `milliseconds 500` 
> or so.
>
>
> On Thursday, July 28, 2016 at 12:42:44 PM UTC-6, John Bugner wrote:
>>
>> In the time library ( 
>> package.elm-lang.org/packages/elm-lang/core/4.0.3/Time ), there are many 
>> functions under the "Units" heading. Under the function `millisecond`, it 
>> says:
>> >Units of time, making it easier to specify things like a half-second 
>> (500 * millisecond) without remembering Elm’s underlying units of time.
>> I find this underwhelming, because nothing forces me to use these unit 
>> functions. I could write `every 5 toMsg` and the compiler will not stop me. 
>> How long of a time am I actually specifying? Probably 5 milliseconds, 
>> because I infer that it's probably using the same unit as JavaScript, but I 
>> can't know for sure. A beginner might think 5 seconds, because it's the 
>> unit that has no prefixes, or 5 minutes if 5 minutes seems appropriate to 
>> what the application does. This is very bad; There should never be doubt 
>> about what unit is being used, and the compiler should enforce this unit 
>> correctness. Currently, Elm can't do this, because `Time` is just an alias 
>> for `Float`.
>>
>> To prevent this kind of error, I propose a new language construct that I 
>> call a "unit type". It would have the following properties:
>> (1) A definition that would look (very roughly) like this:
>> ```
>> type unit Time as Float
>> = Second
>> | Millisecond == Second 0.0001
>> | Nanosecond == Millisecond 0.0001
>> | Minute == Second 60
>> | Hour == Minute 60
>> | Day == Hour 24
>> | Year == Day 365
>> ```
>>
>> The point of the definition is to:
>> (a) Provide an easy way to define different units that measure the same 
>> thing (in this case, time, but you could do the same thing for 
>> length/height/depth in either metric or US imperial units) as constructors.
>> (b) Tell how they are related to eachother. (A minute is 60 seconds, an 
>> hour is 60 minutes, etc.) The compiler would check that all relations of 
>> the constructors eventually flow to a single base unit (in this case, 
>> `Second`). A cycle would be disallowed.
>> (c) Tell what type the unit is based on (in this case, `Float`). (Perhaps 
>> non-number types would be disallowed.)
>>
>> (2) Given that `every` still has the same signature: `Time -> (Time -> 
>> msg) -> Sub msg`, `every 5 toMsg` would cause a compile-time error, because 
>> the types don't match; The function expects a number with a `Time` unit, 
>> but receives `5`, which is just a raw number (a number without any unit).
>> (3) When writing a function that has a parameter of type `Time`, pattern 
>> matching only matches the base unit constructor, not every constructor like 
>> a normal (data/enum) type. The compiler would automatically convert the 
>> other units to the base unit with the conversions that the programmer 
>> provided in the definition.
>> (4) Comparison, addition, and subtraction would b

[elm-discuss] Re: programWithFlags for App using elm-mdl

[Robert Walter]

A better way to this is to use Maybe_s:

main : Program (Maybe Flags)
main =
App.programWithFlags
{ init = init
, view = view
, update = update
, subscriptions = subscriptions
}




init : Maybe Flags -> ( AppState, Cmd Msg )
init maybeFlags =
let
appStateInit =
case maybeFlags of
Nothing ->
defaultAppState


Maybe.Just flags ->
appStateFromFlags flags
in
( appStateInit, Layout.sub0 Mdl )


On Friday, July 29, 2016 at 1:29:58 PM UTC+2, Robert Walter wrote:
>
> Oh man, I just found that out as well. Thank you.
>
> So, I changed it like so:
>
> type alias AppState =
> { mdl : Material.Model
> , viewSelected : Int
> , ...
> , titleEditable : Bool
> , refreshEditorContent : Bool
> }
>
> type alias Flags =
> { viewSelected : Int
> , ...
> , titleEditable : Bool
> , refreshEditorContent : Bool
> }
>
> init : Flags -> ( AppState, Cmd Msg )
> init flags =
> ( defaultOrFromFlags flags, Layout.sub0 Mdl )
>
> Thanks again!
>
>
> On Friday, July 29, 2016 at 1:25:48 PM UTC+2, Sergey Skrynnikov wrote:
>>
>> Hi Robert,
>>
>> your flags don't have to be of the same type as the model - try modifying 
>> your 'init' function to take only your partial state and return (Model, Cmd 
>> Msg).
>>
>> пятница, 29 июля 2016 г., 14:14:39 UTC+3 пользователь Robert Walter 
>> написал:
>>>
>>> Hello,
>>>
>>> I try to initialize my elm application using programWithFlags.
>>>
>>> My app makes use of elm-mdl, so my model looks something like this:
>>>
>>> type alias AppState =
>>> { mdl : Material.Model
>>> , viewSelected : Int
>>> , ...
>>> , titleEditable : Bool
>>> , refreshEditorContent : Bool
>>> }
>>>
>>> In other words, it contains a Material.Model that I need to make proper 
>>> use of elm-mdl.
>>>
>>> When I try to use App.programWithFlags, however, having Material.Model 
>>> in my AppState leads to the following error:
>>>
>>>
>>> -- BAD FLAGS --- 
>>> src/App.elm
>>> Your `main` is demanding an unsupported type as a flag.
>>> 68| main =
>>> 
>>> The specific unsupported type is:
>>> Dict.Dict
>>> (List Int)
>>> { animation : Material.Ripple.Animation
>>> , ignoringMouseDown : Bool
>>> , metrics :
>>>   Maybe
>>>   { rect :
>>> { height : Float
>>> , left : Float
>>> , top : Float
>>> , width : Float
>>> }
>>>   , x : Float
>>>   , y : Float
>>>   }
>>> }
>>> The types of values that can flow through in and out of Elm include:
>>> Ints, Floats, Bools, Strings, Maybes, Lists, Arrays, Tuples, 
>>> Json.Values,
>>> and concrete records.
>>>
>>>
>>> Currently, I use localStorage to store my AppState partially (I do not 
>>> encode 'mdl'). I don't see how I can make this work, however, since I 
>>> assume that programWithFlags can only decode the types mentioned in the BAD 
>>> FLAGS message and it expects to receive a completely serialized AppState.
>>>
>>> Any suggestions from the coomunity?
>>>
>>> Thanks,
>>> Robert
>>>
>>>
>>>

-- 
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: programWithFlags for App using elm-mdl

[Robert Walter]

Oh man, I just found that out as well. Thank you.

So, I changed it like so:

type alias AppState =
{ mdl : Material.Model
, viewSelected : Int
, ...
, titleEditable : Bool
, refreshEditorContent : Bool
}

type alias Flags =
{ viewSelected : Int
, ...
, titleEditable : Bool
, refreshEditorContent : Bool
}

init : Flags -> ( AppState, Cmd Msg )
init flags =
( defaultOrFromFlags flags, Layout.sub0 Mdl )

Thanks again!


On Friday, July 29, 2016 at 1:25:48 PM UTC+2, Sergey Skrynnikov wrote:
>
> Hi Robert,
>
> your flags don't have to be of the same type as the model - try modifying 
> your 'init' function to take only your partial state and return (Model, Cmd 
> Msg).
>
> пятница, 29 июля 2016 г., 14:14:39 UTC+3 пользователь Robert Walter 
> написал:
>>
>> Hello,
>>
>> I try to initialize my elm application using programWithFlags.
>>
>> My app makes use of elm-mdl, so my model looks something like this:
>>
>> type alias AppState =
>> { mdl : Material.Model
>> , viewSelected : Int
>> , ...
>> , titleEditable : Bool
>> , refreshEditorContent : Bool
>> }
>>
>> In other words, it contains a Material.Model that I need to make proper 
>> use of elm-mdl.
>>
>> When I try to use App.programWithFlags, however, having Material.Model in 
>> my AppState leads to the following error:
>>
>>
>> -- BAD FLAGS --- 
>> src/App.elm
>> Your `main` is demanding an unsupported type as a flag.
>> 68| main =
>> 
>> The specific unsupported type is:
>> Dict.Dict
>> (List Int)
>> { animation : Material.Ripple.Animation
>> , ignoringMouseDown : Bool
>> , metrics :
>>   Maybe
>>   { rect :
>> { height : Float
>> , left : Float
>> , top : Float
>> , width : Float
>> }
>>   , x : Float
>>   , y : Float
>>   }
>> }
>> The types of values that can flow through in and out of Elm include:
>> Ints, Floats, Bools, Strings, Maybes, Lists, Arrays, Tuples, 
>> Json.Values,
>> and concrete records.
>>
>>
>> Currently, I use localStorage to store my AppState partially (I do not 
>> encode 'mdl'). I don't see how I can make this work, however, since I 
>> assume that programWithFlags can only decode the types mentioned in the BAD 
>> FLAGS message and it expects to receive a completely serialized AppState.
>>
>> Any suggestions from the coomunity?
>>
>> Thanks,
>> Robert
>>
>>
>>

-- 
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: Is there a way to investigate a Html tree?

[Peter Damoc]

Hi Yousuke,

This looks like something I could use to inspect for classes. Thank you!
I will investigate further.



On Thu, Jul 28, 2016 at 6:56 PM, Yosuke Torii  wrote:

> Recently I wrote a little parser for `toString` representation.
>
>
> https://github.com/jinjor/elm-time-travel/blob/master/src/TimeTravel/Internal/Parser/Parser.elm
>
> It turns
> toString <| div [] [ input [ type' "text", class "foo", onClick 1 ] [],
> text "hello" ]
>
> into
> Record ([Property "type" (StringLiteral "node"),Property "tag" (
> StringLiteral "div"),Property "facts" (Record []),Property "children" (
> Record ([Property "0" (Record ([Property "type" (StringLiteral "node"),
> Property "tag" (StringLiteral "input"),Property "facts" (Record ([Property
> "type" (StringLiteral "text"),Property "className" (StringLiteral "foo"),
> Property "EVENT" (Record ([Property "click" (Record ([Property "options" (
> Record ([Property "stopPropagation" (Union "False" []),Property
> "preventDefault" (Union "False" [])])),Property "decoder" (Value
> "")]))]))])),Property "children" (Record []),Property "namespace"
> (Value ""),Property "descendantsCount" (Value "0")])),
> Property "1" (Record ([Property "type" (StringLiteral "text"),Property
> "text" (StringLiteral "hello")]))])),Property "namespace" (Value " structure>"),Property "descendantsCount" (Value "2")])
>
> Peter, is this close to what you want to do?
>
>
> 2016年7月28日木曜日 18時21分58秒 UTC+9 Peter Damoc:
>
>> I need to gather all the class names used in a Html tree generated by the
>> app.
>>
>> Is there a way to do this short of converting the html to a string and
>> manually parsing it?
>>
>>
>>
>>
>>
>> --
>> 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.
>



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

[elm-discuss] Re: programWithFlags for App using elm-mdl

[Sergey Skrynnikov]

Hi Robert,

your flags don't have to be of the same type as the model - try modifying 
your 'init' function to take only your partial state and return (Model, Cmd 
Msg).

пятница, 29 июля 2016 г., 14:14:39 UTC+3 пользователь Robert Walter написал:
>
> Hello,
>
> I try to initialize my elm application using programWithFlags.
>
> My app makes use of elm-mdl, so my model looks something like this:
>
> type alias AppState =
> { mdl : Material.Model
> , viewSelected : Int
> , ...
> , titleEditable : Bool
> , refreshEditorContent : Bool
> }
>
> In other words, it contains a Material.Model that I need to make proper 
> use of elm-mdl.
>
> When I try to use App.programWithFlags, however, having Material.Model in 
> my AppState leads to the following error:
>
>
> -- BAD FLAGS --- 
> src/App.elm
> Your `main` is demanding an unsupported type as a flag.
> 68| main =
> 
> The specific unsupported type is:
> Dict.Dict
> (List Int)
> { animation : Material.Ripple.Animation
> , ignoringMouseDown : Bool
> , metrics :
>   Maybe
>   { rect :
> { height : Float
> , left : Float
> , top : Float
> , width : Float
> }
>   , x : Float
>   , y : Float
>   }
> }
> The types of values that can flow through in and out of Elm include:
> Ints, Floats, Bools, Strings, Maybes, Lists, Arrays, Tuples, 
> Json.Values,
> and concrete records.
>
>
> Currently, I use localStorage to store my AppState partially (I do not 
> encode 'mdl'). I don't see how I can make this work, however, since I 
> assume that programWithFlags can only decode the types mentioned in the BAD 
> FLAGS message and it expects to receive a completely serialized AppState.
>
> Any suggestions from the coomunity?
>
> Thanks,
> Robert
>
>
>

-- 
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] programWithFlags for App using elm-mdl

[Robert Walter]

Hello,

I try to initialize my elm application using programWithFlags.

My app makes use of elm-mdl, so my model looks something like this:

type alias AppState =
{ mdl : Material.Model
, viewSelected : Int
, ...
, titleEditable : Bool
, refreshEditorContent : Bool
}

In other words, it contains a Material.Model that I need to make proper use 
of elm-mdl.

When I try to use App.programWithFlags, however, having Material.Model in 
my AppState leads to the following error:


-- BAD FLAGS --- 
src/App.elm
Your `main` is demanding an unsupported type as a flag.
68| main =

The specific unsupported type is:
Dict.Dict
(List Int)
{ animation : Material.Ripple.Animation
, ignoringMouseDown : Bool
, metrics :
  Maybe
  { rect :
{ height : Float
, left : Float
, top : Float
, width : Float
}
  , x : Float
  , y : Float
  }
}
The types of values that can flow through in and out of Elm include:
Ints, Floats, Bools, Strings, Maybes, Lists, Arrays, Tuples, 
Json.Values,
and concrete records.


Currently, I use localStorage to store my AppState partially (I do not 
encode 'mdl'). I don't see how I can make this work, however, since I 
assume that programWithFlags can only decode the types mentioned in the BAD 
FLAGS message and it expects to receive a completely serialized AppState.

Any suggestions from the coomunity?

Thanks,
Robert


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

[Peter Damoc]

I need to upload user avatar image and company logo. :)

On Fri, Jul 29, 2016 at 11:54 AM, Michael B  wrote:

> ..and it's for an audio programming language, so the ability to read and
> write binary data would be fantastic.
>
> --
> 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.
>



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

[elm-discuss] Re: Form with union type

[Simone Vittori]

Oh I see! Makes totally sense :)

Thank you very much!

On Thursday, 28 July 2016 17:32:13 UTC+1, Yosuke Torii wrote:
>
> Hi Simone,
>
> I wrote the fixed version here 
>  (copy & 
> paste to Try Elm ).
> Union type was not wrong. The `on` function assumes an event object to be 
> decoded, but you expect a string.
> So I used `targetValue` decoder, which is a shortcut for `e.target.value`.
>
>
> 2016年7月28日木曜日 0時25分46秒 UTC+9 Simone Vittori:
>>
>> I'm building a language selector and I'd like to map the options to a 
>> union type.
>>
>> Here's what I tried:
>>
>> import Json.Decode exposing (Decoder, customDecoder, string)
>>
>> {-| Currently supported languages. -}
>> type Language
>> = English
>> | Japanese
>>
>>
>> {-| A JSON decoder of Language. -}
>> languageDecoder : Decoder Language
>> languageDecoder =
>> customDecoder string fromStringLanguage
>>
>>
>> fromStringLanguage : String -> Result String Language
>> fromStringLanguage str =
>> case str of
>> "English" -> Ok English
>> "Japanese" -> Ok Japanese
>> other -> Err ("Invalid language: " ++ other)
>>
>> And here's how I'm using it:
>>
>> -- MODEL
>>
>> type alias Model = Language
>>
>>
>> -- UPDATE
>>
>> type Msg
>> = Change Language
>>
>> update : Msg -> Model -> Model
>> update msg model =
>> case msg of
>> Change language -> language
>>
>>
>> -- VIEW
>>
>> view : Model -> Html Msg
>> view model =
>> Html.form []
>> [ select [ on "change" <| Json.Decode.map Change languageDecoder ]
>> (List.map (viewOption model) ["English", "Japanese"])
>> ]
>>
>> It does compile successfully, but when I select another option from the 
>> dropdown list, nothing happens. Any ideas?
>> Is this the right way of decoding a union type?
>>
>

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

[Michael B]

..and it's for an audio programming language, so the ability to read and write 
binary data would be fantastic.

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

[Michael B]

I'm making a browser based IDE, so support for the FileReader API is essential 
for opening local files.

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

[John Watson]

Hi, Daniel,  thanks for starting this off.  One thing I'd like to add:

*Binary Base64 decoders.*

These could obviously be for any binary resource that is smuggled into elm 
as text.  In my case I need to reconstitute soundfonts that are available 
as base64 encoded resources embedded in JSON.

I'm mainly interested in web-audio.  It seems to me if ever Evan (or 
somebody) gets round to doing elm-lang/web-audio, then binary types will be 
needed.  And I really would like access to web-audio (and web-midi) by 
means of a core elm library.   

On Thursday, 28 July 2016 22:17:51 UTC+1, 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.