[elm-discuss] Re: [ANN] elm-mdl 7.0.0 — supports all components of Material Design Lite

[debois]

Dear all, 

We've just released 7.6.0, adding upstream's new Chip component (courtesy 
of @vippenti). 7.6.0 also contains performance improvements and a host of 
bugfixes. Enjoy!

- Live demo 
- Release notes 
- Package 
- Github 

We have a lot of work in front of us improving existing components, 
implementing more components from the Material Design spec 
, and integrating recent advances in core 
. If you're 
interested in contributing, look me up (@debois) on the elm-slack.

Cheers,

Søren

-- 
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] Building a UI component library: the Elm compiler

[suttlecommakevin]

*Forgive me if I have missed something or am asking about something that's 
been reposted frequently.*

Let's use a simple example: a custom set of SVG icons, for use in Buttons.
Here are my rookie questions:

*Is the Elm compiler: *

   1. aware of ES6 modules? 
   - asking this because I'm not sure how one would consume these in an 
  otherwise Elm-unaware env. 
  2. able to do code splitting? 
  - The use case here being: I don't want a user to have to download 
  100 SVG icons in one JS file if there are only 3 being used on a page.
   3. able to do hot reloading?
  - Just curious here
   4. ready to start supporting CSS as a 1st class-citizen? 
  - Seems like if Elm is the front-end language of the future, it can't 
  be missing 1/3 of the stack. 
  - I am aware of Richard and others' efforts, and am willing to help 
  .
   

Let's just leave it at that for now. Curious what the responses will be. 
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] Re: Elm shell aliases

[suttlecommakevin]

Mine: https://github.com/kevinSuttle/dotfiles/blob/master/aliases

On Sunday, August 28, 2016 at 4:07:21 PM UTC-4, Max Goldstein wrote:
>
> Here's my list; I use about two-thirds of them regularly.
>
> https://github.com/mgold/dotfiles/blob/master/.aliases
>
> I also use git lg: https://coderwall.com/p/euwpig/a-better-git-log
>

-- 
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] Building a UI component library: the Elm compiler

[Peter Damoc]

I'll venture a personal opinion regarding your 4 questions:

1. Elm compiles to something like ECMAScript3 so... no modules in the
output. Also, the JS output is designed to me more like an assembly kind of
thing and it is planned to maybe someday move beyond JS. I don't think that
Elm output was designed to be used as a library from JS.

2. This is an issue for the minimizer. You can import your icons module,
use the 3 you need and the minimizer should remove the ones you are not
using. In other words, currently, Elm will include everything but it will
do it in such a way that tools like Closure compiler can remove the unused
stuff.

3. Hot reloading / Hot swapping used to work in the old elm-reactor and
will make a comeback RealSoonNow™.

4. Elm favors doing things the right way and CSS is a very complex topic so
I guess it got on the back-burner. I have tried to start discussions on
this subject before and there was simply not enough interest. There is a
huge opportunity to do something interesting in that domain but that would
involve designing a very large scale API and I've lost hope that we will
see this in a foreseeable future. There is however an opportunity here: you
can start a discussion about an approach that you might find
intriguing/useful.

Now, considering the title you picked for this topic, I want to point
something else out.
Elm doesn't have an official approach to building something like an UI
toolkit (frequently used components library).
This in itself is a very complex topic with a lot of moving parts that
might have also ended up on the back-burner.

The topic of components keeps resurfacing quite frequently and what I've
seen so far is mostly a downplay of the issue.

People who want to implement webapps with simple, CSS only,
components/widgets can use an external CSS and classes in elm-lang/html.
People who want more sophisticated components/widgets are out of luck.
Either they need to use a hack like elm-parts that uses techniques actively
discouraged by Evan or they submit to a world of boilerplate.
I even went so far as to create an example of this boilerplate:
https://github.com/pdamoc/elm-boilerplate-example
It generated a small discussion on Slack but... no other effect.

I guess people are using Elm to implement either CSS only kind of webapps
with dynamic content served by Elm OR they have figured out how to
integrate sliders, date pickers, light-boxes, dropdowns and other amenities
available in the JS driven toolkits (I could not figure that out as I don't
have a JS background).




On Thu, Sep 1, 2016 at 6:49 PM, suttlecommakevin  wrote:

