[elm-discuss] TypeNats, SafeList and Array-Multidim updated for 0.17

[Joey Eremondi]

Hi All,

I've updated my libraries for 0.17. Nothing changed really for the API, but
I've changed the naming to match the "don't start with elm-" guideline.

http://package.elm-lang.org/packages/JoeyEremondi/typenats/1.0.0
http://package.elm-lang.org/packages/JoeyEremondi/elm-SafeLists/2.0.0/List-SafeList
http://package.elm-lang.org/packages/JoeyEremondi/array-multidim/1.0.0/Array-MultiDim

As always, feedback is welcome.

In the next iteration, I'd like to make specialized versions of 2d, 3d and
4d arrays so people can use them without ever seeing SafeLists.

-- 
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: Basic behavioral composition

[debois]

This is a great question! 

Without internal state

I think the most productive way of working with Elm is to avoid trying to 
generalise and stick with expressing yourself directly in elm-lang/html 
whenever possible. If you find yourself doing something a lot, use helper 
functions to construct high-frequency pieces of `Html m`. Richards' answer 
above is compatible with this philosophy. 

You'll see elm-mdl take this route in a number of places, i.e., the Card, 
Elevation, Footer, Grid, Lists and Typography modules contain just 
functions constructing `Html a` values for you. You add behaviour as you 
would anything in elm-lang/html by supplying your own attributes, typically 
Html.Events.on*. 

With internal state

However, all the answers above make sense only if the Button you're 
building doesn't have internal state. Let's say yours is a a fancy button 
with animations; someone needs to track the current animation state of the 
button, and update that state in response to DOM events. You now have just 
two options for who that someone might be: (1) That someone is you: Stick 
with working directly in elm-lang/html and manually integrate animation 
logic for each button in your app's `Msg/update`. (2) That someone is a 
component: Built a TEA component for your button. (If you think about it a 
bit, you'll realise that if you don't like (1), whatever else you do, you *must 
*do the things TEA components do anyway.)

Composing behaviours

This choice brings us back to the original question: "How do I compose 
behaviours in Elm"? If you go for (1),  "composing behaviours" is trivial, 
because you didn't put up a wall in the shape of an API between your fancy 
button and its surroundings; you just adjust the code from case to case as 
you need. This emphatically *does not* mean that you now code by 
cut-and-paste: As usual, when you find yourself doing the same thing in 
different places, you factor out that thing into a helper function. As you 
get more helper functions, perhaps a good API for a button component will 
emerge.

If you go for (2), full TEA component, "composing behaviours" is much, much 
harder. You have to chose an API your button, and that API will dictate 
exactly how it can and cannot interact with the rest of your app. For a 
button, figuring out this API is maybe not that hard (maybe you can set CSS 
on it, set its label, set its icon, and give it a Msg to fire when 
clicked), but for even slightly more complex behaviours, I find producing 
proper APIs surprisingly hard. A very large portion of the time spent on 
elm-mdl went to devising APIs for seemingly simple components, like Cards, 
Lists, and Badges. 

The approach we took in elm-mdl was to mimic elm-lang/html as much as 
possible: The only way to interact with a component is to customise it 
through parameters to `view` (think `Attribute m`).  You "compose 
behaviours" specifically by supplying `Msg`es you'd like to be sent in 
response to internal events of the component. This approach is compatible 
with the guidelines in Evan's sortableTable 
. 

In elm-mdl, we customise components only through parameters to `view` 
because that's what elm-lang/html looks like. You could view it as a 
ruthless, take-no-prisoners realisation of that guideline, though: When we 
customise only in `view`, the component *cannot* store any of your data in 
its model(*). 

So, altogether, this is *my* preferred approach to "composing behaviour" in 
elm:

1. Avoid components and work directly with `Html m` if possible. Avoid 
repeating yourself by ample use of helper functions. "Composing behaviour" 
is just producing `Html m` values. 
2. When you must make a component, let the Model of the component contain 
*only* internal state of that component.
3. When you must make a component, "compose behaviour" with that component 
by (a) telling it what to look like in `view` and (b) reacting to messages 
it sends (back) to you. Never touch its Model. Never send it messages.