> *Forgive me if I have missed something or am asking about something that's
> been reposted frequently.*
>
> Let's use a simple example: a custom set of SVG icons, for use in Buttons.
> Here are my rookie questions:
>
> *Is the Elm compiler: *
>
>1. aware of ES6 modules?
>- asking this because I'm not sure how one would consume these in an
>   otherwise Elm-unaware env.
>   2. able to do code splitting?
>   - The use case here being: I don't want a user to have to download
>   100 SVG icons in one JS file if there are only 3 being used on a page.
>3. able to do hot reloading?
>   - Just curious here
>4. ready to start supporting CSS as a 1st class-citizen?
>   - Seems like if Elm is the front-end language of the future, it
>   can't be missing 1/3 of the stack.
>   - I am aware of Richard and others' efforts, and am willing to help
>   .
>
>
> Let's just leave it at that for now. Curious what the responses will be.
> 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.
>



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

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

Re: [elm-discuss] Building a UI component library: the Elm compiler

[Zachary Kessin]

I for one would love to see a really nice nestable component library
somewhat similar to the good parts of ExtJS in elm. The problem is that I
think how to do that with a great API and in a type safe way is probably
not as obvious as I think it is. I think it would need to have someone put
12-18 months of work into it to get it going.

I at least can not do that even if Ihad the skills

Zach
ᐧ

On Thu, Sep 1, 2016 at 8:06 PM, Peter Damoc  wrote:

> I'll venture a personal opinion regarding your 4 questions:
>
> 1. Elm compiles to something like ECMAScript3 so... no modules in the
> output. Also, the JS output is designed to me more like an assembly kind of
> thing and it is planned to maybe someday move beyond JS. I don't think that
> Elm output was designed to be used as a library from JS.
>
> 2. This is an issue for the minimizer. You can import your icons module,
> use the 3 you need and the minimizer should remove the ones you are not
> using. In other words, currently, Elm will include everything but it will
> do it in such a way that tools like Closure compiler can remove the unused
> stuff.
>
> 3. Hot reloading / Hot swapping used to work in the old elm-reactor and
> will make a comeback RealSoonNow™.
>
> 4. Elm favors doing things the right way and CSS is a very complex topic
> so I guess it got on the back-burner. I have tried to start discussions on
> this subject before and there was simply not enough interest. There is a
> huge opportunity to do something interesting in that domain but that would
> involve designing a very large scale API and I've lost hope that we will
> see this in a foreseeable future. There is however an opportunity here: you
> can start a discussion about an approach that you might find
> intriguing/useful.
>
> Now, considering the title you picked for this topic, I want to point
> something else out.
> Elm doesn't have an official approach to building something like an UI
> toolkit (frequently used components library).
> This in itself is a very complex topic with a lot of moving parts that
> might have also ended up on the back-burner.
>
> The topic of components keeps resurfacing quite frequently and what I've
> seen so far is mostly a downplay of the issue.
>
> People who want to implement webapps with simple, CSS only,
> components/widgets can use an external CSS and classes in elm-lang/html.
> People who want more sophisticated components/widgets are out of luck.
> Either they need to use a hack like elm-parts that uses techniques
> actively discouraged by Evan or they submit to a world of boilerplate.
> I even went so far as to create an example of this boilerplate:
> https://github.com/pdamoc/elm-boilerplate-example
> It generated a small discussion on Slack but... no other effect.
>
> I guess people are using Elm to implement either CSS only kind of webapps
> with dynamic content served by Elm OR they have figured out how to
> integrate sliders, date pickers, light-boxes, dropdowns and other amenities
> available in the JS driven toolkits (I could not figure that out as I don't
> have a JS background).
>
>
>
>
> On Thu, Sep 1, 2016 at 6:49 PM, suttlecommakevin <
> suttlecommake...@gmail.com> wrote:
>
>> *Forgive me if I have missed something or am asking about something
>> that's been reposted frequently.*
>>
>> Let's use a simple example: a custom set of SVG icons, for use in Buttons.
>> Here are my rookie questions:
>>
>> *Is the Elm compiler: *
>>
>>1. aware of ES6 modules?
>>- asking this because I'm not sure how one would consume these in an
>>   otherwise Elm-unaware env.
>>   2. able to do code splitting?
>>   - The use case here being: I don't want a user to have to download
>>   100 SVG icons in one JS file if there are only 3 being used on a page.
>>3. able to do hot reloading?
>>   - Just curious here
>>4. ready to start supporting CSS as a 1st class-citizen?
>>   - Seems like if Elm is the front-end language of the future, it
>>   can't be missing 1/3 of the stack.
>>   - I am aware of Richard and others' efforts, and am willing to help
>>   .
>>
>>
>> Let's just leave it at that for now. Curious what the responses will be.
>> 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.
>>
>
>
>
> --
> 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.
>



-- 
Zach Kessin
SquareTarget 

Re: [elm-discuss] Re: Design of Large Elm apps

[Erik Lott]

Mark: I spent some time last night looking at a simplified scenario.

Here's a quick explanation for anyone who cares: An app has an API module 
which contains all of the task/command related logic needed to communicate 
with the server. The API module also manages some internal state related to 
these tasks/commands (e.g. task queue, data cache, etc), so it is a 
"stateful" module that sends Msg's and has an update function. This state 
must live near the top level of the application, since it exists for the 
lifespan of the application. Question: How can other deeply nested modules 
make use of the API module?

After I attacked this from a bunch of different angles, I think I agree 
with you Mark: I don't really see another way to make this work without 
swapping the existing Cmd in the update cycle for a custom implementation 
(or cheating by using javascript/native/ports).

Original update cycle
update : Msg -> Model -> (Model, Cmd)

New update cycle
update : Msg -> Model -> (Model, ClientCommand)

This adds some additional layers of abstraction at the top of the app where 
everything is wired together, but aside from that, this isn't so bad. 


On Wednesday, August 31, 2016 at 4:32:13 PM UTC-4, Mark Hamburg wrote:
>
> I re-read your message, Erik, and my reply and realized that I hadn't 
> answered all of the questions. The routing I've been working with handles 
> both commands created by the client side and handled by the service side 
> and commands created by the client and handled by "normal" external means. 
> This gets addressed through the type declaration:
>
> type ClientCommand msg
> = Batch (List (ClientCommand msg))
> | PlatformCmd (Platform.Cmd msg)
> | APIFromClient (APICommand msg)
>
>
> The key point here is in having the platform and API commands split out so 
> that they can be mapped differently. From the client standpoint, if you can 
> make a Cmd, then you can call ClientCommand.fromCmd and turn it into a 
> ClientCommand which can then be batched with API commands. At the point 
> where the "client" meets the "service" in the model, these get turned back 
> into Platform.Cmd's (through Task.succeed to set up the delivery of the 
> the APICommand value to the service).
>
> If I could figure out how to do this with tasks, that might well be 
> simpler and easier to plug in. I may need to take a pass at that again.
>
> Mark
>
> P.S. I don't really like the words "client" and "service" but they seemed 
> better at least than "client" and "server" since the latter would suggest 
> code running on another machine which while this separation enables that 
> possibility is not something that is happening here. I thought about 
> "viewModel" and "dataModel" but that seemed to have a certain amount of 
> verbal noise in saying "model" everywhere.
>
> On Sun, Aug 28, 2016 at 7:52 PM, Erik Lott  > wrote:
>
>> Mark, tell me about this code:
>>
>> type APICommand msg
>> = AddForum (Error -> msg) (ForumID -> msg) String
>> | DeleteForum (Error -> msg) (() -> msg) ForumID
>> | PostMessage (Error -> msg) (() -> msg) ForumID String
>>
>>
>> type APISubscription msg
>> = ForumList (List (ForumID, String) -> msg)
>> | MessageList (Array.Array String -> msg) ForumID
>>
>>
>> Conceptually, I appreciate what you're trying to do here (create a simple 
>> system driven by domain messages - AddForum, DeleteForum, etc) , but the 
>> actual implementation worries me. I'm wondering why you're not simply 
>> creating an API module instead:
>>
>> module API exposing(addForum, deleteForum, postMessage)
>>
>> addForum: String -> Task Http.Error Forum
>> // code here...
>>
>> deleteForum: String -> Task Http.Error Never
>> // code here
>>
>> etc
>>  
>>
>> I know that you mentioned that you have some additional complexity (task 
>> queue, websockets,etc), but I haven't actually seen anything that would 
>> cause me to abandon the built-in command/subscriptions system. What if you 
>> need to do something in the page that is not necessarily domain related, 
>> but requires a task/command - e.g. generate a random number? Are these 
>> types of situations factored into your design?
>>
>>
>>
>>
>> On Saturday, August 27, 2016 at 6:14:41 PM UTC-4, Mark Hamburg wrote:
>>
>>> I'm working on some example code. I'm varying between a moderately 
>>> fleshed out example of the plumbing but with little backing it up and a 
>>> fully worked but trivial to the point of not being interesting example. The 
>>> general model, however, works as follows:
>>>
>>> • We have a service model and a client model. The idea is that after 
>>> agreeing on an API, these can then undergo independent development. 
>>> Furthermore, we should be able to do things like mock the service rapidly 
>>> and then fill it in with a version that talks to the web service or 
>>> whatever is needed. Similarly, we could mock the client side quickly if we 
>>> just wanted to test the service APIs.
>>>
>>> • The API is represen