This approach is not all-encompassing; I had to give up on (3) for the 
Snackbar  component(**). For UI 
components in general, though, I do think this approach is something to 
strive for, and I do think it makes sense outside of elm-mdl. 

Cheers,

Søren

(*) Almost can't. 

(**) Snackbar holds a queue of messages to display. That queue has to live 
in the model. The user can only add messages to the queue by messing with 
the model or (actual choice) send messages to Snackbar. 

-- 
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 design ideas for File/FileReader, ArrayBuffer and TypedArrays/DataViews

[Markus]

Thanks Daniel.

That is a great example, thanks Markus! I hope to have some time next 
> week to look at your example in more detail, but one thing I already 
> noticed is that you don't explicitly deal with endianness. Have you 
> verified that all your clients use the same (in this case presumably 
> little endian) encoding? 
>

Where this experiment/idea come from, a big SPA that uses binary data 
inside fields of most json responses, we use big endian exclusively so, 
originally, handling endianness was unnecessary. 
 

> I am currently thinking back and forth how closely to expose the 
> various browser apis surrounding binary data especially with regards 
> to endianness. Do we want to expose both typed arrays and data views? 
> Or should the elm api be based solely on dataviews and require the 
> user to always specify the endianness? 

 

> Several file formats either specify the endianness in the file and 
> some insane ones even switch endinaness for certain blocks (psd for 
> example but I think also jpeg because the exif block can be in a 
> different endianness than the rest of the file). So maybe the actual 
> functions of a binary decoder/encoder will have to explicitly state 
> the endianness. 
>
> I am brainstorming while I write this - I think a binary 
> decoder/encoder might be based on typed array using uint8 only 
> internally, and on the elm side we expose a number of functions with 
> specified endianness. 
>
> ```elm 
> type alias Cursor = { arrayBuffer : ArrayBuffer, position : Int } 
>
> -- Decoders: 
> uint16Little : Cursor -> (Int, Cursor) 
> uint16Big: Cursor -> (Int, Cursor) 
> float32Little : Cursor -> (Float, Cursor) 
> float32Big : Cursor -> (Float, Cursor) 
> float64Little : Cursor -> (Float, Cursor) 
> float64Big : Cursor -> (Float, Cursor) 
>
> type alias DecoderFn a = (Cursor -> (a, Cursor)) 
>
> array : DecoderFn a -> Int -> Cursor -> (Array a, Cursor) 
> combine : (a -> b -> c) -> DecoderFn a -> DecoderFn b -> Cursor -> (c, 
> Cursor) 
> -- we may want to have map and andThen too or instead of combine 
> ``` 
>
> Do you think you will also have the use case where you have data that 
> is more complex than just lists of numbers? Do you think an api along 
> these lines would make sense? 
>
>
Well, my example is designed to address the most trivial use case, that is 
a list in plain binary data. The full version should support zlib and 
protocol-buffer, which I have no idea how to implement in Elm at the moment 
:)

Regarding the use of unit8 only, it's what I actually do to create all 
typed arrays, first the data is dumped to an Uint8Array, and then its 
underlying buffer is passed to the constructor of each specific typed array.

TypedArrays are used for lots of stuff internally in javascript 
(webgl, 
audio, canvas, websockets, etc), which means that any api has to be able to 
work with all those use cases (some are already Elm packages), so the api 
you propose, even though is reasonable and type safe, might not be enough, 
or flexible enough, to cover all use cases. Additionally, there are things 
like decoding files (psd or jpeg as you've mentioned), or strings that 
contain binary data (like my example), that might require a different way 
of working with data.

Finally, performance is also a big design concern, because letting 
javascript do most of the work will be a lot faster than providing a rich 
Elm api that allows you to read and manipulate the input byte by byte.

Providing a minimal api, like Blob 
 in elm-http, 
might be another interesting approach. However, more use cases will 
definitely help a lot.
 

> -- 
> Daniel Bachler 
> http://www.danielbachler.de 
>
>
> On 16 August 2016 at 13:33, Markus  
> wrote: 
> > Regarding the binary encoder/decoder, our team is developing a SPA 
> (mostly 
> > native but slowly moving it to Elm) where the server uses binary strings 
> to 
> > encode large typed arrays inside json responses. These typed arrays are 
> > encoded in base64 strings, and must be decoded depending on the data 
> they 
> > represent. For instance, we use uInt32 for timestamps and float32 for 
> real 
> > numbers. 
> > 
> > The encode/decode process is pretty straightforward using the native 
> > TypedArray, but unfortunately that means that any json response that 
> > contains binary data must be handled outside elm and then sent as flags 
> to 
> > the app or using a port. 
> > 
> > I've been playing with several ideas to integrate this _inside_ elm, so 
> I 
> > can use packages like HTTP. The result is a more or less elaborate 
> > experiment, available here https://github.com/mapmarkus/elm-bytestring. 
> It 
> > contains an example where you can see the result of encoding and 
> decoding 
> > different kinds of typed arrays. The native implementation is basically 
> what 
> > we use 

Re: [elm-discuss] Re: Debugging json decoders

[Sergey Zubtsovskiy]

Thank you for explanation! I should give it a try.

Sergey Zubtsovskiy
sergey.zubtsovs...@gmail.com
Skype: szubtsovskiy


2016-08-19 23:06 GMT+02:00 OvermindDL1 :

> Given this:
> ```elm
> onScroll tagger =
>   on "scroll" (Json.Decode.map tagger decodeScrollPosition)
> ```
> If you *always* want it to be called, and since we know in this case that
> the scroll javascript event will not return a negative number then you
> could do this for decodeScrollPosition:
> ```elm
> decodeScrollPosition =
>   Json.Decode.oneOf
> [ Json.Decoder.int
> , Json.Decoder.succeed -1
> ]
> ```
>
> Or you could parse out a `Maybe Int`, or you could parse out a structure
> if you want a more stuff.  Etc...  :-)
>
>
> On Friday, August 19, 2016 at 2:45:32 PM UTC-6, Sergey Zubtsovskiy wrote:
>>
>> I am not sure I understand the answer. If you are talking about calling
>> decode function then, as Jacob mentioned, it works in all cases but the one
>> we're wondering about.
>>
>> Check this example:
>>
>> onScroll tagger =
>>>   on "scroll" (Json.Decode.map tagger decodeScrollPosition)
>>
>>
>> Where decodeScrollPosition is:
>>
>>> decodeScrollPosition : Json.Decode.Decoder Int
>>
>>
>> "on" function is only accepting value of type Json.Decode.Decoder. If I
>> was decoding myself (e.g. by calling Json.Decode.decodeString) I would get
>> a Result and process it the way you mention. But in case of an event
>> listener decoding is happening somewhere within Elm runtime which silently
>> swallows error. If I, for example, misspell event's field name, nothing
>> will happen. No runtime error (that's still valid), but no result either.
>>
>> I am wondering if I am missing something. To my mind it does not fit to
>> the whole impression Elm's trying to create. And I am a bit confused.
>>
>> Sergey Zubtsovskiy
>> sergey.zu...@gmail.com
>> Skype: szubtsovskiy
>>
>>
>> 2016-08-19 21:31 GMT+02:00 Simon :
>>
>>> 
>>> My emulator may help - http://simonh1000.github.io/decoder/
>>> 
>>>
>>> On Friday, 19 August 2016 19:56:05 UTC+2, OvermindDL1 wrote:
>>>
>>> On Friday, August 19, 2016 at 11:17:45 AM UTC-6, Sergey Zubtsovskiy
 wrote:
>
> Hey Jacob,
>
> Any update on this topic? I am facing the same issue, even in Elm 0.17
> with latest libraries...
>

 You can setup multiple branches in a decode so it one fails then you
 can fall back to a default value so it still passes.  You could even return
 a Maybe and return a default value of Nothing if you want, wrapping the
 main decode branch in a Just.

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

-- 
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-mdl implementations - suggest projects that can be added to reference list

[Dmytro Gladkyi]

You can press on a blue Card (anywhere) and it will navigate back to list. I'll 
add button for this anyway.

-- 
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: mdl layout

[Rex van der Spuy]

> It only works when it is the top-most 
> element in your app. 
>

That makes sense :)