Re: [elm-discuss] Building a UI component library: the Elm compiler

[OvermindDL1]

Well get to PR'ing into `elm-mdl`, or make a new one based on `elm-parts` 
(which is what `elm-mdl` is built off of)?  ^.^


On Thursday, September 1, 2016 at 12:22:31 PM UTC-6, Zachary Kessin wrote:
>
> I for one would love to see a really nice nestable component library 
> somewhat similar to the good parts of ExtJS in elm. The problem is that I 
> think how to do that with a great API and in a type safe way is probably 
> not as obvious as I think it is. I think it would need to have someone put 
> 12-18 months of work into it to get it going. 
>
> I at least can not do that even if Ihad the skills
>
> Zach
> ᐧ
>
> On Thu, Sep 1, 2016 at 8:06 PM, Peter Damoc  > wrote:
>
>> I'll venture a personal opinion regarding your 4 questions:
>>
>> 1. Elm compiles to something like ECMAScript3 so... no modules in the 
>> output. Also, the JS output is designed to me more like an assembly kind of 
>> thing and it is planned to maybe someday move beyond JS. I don't think that 
>> Elm output was designed to be used as a library from JS.  
>>
>> 2. This is an issue for the minimizer. You can import your icons module, 
>> use the 3 you need and the minimizer should remove the ones you are not 
>> using. In other words, currently, Elm will include everything but it will 
>> do it in such a way that tools like Closure compiler can remove the unused 
>> stuff. 
>>
>> 3. Hot reloading / Hot swapping used to work in the old elm-reactor and 
>> will make a comeback RealSoonNow™. 
>>
>> 4. Elm favors doing things the right way and CSS is a very complex topic 
>> so I guess it got on the back-burner. I have tried to start discussions on 
>> this subject before and there was simply not enough interest. There is a 
>> huge opportunity to do something interesting in that domain but that would 
>> involve designing a very large scale API and I've lost hope that we will 
>> see this in a foreseeable future. There is however an opportunity here: you 
>> can start a discussion about an approach that you might find 
>> intriguing/useful. 
>>
>> Now, considering the title you picked for this topic, I want to point 
>> something else out. 
>> Elm doesn't have an official approach to building something like an UI 
>> toolkit (frequently used components library). 
>> This in itself is a very complex topic with a lot of moving parts that 
>> might have also ended up on the back-burner.
>>
>> The topic of components keeps resurfacing quite frequently and what I've 
>> seen so far is mostly a downplay of the issue.
>>
>> People who want to implement webapps with simple, CSS only, 
>> components/widgets can use an external CSS and classes in elm-lang/html. 
>> People who want more sophisticated components/widgets are out of luck. 
>> Either they need to use a hack like elm-parts that uses techniques 
>> actively discouraged by Evan or they submit to a world of boilerplate. 
>> I even went so far as to create an example of this boilerplate:
>> https://github.com/pdamoc/elm-boilerplate-example
>> It generated a small discussion on Slack but... no other effect. 
>>
>> I guess people are using Elm to implement either CSS only kind of webapps 
>> with dynamic content served by Elm OR they have figured out how to 
>> integrate sliders, date pickers, light-boxes, dropdowns and other amenities 
>> available in the JS driven toolkits (I could not figure that out as I don't 
>> have a JS background). 
>>
>>
>>
>>
>> On Thu, Sep 1, 2016 at 6:49 PM, suttlecommakevin > > wrote:
>>
>>> *Forgive me if I have missed something or am asking about something 
>>> that's been reposted frequently.*
>>>
>>> Let's use a simple example: a custom set of SVG icons, for use in 
>>> Buttons.
>>> Here are my rookie questions:
>>>
>>> *Is the Elm compiler: *
>>>
>>>1. aware of ES6 modules? 
>>>- asking this because I'm not sure how one would consume these in an 
>>>   otherwise Elm-unaware env. 
>>>   2. able to do code splitting? 
>>>   - The use case here being: I don't want a user to have to 
>>>   download 100 SVG icons in one JS file if there are only 3 being used 
>>> on a 
>>>   page.
>>>3. able to do hot reloading?
>>>   - Just curious here
>>>4. ready to start supporting CSS as a 1st class-citizen? 
>>>   - Seems like if Elm is the front-end language of the future, it 
>>>   can't be missing 1/3 of the stack. 
>>>   - I am aware of Richard and others' efforts, and am willing to 
>>>   help .
>>>
>>>
>>> Let's just leave it at that for now. Curious what the responses will be. 
>>> 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...@googlegroups.com .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> -- 
>> There is NO FATE, we are the creators.
>> bl