I've been playing around with 7.4/5 all week and it's a delightful 
experience!
What so nice is that it's effortless to mix and match elm-mdl components 
with elm-html elements.

-- 
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: mdl layout

[debois]

It only works when it is the top-most
element in your app.

It seems a lot of people have trouble getting started with Layout. Could 
someone open an issue saying that the demo should have a more explicit code 
sample?

PS. Remember subscriptions and init—if your
layout doesn't resize right, that's probably why.

-- 
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] Decoding JSON tree using Either type

[Max Goldstein]

That's exactly why core exports a Result type rather than Haskell's Either: 
Left and Right get confusing fast!

-- 
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 design ideas for File/FileReader, ArrayBuffer and TypedArrays/DataViews

[Daniel Bachler]

That is a great example, thanks Markus! I hope to have some time next
week to look at your example in more detail, but one thing I already
noticed is that you don't explicitly deal with endianness. Have you
verified that all your clients use the same (in this case presumably
little endian) encoding?

I am currently thinking back and forth how closely to expose the
various browser apis surrounding binary data especially with regards
to endianness. Do we want to expose both typed arrays and data views?
Or should the elm api be based solely on dataviews and require the
user to always specify the endianness?

Several file formats either specify the endianness in the file and
some insane ones even switch endinaness for certain blocks (psd for
example but I think also jpeg because the exif block can be in a
different endianness than the rest of the file). So maybe the actual
functions of a binary decoder/encoder will have to explicitly state
the endianness.

I am brainstorming while I write this - I think a binary
decoder/encoder might be based on typed array using uint8 only
internally, and on the elm side we expose a number of functions with
specified endianness.

```elm
type alias Cursor = { arrayBuffer : ArrayBuffer, position : Int }

-- Decoders:
uint16Little : Cursor -> (Int, Cursor)
uint16Big: Cursor -> (Int, Cursor)
float32Little : Cursor -> (Float, Cursor)
float32Big : Cursor -> (Float, Cursor)
float64Little : Cursor -> (Float, Cursor)
float64Big : Cursor -> (Float, Cursor)

type alias DecoderFn a = (Cursor -> (a, Cursor))

array : DecoderFn a -> Int -> Cursor -> (Array a, Cursor)
combine : (a -> b -> c) -> DecoderFn a -> DecoderFn b -> Cursor -> (c, Cursor)
-- we may want to have map and andThen too or instead of combine
```

Do you think you will also have the use case where you have data that
is more complex than just lists of numbers? Do you think an api along
these lines would make sense?

--
Daniel Bachler
http://www.danielbachler.de


On 16 August 2016 at 13:33, Markus  wrote:
> Regarding the binary encoder/decoder, our team is developing a SPA (mostly
> native but slowly moving it to Elm) where the server uses binary strings to
> encode large typed arrays inside json responses. These typed arrays are
> encoded in base64 strings, and must be decoded depending on the data they
> represent. For instance, we use uInt32 for timestamps and float32 for real
> numbers.
>
> The encode/decode process is pretty straightforward using the native
> TypedArray, but unfortunately that means that any json response that
> contains binary data must be handled outside elm and then sent as flags to
> the app or using a port.
>
> I've been playing with several ideas to integrate this _inside_ elm, so I
> can use packages like HTTP. The result is a more or less elaborate
> experiment, available here https://github.com/mapmarkus/elm-bytestring. It
> contains an example where you can see the result of encoding and decoding
> different kinds of typed arrays. The native implementation is basically what
> we use right now in plain javascript to manipulate binary strings.
>
> I hope that servers as a valid example for this thread.
>
>
> On Monday, 15 August 2016 23:00:31 UTC+2, Daniel Bachler wrote:
>>
>> In this thread we collected use cases for dealing with loading files and
>> decoding and constructing of binary data.
>>
>> I would now like to take this discussion to the next stage and start
>> collecting design ideas for those use cases. I think it would be best to try
>> and see what we would like an Elm solution to the collected use cases to
>> look like, where the goal would be for the solution to feel "elmish" but
>> ideally also be informed by the capabilities and limitations of the
>> available native browser APIs. Let us explore the design space a little and
>> see what we can come up with.
>>
>> I think that discussing several different proposals in detail in one
>> dicussion thread will quickly become unwieldy, so my thought was that we
>> could try to discuss individual ideas as gists with specific feedback
>> happening there, and use this thread for big picture ideas and to
>> synchronize what is happening on the gists.
>>
>> Simon has already started with a draft of reading local files and
>> uploading them as signed uploads to S3 - Simon, could you create a gist for
>> that?
>>
>> I started reading up a bit on the TypedArray/DataView apis and created
>> drafts for 3 use cases that, in addition to Simon's read-and-upload example
>> represent some of the major use case themes.
>>
>> Here is what one of the simplest use cases could look like, reading local
>> text files:
>> https://gist.github.com/danyx23/35cea7421be6691cbda9e437d58641f0
>>
>> Here are some initial thoughts on what a binary data decoder could look
>> like. I haven't thought about this in detail, it is really just a
>> conversation starter. This is a very bare-bones api idea - it is probably a
>> lot more elmish to create a 

Re: [elm-discuss] Re: Making imports more pleasant

[Will White]

But it would cause naming collisions if there were two imported modules 
both with id. As import exposing (a, b) would break the guarantee against 
the problem I had, that could be made clear, perhaps by naming it unsafe 
import exposing (a, b).

On Saturday, August 20, 2016 at 9:07:44 AM UTC+1, Will White wrote:
>
> Yes, you're right. What I should have said is that it shouldn't be 
> something the programmer has to think about *until* there's a name 
> collision.
>
> I've been import exposing (..) a lot, and using variable names like id 
> too. I haven't noticed lots of naming collisions as you describe, so I 
> thought I'd check it out:
>
> module Main exposing (..)
>
> import Html exposing (..)
> import Html.Attributes exposing (..)
> import Html.App exposing (..)
>
> main =
> Html.App.beginnerProgram
> { model = ()
> , update = (\_ _ -> ())
> , view = view
> }
>
> id =
> 2
>
> view model =
> div [ class "something" ] []
>
>
> This doesn't actually cause any naming collisions between id and 
> Html.Attributes.id.
>
> On Friday, August 19, 2016 at 11:29:37 PM UTC+1, Nick H wrote:
>>
>> Let me try to state my concern in a different way. You say:
>>
>> The fact that class is only one of an arbitrary number of functions in 
>>> Html.Attributes isn't actually something the programmer should have to 
>>> think about
>>>
>>
>> I completely agree with this! And it is exactly why I write "exposing 
>> (class)" and not "exposing (..)". Because I am telling the compiler 
>> "Whatever else is in Html.Attributes, I don't want to think about it. So 
>> please leave it in its namespace where it won't get in my way." This 
>> approach works whether class is the only function in the module, or if it 
>> is one of millions.
>>
>>
>> On Fri, Aug 19, 2016 at 2:23 PM, Nick H  wrote:
>>
>>> It is something I have to worry about, because having 50+ useless 
>>> functions with names like "id" and "title" imported into my default 
>>> namespace is a recipe for naming collisions and confusing compiler errors.
>>>
>>> Supposing Html.Attributes had a function called "toString" that I didn't 
>>> know or care about? Your proposal sounds like it will take the problem you 
>>> are trying to solve and just make it worse.
>>>
>>> On Fri, Aug 19, 2016 at 2:13 PM, Will White  wrote:
>>>
 That's optimisation work that should be done by the compiler. The fact 
 that class is only one of an arbitrary number of functions in 
 Html.Attributes isn't actually something the programmer should have to 
 think about. The compiler would look at the Html.Attributes you use in 
 your 
 file, find only class, and do whatever import exposing (class) does now.

 On Friday, August 19, 2016 at 10:00:07 PM UTC+1, Nick H wrote:
>
> Will, how would you propose to deal with selective imports? For 
> example:
>
> import Html.Attributes exposing (class)
>
> This is a frequent usage for me. Html.Attributes has a bazillion 
> things in it, and a lot of them are common words. I want to de-namespace 
> "class" because I use it frequently, but not the rest of that junk.
>
>
>
> On Fri, Aug 19, 2016 at 1:41 PM, Joey Eremondi  
> wrote:
>
>> I had suggested something similar a while back: 
>> https://groups.google.com/forum/#!topic/elm-discuss/qJL51Kf8C2M
>>
>> The arguments against it are still valid.
>>
>> I don't think there's  widespread dissatisfaction with the import 
>> system as of 0.17, so I doubt it will change any time soon.
>>
>> On Fri, Aug 19, 2016 at 1:37 PM, Will White  
>> wrote:
>>
>>> I have an idea that I think is nice. Make writing List.map actually 
>>> *do* what import List exposing (map) does, so you don't have to 
>>> write import List at all. And if you want to use a function without a 
>>> namespace, e.g. Html, import Html could do what import Html exposing 
>>> (..) 
>>> does now.
>>>
>>>
>>> On Saturday, February 7, 2015 at 5:17:50 PM UTC, Evan wrote:

 Since 0.14, I have been hearing more complaints about imports. Lots 
 of different proposals and discussions. Beginners struggling to 
 understand 
 how the different variations fit together. After hearing Laszlo's take 
 on 
 this, I am trying out a new syntax and semantics 
 
 .

 Here are all the variations of the *syntax*:

 import List
 import List exposing (map, filter)
 import List exposing (..)

 import List as L
 import List as L exposing (map, filter)
 import List as L exposing (..)

 The most important change is in *semantics* 

[elm-discuss] Re: Elm-mdl implementations - suggest projects that can be added to reference list

[Håkon Rossebø]

Thanks - looks nice. I'll add it to the list. A possible improvement - I 
tried a couple of url's and could not find any way of navigating back to 
the article list.


fredag 19. august 2016 23.46.54 UTC+2 skrev Dmytro Gladkyi følgende:
>
> Hi Håkon,
>
> I have switched from React + Redux + Bootstrap to Elm + Elm Mdl my hobby 
> project:
> *https://offtie.com/* 
>
> Project allows to save urls to read later without data connection or in 
> AirPlane Mode.
> Urls are parsed by www.readability.com and saved into LocalStorage.
>
> Site uses Service Workers (in JS) to cache all site resources so they are 
> available offline (works in Chrome, FF).
>
> *UI+backend connection is all in Elm + Elm Mdl. *Main.elm is 220 lines. 
> Can be reduced to 150.
> *LocalStorage stuff is done via ports.*
>
> Minified and gzipped bundle is in 5 times smaller than React + Redux 
> version.
>
> Minified gzipped Elm bundle is 42Kb + 26Kb material design css.
>
> React bundle (babelify + minify + gzip) was about 200Kb. + 70Kb bootstrap.
>
> On Tuesday, August 16, 2016 at 11:33:35 AM UTC+3, Håkon Rossebø wrote:
>>
>> Elm-mdl  - is getting more usage in 
>> various applications/projects. To improve documentation, we want to create 
>> a list of implementations - all kinds - simple to complex and use it as a 
>> reference on elm-mdl . I would 
>> appreciate if people could suggest any implementations that can be added to 
>> this list.
>>
>> If you know any projects/applications/repositories - reply to this thread.
>>
>

-- 
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: Making imports more pleasant

[Will White]

Yes, you're right. What I should have said is that it shouldn't be 
something the programmer has to think about *until* there's a name 
collision.

I've been import exposing (..) a lot, and using variable names like id too. 
I haven't noticed lots of naming collisions as you describe, so I thought 
I'd check it out:

module Main exposing (..)

import Html exposing (..)
import Html.Attributes exposing (..)
import Html.App exposing (..)

main =
Html.App.beginnerProgram
{ model = ()
, update = (\_ _ -> ())
, view = view
}

id =
2

view model =
div [ class "something" ] []