[elm-discuss] Broken link on Elm blog page.

[Carlos De la Guardia]

It looks like this link is 
broken: http://elm-lang.org/blog/escape-from-callback-hell

-- 
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] Idea / suggestion: Debug.todo - Fill gaps during prototyping

[Zinggi]

Hi everyone,

I just had this idea which I think would be awesome to have.
Basically I'd like to have this:

  Debug.todo : a
  Debug.todo =
  Debug.crash "TODO"

Which would be very simple to implement myself, but my idea would need some 
additional compiler support.

This could be used to *fill a gap* in your code during prototyping, before 
actually implementing anything.
Then the compiler should *generate a warning* wherever you've used it, 
telling you the *type* that would be needed there.
Let me give you an example:

  someButton : Html Msg
  someButton =
  button [ onClick Debug.todo ] [ text "foo" ]

Then the compiler would give you a warning along the lines of this:

*  Missing value** on line xx   
// *or: missing implementation


*  button [ onClick Debug.todo ] [ text "foo" ]*
*^^^*
*  This needs to be replaced with a value** of type:   
   // *or: needs to be replaced with a function of type

* Msg*


Couple that with a good text editor like atom which displays warnings 
inline and you immediately see what you need to provide to fill the gaps.
We could even go a step further and have:

  _ = Debug.todo

This might be a bit confusing, as _ already serves as a catch all pattern, 
but it isn't used as a value yet, so it would be free.



*TL;DR*

Fill gaps in your code with *Debug.todo* and the compiler tells you what 
needs to go there.


*What do you think?*

I'm already using *Debug.crash* quite often for that purpose, but a 
designated compiler supported solution would be ideal.

-- 
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: Design of Large Elm apps

[Mark Hamburg]

One nice thing that comes out of this architecture is that if one could run 
pieces on separate threads, it would split very naturally between the service 
side and the client side. The only ugly part is that in addition to moving data 
over whatever bridge we're using, we also need to move tagger functions and I 
can imagine that being harder to do than pure data.

We're looking at how much code sharing we can do between an iOS app written in 
Swift and a web app written in Elm. One of the potential answers is that the 
service side code could run in a JavaScript context while leaving the UI itself 
in native code.

Mark