This doesn't actually cause any naming collisions between id and 
Html.Attributes.id.

On Friday, August 19, 2016 at 11:29:37 PM UTC+1, Nick H wrote:
>
> Let me try to state my concern in a different way. You say:
>
> The fact that class is only one of an arbitrary number of functions in 
>> Html.Attributes isn't actually something the programmer should have to 
>> think about
>>
>
> I completely agree with this! And it is exactly why I write "exposing 
> (class)" and not "exposing (..)". Because I am telling the compiler 
> "Whatever else is in Html.Attributes, I don't want to think about it. So 
> please leave it in its namespace where it won't get in my way." This 
> approach works whether class is the only function in the module, or if it 
> is one of millions.
>
>
> On Fri, Aug 19, 2016 at 2:23 PM, Nick H  > wrote:
>
>> It is something I have to worry about, because having 50+ useless 
>> functions with names like "id" and "title" imported into my default 
>> namespace is a recipe for naming collisions and confusing compiler errors.
>>
>> Supposing Html.Attributes had a function called "toString" that I didn't 
>> know or care about? Your proposal sounds like it will take the problem you 
>> are trying to solve and just make it worse.
>>
>> On Fri, Aug 19, 2016 at 2:13 PM, Will White > > wrote:
>>
>>> That's optimisation work that should be done by the compiler. The fact 
>>> that class is only one of an arbitrary number of functions in 
>>> Html.Attributes isn't actually something the programmer should have to 
>>> think about. The compiler would look at the Html.Attributes you use in your 
>>> file, find only class, and do whatever import exposing (class) does now.
>>>
>>> On Friday, August 19, 2016 at 10:00:07 PM UTC+1, Nick H wrote:

 Will, how would you propose to deal with selective imports? For example:

 import Html.Attributes exposing (class)

 This is a frequent usage for me. Html.Attributes has a bazillion things 
 in it, and a lot of them are common words. I want to de-namespace "class" 
 because I use it frequently, but not the rest of that junk.



 On Fri, Aug 19, 2016 at 1:41 PM, Joey Eremondi  
 wrote:

> I had suggested something similar a while back: 
> https://groups.google.com/forum/#!topic/elm-discuss/qJL51Kf8C2M
>
> The arguments against it are still valid.
>
> I don't think there's  widespread dissatisfaction with the import 
> system as of 0.17, so I doubt it will change any time soon.
>
> On Fri, Aug 19, 2016 at 1:37 PM, Will White  
> wrote:
>
>> I have an idea that I think is nice. Make writing List.map actually 
>> *do* what import List exposing (map) does, so you don't have to 
>> write import List at all. And if you want to use a function without a 
>> namespace, e.g. Html, import Html could do what import Html exposing 
>> (..) 
>> does now.
>>
>>
>> On Saturday, February 7, 2015 at 5:17:50 PM UTC, Evan wrote:
>>>
>>> Since 0.14, I have been hearing more complaints about imports. Lots 
>>> of different proposals and discussions. Beginners struggling to 
>>> understand 
>>> how the different variations fit together. After hearing Laszlo's take 
>>> on 
>>> this, I am trying out a new syntax and semantics 
>>> 
>>> .
>>>
>>> Here are all the variations of the *syntax*:
>>>
>>> import List
>>> import List exposing (map, filter)
>>> import List exposing (..)
>>>
>>> import List as L
>>> import List as L exposing (map, filter)
>>> import List as L exposing (..)
>>>
>>> The most important change is in *semantics* though. In cases 1-3 
>>> you are able to refer to anything in the List module as List.member 
>>> and List.isEmpty. So importing a module implies that you want to be 
>>> able to use it's name to qualify all of its values.
>>>
>>> In cases 4-6, it is the same except you can qualify with L but not 
>>> List. Why hide List though? There may come a time when you don't 
>>> want name overlaps with modules, so this makes it possible to avoid 

[elm-discuss] Re: Will server side elm be a game changer?

[Magnus Rundberget]

My bad I read server side *rendering• in my mind. server side elm is a 
different beast alltogether and who knows.

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