> On Sep 1, 2016, at 12:21 PM, Erik Lott  wrote:
> 
> Mark: I spent some time last night looking at a simplified scenario.
> 
> Here's a quick explanation for anyone who cares: An app has an API module 
> which contains all of the task/command related logic needed to communicate 
> with the server. The API module also manages some internal state related to 
> these tasks/commands (e.g. task queue, data cache, etc), so it is a 
> "stateful" module that sends Msg's and has an update function. This state 
> must live near the top level of the application, since it exists for the 
> lifespan of the application. Question: How can other deeply nested modules 
> make use of the API module?
> 
> After I attacked this from a bunch of different angles, I think I agree with 
> you Mark: I don't really see another way to make this work without swapping 
> the existing Cmd in the update cycle for a custom implementation (or cheating 
> by using javascript/native/ports).
> 
> Original update cycle
> update : Msg -> Model -> (Model, Cmd)
> 
> New update cycle
> update : Msg -> Model -> (Model, ClientCommand)
> 
> This adds some additional layers of abstraction at the top of the app where 
> everything is wired together, but aside from that, this isn't so bad. 
> 
> 
>> On Wednesday, August 31, 2016 at 4:32:13 PM UTC-4, Mark Hamburg wrote:
>> I re-read your message, Erik, and my reply and realized that I hadn't 
>> answered all of the questions. The routing I've been working with handles 
>> both commands created by the client side and handled by the service side and 
>> commands created by the client and handled by "normal" external means. This 
>> gets addressed through the type declaration:
>> 
>> type ClientCommand msg
>> = Batch (List (ClientCommand msg))
>> | PlatformCmd (Platform.Cmd msg)
>> | APIFromClient (APICommand msg)
>> 
>> The key point here is in having the platform and API commands split out so 
>> that they can be mapped differently. From the client standpoint, if you can 
>> make a Cmd, then you can call ClientCommand.fromCmd and turn it into a 
>> ClientCommand which can then be batched with API commands. At the point 
>> where the "client" meets the "service" in the model, these get turned back 
>> into Platform.Cmd's (through Task.succeed to set up the delivery of the the 
>> APICommand value to the service).
>> 
>> If I could figure out how to do this with tasks, that might well be simpler 
>> and easier to plug in. I may need to take a pass at that again.
>> 
>> Mark
>> 
>> P.S. I don't really like the words "client" and "service" but they seemed 
>> better at least than "client" and "server" since the latter would suggest 
>> code running on another machine which while this separation enables that 
>> possibility is not something that is happening here. I thought about 
>> "viewModel" and "dataModel" but that seemed to have a certain amount of 
>> verbal noise in saying "model" everywhere.
>> 
>>> On Sun, Aug 28, 2016 at 7:52 PM, Erik Lott  wrote:
>>> Mark, tell me about this code:
>>> 
>>> type APICommand msg
>>> = AddForum (Error -> msg) (ForumID -> msg) String
>>> | DeleteForum (Error -> msg) (() -> msg) ForumID
>>> | PostMessage (Error -> msg) (() -> msg) ForumID String
>>> 
>>> 
>>> type APISubscription msg
>>> = ForumList (List (ForumID, String) -> msg)
>>> | MessageList (Array.Array String -> msg) ForumID
>>> 
>>> 
>>> Conceptually, I appreciate what you're trying to do here (create a simple 
>>> system driven by domain messages - AddForum, DeleteForum, etc) , but the 
>>> actual implementation worries me. I'm wondering why you're not simply 
>>> creating an API module instead:
>>> 
>>> module API exposing(addForum, deleteForum, postMessage)
>>> 
>>> addForum: String -> Task Http.Error Forum
>>> // code here...
>>> 
>>> deleteForum: String -> Task Http.Error Never
>>> // code here
>>> 
>>> etc
>>>  
>>> 
>>> I know that you mentioned that you have some additional complexity (task 
>>> queue, websockets,etc), but I haven't actually seen anything that would 
>>> cause me to abandon the built-in command/subscriptions system. What if you 
>>> need to do something in the page that is not necessarily domain related, 
>>> but requires a task/command - e.g. generate a random number? Are these 
>>> types of situations factored into your design?
>>> 

[elm-discuss] Re: [ANN] elm-mdl 7.0.0 — supports all components of Material Design Lite

[Joaquín Oltra]

That list of credits is lovely and awesome. It is great to see such a rich list 
of collaborators.

Congratulations on the release!

-- 
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] Idea / suggestion: Debug.todo - Fill gaps during prototyping

[Nick H]

I really like the compiler warnings. But the todo function seems
redundant... Debug.crash has no other legitimate uses.

On Thu, Sep 1, 2016 at 2:16 PM, Zinggi  wrote:

> Hi everyone,
>
> I just had this idea which I think would be awesome to have.
> Basically I'd like to have this:
>
>   Debug.todo : a
>   Debug.todo =
>   Debug.crash "TODO"
>
> Which would be very simple to implement myself, but my idea would need
> some additional compiler support.
>
> This could be used to *fill a gap* in your code during prototyping,
> before actually implementing anything.
> Then the compiler should *generate a warning* wherever you've used it,
> telling you the *type* that would be needed there.
> Let me give you an example:
>
>   someButton : Html Msg
>   someButton =
>   button [ onClick Debug.todo ] [ text "foo" ]
>
> Then the compiler would give you a warning along the lines of this:
>
> *  Missing value** on line xx
>   // *or: missing implementation
>
>
> *  button [ onClick Debug.todo ] [ text "foo" ]*
> *^^^*
> *  This needs to be replaced with a value** of type:
>  // *or: needs to be replaced with a function of type
>
> * Msg*
>
>
> Couple that with a good text editor like atom which displays warnings
> inline and you immediately see what you need to provide to fill the gaps.
> We could even go a step further and have:
>
>   _ = Debug.todo
>
> This might be a bit confusing, as _ already serves as a catch all pattern,
> but it isn't used as a value yet, so it would be free.
>
>
>
> *TL;DR*
>
> Fill gaps in your code with *Debug.todo* and the compiler tells you what
> needs to go there.
>
>
> *What do you think?*
>
> I'm already using *Debug.crash* quite often for that purpose, but a
> designated compiler supported solution would be ideal.
>
> --
> 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] How to order imports?

[John Bugner]

Is there a "right" (de-jure or de-facto) way to order imports? If not, then 
how do you order them?

As I see it, there's two kinds of imports:
(1) local imports (Main, Engine, EnginePart, etc)
(2) and standard imports (List, Dict, Maybe, etc)

I put the local imports first, then an empty line, then the standard 
imports.

And, is there a right way to order each import within its set? That is, 
should one try to "logically" order them, like having 'import List' come 
before 'import Array', because the former is more "basic" than the latter? 
Or should they just be in alphabetical order?

I prefer to logically order imports; I try to order them consistently in 
every project, but it doesn't always happen.

-- 
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] Idea / suggestion: Debug.todo - Fill gaps during prototyping

[Max Goldstein]

Debug.crash is used when you know a condition is impossible. I have a library 
where I sort a non empty list and do case analysis on the result. I call 
Debug.crash on the empty list case. It can't happen because sorting doesn't 
change the length of the list, but building that into the type system is way to 
complicated for Elm's goals. 

Language and tooling features are focusing on "making impossible things 
possible" not "making possible things pleasant", so Debug.todo is unlikely to 
get implemented anytime soon. But I think it's a pretty neat idea!

-- 
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] Idea / suggestion: Debug.todo - Fill gaps during prototyping

[Joey Eremondi]

This is basically the same as Typed Holes, which Haskell has.

There was a proposal for this a while back (which I fully support).

https://groups.google.com/forum/#!searchin/elm-dev/type$20holes%7Csort:relevance/elm-dev/_mS33Io74vs/qR0qESkyBwAJ

On Thu, Sep 1, 2016 at 5:21 PM, Max Goldstein 
wrote:

> Debug.crash is used when you know a condition is impossible. I have a
> library where I sort a non empty list and do case analysis on the result. I
> call Debug.crash on the empty list case. It can't happen because sorting
> doesn't change the length of the list, but building that into the type
> system is way to complicated for Elm's goals.
>
> Language and tooling features are focusing on "making impossible things
> possible" not "making possible things pleasant", so Debug.todo is unlikely
> to get implemented anytime soon. But I think it's a pretty neat idea!
>
> --
> 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: How to order imports?

[Justin Mimbs]

I list them all together, alphabetically. This way I don't spend time 
internally debating the most logical order when adding an import, and it 
gives me fast human lookup times when I need to scan the imports.

On Thursday, September 1, 2016 at 7:54:35 PM UTC-4, John Bugner wrote:
>
> Is there a "right" (de-jure or de-facto) way to order imports? If not, 
> then how do you order them?
>
> As I see it, there's two kinds of imports:
> (1) local imports (Main, Engine, EnginePart, etc)
> (2) and standard imports (List, Dict, Maybe, etc)
>
> I put the local imports first, then an empty line, then the standard 
> imports.
>
> And, is there a right way to order each import within its set? That is, 
> should one try to "logically" order them, like having 'import List' come 
> before 'import Array', because the former is more "basic" than the latter? 
> Or should they just be in alphabetical order?
>
> I prefer to logically order imports; I try to order them consistently in 
> every project, but it doesn't always happen.
>
>

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