Re: [elm-discuss] Re: Code review request

[Nick H]

>
> (Btw, the (<|) function is the opposite of (|>). I personally use only the
> former, because it does things in the same order that you normally write a
> function. The latter makes things look "backwards".)


I personally use only the latter, because it works like the pipe operator
in bash :-)

On Thu, Aug 18, 2016 at 8:44 PM, John Bugner  wrote:

> >While adding type annotations I encountered something I didn't understand
> that I worked around at https://github.com/thomasba
> llinger/loveinthetimeoftetris/blob/3f968afad490ebab54b4f0c3b
> afdf45b779ebc4b/src/Main.elm#L278
> ,
> I tried to simplify the behavior and got it down to this
> https://gist.github.com/thomasballinger/a0d8b38fa7186ee2e608d4772f2ebe7e
> 
>  which
> I'd appreciate a hand from anyone in understanding.
> I haven't used extensible records very much, but I think it's because
> the signatures don't match.
> The first is:
> >hasBothXAndY : HasXAndY (HasX a)
> but the other is:
> >fieldOfBothTypes : HasX (HasXAndY {})
> The order matters.
>
> (Btw, the (<|) function is the opposite of (|>). I personally use only the
> former, because it does things in the same order that you normally write a
> function. The latter makes things look "backwards".)
>
> On Thursday, August 18, 2016 at 7:06:13 PM UTC-5, Thomas Ballinger wrote:
>>
>> Thanks very much John. The auto-formatter I'm using is
>> https://github.com/avh4/elm-format, I also found it to be a bit much.
>> I'm a big fan of automatic formatting so might look at changing these
>> settings in elm-format, or if anyone knows of other autoformatters please
>> let me know.
>>
>> While adding type annotations I encountered something I didn't understand
>> that I worked around at https://github.com/thomasba
>> llinger/loveinthetimeoftetris/blob/3f968afad490ebab54b4f0c3b
>> afdf45b779ebc4b/src/Main.elm#L278, I tried to simplify the behavior and
>> got it down to this https://gist.github.com/thomas
>> ballinger/a0d8b38fa7186ee2e608d4772f2ebe7e which I'd appreciate a hand
>> from anyone in understanding.
>>
>> I did the rest of these except for switching to SVG, but I'm looking
>> forward to that too.
>>
>>
>>> >* I don't think I'll be using evancz/elm-graphics in the future since
>>> I'll be doing less gamey stuff or want to work with canvas more directly.
>>> How is this usually done?
>>> By using Svg instead: http://package.elm-lang.org/packages/elm-lang/svg/
>>> 1.1.1
>>>
>>> On Wednesday, August 17, 2016 at 4:40:38 PM UTC-5, Thomas Ballinger
>>> wrote:

 Hi Elm folks! I've enjoyed reading this list for a bit. I've written my
 first Elm thing over the last couple weeks and would love to hear any kind
 of feedback on it. It's an unfinished game jam piece I kept running with so
 the title doesn't make sense.

 code: https://github.com/thomasballinger/loveinthetimeoftetris
 live: love.ballingt.com (takes about 70 seconds to play all of)

 I was going to clean things up the way I know how, but I need to take a
 break to get some other things done and I thought I'd learn more by asking
 how someone else might clean it up. Please don't assume I know what I'm
 doing in the slightest :)

 Any feedback would be great, but if prompts are helpful:
 * what does this code make it look like I'm missing about Elm?
 * what do you think of the extensible record type aliases? I think the
 way I've used them is mostly terrible, I designed them up front instead of
 letting them evolve.
 * code style?
 * I'm using an elm autoformatter, how's my formatting? Is this style
 common?
 * I don't think I'll be using evancz/elm-graphics in the future since
 I'll be doing less gamey stuff or want to work with canvas more directly.
 How is this usually done?
 * I abandoned elm reactor once I started embedding in html, is that a
 viable workflow I should have stuck with for longer?
 * I was tempted to start a utils file or look for an external lib but
 was trying to focus on learning the stdlib. Are there pretty common util
 libs folks use? I sure missed some list functions.
 * I escaped to JavaScript anytime I thought it would be hard to do
 something with the stdlib, presumably it would be nice to use Elm for some
 of these things?

 Thanks so much, and feel free to contact off list if you prefer at
 m...@ballingt.com - if you do I'll report back what I learned to the
 list.

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

Re: [elm-discuss] Re: Code review request

[Joey Eremondi]

>
> Thanks very much John. The auto-formatter I'm using is
> https://github.com/avh4/elm-format, I also found it to be a bit much. I'm
> a big fan of automatic formatting so might look at changing these settings
> in elm-format, or if anyone knows of other autoformatters please let me
> know.


That's the official formatter, so you're definitely doing the right thing
by using it. Nobody can agree on the settings they like best, but for
standardization, a deliberate choice has been made not to allow users to
tweak the settings of elm-format.

I think most people on this mailing list would advocate that you use it, to
maximize the uniformity and readability of your code, even if it does odd
things with indentation.

On Thu, Aug 18, 2016 at 8:44 PM, John Bugner  wrote:

> >While adding type annotations I encountered something I didn't understand
> that I worked around at https://github.com/thomasba
> llinger/loveinthetimeoftetris/blob/3f968afad490ebab54b4f0c3b
> afdf45b779ebc4b/src/Main.elm#L278
> ,
> I tried to simplify the behavior and got it down to this
> https://gist.github.com/thomasballinger/a0d8b38fa7186ee2e608d4772f2ebe7e
> 
>  which
> I'd appreciate a hand from anyone in understanding.
> I haven't used extensible records very much, but I think it's because
> the signatures don't match.
> The first is:
> >hasBothXAndY : HasXAndY (HasX a)
> but the other is:
> >fieldOfBothTypes : HasX (HasXAndY {})
> The order matters.
>
> (Btw, the (<|) function is the opposite of (|>). I personally use only the
> former, because it does things in the same order that you normally write a
> function. The latter makes things look "backwards".)
>
> On Thursday, August 18, 2016 at 7:06:13 PM UTC-5, Thomas Ballinger wrote:
>>
>> Thanks very much John. The auto-formatter I'm using is
>> https://github.com/avh4/elm-format, I also found it to be a bit much.
>> I'm a big fan of automatic formatting so might look at changing these
>> settings in elm-format, or if anyone knows of other autoformatters please
>> let me know.
>>
>> While adding type annotations I encountered something I didn't understand
>> that I worked around at https://github.com/thomasba
>> llinger/loveinthetimeoftetris/blob/3f968afad490ebab54b4f0c3b
>> afdf45b779ebc4b/src/Main.elm#L278, I tried to simplify the behavior and
>> got it down to this https://gist.github.com/thomas
>> ballinger/a0d8b38fa7186ee2e608d4772f2ebe7e which I'd appreciate a hand
>> from anyone in understanding.
>>
>> I did the rest of these except for switching to SVG, but I'm looking
>> forward to that too.
>>
>>
>>> >* I don't think I'll be using evancz/elm-graphics in the future since
>>> I'll be doing less gamey stuff or want to work with canvas more directly.
>>> How is this usually done?
>>> By using Svg instead: http://package.elm-lang.org/packages/elm-lang/svg/
>>> 1.1.1
>>>
>>> On Wednesday, August 17, 2016 at 4:40:38 PM UTC-5, Thomas Ballinger
>>> wrote:

 Hi Elm folks! I've enjoyed reading this list for a bit. I've written my
 first Elm thing over the last couple weeks and would love to hear any kind
 of feedback on it. It's an unfinished game jam piece I kept running with so
 the title doesn't make sense.

 code: https://github.com/thomasballinger/loveinthetimeoftetris
 live: love.ballingt.com (takes about 70 seconds to play all of)

 I was going to clean things up the way I know how, but I need to take a
 break to get some other things done and I thought I'd learn more by asking
 how someone else might clean it up. Please don't assume I know what I'm
 doing in the slightest :)

 Any feedback would be great, but if prompts are helpful:
 * what does this code make it look like I'm missing about Elm?
 * what do you think of the extensible record type aliases? I think the
 way I've used them is mostly terrible, I designed them up front instead of
 letting them evolve.
 * code style?
 * I'm using an elm autoformatter, how's my formatting? Is this style
 common?
 * I don't think I'll be using evancz/elm-graphics in the future since
 I'll be doing less gamey stuff or want to work with canvas more directly.
 How is this usually done?
 * I abandoned elm reactor once I started embedding in html, is that a
 viable workflow I should have stuck with for longer?
 * I was tempted to start a utils file or look for an external lib but
 was trying to focus on learning the stdlib. Are there pretty common util
 libs folks use? I sure missed some list functions.
 * I escaped to JavaScript anytime 

[elm-discuss] Re: Code review request

[John Bugner]

>While adding type annotations I encountered something I didn't understand 
that I worked around at 
https://github.com/thomasballinger/loveinthetimeoftetris/blob/3f968afad490ebab54b4f0c3bafdf45b779ebc4b/src/Main.elm#L278
 
,
 
I tried to simplify the behavior and got it down to this 
https://gist.github.com/thomasballinger/a0d8b38fa7186ee2e608d4772f2ebe7e 

 which 
I'd appreciate a hand from anyone in understanding.
I haven't used extensible records very much, but I think it's because 
the signatures don't match.
The first is:
>hasBothXAndY : HasXAndY (HasX a)
but the other is:
>fieldOfBothTypes : HasX (HasXAndY {})
The order matters.

(Btw, the (<|) function is the opposite of (|>). I personally use only the 
former, because it does things in the same order that you normally write a 
function. The latter makes things look "backwards".)

On Thursday, August 18, 2016 at 7:06:13 PM UTC-5, Thomas Ballinger wrote:
>
> Thanks very much John. The auto-formatter I'm using is 
> https://github.com/avh4/elm-format, I also found it to be a bit much. I'm 
> a big fan of automatic formatting so might look at changing these settings 
> in elm-format, or if anyone knows of other autoformatters please let me 
> know.
>
> While adding type annotations I encountered something I didn't understand 
> that I worked around at 
> https://github.com/thomasballinger/loveinthetimeoftetris/blob/3f968afad490ebab54b4f0c3bafdf45b779ebc4b/src/Main.elm#L278,
>  
> I tried to simplify the behavior and got it down to this 
> https://gist.github.com/thomasballinger/a0d8b38fa7186ee2e608d4772f2ebe7e 
> which I'd appreciate a hand from anyone in understanding.
>
> I did the rest of these except for switching to SVG, but I'm looking 
> forward to that too.
>  
>
>> >* I don't think I'll be using evancz/elm-graphics in the future since 
>> I'll be doing less gamey stuff or want to work with canvas more directly. 
>> How is this usually done?
>> By using Svg instead: 
>> http://package.elm-lang.org/packages/elm-lang/svg/1.1.1
>>
>> On Wednesday, August 17, 2016 at 4:40:38 PM UTC-5, Thomas Ballinger wrote:
>>>
>>> Hi Elm folks! I've enjoyed reading this list for a bit. I've written my 
>>> first Elm thing over the last couple weeks and would love to hear any kind 
>>> of feedback on it. It's an unfinished game jam piece I kept running with so 
>>> the title doesn't make sense.
>>>
>>> code: https://github.com/thomasballinger/loveinthetimeoftetris
>>> live: love.ballingt.com (takes about 70 seconds to play all of)
>>>
>>> I was going to clean things up the way I know how, but I need to take a 
>>> break to get some other things done and I thought I'd learn more by asking 
>>> how someone else might clean it up. Please don't assume I know what I'm 
>>> doing in the slightest :)
>>>
>>> Any feedback would be great, but if prompts are helpful:
>>> * what does this code make it look like I'm missing about Elm?
>>> * what do you think of the extensible record type aliases? I think the 
>>> way I've used them is mostly terrible, I designed them up front instead of 
>>> letting them evolve.
>>> * code style?
>>> * I'm using an elm autoformatter, how's my formatting? Is this style 
>>> common?
>>> * I don't think I'll be using evancz/elm-graphics in the future since 
>>> I'll be doing less gamey stuff or want to work with canvas more directly. 
>>> How is this usually done?
>>> * I abandoned elm reactor once I started embedding in html, is that a 
>>> viable workflow I should have stuck with for longer?
>>> * I was tempted to start a utils file or look for an external lib but 
>>> was trying to focus on learning the stdlib. Are there pretty common util 
>>> libs folks use? I sure missed some list functions.
>>> * I escaped to JavaScript anytime I thought it would be hard to do 
>>> something with the stdlib, presumably it would be nice to use Elm for some 
>>> of these things?
>>>
>>> Thanks so much, and feel free to contact off list if you prefer at 
>>> m...@ballingt.com - if you do I'll report back what I learned to the 
>>> list.
>>>
>>

-- 
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: Remove ways of importing except `import exposing (..)`?

[Ian Mackenzie]

Edit: I did some searching after I posted this and realized just how common 
it was to have custom toString functions, so I take back what I said about 
not naming your own functions toString. Switching Basics.toString to 
Debug.toString could be a good solution, although that would be annoying 
for simple cases like converting an Int to a String (which is often needed 
in non-debug situations like setting up HTML/SVG attributes). Maybe there 
should be a specialized Int.toString function instead. I do think it's a 
sufficiently special case that 'always import qualified' is still the best 
strategy though.

On Friday, 19 August 2016 09:28:56 UTC+10, Ian Mackenzie wrote:
>
> It seems to me that the issues you are encountering come from two things:
>
>- Using a mix of qualified and unqualified imports
>- Having a function the same name as one in Basics
>
> One solution is to never use qualified imports, but a better solution is 
> to *always *use qualified imports and just not name any of your own 
> functions toString (or min, or max, or degrees, or anything else in Basics
> ). That way you never have any ambiguity between functions, you never 
> have to switch between qualified and unqualified (if, perhaps, you start 
> using Maybe.map in a file that already uses List.map), and it's always 
> clear where a function (or value) is coming from.
>
> On Thursday, 18 August 2016 23:33:25 UTC+10, Will White wrote:
>>
>> import ModuleWithToString
>>
>> toString typeFromThatModule
>>
>> Compiles with unexpected results that you have to catch.
>>
>> import ModuleWithToString exposing (..)
>>
>> toString typeFromThatModule
>>
>> Doesn't compile: "use of toString is ambiguous: did you mean 
>> Basics.toString or ModuleWithToString.toString?"
>>
>

-- 
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: Remove ways of importing except `import exposing (..)`?

[Max Goldstein]

I won't go so far as to say that (..) imports should be removed from the 
language but I'm definitely on the side of rarely using them for reasons that 
have been cited repeatedly in this thread. Furthermore, having written several 
data structures in Elm, you want to keep names like map available for you to 
define yourself. So if you see map with no qualifier, it's the map for this 
data structure, defined in this module. 

-- 
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: Code review request

[Thomas Ballinger]

Thanks very much for all this Nick!

Re Maybe use, good call

Re List methods: I had seen elm-community/list-extra 

 but 
wanted to make sure I wasn't missing anything in the stdlib first. Great to 
hear that's pretty normal to use.
 
Re type alias + maybe instead of a new type, that seems pretty reasonable.

Re: extensible records, I certainly concede they're not paying off here. I 
am using different combinations a bit, but I don't need so many. I also ran 
into some type annotating behavior that confuses me with extensible types, 
see https://gist.github.com/thomasballinger/a0d8b38fa7186ee2e608d4772f2ebe7e 
(also described in a sibling thread)


On Thursday, August 18, 2016 at 7:30:01 PM UTC-4, Nick H wrote:
>
> Regarding the extensible records... Movable (Standable (Collidable (
> Drawable {}))) sure is a mouthful isn't it? :-)  It looks like every 
> thing in your game is the union of all four type aliases... so why not just 
> make it one type alias?
>
>
> OK, one last thing. This type definition...
>
> type PossibleCollision = NoCollision | Collision CollisionType Float 
> (Float, Float)
>
> I think the more idiomatic thing to do (but this might just be personal 
> taste) would be to define
>
> type alias Collision =
> { collisionType : CollisionType
> , overlap : Float
> , velocity : Float
> }
>
> And then in the places where you are using "PossibleCollision," use "Maybe 
> Collision" instead. The Maybe 
>  is super 
> useful for dealing with cases where you have either something or nothing. I 
> bet that you could shorten your collision detection code a lot by switching 
> to using Maybes. (For instance, you could use List.filterMap 
> 
> ).
>
>
>
>
>
>
>
> On Thu, Aug 18, 2016 at 4:07 PM, Nick H  > wrote:
>
>> (Well, I don't know if the reactor will be *replaced*, but a debug mode 
>> will be added, and it sounds like it will be much more useful for serious 
>> projects.)
>>
>> On Thu, Aug 18, 2016 at 4:04 PM, Nick H > > wrote:
>>
>>> Couple of things I noticed:
>>>
>>> You are handling window resizing with a port. Elm has a Window module 
>>>  that can 
>>> handle this for you.
>>>
>>> Your Util.range can be replaced by built in syntax [ 0 .. max ]
>>>
>>> For list utilities, I highly recommend looking at 
>>> elm-community/list-extra 
>>> .
>>>  
>>> Similarly, elm-community has dict-extra, maybe-extra, and a whole lot more. 
>>> Just search the package manager for "extra" and you will find a lot of 
>>> stuff!
>>>  
>>> As far as formatting goes, yours looks pretty standard. Were you using 
>>> elm-format?
>>>
>>> Don't feel bad about abandoning the reactor. Evan has said 
>>> 
>>>  
>>> it's going to be replaced with a "debug" flag in the compiler. That will 
>>> allow some of the nice reactor features to be used in programs that are 
>>> embedded in HTML.
>>>
>>>
>>> On Thu, Aug 18, 2016 at 1:43 PM, Thomas Ballinger >> > wrote:
>>>
 Thanks so much for taking a look! I've fixed (a likely cause of) the 
 collision bug. It's fun to hear about your experience playing, despite the 
 current lack of game experience. I'm a fan of the "h it's tetris" 
 realization (and ideally would like to time the music's transition to the 
 tetris theme to this moment) so don't want to start out zoomed out, but 
 plan to put off decisions about that until there's some gameplay. Let me 
 know if you get a chance to look at the code.


 On Thursday, August 18, 2016 at 2:13:41 PM UTC-4, Will White wrote:
>
> Screenshot
>
> On Thursday, August 18, 2016 at 6:25:24 PM UTC+1, Will White wrote:
>>
>> Hi Thomas!
>>
>> I've played the game and I'd like to give you my thoughts on the UX. 
>> I may be able to review the code later. I wish I'd recorded my thoughts 
>> as 
>> I played.
>>
>> I ran right (it's Mario), bumped into a red wall. Ran left, same. 
>> What do I do? Ran right, green block has appeared. Jump over it. Oh, 
>> it's a 
>> Tetris block. Oh, the grey is where the block's coming down. 1 I get 
>> squashed and it bugs out (screenshot). I think I'm able to play on 
>> (arena 
>> not reset). "Tetris controls IJKL" Oh cool, I can control the Tetris 
>> blocks 
>> too!
>>
>> Having a zoomed out view to start with (and then zooming in) would 

[elm-discuss] Re: Code review request

[Thomas Ballinger]

Thanks very much John. The auto-formatter I'm using 
is https://github.com/avh4/elm-format, I also found it to be a bit much. 
I'm a big fan of automatic formatting so might look at changing these 
settings in elm-format, or if anyone knows of other autoformatters please 
let me know.

While adding type annotations I encountered something I didn't understand 
that I worked around 
at 
https://github.com/thomasballinger/loveinthetimeoftetris/blob/3f968afad490ebab54b4f0c3bafdf45b779ebc4b/src/Main.elm#L278,
 
I tried to simplify the behavior and got it down to this 
https://gist.github.com/thomasballinger/a0d8b38fa7186ee2e608d4772f2ebe7e 
which I'd appreciate a hand from anyone in understanding.

I did the rest of these except for switching to SVG, but I'm looking 
forward to that too.
 

> >* I don't think I'll be using evancz/elm-graphics in the future since 
> I'll be doing less gamey stuff or want to work with canvas more directly. 
> How is this usually done?
> By using Svg instead: 
> http://package.elm-lang.org/packages/elm-lang/svg/1.1.1
>
> On Wednesday, August 17, 2016 at 4:40:38 PM UTC-5, Thomas Ballinger wrote:
>>
>> Hi Elm folks! I've enjoyed reading this list for a bit. I've written my 
>> first Elm thing over the last couple weeks and would love to hear any kind 
>> of feedback on it. It's an unfinished game jam piece I kept running with so 
>> the title doesn't make sense.
>>
>> code: https://github.com/thomasballinger/loveinthetimeoftetris
>> live: love.ballingt.com (takes about 70 seconds to play all of)
>>
>> I was going to clean things up the way I know how, but I need to take a 
>> break to get some other things done and I thought I'd learn more by asking 
>> how someone else might clean it up. Please don't assume I know what I'm 
>> doing in the slightest :)
>>
>> Any feedback would be great, but if prompts are helpful:
>> * what does this code make it look like I'm missing about Elm?
>> * what do you think of the extensible record type aliases? I think the 
>> way I've used them is mostly terrible, I designed them up front instead of 
>> letting them evolve.
>> * code style?
>> * I'm using an elm autoformatter, how's my formatting? Is this style 
>> common?
>> * I don't think I'll be using evancz/elm-graphics in the future since 
>> I'll be doing less gamey stuff or want to work with canvas more directly. 
>> How is this usually done?
>> * I abandoned elm reactor once I started embedding in html, is that a 
>> viable workflow I should have stuck with for longer?
>> * I was tempted to start a utils file or look for an external lib but was 
>> trying to focus on learning the stdlib. Are there pretty common util libs 
>> folks use? I sure missed some list functions.
>> * I escaped to JavaScript anytime I thought it would be hard to do 
>> something with the stdlib, presumably it would be nice to use Elm for some 
>> of these things?
>>
>> Thanks so much, and feel free to contact off list if you prefer at 
>> m...@ballingt.com - if you do I'll report back what I learned to the 
>> list.
>>
>

-- 
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: Code review request

[Nick H]

Regarding the extensible records... Movable (Standable (Collidable (Drawable
{}))) sure is a mouthful isn't it? :-)  It looks like every thing in your
game is the union of all four type aliases... so why not just make it one
type alias?


OK, one last thing. This type definition...

type PossibleCollision = NoCollision | Collision CollisionType Float
(Float, Float)

I think the more idiomatic thing to do (but this might just be personal
taste) would be to define

type alias Collision =
{ collisionType : CollisionType
, overlap : Float
, velocity : Float
}

And then in the places where you are using "PossibleCollision," use "Maybe
Collision" instead. The Maybe
 is super
useful for dealing with cases where you have either something or nothing. I
bet that you could shorten your collision detection code a lot by switching
to using Maybes. (For instance, you could use List.filterMap
).







On Thu, Aug 18, 2016 at 4:07 PM, Nick H  wrote:

> (Well, I don't know if the reactor will be *replaced*, but a debug mode
> will be added, and it sounds like it will be much more useful for serious
> projects.)
>
> On Thu, Aug 18, 2016 at 4:04 PM, Nick H  wrote:
>
>> Couple of things I noticed:
>>
>> You are handling window resizing with a port. Elm has a Window module
>>  that can
>> handle this for you.
>>
>> Your Util.range can be replaced by built in syntax [ 0 .. max ]
>>
>> For list utilities, I highly recommend looking at
>> elm-community/list-extra
>> .
>> Similarly, elm-community has dict-extra, maybe-extra, and a whole lot more.
>> Just search the package manager for "extra" and you will find a lot of
>> stuff!
>>
>> As far as formatting goes, yours looks pretty standard. Were you using
>> elm-format?
>>
>> Don't feel bad about abandoning the reactor. Evan has said
>> 
>> it's going to be replaced with a "debug" flag in the compiler. That will
>> allow some of the nice reactor features to be used in programs that are
>> embedded in HTML.
>>
>>
>> On Thu, Aug 18, 2016 at 1:43 PM, Thomas Ballinger <
>> thomasballin...@gmail.com> wrote:
>>
>>> Thanks so much for taking a look! I've fixed (a likely cause of) the
>>> collision bug. It's fun to hear about your experience playing, despite the
>>> current lack of game experience. I'm a fan of the "h it's tetris"
>>> realization (and ideally would like to time the music's transition to the
>>> tetris theme to this moment) so don't want to start out zoomed out, but
>>> plan to put off decisions about that until there's some gameplay. Let me
>>> know if you get a chance to look at the code.
>>>
>>>
>>> On Thursday, August 18, 2016 at 2:13:41 PM UTC-4, Will White wrote:

 Screenshot

 On Thursday, August 18, 2016 at 6:25:24 PM UTC+1, Will White wrote:
>
> Hi Thomas!
>
> I've played the game and I'd like to give you my thoughts on the UX. I
> may be able to review the code later. I wish I'd recorded my thoughts as I
> played.
>
> I ran right (it's Mario), bumped into a red wall. Ran left, same. What
> do I do? Ran right, green block has appeared. Jump over it. Oh, it's a
> Tetris block. Oh, the grey is where the block's coming down. 1 I get
> squashed and it bugs out (screenshot). I think I'm able to play on (arena
> not reset). "Tetris controls IJKL" Oh cool, I can control the Tetris 
> blocks
> too!
>
> Having a zoomed out view to start with (and then zooming in) would
> have got rid of all the thoughts up to 1. Knowing the Tetris controls
> earlier would have been fairer.
>
> Cool idea!
>
> On Wednesday, August 17, 2016 at 10:40:38 PM UTC+1, Thomas Ballinger
> wrote:
>>
>> Hi Elm folks! I've enjoyed reading this list for a bit. I've written
>> my first Elm thing over the last couple weeks and would love to hear any
>> kind of feedback on it. It's an unfinished game jam piece I kept running
>> with so the title doesn't make sense.
>>
>> code: https://github.com/thomasballinger/loveinthetimeoftetris
>> live: love.ballingt.com (takes about 70 seconds to play all of)
>>
>> I was going to clean things up the way I know how, but I need to take
>> a break to get some other things done and I thought I'd learn more by
>> asking how someone else might clean it up. Please don't assume I know 
>> what
>> I'm doing in the slightest :)
>>
>> Any feedback would be great, but if prompts are helpful:
>> * what does this code make it look like I'm missing about Elm?
>> * what do you think of the extensible record type aliases

[elm-discuss] Re: Remove ways of importing except `import exposing (..)`?

[Ian Mackenzie]

It seems to me that the issues you are encountering come from two things:

   - Using a mix of qualified and unqualified imports
   - Having a function the same name as one in Basics

One solution is to never use qualified imports, but a better solution is to 
*always *use qualified imports and just not name any of your own functions 
toString (or min, or max, or degrees, or anything else in Basics). That way 
you never have any ambiguity between functions, you never have to switch 
between qualified and unqualified (if, perhaps, you start using Maybe.map in 
a file that already uses List.map), and it's always clear where a function 
(or value) is coming from.

On Thursday, 18 August 2016 23:33:25 UTC+10, Will White wrote:
>
> import ModuleWithToString
>
> toString typeFromThatModule
>
> Compiles with unexpected results that you have to catch.
>
> import ModuleWithToString exposing (..)
>
> toString typeFromThatModule
>
> Doesn't compile: "use of toString is ambiguous: did you mean 
> Basics.toString or ModuleWithToString.toString?"
>

-- 
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: Code review request

[Nick H]

(Well, I don't know if the reactor will be *replaced*, but a debug mode
will be added, and it sounds like it will be much more useful for serious
projects.)

On Thu, Aug 18, 2016 at 4:04 PM, Nick H  wrote:

> Couple of things I noticed:
>
> You are handling window resizing with a port. Elm has a Window module
>  that can
> handle this for you.
>
> Your Util.range can be replaced by built in syntax [ 0 .. max ]
>
> For list utilities, I highly recommend looking at elm-community/list-extra
> .
> Similarly, elm-community has dict-extra, maybe-extra, and a whole lot more.
> Just search the package manager for "extra" and you will find a lot of
> stuff!
>
> As far as formatting goes, yours looks pretty standard. Were you using
> elm-format?
>
> Don't feel bad about abandoning the reactor. Evan has said
> 
> it's going to be replaced with a "debug" flag in the compiler. That will
> allow some of the nice reactor features to be used in programs that are
> embedded in HTML.
>
>
> On Thu, Aug 18, 2016 at 1:43 PM, Thomas Ballinger <
> thomasballin...@gmail.com> wrote:
>
>> Thanks so much for taking a look! I've fixed (a likely cause of) the
>> collision bug. It's fun to hear about your experience playing, despite the
>> current lack of game experience. I'm a fan of the "h it's tetris"
>> realization (and ideally would like to time the music's transition to the
>> tetris theme to this moment) so don't want to start out zoomed out, but
>> plan to put off decisions about that until there's some gameplay. Let me
>> know if you get a chance to look at the code.
>>
>>
>> On Thursday, August 18, 2016 at 2:13:41 PM UTC-4, Will White wrote:
>>>
>>> Screenshot
>>>
>>> On Thursday, August 18, 2016 at 6:25:24 PM UTC+1, Will White wrote:

 Hi Thomas!

 I've played the game and I'd like to give you my thoughts on the UX. I
 may be able to review the code later. I wish I'd recorded my thoughts as I
 played.

 I ran right (it's Mario), bumped into a red wall. Ran left, same. What
 do I do? Ran right, green block has appeared. Jump over it. Oh, it's a
 Tetris block. Oh, the grey is where the block's coming down. 1 I get
 squashed and it bugs out (screenshot). I think I'm able to play on (arena
 not reset). "Tetris controls IJKL" Oh cool, I can control the Tetris blocks
 too!

 Having a zoomed out view to start with (and then zooming in) would have
 got rid of all the thoughts up to 1. Knowing the Tetris controls earlier
 would have been fairer.

 Cool idea!

 On Wednesday, August 17, 2016 at 10:40:38 PM UTC+1, Thomas Ballinger
 wrote:
>
> Hi Elm folks! I've enjoyed reading this list for a bit. I've written
> my first Elm thing over the last couple weeks and would love to hear any
> kind of feedback on it. It's an unfinished game jam piece I kept running
> with so the title doesn't make sense.
>
> code: https://github.com/thomasballinger/loveinthetimeoftetris
> live: love.ballingt.com (takes about 70 seconds to play all of)
>
> I was going to clean things up the way I know how, but I need to take
> a break to get some other things done and I thought I'd learn more by
> asking how someone else might clean it up. Please don't assume I know what
> I'm doing in the slightest :)
>
> Any feedback would be great, but if prompts are helpful:
> * what does this code make it look like I'm missing about Elm?
> * what do you think of the extensible record type aliases? I think the
> way I've used them is mostly terrible, I designed them up front instead of
> letting them evolve.
> * code style?
> * I'm using an elm autoformatter, how's my formatting? Is this style
> common?
> * I don't think I'll be using evancz/elm-graphics in the future since
> I'll be doing less gamey stuff or want to work with canvas more directly.
> How is this usually done?
> * I abandoned elm reactor once I started embedding in html, is that a
> viable workflow I should have stuck with for longer?
> * I was tempted to start a utils file or look for an external lib but
> was trying to focus on learning the stdlib. Are there pretty common util
> libs folks use? I sure missed some list functions.
> * I escaped to JavaScript anytime I thought it would be hard to do
> something with the stdlib, presumably it would be nice to use Elm for some
> of these things?
>
> Thanks so much, and feel free to contact off list if you prefer at
> m...@ballingt.com - if you do I'll report back what I learned to the
> list.
>
 --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Dis

Re: [elm-discuss] Re: Code review request

[Nick H]

Couple of things I noticed:

You are handling window resizing with a port. Elm has a Window module
 that can
handle this for you.

Your Util.range can be replaced by built in syntax [ 0 .. max ]

For list utilities, I highly recommend looking at elm-community/list-extra
.
Similarly, elm-community has dict-extra, maybe-extra, and a whole lot more.
Just search the package manager for "extra" and you will find a lot of
stuff!

As far as formatting goes, yours looks pretty standard. Were you using
elm-format?

Don't feel bad about abandoning the reactor. Evan has said

it's going to be replaced with a "debug" flag in the compiler. That will
allow some of the nice reactor features to be used in programs that are
embedded in HTML.


On Thu, Aug 18, 2016 at 1:43 PM, Thomas Ballinger  wrote:

> Thanks so much for taking a look! I've fixed (a likely cause of) the
> collision bug. It's fun to hear about your experience playing, despite the
> current lack of game experience. I'm a fan of the "h it's tetris"
> realization (and ideally would like to time the music's transition to the
> tetris theme to this moment) so don't want to start out zoomed out, but
> plan to put off decisions about that until there's some gameplay. Let me
> know if you get a chance to look at the code.
>
>
> On Thursday, August 18, 2016 at 2:13:41 PM UTC-4, Will White wrote:
>>
>> Screenshot
>>
>> On Thursday, August 18, 2016 at 6:25:24 PM UTC+1, Will White wrote:
>>>
>>> Hi Thomas!
>>>
>>> I've played the game and I'd like to give you my thoughts on the UX. I
>>> may be able to review the code later. I wish I'd recorded my thoughts as I
>>> played.
>>>
>>> I ran right (it's Mario), bumped into a red wall. Ran left, same. What
>>> do I do? Ran right, green block has appeared. Jump over it. Oh, it's a
>>> Tetris block. Oh, the grey is where the block's coming down. 1 I get
>>> squashed and it bugs out (screenshot). I think I'm able to play on (arena
>>> not reset). "Tetris controls IJKL" Oh cool, I can control the Tetris blocks
>>> too!
>>>
>>> Having a zoomed out view to start with (and then zooming in) would have
>>> got rid of all the thoughts up to 1. Knowing the Tetris controls earlier
>>> would have been fairer.
>>>
>>> Cool idea!
>>>
>>> On Wednesday, August 17, 2016 at 10:40:38 PM UTC+1, Thomas Ballinger
>>> wrote:

 Hi Elm folks! I've enjoyed reading this list for a bit. I've written my
 first Elm thing over the last couple weeks and would love to hear any kind
 of feedback on it. It's an unfinished game jam piece I kept running with so
 the title doesn't make sense.

 code: https://github.com/thomasballinger/loveinthetimeoftetris
 live: love.ballingt.com (takes about 70 seconds to play all of)

 I was going to clean things up the way I know how, but I need to take a
 break to get some other things done and I thought I'd learn more by asking
 how someone else might clean it up. Please don't assume I know what I'm
 doing in the slightest :)

 Any feedback would be great, but if prompts are helpful:
 * what does this code make it look like I'm missing about Elm?
 * what do you think of the extensible record type aliases? I think the
 way I've used them is mostly terrible, I designed them up front instead of
 letting them evolve.
 * code style?
 * I'm using an elm autoformatter, how's my formatting? Is this style
 common?
 * I don't think I'll be using evancz/elm-graphics in the future since
 I'll be doing less gamey stuff or want to work with canvas more directly.
 How is this usually done?
 * I abandoned elm reactor once I started embedding in html, is that a
 viable workflow I should have stuck with for longer?
 * I was tempted to start a utils file or look for an external lib but
 was trying to focus on learning the stdlib. Are there pretty common util
 libs folks use? I sure missed some list functions.
 * I escaped to JavaScript anytime I thought it would be hard to do
 something with the stdlib, presumably it would be nice to use Elm for some
 of these things?

 Thanks so much, and feel free to contact off list if you prefer at
 m...@ballingt.com - if you do I'll report back what I learned to the
 list.

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

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

[Joey Eremondi]

@Will White: this case is excedingly rare. For example, it's not possible
to write "toString : a -> String" in Pure Elm. It needs Native code to do
so. There are theorems that say that any function of the type (a -> T) for
some concrete type T have to ignore their argument. The key is that
toString isn't polymorphic in its return type.

There won't be (a -> JSON) or (a -> Dict Int String) or (a -> Html Msg)
functions floating around. String is a special case, where we break the
rules for practical debugging.

So yes, it happens any time that there's a function polymorphic in its
argument *and not in its return type*, but this is basically only with
toString. It's not like every module exports its own version of (\ x y ->
x).

The case you describe is possible, and still awkward even if the compiler
does catch your mistake. But the solution is *just don't import Module1WithToX
exposing (..)*. Do Module1WithToX.toX. Your code will be clearer, and it
will not be ambiguous which one you mean.


On Thu, Aug 18, 2016 at 3:26 PM, Will White  wrote:

> Without import exposing (..) by default, it'll be the same problem if
> there are two functions with the same name from two modules, and either
> they both have the same type signature, or one of them is polymorphic in
> its argument.
>
> > import Module1WithToX exposing (toX)
>
> > import Module2WithToX
>
> > toX "r"
>
> "rr" : String
>
> > import Module1WithToX exposing (..)
>
> > import Module2WithToX exposing (..)
>
> > toX "r"
>
> -- NAMING ERROR -- repl-temp-
> 000.elm
>
>
> This usage of variable `toX` is ambiguous.
>
>
> 5|   toX "r"
>
> ^^^
>
> Maybe you want one of the following?
>
>
> Module1WithToX.toX
>
> Module2WithToX.toX
>
>
>
> On Thursday, August 18, 2016 at 10:23:57 PM UTC+1, Joey Eremondi wrote:
>>
>> Okay, so I think this is somewhat of a special case. The problems you are
>> running into come because toString is provided by Basics, so you expected
>> your import to shadow it, but it did not.
>>
>> This is a bit of a tricky scenario:
>> * The typechecker can't help us, because Basics.toString has type (a
>> -> String) i.e. polymorphic in its argument, so it will always typecheck
>> * The whole point of Basics.toString is to be a quick and dirty
>> debugging tool, so needing to import it is a hassle
>>
>> When we use Foo.map, generally the typechecker will tell us if we used
>> List.map when we wanted Maybe.map. So we shouldn't use polymorphic values
>> with the same name when we don't have to.
>>
>> Solutions:
>>   * Rename Basics.toString, maybe to Basics.showAnything, or something
>> similar
>>   * Move Basics.toString to Debug.toString, and import Debug qualified by
>> default.
>>
>> Non-solutions:
>>   * Import everything unqualified by default, shadowing Basics
>>
>>
>>
>> On Thu, Aug 18, 2016 at 2:15 PM, Will White  wrote:
>>
>>> In the first snippet, I was erroneously expecting toString to call
>>> toString from ModuleWithToString, possibly because I'd just been looking at
>>> toString in ModuleWithToString. import exposing (..) makes this foolproof.
>>>
>>> On Thursday, August 18, 2016 at 8:41:02 PM UTC+1, Janis Voigtländer
>>> wrote:

 Or maybe I'm still misunderstanding what your exact problem is in the
 absence of "exposing (..)". Maybe you can expand on the problem description
 from your first message in this thread?

 Am 18.08.2016 um 22:31 schrieb Janis Voigtländer <
 janis.voi...@gmail.com>:

 You won't be able to forget one if "exposing (..)" is eliminated from
 the language, as is proposed in the issue I linked to.

 You'd then either have to qualify or add the entities explicitly in
 "exposing (concrete entities)". Problem solved, because in both cases a
 reader of the code does not need to wonder too much where any given name
 comes from.

 Am 18.08.2016 um 22:19 schrieb Will White :

 Then I'll always namespace them. If I forget one though...

 On Thursday, August 18, 2016 at 6:35:19 PM UTC+1, Janis Voigtländer
 wrote:
>
> More importantly, maybe, you will have to *remember* to use each
> imported function at least once in qualified form in each module, or you
> will end up in the situation Nick described, where in six months you don't
> know (and other readers of your code do not even know the next day after
> you wrote the code) where reticulateSplines comes from.
>
> Am 18.08.2016 um 20:03 schrieb Nick H :
>
> Is that a good idea? It seems like occasionally, but not always, using
> the namespace would make your code less readable than not doing it at all.
>
>
> On Thu, Aug 18, 2016 at 9:37 AM, Will White 
> wrote:
>
>> I can still namespace functions with import exposing (..).
>>
>> On Thursday, August 18, 2016 at 5:08:29 PM UTC+1, Nick H wrote:
>>>
>>> If you prefer not having to remember t

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

[Will White]

Without import exposing (..) by default, it'll be the same problem if there 
are two functions with the same name from two modules, and either they both 
have the same type signature, or one of them is polymorphic in its argument.

> import Module1WithToX exposing (toX)

> import Module2WithToX

> toX "r"

"rr" : String

> import Module1WithToX exposing (..)

> import Module2WithToX exposing (..)

> toX "r"

-- NAMING ERROR -- repl-temp-
000.elm


This usage of variable `toX` is ambiguous.


5|   toX "r"

^^^

Maybe you want one of the following?


Module1WithToX.toX

Module2WithToX.toX



On Thursday, August 18, 2016 at 10:23:57 PM UTC+1, Joey Eremondi wrote:
>
> Okay, so I think this is somewhat of a special case. The problems you are 
> running into come because toString is provided by Basics, so you expected 
> your import to shadow it, but it did not.
>
> This is a bit of a tricky scenario:
> * The typechecker can't help us, because Basics.toString has type (a 
> -> String) i.e. polymorphic in its argument, so it will always typecheck
> * The whole point of Basics.toString is to be a quick and dirty 
> debugging tool, so needing to import it is a hassle
>
> When we use Foo.map, generally the typechecker will tell us if we used 
> List.map when we wanted Maybe.map. So we shouldn't use polymorphic values 
> with the same name when we don't have to.
>
> Solutions:
>   * Rename Basics.toString, maybe to Basics.showAnything, or something 
> similar
>   * Move Basics.toString to Debug.toString, and import Debug qualified by 
> default.
>
> Non-solutions:
>   * Import everything unqualified by default, shadowing Basics
>
>
>
> On Thu, Aug 18, 2016 at 2:15 PM, Will White  > wrote:
>
>> In the first snippet, I was erroneously expecting toString to call 
>> toString from ModuleWithToString, possibly because I'd just been looking at 
>> toString in ModuleWithToString. import exposing (..) makes this foolproof.
>>
>> On Thursday, August 18, 2016 at 8:41:02 PM UTC+1, Janis Voigtländer wrote:
>>>
>>> Or maybe I'm still misunderstanding what your exact problem is in the 
>>> absence of "exposing (..)". Maybe you can expand on the problem description 
>>> from your first message in this thread?
>>>
>>> Am 18.08.2016 um 22:31 schrieb Janis Voigtländer >> >:
>>>
>>> You won't be able to forget one if "exposing (..)" is eliminated from 
>>> the language, as is proposed in the issue I linked to.
>>>
>>> You'd then either have to qualify or add the entities explicitly in 
>>> "exposing (concrete entities)". Problem solved, because in both cases a 
>>> reader of the code does not need to wonder too much where any given name 
>>> comes from. 
>>>
>>> Am 18.08.2016 um 22:19 schrieb Will White :
>>>
>>> Then I'll always namespace them. If I forget one though...
>>>
>>> On Thursday, August 18, 2016 at 6:35:19 PM UTC+1, Janis Voigtländer 
>>> wrote:

 More importantly, maybe, you will have to *remember* to use each 
 imported function at least once in qualified form in each module, or you 
 will end up in the situation Nick described, where in six months you don't 
 know (and other readers of your code do not even know the next day after 
 you wrote the code) where reticulateSplines comes from. 

 Am 18.08.2016 um 20:03 schrieb Nick H :

 Is that a good idea? It seems like occasionally, but not always, using 
 the namespace would make your code less readable than not doing it at all.


 On Thu, Aug 18, 2016 at 9:37 AM, Will White  
 wrote:

> I can still namespace functions with import exposing (..).
>
> On Thursday, August 18, 2016 at 5:08:29 PM UTC+1, Nick H wrote:
>>
>> If you prefer not having to remember things, then you should use 
>> qualified imports.
>>
>> Stripping the namespace off of all your imported functions means that 
>> your code no longer tells you where these functions come from. You will 
>> have to remember this information yourself. This doesn't seem like much 
>> of 
>> a mental burden at the moment, but it will likely become much more 
>> burdensome in 6 months when you are reading through your code again 
>> (e.g. 
>> "Now, which of these 10 modules did that 'reticulateSplines' function 
>> come 
>> from?") And if you never run into that annoyance, I guarantee that every 
>> other person who reads your code will.
>>
>> What's more, APIs that follow the design guidelines 
>>  are 
>> going to make your life even harder, because the functions will have 
>> names 
>> designed to work with a qualifier. Look at your own example. If 
>> "toString" 
>> only works on one type, then it is a terribly undescriptive name. But if 
>> the module is named "Foo" and the type defined in that module is named 
>> "Foo", then "F

Re: [elm-discuss] Re: Elm UI boilerplate

[Kasey Speakman]

I had the same thought... Elm's HTML components stand out as examples of 
self-contained components. But when I checked their implementations, they 
all turned out to be native. Their effects/state are managed by native code 

.

This unfortunately means that the way they work has no corollary in pure 
Elm. Maybe it's possible to build your own components by calling the same 
native functions. I haven't seen any guidance suggesting this approach. I 
would imagine a lot of the safety features are bypassed this way. I think 
even then, all the component's Elm messages would get send to the top of 
the program, not the component itself, the same way Elm messages work for 
standard HTML components.

The view function is pure in that: given the same inputs, the same output 
is generated. But the program on the whole is not pure. (Pure programs are 
generally useless since they can't interact with the outside.) The 
framework steps in to handle turning the rendered HTML into effect-ful 
elements (attaching event handlers, delivering messages, etc).

I, too, wonder if there is a way to bridge the Elm world to native in a 
safe way for building components, but I would be wary of losing the 
benefits of determinism. Currently Elm forces you to write your application 
bits as pure functions so that your code holds no accidental complexity. 
Then it handles the effectful complexity for you, or at least forces it to 
take place "outside" in JS where you're used to it.

On Thursday, August 18, 2016 at 4:47:53 AM UTC-5, Peter Damoc wrote:
>
> Hi Kasey,
>
> Take this code as example: 
>
> import Html exposing (..)
> import Html.App as App
> import Html.Events exposing (..)
>
> main =
>   App.beginnerProgram
> { model = 0
> , view = view
> , update = \msg model -> model
> }
>
> type Msg = NoOp String  
>
> view : Int -> Html Msg
> view model =
>   div []
> [ input [onInput NoOp ][]
> ]
>  
> if you type in the input of this short program you will see characters. 
> Those characters are not part of the model. 
> Every time you press something, the view is called again with the exact 
> same argument and what you see on the screen is different. 
>
> In order for this input component to work, there has to be state. State 
> that holds the characters typed, state that holds the cursor position, even 
> state that animates that cursor. 
>
> So, if elm views are pure, what does this make `Html msg`? 
>
> The easiest answer I could come up with is that `Html msg` behaves like 
> the record you give to a `Html.App.program`
>
> Given this record, the runtime could create some state if it hasn't 
> already done this and use the provided functions to update it / represent 
> it.  
>
> Of course, elm-html is not implemented like this but, from a type 
> conceptualization point of view, this is the easiest way that I could find 
> to explain the *behavior* or elm-html and still maintain the idea that 
> the view is pure. 
>
> And this brings us back to the issue of boilerplate. If elm-html can do 
> this automatic state and avoid the boilerplate, how can alternatives to 
> elm-html do the same thing? 
>
> Another way to think about it is, how would a pure Elm ui be implemented 
> if there would not be the support of state management that the dom does? 
> (Imagine a cross platform UI implemented in Elm on top of something like a 
> canvas ) 
>
>
>
>
>
>
>
> On Thu, Aug 18, 2016 at 11:32 AM, Kasey Speakman  > wrote:
>
>> I've hesitated to mention this since I'm a newcomer to Elm, but I'll 
>> throw it out there and see what you think.
>>
>> The way Elm currently renders subcomponents is because the view is a pure 
>> function, so all subparts must be pure functions. That's what makes 
>> stateful subcomponents irritating to work with... the boilerplate of 
>> accounting for them in the parent.
>>
>> As a thought experiment, what if Elm were to bring in support for UI 
>> components that were independent of Main? They get wired to received 
>> init/update/view independently of the parent. They get avenues to send 
>> messages to the parent and vice versa. They get some state from the parent 
>> on init. Etc. That path has already been well-traveled by most every other 
>> front-end so we can know the answer. Doing that is basically bringing in 
>> object orientation and all the accidental complexity that comes with it. 
>> Right now Elm steers us away from those problems by forcing our code to be 
>> deterministic, but with the trade-off of the parent being responsible for 
>> everything underneath (requiring the boilerplate).
>>
>> That's not an answer to the issue at hand. It's just an observation that 
>> Elm does provide a (perhaps non-obvious) benefit with the current way it 
>> does things. It still definitely has pain, but it's clear-cut as opposed to 
>> accidental and pervasive. So I think that's why we hear the advice from

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

[Joey Eremondi]

Okay, so I think this is somewhat of a special case. The problems you are
running into come because toString is provided by Basics, so you expected
your import to shadow it, but it did not.

This is a bit of a tricky scenario:
* The typechecker can't help us, because Basics.toString has type (a ->
String) i.e. polymorphic in its argument, so it will always typecheck
* The whole point of Basics.toString is to be a quick and dirty
debugging tool, so needing to import it is a hassle

When we use Foo.map, generally the typechecker will tell us if we used
List.map when we wanted Maybe.map. So we shouldn't use polymorphic values
with the same name when we don't have to.

Solutions:
  * Rename Basics.toString, maybe to Basics.showAnything, or something
similar
  * Move Basics.toString to Debug.toString, and import Debug qualified by
default.

Non-solutions:
  * Import everything unqualified by default, shadowing Basics



On Thu, Aug 18, 2016 at 2:15 PM, Will White  wrote:

> In the first snippet, I was erroneously expecting toString to call
> toString from ModuleWithToString, possibly because I'd just been looking at
> toString in ModuleWithToString. import exposing (..) makes this foolproof.
>
> On Thursday, August 18, 2016 at 8:41:02 PM UTC+1, Janis Voigtländer wrote:
>>
>> Or maybe I'm still misunderstanding what your exact problem is in the
>> absence of "exposing (..)". Maybe you can expand on the problem description
>> from your first message in this thread?
>>
>> Am 18.08.2016 um 22:31 schrieb Janis Voigtländer > >:
>>
>> You won't be able to forget one if "exposing (..)" is eliminated from the
>> language, as is proposed in the issue I linked to.
>>
>> You'd then either have to qualify or add the entities explicitly in
>> "exposing (concrete entities)". Problem solved, because in both cases a
>> reader of the code does not need to wonder too much where any given name
>> comes from.
>>
>> Am 18.08.2016 um 22:19 schrieb Will White :
>>
>> Then I'll always namespace them. If I forget one though...
>>
>> On Thursday, August 18, 2016 at 6:35:19 PM UTC+1, Janis Voigtländer wrote:
>>>
>>> More importantly, maybe, you will have to *remember* to use each
>>> imported function at least once in qualified form in each module, or you
>>> will end up in the situation Nick described, where in six months you don't
>>> know (and other readers of your code do not even know the next day after
>>> you wrote the code) where reticulateSplines comes from.
>>>
>>> Am 18.08.2016 um 20:03 schrieb Nick H :
>>>
>>> Is that a good idea? It seems like occasionally, but not always, using
>>> the namespace would make your code less readable than not doing it at all.
>>>
>>>
>>> On Thu, Aug 18, 2016 at 9:37 AM, Will White  wrote:
>>>
 I can still namespace functions with import exposing (..).

 On Thursday, August 18, 2016 at 5:08:29 PM UTC+1, Nick H wrote:
>
> If you prefer not having to remember things, then you should use
> qualified imports.
>
> Stripping the namespace off of all your imported functions means that
> your code no longer tells you where these functions come from. You will
> have to remember this information yourself. This doesn't seem like much of
> a mental burden at the moment, but it will likely become much more
> burdensome in 6 months when you are reading through your code again (e.g.
> "Now, which of these 10 modules did that 'reticulateSplines' function come
> from?") And if you never run into that annoyance, I guarantee that every
> other person who reads your code will.
>
> What's more, APIs that follow the design guidelines
>  are going
> to make your life even harder, because the functions will have names
> designed to work with a qualifier. Look at your own example. If "toString"
> only works on one type, then it is a terribly undescriptive name. But if
> the module is named "Foo" and the type defined in that module is named
> "Foo", then "Foo.toString" is not a terrible name.
>
> From the design guidelines:
>
>> A function called State.runState is redundant and silly. More
>> importantly, it encourages people to use import State exposing (..)
>> which does not scale well. In files with many so-called "unqualified"
>> dependencies, it is essentially impossible to figure out where functions
>> are coming from. This can make large code bases impossible to understand,
>> especially if custom infix operators are used as well. Repeating the 
>> module
>> name actively encourages this kind of unreadable code.
>> With a name like State.run the user is encouraged to disambiguate
>> functions with namespacing, leading to a codebase that will be clearer to
>> people reading the project for the first time. A great example from the
>> standard library is Bitwise.and
>>
>
>
> On Thu, Aug 

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

[Will White]

In the first snippet, I was erroneously expecting toString to call toString 
from ModuleWithToString, possibly because I'd just been looking at toString 
in ModuleWithToString. import exposing (..) makes this foolproof.

On Thursday, August 18, 2016 at 8:41:02 PM UTC+1, Janis Voigtländer wrote:
>
> Or maybe I'm still misunderstanding what your exact problem is in the 
> absence of "exposing (..)". Maybe you can expand on the problem description 
> from your first message in this thread?
>
> Am 18.08.2016 um 22:31 schrieb Janis Voigtländer  >:
>
> You won't be able to forget one if "exposing (..)" is eliminated from the 
> language, as is proposed in the issue I linked to.
>
> You'd then either have to qualify or add the entities explicitly in 
> "exposing (concrete entities)". Problem solved, because in both cases a 
> reader of the code does not need to wonder too much where any given name 
> comes from. 
>
> Am 18.08.2016 um 22:19 schrieb Will White  >:
>
> Then I'll always namespace them. If I forget one though...
>
> On Thursday, August 18, 2016 at 6:35:19 PM UTC+1, Janis Voigtländer wrote:
>>
>> More importantly, maybe, you will have to *remember* to use each imported 
>> function at least once in qualified form in each module, or you will end up 
>> in the situation Nick described, where in six months you don't know (and 
>> other readers of your code do not even know the next day after you wrote 
>> the code) where reticulateSplines comes from. 
>>
>> Am 18.08.2016 um 20:03 schrieb Nick H :
>>
>> Is that a good idea? It seems like occasionally, but not always, using 
>> the namespace would make your code less readable than not doing it at all.
>>
>>
>> On Thu, Aug 18, 2016 at 9:37 AM, Will White  wrote:
>>
>>> I can still namespace functions with import exposing (..).
>>>
>>> On Thursday, August 18, 2016 at 5:08:29 PM UTC+1, Nick H wrote:

 If you prefer not having to remember things, then you should use 
 qualified imports.

 Stripping the namespace off of all your imported functions means that 
 your code no longer tells you where these functions come from. You will 
 have to remember this information yourself. This doesn't seem like much of 
 a mental burden at the moment, but it will likely become much more 
 burdensome in 6 months when you are reading through your code again (e.g. 
 "Now, which of these 10 modules did that 'reticulateSplines' function come 
 from?") And if you never run into that annoyance, I guarantee that every 
 other person who reads your code will.

 What's more, APIs that follow the design guidelines 
  are going 
 to make your life even harder, because the functions will have names 
 designed to work with a qualifier. Look at your own example. If "toString" 
 only works on one type, then it is a terribly undescriptive name. But if 
 the module is named "Foo" and the type defined in that module is named 
 "Foo", then "Foo.toString" is not a terrible name.

 From the design guidelines:

> A function called State.runState is redundant and silly. More 
> importantly, it encourages people to use import State exposing (..) 
> which does not scale well. In files with many so-called "unqualified" 
> dependencies, it is essentially impossible to figure out where functions 
> are coming from. This can make large code bases impossible to understand, 
> especially if custom infix operators are used as well. Repeating the 
> module 
> name actively encourages this kind of unreadable code.
> With a name like State.run the user is encouraged to disambiguate 
> functions with namespacing, leading to a codebase that will be clearer to 
> people reading the project for the first time. A great example from the 
> standard library is Bitwise.and
>


 On Thu, Aug 18, 2016 at 8:18 AM, Janis Voigtländer <
 janis.voi...@gmail.com> wrote:

> I can’t search for the thread right now, but I’m sure you can find it 
> yourself via the archive. In any case, one aspect of it (but I think 
> there 
> were more) was this: https://github.com/elm-lang/elm-make/issues/61 
> ​
>
> 2016-08-18 17:08 GMT+02:00 Will White :
>
>> What unexpected results? The compiler has your back if two 
>> unqualified functions have the same name.
>>
>> On Thursday, August 18, 2016 at 3:56:50 PM UTC+1, Janis Voigtländer 
>> wrote:
>>>
>>> That's not an answer to my question I understand as a problem 
>>> description. 
>>>
>>> Also, there have been earlier threads here that have discussed what 
>>> can go wrong if you unwittingly import with exposing everything. So, 
>>> where 
>>> not remembering that one of those imports brought a certain function 
>>> name 
>>> into scope, lead to unexpected results. If your concern 

[elm-discuss] Re: Code review request

[Thomas Ballinger]

Thanks so much for taking a look! I've fixed (a likely cause of) the 
collision bug. It's fun to hear about your experience playing, despite the 
current lack of game experience. I'm a fan of the "h it's tetris" 
realization (and ideally would like to time the music's transition to the 
tetris theme to this moment) so don't want to start out zoomed out, but 
plan to put off decisions about that until there's some gameplay. Let me 
know if you get a chance to look at the code.

On Thursday, August 18, 2016 at 2:13:41 PM UTC-4, Will White wrote:
>
> Screenshot
>
> On Thursday, August 18, 2016 at 6:25:24 PM UTC+1, Will White wrote:
>>
>> Hi Thomas!
>>
>> I've played the game and I'd like to give you my thoughts on the UX. I 
>> may be able to review the code later. I wish I'd recorded my thoughts as I 
>> played.
>>
>> I ran right (it's Mario), bumped into a red wall. Ran left, same. What do 
>> I do? Ran right, green block has appeared. Jump over it. Oh, it's a Tetris 
>> block. Oh, the grey is where the block's coming down. 1 I get squashed and 
>> it bugs out (screenshot). I think I'm able to play on (arena not reset). 
>> "Tetris controls IJKL" Oh cool, I can control the Tetris blocks too!
>>
>> Having a zoomed out view to start with (and then zooming in) would have 
>> got rid of all the thoughts up to 1. Knowing the Tetris controls earlier 
>> would have been fairer.
>>
>> Cool idea!
>>
>> On Wednesday, August 17, 2016 at 10:40:38 PM UTC+1, Thomas Ballinger 
>> wrote:
>>>
>>> Hi Elm folks! I've enjoyed reading this list for a bit. I've written my 
>>> first Elm thing over the last couple weeks and would love to hear any kind 
>>> of feedback on it. It's an unfinished game jam piece I kept running with so 
>>> the title doesn't make sense.
>>>
>>> code: https://github.com/thomasballinger/loveinthetimeoftetris
>>> live: love.ballingt.com (takes about 70 seconds to play all of)
>>>
>>> I was going to clean things up the way I know how, but I need to take a 
>>> break to get some other things done and I thought I'd learn more by asking 
>>> how someone else might clean it up. Please don't assume I know what I'm 
>>> doing in the slightest :)
>>>
>>> Any feedback would be great, but if prompts are helpful:
>>> * what does this code make it look like I'm missing about Elm?
>>> * what do you think of the extensible record type aliases? I think the 
>>> way I've used them is mostly terrible, I designed them up front instead of 
>>> letting them evolve.
>>> * code style?
>>> * I'm using an elm autoformatter, how's my formatting? Is this style 
>>> common?
>>> * I don't think I'll be using evancz/elm-graphics in the future since 
>>> I'll be doing less gamey stuff or want to work with canvas more directly. 
>>> How is this usually done?
>>> * I abandoned elm reactor once I started embedding in html, is that a 
>>> viable workflow I should have stuck with for longer?
>>> * I was tempted to start a utils file or look for an external lib but 
>>> was trying to focus on learning the stdlib. Are there pretty common util 
>>> libs folks use? I sure missed some list functions.
>>> * I escaped to JavaScript anytime I thought it would be hard to do 
>>> something with the stdlib, presumably it would be nice to use Elm for some 
>>> of these things?
>>>
>>> Thanks so much, and feel free to contact off list if you prefer at 
>>> m...@ballingt.com - if you do I'll report back what I learned to the 
>>> list.
>>>
>>

-- 
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: Code review request

[John Bugner]

I just browsed around a bit, and noticed the following things:
(1) Put your code in a source folder. Having all your elm files in the same 
folder as elm-package.json, .gitignore, index.html, etc is distracting. To 
do this, add your source folder to the "source-directories" property in 
elm-package.json, like this:
currently:
source-directories": [
"."
],
change it to:
"source-directories": [
"src"
],
(2) Auto-formatter? I don't like this one. It needlessly deeply indents 
things, like the 'rotations'' function 
here: 
https://github.com/thomasballinger/loveinthetimeoftetris/blob/master/Piece.elm#L172
 
I prefer to put 'case ... of' on one line, the same line as the '=' it 
follows, because it's usually short. Too much indentation makes code 
unreadable. I think the official coding style (unfortunately) promotes this 
though...
(3) 'rotate' looks very 
inefficient: 
https://github.com/thomasballinger/loveinthetimeoftetris/blob/master/Piece.elm#L172
 
It's just a bunch of 'if's. Why not turn 'Piece' into an enum type, and 
then have 'rotate' pattern match the enum? ... The texture property looks 
like it should just be a wrapper: 'type Textured a = Textured Int a'. ... 
Using an 'Int' as an index for some list/array (I assume that's how it's 
working.) is very C-like. Unless there's a nearly unlimited amount of 
textures (one for each integer value), use an enumeration with a fixed 
amount of constructors instead. To me, a type represents not only the shape 
of its underlying data, *but also its **semantics** *. (I admit, Elm 
doesn't fully embrace this philosophy yet, (partly because nearly all the 
languages that have come before it don't either, so people still have 
trouble thinking outside the C-like imperative-OO box), but I think it's 
the way forward, because when it's paired with a strong type system like 
Haskell's or Elm's, it prevents many logic errors, like adding 1 meter to 2 
feet and getting 3 feet, or 4 ticks to 5 seconds and getting 9 seconds, or 
7 apples to 8 oranges and getting 15 oranges, etc.)
(4) You should always give a function a type annotation: 
https://github.com/thomasballinger/loveinthetimeoftetris/blob/master/Progression.elm#L23
 
. 

>* I don't think I'll be using evancz/elm-graphics in the future since I'll 
be doing less gamey stuff or want to work with canvas more directly. How is 
this usually done?
By using Svg 
instead: http://package.elm-lang.org/packages/elm-lang/svg/1.1.1

On Wednesday, August 17, 2016 at 4:40:38 PM UTC-5, Thomas Ballinger wrote:
>
> Hi Elm folks! I've enjoyed reading this list for a bit. I've written my 
> first Elm thing over the last couple weeks and would love to hear any kind 
> of feedback on it. It's an unfinished game jam piece I kept running with so 
> the title doesn't make sense.
>
> code: https://github.com/thomasballinger/loveinthetimeoftetris
> live: love.ballingt.com (takes about 70 seconds to play all of)
>
> I was going to clean things up the way I know how, but I need to take a 
> break to get some other things done and I thought I'd learn more by asking 
> how someone else might clean it up. Please don't assume I know what I'm 
> doing in the slightest :)
>
> Any feedback would be great, but if prompts are helpful:
> * what does this code make it look like I'm missing about Elm?
> * what do you think of the extensible record type aliases? I think the way 
> I've used them is mostly terrible, I designed them up front instead of 
> letting them evolve.
> * code style?
> * I'm using an elm autoformatter, how's my formatting? Is this style 
> common?
> * I don't think I'll be using evancz/elm-graphics in the future since I'll 
> be doing less gamey stuff or want to work with canvas more directly. How is 
> this usually done?
> * I abandoned elm reactor once I started embedding in html, is that a 
> viable workflow I should have stuck with for longer?
> * I was tempted to start a utils file or look for an external lib but was 
> trying to focus on learning the stdlib. Are there pretty common util libs 
> folks use? I sure missed some list functions.
> * I escaped to JavaScript anytime I thought it would be hard to do 
> something with the stdlib, presumably it would be nice to use Elm for some 
> of these things?
>
> Thanks so much, and feel free to contact off list if you prefer at 
> m...@ballingt.com  - if you do I'll report back what I 
> learned to the list.
>

-- 
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] Remove ways of importing except `import exposing (..)`?

[Janis Voigtländer]

Or maybe I'm still misunderstanding what your exact problem is in the absence 
of "exposing (..)". Maybe you can expand on the problem description from your 
first message in this thread?

> Am 18.08.2016 um 22:31 schrieb Janis Voigtländer 
> :
> 
> You won't be able to forget one if "exposing (..)" is eliminated from the 
> language, as is proposed in the issue I linked to.
> 
> You'd then either have to qualify or add the entities explicitly in "exposing 
> (concrete entities)". Problem solved, because in both cases a reader of the 
> code does not need to wonder too much where any given name comes from. 
> 
>> Am 18.08.2016 um 22:19 schrieb Will White :
>> 
>> Then I'll always namespace them. If I forget one though...
>> 
>>> On Thursday, August 18, 2016 at 6:35:19 PM UTC+1, Janis Voigtländer wrote:
>>> More importantly, maybe, you will have to *remember* to use each imported 
>>> function at least once in qualified form in each module, or you will end up 
>>> in the situation Nick described, where in six months you don't know (and 
>>> other readers of your code do not even know the next day after you wrote 
>>> the code) where reticulateSplines comes from. 
>>> 
 Am 18.08.2016 um 20:03 schrieb Nick H :
 
 Is that a good idea? It seems like occasionally, but not always, using the 
 namespace would make your code less readable than not doing it at all.
 
 
> On Thu, Aug 18, 2016 at 9:37 AM, Will White  wrote:
> I can still namespace functions with import exposing (..).
> 
>> On Thursday, August 18, 2016 at 5:08:29 PM UTC+1, Nick H wrote:
>> If you prefer not having to remember things, then you should use 
>> qualified imports.
>> 
>> Stripping the namespace off of all your imported functions means that 
>> your code no longer tells you where these functions come from. You will 
>> have to remember this information yourself. This doesn't seem like much 
>> of a mental burden at the moment, but it will likely become much more 
>> burdensome in 6 months when you are reading through your code again 
>> (e.g. "Now, which of these 10 modules did that 'reticulateSplines' 
>> function come from?") And if you never run into that annoyance, I 
>> guarantee that every other person who reads your code will.
>> 
>> What's more, APIs that follow the design guidelines are going to make 
>> your life even harder, because the functions will have names designed to 
>> work with a qualifier. Look at your own example. If "toString" only 
>> works on one type, then it is a terribly undescriptive name. But if the 
>> module is named "Foo" and the type defined in that module is named 
>> "Foo", then "Foo.toString" is not a terrible name.
>> 
>> From the design guidelines:
>>> A function called State.runState is redundant and silly. More 
>>> importantly, it encourages people to use import State exposing (..) 
>>> which does not scale well. In files with many so-called "unqualified" 
>>> dependencies, it is essentially impossible to figure out where 
>>> functions are coming from. This can make large code bases impossible to 
>>> understand, especially if custom infix operators are used as well. 
>>> Repeating the module name actively encourages this kind of unreadable 
>>> code.
>>> 
>>> With a name like State.run the user is encouraged to disambiguate 
>>> functions with namespacing, leading to a codebase that will be clearer 
>>> to people reading the project for the first time. A great example from 
>>> the standard library is Bitwise.and
>> 
>> 
>>> On Thu, Aug 18, 2016 at 8:18 AM, Janis Voigtländer 
>>>  wrote:
>>> I can’t search for the thread right now, but I’m sure you can find it 
>>> yourself via the archive. In any case, one aspect of it (but I think 
>>> there were more) was this: 
>>> https://github.com/elm-lang/elm-make/issues/61
>>> 
>>> 
>>> 2016-08-18 17:08 GMT+02:00 Will White :
 What unexpected results? The compiler has your back if two unqualified 
 functions have the same name.
 
> On Thursday, August 18, 2016 at 3:56:50 PM UTC+1, Janis Voigtländer 
> wrote:
> That's not an answer to my question I understand as a problem 
> description. 
> 
> Also, there have been earlier threads here that have discussed what 
> can go wrong if you unwittingly import with exposing everything. So, 
> where not remembering that one of those imports brought a certain 
> function name into scope, lead to unexpected results. If your concern 
> is valid, theirs is at least as much. 
> 
>> Am 18.08.2016 um 17:48 schrieb Will White :
>> 
>> You have to remember to qualify.
>> 
>>> On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis Voigtländer 
>>> wrote:
>

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

[Janis Voigtländer]

You won't be able to forget one if "exposing (..)" is eliminated from the 
language, as is proposed in the issue I linked to.

You'd then either have to qualify or add the entities explicitly in "exposing 
(concrete entities)". Problem solved, because in both cases a reader of the 
code does not need to wonder too much where any given name comes from. 

> Am 18.08.2016 um 22:19 schrieb Will White :
> 
> Then I'll always namespace them. If I forget one though...
> 
>> On Thursday, August 18, 2016 at 6:35:19 PM UTC+1, Janis Voigtländer wrote:
>> More importantly, maybe, you will have to *remember* to use each imported 
>> function at least once in qualified form in each module, or you will end up 
>> in the situation Nick described, where in six months you don't know (and 
>> other readers of your code do not even know the next day after you wrote the 
>> code) where reticulateSplines comes from. 
>> 
>>> Am 18.08.2016 um 20:03 schrieb Nick H :
>>> 
>>> Is that a good idea? It seems like occasionally, but not always, using the 
>>> namespace would make your code less readable than not doing it at all.
>>> 
>>> 
 On Thu, Aug 18, 2016 at 9:37 AM, Will White  wrote:
 I can still namespace functions with import exposing (..).
 
> On Thursday, August 18, 2016 at 5:08:29 PM UTC+1, Nick H wrote:
> If you prefer not having to remember things, then you should use 
> qualified imports.
> 
> Stripping the namespace off of all your imported functions means that 
> your code no longer tells you where these functions come from. You will 
> have to remember this information yourself. This doesn't seem like much 
> of a mental burden at the moment, but it will likely become much more 
> burdensome in 6 months when you are reading through your code again (e.g. 
> "Now, which of these 10 modules did that 'reticulateSplines' function 
> come from?") And if you never run into that annoyance, I guarantee that 
> every other person who reads your code will.
> 
> What's more, APIs that follow the design guidelines are going to make 
> your life even harder, because the functions will have names designed to 
> work with a qualifier. Look at your own example. If "toString" only works 
> on one type, then it is a terribly undescriptive name. But if the module 
> is named "Foo" and the type defined in that module is named "Foo", then 
> "Foo.toString" is not a terrible name.
> 
> From the design guidelines:
>> A function called State.runState is redundant and silly. More 
>> importantly, it encourages people to use import State exposing (..) 
>> which does not scale well. In files with many so-called "unqualified" 
>> dependencies, it is essentially impossible to figure out where functions 
>> are coming from. This can make large code bases impossible to 
>> understand, especially if custom infix operators are used as well. 
>> Repeating the module name actively encourages this kind of unreadable 
>> code.
>> 
>> With a name like State.run the user is encouraged to disambiguate 
>> functions with namespacing, leading to a codebase that will be clearer 
>> to people reading the project for the first time. A great example from 
>> the standard library is Bitwise.and
> 
> 
>> On Thu, Aug 18, 2016 at 8:18 AM, Janis Voigtländer 
>>  wrote:
>> I can’t search for the thread right now, but I’m sure you can find it 
>> yourself via the archive. In any case, one aspect of it (but I think 
>> there were more) was this: https://github.com/elm-lang/elm-make/issues/61
>> 
>> 
>> 2016-08-18 17:08 GMT+02:00 Will White :
>>> What unexpected results? The compiler has your back if two unqualified 
>>> functions have the same name.
>>> 
 On Thursday, August 18, 2016 at 3:56:50 PM UTC+1, Janis Voigtländer 
 wrote:
 That's not an answer to my question I understand as a problem 
 description. 
 
 Also, there have been earlier threads here that have discussed what 
 can go wrong if you unwittingly import with exposing everything. So, 
 where not remembering that one of those imports brought a certain 
 function name into scope, lead to unexpected results. If your concern 
 is valid, theirs is at least as much. 
 
> Am 18.08.2016 um 17:48 schrieb Will White :
> 
> You have to remember to qualify.
> 
>> On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis Voigtländer 
>> wrote:
>> In what ways are qualified imports at odds with safe code?
>> 
>> I think the opposite is the case: unqualified imports lead to less 
>> code safety. 
>> 
>>> Am 18.08.2016 um 17:37 schrieb Will White :
>>> 
>>> I prefer safe code to qualified imports.
>>> 
>>> On Thursday

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

[Will White]

Then I'll always namespace them. If I forget one though...

On Thursday, August 18, 2016 at 6:35:19 PM UTC+1, Janis Voigtländer wrote:
>
> More importantly, maybe, you will have to *remember* to use each imported 
> function at least once in qualified form in each module, or you will end up 
> in the situation Nick described, where in six months you don't know (and 
> other readers of your code do not even know the next day after you wrote 
> the code) where reticulateSplines comes from. 
>
> Am 18.08.2016 um 20:03 schrieb Nick H 
> >:
>
> Is that a good idea? It seems like occasionally, but not always, using the 
> namespace would make your code less readable than not doing it at all.
>
>
> On Thu, Aug 18, 2016 at 9:37 AM, Will White  > wrote:
>
>> I can still namespace functions with import exposing (..).
>>
>> On Thursday, August 18, 2016 at 5:08:29 PM UTC+1, Nick H wrote:
>>>
>>> If you prefer not having to remember things, then you should use 
>>> qualified imports.
>>>
>>> Stripping the namespace off of all your imported functions means that 
>>> your code no longer tells you where these functions come from. You will 
>>> have to remember this information yourself. This doesn't seem like much of 
>>> a mental burden at the moment, but it will likely become much more 
>>> burdensome in 6 months when you are reading through your code again (e.g. 
>>> "Now, which of these 10 modules did that 'reticulateSplines' function come 
>>> from?") And if you never run into that annoyance, I guarantee that every 
>>> other person who reads your code will.
>>>
>>> What's more, APIs that follow the design guidelines 
>>>  are going 
>>> to make your life even harder, because the functions will have names 
>>> designed to work with a qualifier. Look at your own example. If "toString" 
>>> only works on one type, then it is a terribly undescriptive name. But if 
>>> the module is named "Foo" and the type defined in that module is named 
>>> "Foo", then "Foo.toString" is not a terrible name.
>>>
>>> From the design guidelines:
>>>
 A function called State.runState is redundant and silly. More 
 importantly, it encourages people to use import State exposing (..) 
 which does not scale well. In files with many so-called "unqualified" 
 dependencies, it is essentially impossible to figure out where functions 
 are coming from. This can make large code bases impossible to understand, 
 especially if custom infix operators are used as well. Repeating the 
 module 
 name actively encourages this kind of unreadable code.
 With a name like State.run the user is encouraged to disambiguate 
 functions with namespacing, leading to a codebase that will be clearer to 
 people reading the project for the first time. A great example from the 
 standard library is Bitwise.and

>>>
>>>
>>> On Thu, Aug 18, 2016 at 8:18 AM, Janis Voigtländer <
>>> janis.voi...@gmail.com> wrote:
>>>
 I can’t search for the thread right now, but I’m sure you can find it 
 yourself via the archive. In any case, one aspect of it (but I think there 
 were more) was this: https://github.com/elm-lang/elm-make/issues/61 
 ​

 2016-08-18 17:08 GMT+02:00 Will White :

> What unexpected results? The compiler has your back if two unqualified 
> functions have the same name.
>
> On Thursday, August 18, 2016 at 3:56:50 PM UTC+1, Janis Voigtländer 
> wrote:
>>
>> That's not an answer to my question I understand as a problem 
>> description. 
>>
>> Also, there have been earlier threads here that have discussed what 
>> can go wrong if you unwittingly import with exposing everything. So, 
>> where 
>> not remembering that one of those imports brought a certain function 
>> name 
>> into scope, lead to unexpected results. If your concern is valid, theirs 
>> is 
>> at least as much. 
>>
>> Am 18.08.2016 um 17:48 schrieb Will White :
>>
>> You have to remember to qualify.
>>
>> On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis Voigtländer 
>> wrote:
>>>
>>> In what ways are qualified imports at odds with safe code?
>>>
>>> I think the opposite is the case: unqualified imports lead to less 
>>> code safety. 
>>>
>>> Am 18.08.2016 um 17:37 schrieb Will White :
>>>
>>> I prefer safe code to qualified imports.
>>>
>>> On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc wrote:

 "Qualified imports are preferred."

 http://elm-lang.org/docs/syntax#modules

 I try to avoid as much as possible importing everything from a 
 module. 
 If I would have IDE support for automatic imports I would never do a 
 import 
 Module exposing (..). 

 -- 
>>> You received this message because you are subscrib

[elm-discuss] Re: Code review request

[Will White]

Screenshot

On Thursday, August 18, 2016 at 6:25:24 PM UTC+1, Will White wrote:
>
> Hi Thomas!
>
> I've played the game and I'd like to give you my thoughts on the UX. I may 
> be able to review the code later. I wish I'd recorded my thoughts as I 
> played.
>
> I ran right (it's Mario), bumped into a red wall. Ran left, same. What do 
> I do? Ran right, green block has appeared. Jump over it. Oh, it's a Tetris 
> block. Oh, the grey is where the block's coming down. 1 I get squashed and 
> it bugs out (screenshot). I think I'm able to play on (arena not reset). 
> "Tetris controls IJKL" Oh cool, I can control the Tetris blocks too!
>
> Having a zoomed out view to start with (and then zooming in) would have 
> got rid of all the thoughts up to 1. Knowing the Tetris controls earlier 
> would have been fairer.
>
> Cool idea!
>
> On Wednesday, August 17, 2016 at 10:40:38 PM UTC+1, Thomas Ballinger wrote:
>>
>> Hi Elm folks! I've enjoyed reading this list for a bit. I've written my 
>> first Elm thing over the last couple weeks and would love to hear any kind 
>> of feedback on it. It's an unfinished game jam piece I kept running with so 
>> the title doesn't make sense.
>>
>> code: https://github.com/thomasballinger/loveinthetimeoftetris
>> live: love.ballingt.com (takes about 70 seconds to play all of)
>>
>> I was going to clean things up the way I know how, but I need to take a 
>> break to get some other things done and I thought I'd learn more by asking 
>> how someone else might clean it up. Please don't assume I know what I'm 
>> doing in the slightest :)
>>
>> Any feedback would be great, but if prompts are helpful:
>> * what does this code make it look like I'm missing about Elm?
>> * what do you think of the extensible record type aliases? I think the 
>> way I've used them is mostly terrible, I designed them up front instead of 
>> letting them evolve.
>> * code style?
>> * I'm using an elm autoformatter, how's my formatting? Is this style 
>> common?
>> * I don't think I'll be using evancz/elm-graphics in the future since 
>> I'll be doing less gamey stuff or want to work with canvas more directly. 
>> How is this usually done?
>> * I abandoned elm reactor once I started embedding in html, is that a 
>> viable workflow I should have stuck with for longer?
>> * I was tempted to start a utils file or look for an external lib but was 
>> trying to focus on learning the stdlib. Are there pretty common util libs 
>> folks use? I sure missed some list functions.
>> * I escaped to JavaScript anytime I thought it would be hard to do 
>> something with the stdlib, presumably it would be nice to use Elm for some 
>> of these things?
>>
>> Thanks so much, and feel free to contact off list if you prefer at 
>> m...@ballingt.com - if you do I'll report back what I learned to the 
>> list.
>>
>

-- 
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: More thorough side-effect isolation

[Kasey Speakman]

However, I had been using Cmd as the vehicle to get the messages back to
the top of the application.

On Thu, Aug 18, 2016 at 12:46 PM, Kasey Speakman 
wrote:

> You could be right. I'm thinking of back-end systems where a PM may need
> to send a command to an "external" system (or even calls to its own system
> are done as "external" calls), so I/O is involved. Maybe that scenario
> doesn't apply on the front-end.
>
> On Thu, Aug 18, 2016 at 9:32 AM, Marco Perone  wrote:
>
>> Thanks Kasey for your observations!
>>
>> I agree with everything except for one thing. Regarding `process`, I
>> don't think it should return a Cmd Command. Cmd generates asynchronous
>> operations, and we receive a notification when they are completed, so I'd
>> rather represent this message with an Event. I guess that `process` should
>> return something like Command | Cmd Event, to allow both synchronous and
>> asynchronous commands
>>
>>
>> On Wednesday, August 17, 2016 at 9:31:02 PM UTC+2, Kasey Speakman wrote:
>>>
>>> So, reading through your implementation:
>>>
>>> Bug: In `projection`, you're doing a foldl on your history, but you're
>>> putting new events at the head of your history using cons (::). So your
>>> history be replayed in reverse order. I think there was a quite humorous
>>> Red Dwarf episode about that.
>>>
>>> Possible typo: `process` should return a Cmd Command instead of Cmd
>>> Event if we're talking about the Process Manager pattern. I would also do a
>>> List instead of Maybe. (You can Cmd.batch them, and Cmd.none is actually
>>> implemented as Cmd.batch on an empty list)
>>>
>>> Also, `process` is called incorrectly if it only uses Events to make
>>> decisions. It should be called with all history, not just the events
>>> generated from the one command. With only current events, it might be
>>> missing the information needed to know if a Command is warranted. RPG
>>> example: your game didn't have full history, so even though you got a
>>> GoblinSlayer sword 5 minutes ago, it didn't on turn Glow on when
>>> GoblinsEnteredTheArea.
>>>
>>> `commandHandler` - I believe the definition of commandHandler as
>>> `Command -> Events -> Events` is too narrow. A command handler is often
>>> responsible for wrangling external resources (e.g. API calls). The only way
>>> to make this possible is to return `Cmd Events`. I also imagine it possible
>>> to perform some IO through Cmd and subsequently need to issue another
>>> Command to do something else with logic or IO. (Generally, I think multiple
>>> API calls would be handled better by an API gateway, but I wouldn't want to
>>> limit possibilities here.) I think Cmd Msg or Cmd (List Msg) would be more
>>> expected here.
>>>
>>> As previously mentioned, I don't think it's a good idea to carry around
>>> the increment value and actually calculate it in the `eventHandler`. The
>>> relating of Incremented to the plus operator and Decremented to minus is
>>> logic, and logic should be under the command handler. Updating a model with
>>> event data should be as dumb as possible, because it should not have the
>>> possibility to fail when simply responding to facts. Not sure if plus/minus
>>> overflow in Elm (in JS, they flip sign on overflow), but other kinds of
>>> operators could.
>>>
>>> On Wednesday, August 17, 2016 at 11:32:27 AM UTC-5, Marco Perone wrote:

 Hi!

 I was eventually able to read carefully the thread and give some
 thoughts about it.

 @kasey, I had a look to your Gist and it looks really interesting! Some
 notes about it:

 - I think it would be better to store in the parameter of the Fact's
 the increment, and not the state of the application. It looks to me that
 you are mixing two concerns, i.e. the state of the applications and the
 events that happens to it

 - if I'm not mistaken, from you implementation it seems that only Act's
 (and not Fact's) can generate new Cmd's. I think that is some applications
 there could be the need to react automatically with a new Cmd to some
 events that happened

 To make everything clearer in my mind, I wrote my own implementation of
 something similar to what you did. You can find it here:

 https://github.com/marcosh/elm-escqrs/blob/master/EsCqrsMain.elm

 It should be just a functional transposition of a standard es/cqrs
 architecture (I actually used also es/cqrs jargon), adacted to the Elm
 Architecture.

 I'd really like to know what you think of it. Let me know if something
 is not clear enough

 On Sunday, August 14, 2016 at 7:37:25 AM UTC+2, Kasey Speakman wrote:
>
> So, I made a Gist
> 
> of the helper stuff which splits Facts and Acts. I call the helper
> Factor... (Fact or Act ~=> Factor). There is a subsequent comment with an
> example program explaining the helper's usage.
>

Re: [elm-discuss] Re: More thorough side-effect isolation

[Kasey Speakman]

You could be right. I'm thinking of back-end systems where a PM may need to
send a command to an "external" system (or even calls to its own system are
done as "external" calls), so I/O is involved. Maybe that scenario doesn't
apply on the front-end.

On Thu, Aug 18, 2016 at 9:32 AM, Marco Perone  wrote:

> Thanks Kasey for your observations!
>
> I agree with everything except for one thing. Regarding `process`, I don't
> think it should return a Cmd Command. Cmd generates asynchronous
> operations, and we receive a notification when they are completed, so I'd
> rather represent this message with an Event. I guess that `process` should
> return something like Command | Cmd Event, to allow both synchronous and
> asynchronous commands
>
>
> On Wednesday, August 17, 2016 at 9:31:02 PM UTC+2, Kasey Speakman wrote:
>>
>> So, reading through your implementation:
>>
>> Bug: In `projection`, you're doing a foldl on your history, but you're
>> putting new events at the head of your history using cons (::). So your
>> history be replayed in reverse order. I think there was a quite humorous
>> Red Dwarf episode about that.
>>
>> Possible typo: `process` should return a Cmd Command instead of Cmd Event
>> if we're talking about the Process Manager pattern. I would also do a List
>> instead of Maybe. (You can Cmd.batch them, and Cmd.none is actually
>> implemented as Cmd.batch on an empty list)
>>
>> Also, `process` is called incorrectly if it only uses Events to make
>> decisions. It should be called with all history, not just the events
>> generated from the one command. With only current events, it might be
>> missing the information needed to know if a Command is warranted. RPG
>> example: your game didn't have full history, so even though you got a
>> GoblinSlayer sword 5 minutes ago, it didn't on turn Glow on when
>> GoblinsEnteredTheArea.
>>
>> `commandHandler` - I believe the definition of commandHandler as `Command
>> -> Events -> Events` is too narrow. A command handler is often responsible
>> for wrangling external resources (e.g. API calls). The only way to make
>> this possible is to return `Cmd Events`. I also imagine it possible to
>> perform some IO through Cmd and subsequently need to issue another Command
>> to do something else with logic or IO. (Generally, I think multiple API
>> calls would be handled better by an API gateway, but I wouldn't want to
>> limit possibilities here.) I think Cmd Msg or Cmd (List Msg) would be more
>> expected here.
>>
>> As previously mentioned, I don't think it's a good idea to carry around
>> the increment value and actually calculate it in the `eventHandler`. The
>> relating of Incremented to the plus operator and Decremented to minus is
>> logic, and logic should be under the command handler. Updating a model with
>> event data should be as dumb as possible, because it should not have the
>> possibility to fail when simply responding to facts. Not sure if plus/minus
>> overflow in Elm (in JS, they flip sign on overflow), but other kinds of
>> operators could.
>>
>> On Wednesday, August 17, 2016 at 11:32:27 AM UTC-5, Marco Perone wrote:
>>>
>>> Hi!
>>>
>>> I was eventually able to read carefully the thread and give some
>>> thoughts about it.
>>>
>>> @kasey, I had a look to your Gist and it looks really interesting! Some
>>> notes about it:
>>>
>>> - I think it would be better to store in the parameter of the Fact's the
>>> increment, and not the state of the application. It looks to me that you
>>> are mixing two concerns, i.e. the state of the applications and the events
>>> that happens to it
>>>
>>> - if I'm not mistaken, from you implementation it seems that only Act's
>>> (and not Fact's) can generate new Cmd's. I think that is some applications
>>> there could be the need to react automatically with a new Cmd to some
>>> events that happened
>>>
>>> To make everything clearer in my mind, I wrote my own implementation of
>>> something similar to what you did. You can find it here:
>>>
>>> https://github.com/marcosh/elm-escqrs/blob/master/EsCqrsMain.elm
>>>
>>> It should be just a functional transposition of a standard es/cqrs
>>> architecture (I actually used also es/cqrs jargon), adacted to the Elm
>>> Architecture.
>>>
>>> I'd really like to know what you think of it. Let me know if something
>>> is not clear enough
>>>
>>> On Sunday, August 14, 2016 at 7:37:25 AM UTC+2, Kasey Speakman wrote:

 So, I made a Gist
 
 of the helper stuff which splits Facts and Acts. I call the helper
 Factor... (Fact or Act ~=> Factor). There is a subsequent comment with an
 example program explaining the helper's usage.

 --
> 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/yKRYkoiQmPs/unsubscribe.
> To unsubscribe from this group an

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

[Janis Voigtländer]

More importantly, maybe, you will have to *remember* to use each imported 
function at least once in qualified form in each module, or you will end up in 
the situation Nick described, where in six months you don't know (and other 
readers of your code do not even know the next day after you wrote the code) 
where reticulateSplines comes from. 

> Am 18.08.2016 um 20:03 schrieb Nick H :
> 
> Is that a good idea? It seems like occasionally, but not always, using the 
> namespace would make your code less readable than not doing it at all.
> 
> 
>> On Thu, Aug 18, 2016 at 9:37 AM, Will White  wrote:
>> I can still namespace functions with import exposing (..).
>> 
>>> On Thursday, August 18, 2016 at 5:08:29 PM UTC+1, Nick H wrote:
>>> If you prefer not having to remember things, then you should use qualified 
>>> imports.
>>> 
>>> Stripping the namespace off of all your imported functions means that your 
>>> code no longer tells you where these functions come from. You will have to 
>>> remember this information yourself. This doesn't seem like much of a mental 
>>> burden at the moment, but it will likely become much more burdensome in 6 
>>> months when you are reading through your code again (e.g. "Now, which of 
>>> these 10 modules did that 'reticulateSplines' function come from?") And if 
>>> you never run into that annoyance, I guarantee that every other person who 
>>> reads your code will.
>>> 
>>> What's more, APIs that follow the design guidelines are going to make your 
>>> life even harder, because the functions will have names designed to work 
>>> with a qualifier. Look at your own example. If "toString" only works on one 
>>> type, then it is a terribly undescriptive name. But if the module is named 
>>> "Foo" and the type defined in that module is named "Foo", then 
>>> "Foo.toString" is not a terrible name.
>>> 
>>> From the design guidelines:
 A function called State.runState is redundant and silly. More importantly, 
 it encourages people to use import State exposing (..) which does not 
 scale well. In files with many so-called "unqualified" dependencies, it is 
 essentially impossible to figure out where functions are coming from. This 
 can make large code bases impossible to understand, especially if custom 
 infix operators are used as well. Repeating the module name actively 
 encourages this kind of unreadable code.
 
 With a name like State.run the user is encouraged to disambiguate 
 functions with namespacing, leading to a codebase that will be clearer to 
 people reading the project for the first time. A great example from the 
 standard library is Bitwise.and
>>> 
>>> 
 On Thu, Aug 18, 2016 at 8:18 AM, Janis Voigtländer 
  wrote:
 I can’t search for the thread right now, but I’m sure you can find it 
 yourself via the archive. In any case, one aspect of it (but I think there 
 were more) was this: https://github.com/elm-lang/elm-make/issues/61
 
 
 2016-08-18 17:08 GMT+02:00 Will White :
> What unexpected results? The compiler has your back if two unqualified 
> functions have the same name.
> 
>> On Thursday, August 18, 2016 at 3:56:50 PM UTC+1, Janis Voigtländer 
>> wrote:
>> That's not an answer to my question I understand as a problem 
>> description. 
>> 
>> Also, there have been earlier threads here that have discussed what can 
>> go wrong if you unwittingly import with exposing everything. So, where 
>> not remembering that one of those imports brought a certain function 
>> name into scope, lead to unexpected results. If your concern is valid, 
>> theirs is at least as much. 
>> 
>>> Am 18.08.2016 um 17:48 schrieb Will White :
>>> 
>>> You have to remember to qualify.
>>> 
 On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis Voigtländer 
 wrote:
 In what ways are qualified imports at odds with safe code?
 
 I think the opposite is the case: unqualified imports lead to less 
 code safety. 
 
> Am 18.08.2016 um 17:37 schrieb Will White :
> 
> I prefer safe code to qualified imports.
> 
> On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc wrote:
>> 
>>> "Qualified imports are preferred."
>> http://elm-lang.org/docs/syntax#modules
>> 
>> I try to avoid as much as possible importing everything from a 
>> module. 
>> If I would have IDE support for automatic imports I would never do a 
>> import Module exposing (..). 
> 
> -- 
> 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/

[elm-discuss] Re: Code review request

[Will White]

Hi Thomas!

I've played the game and I'd like to give you my thoughts on the UX. I may 
be able to review the code later. I wish I'd recorded my thoughts as I 
played.

I ran right (it's Mario), bumped into a red wall. Ran left, same. What do I 
do? Ran right, green block has appeared. Jump over it. Oh, it's a Tetris 
block. Oh, the grey is where the block's coming down. 1 I get squashed and 
it bugs out (screenshot). I think I'm able to play on (arena not reset). 
"Tetris controls IJKL" Oh cool, I can control the Tetris blocks too!

Having a zoomed out view to start with (and then zooming in) would have got 
rid of all the thoughts up to 1. Knowing the Tetris controls earlier would 
have been fairer.

Cool idea!

On Wednesday, August 17, 2016 at 10:40:38 PM UTC+1, Thomas Ballinger wrote:
>
> Hi Elm folks! I've enjoyed reading this list for a bit. I've written my 
> first Elm thing over the last couple weeks and would love to hear any kind 
> of feedback on it. It's an unfinished game jam piece I kept running with so 
> the title doesn't make sense.
>
> code: https://github.com/thomasballinger/loveinthetimeoftetris
> live: love.ballingt.com (takes about 70 seconds to play all of)
>
> I was going to clean things up the way I know how, but I need to take a 
> break to get some other things done and I thought I'd learn more by asking 
> how someone else might clean it up. Please don't assume I know what I'm 
> doing in the slightest :)
>
> Any feedback would be great, but if prompts are helpful:
> * what does this code make it look like I'm missing about Elm?
> * what do you think of the extensible record type aliases? I think the way 
> I've used them is mostly terrible, I designed them up front instead of 
> letting them evolve.
> * code style?
> * I'm using an elm autoformatter, how's my formatting? Is this style 
> common?
> * I don't think I'll be using evancz/elm-graphics in the future since I'll 
> be doing less gamey stuff or want to work with canvas more directly. How is 
> this usually done?
> * I abandoned elm reactor once I started embedding in html, is that a 
> viable workflow I should have stuck with for longer?
> * I was tempted to start a utils file or look for an external lib but was 
> trying to focus on learning the stdlib. Are there pretty common util libs 
> folks use? I sure missed some list functions.
> * I escaped to JavaScript anytime I thought it would be hard to do 
> something with the stdlib, presumably it would be nice to use Elm for some 
> of these things?
>
> Thanks so much, and feel free to contact off list if you prefer at 
> m...@ballingt.com  - if you do I'll report back what I 
> learned to the list.
>

-- 
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] Remove ways of importing except `import exposing (..)`?

[Nick H]

Is that a good idea? It seems like occasionally, but not always, using the
namespace would make your code less readable than not doing it at all.


On Thu, Aug 18, 2016 at 9:37 AM, Will White  wrote:

> I can still namespace functions with import exposing (..).
>
> On Thursday, August 18, 2016 at 5:08:29 PM UTC+1, Nick H wrote:
>>
>> If you prefer not having to remember things, then you should use
>> qualified imports.
>>
>> Stripping the namespace off of all your imported functions means that
>> your code no longer tells you where these functions come from. You will
>> have to remember this information yourself. This doesn't seem like much of
>> a mental burden at the moment, but it will likely become much more
>> burdensome in 6 months when you are reading through your code again (e.g.
>> "Now, which of these 10 modules did that 'reticulateSplines' function come
>> from?") And if you never run into that annoyance, I guarantee that every
>> other person who reads your code will.
>>
>> What's more, APIs that follow the design guidelines
>>  are going to
>> make your life even harder, because the functions will have names designed
>> to work with a qualifier. Look at your own example. If "toString" only
>> works on one type, then it is a terribly undescriptive name. But if the
>> module is named "Foo" and the type defined in that module is named "Foo",
>> then "Foo.toString" is not a terrible name.
>>
>> From the design guidelines:
>>
>>> A function called State.runState is redundant and silly. More
>>> importantly, it encourages people to use import State exposing (..)
>>> which does not scale well. In files with many so-called "unqualified"
>>> dependencies, it is essentially impossible to figure out where functions
>>> are coming from. This can make large code bases impossible to understand,
>>> especially if custom infix operators are used as well. Repeating the module
>>> name actively encourages this kind of unreadable code.
>>> With a name like State.run the user is encouraged to disambiguate
>>> functions with namespacing, leading to a codebase that will be clearer to
>>> people reading the project for the first time. A great example from the
>>> standard library is Bitwise.and
>>>
>>
>>
>> On Thu, Aug 18, 2016 at 8:18 AM, Janis Voigtländer <
>> janis.voi...@gmail.com> wrote:
>>
>>> I can’t search for the thread right now, but I’m sure you can find it
>>> yourself via the archive. In any case, one aspect of it (but I think there
>>> were more) was this: https://github.com/elm-lang/elm-make/issues/61
>>> ​
>>>
>>> 2016-08-18 17:08 GMT+02:00 Will White :
>>>
 What unexpected results? The compiler has your back if two unqualified
 functions have the same name.

 On Thursday, August 18, 2016 at 3:56:50 PM UTC+1, Janis Voigtländer
 wrote:
>
> That's not an answer to my question I understand as a problem
> description.
>
> Also, there have been earlier threads here that have discussed what
> can go wrong if you unwittingly import with exposing everything. So, where
> not remembering that one of those imports brought a certain function name
> into scope, lead to unexpected results. If your concern is valid, theirs 
> is
> at least as much.
>
> Am 18.08.2016 um 17:48 schrieb Will White :
>
> You have to remember to qualify.
>
> On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis Voigtländer
> wrote:
>>
>> In what ways are qualified imports at odds with safe code?
>>
>> I think the opposite is the case: unqualified imports lead to less
>> code safety.
>>
>> Am 18.08.2016 um 17:37 schrieb Will White :
>>
>> I prefer safe code to qualified imports.
>>
>> On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc wrote:
>>>
>>> "Qualified imports are preferred."
>>>
>>> http://elm-lang.org/docs/syntax#modules
>>>
>>> I try to avoid as much as possible importing everything from a
>>> module.
>>> If I would have IDE support for automatic imports I would never do a 
>>> import
>>> Module exposing (..).
>>>
>>> --
>> 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 

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

[Will White]

I can still namespace functions with import exposing (..).

On Thursday, August 18, 2016 at 5:08:29 PM UTC+1, Nick H wrote:
>
> If you prefer not having to remember things, then you should use qualified 
> imports.
>
> Stripping the namespace off of all your imported functions means that your 
> code no longer tells you where these functions come from. You will have to 
> remember this information yourself. This doesn't seem like much of a mental 
> burden at the moment, but it will likely become much more burdensome in 6 
> months when you are reading through your code again (e.g. "Now, which of 
> these 10 modules did that 'reticulateSplines' function come from?") And if 
> you never run into that annoyance, I guarantee that every other person who 
> reads your code will.
>
> What's more, APIs that follow the design guidelines 
>  are going to 
> make your life even harder, because the functions will have names designed 
> to work with a qualifier. Look at your own example. If "toString" only 
> works on one type, then it is a terribly undescriptive name. But if the 
> module is named "Foo" and the type defined in that module is named "Foo", 
> then "Foo.toString" is not a terrible name.
>
> From the design guidelines:
>
>> A function called State.runState is redundant and silly. More 
>> importantly, it encourages people to use import State exposing (..) 
>> which does not scale well. In files with many so-called "unqualified" 
>> dependencies, it is essentially impossible to figure out where functions 
>> are coming from. This can make large code bases impossible to understand, 
>> especially if custom infix operators are used as well. Repeating the module 
>> name actively encourages this kind of unreadable code.
>> With a name like State.run the user is encouraged to disambiguate 
>> functions with namespacing, leading to a codebase that will be clearer to 
>> people reading the project for the first time. A great example from the 
>> standard library is Bitwise.and
>>
>
>
> On Thu, Aug 18, 2016 at 8:18 AM, Janis Voigtländer  > wrote:
>
>> I can’t search for the thread right now, but I’m sure you can find it 
>> yourself via the archive. In any case, one aspect of it (but I think there 
>> were more) was this: https://github.com/elm-lang/elm-make/issues/61 
>> ​
>>
>> 2016-08-18 17:08 GMT+02:00 Will White >
>> :
>>
>>> What unexpected results? The compiler has your back if two unqualified 
>>> functions have the same name.
>>>
>>> On Thursday, August 18, 2016 at 3:56:50 PM UTC+1, Janis Voigtländer 
>>> wrote:

 That's not an answer to my question I understand as a problem 
 description. 

 Also, there have been earlier threads here that have discussed what can 
 go wrong if you unwittingly import with exposing everything. So, where not 
 remembering that one of those imports brought a certain function name into 
 scope, lead to unexpected results. If your concern is valid, theirs is at 
 least as much. 

 Am 18.08.2016 um 17:48 schrieb Will White :

 You have to remember to qualify.

 On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis Voigtländer 
 wrote:
>
> In what ways are qualified imports at odds with safe code?
>
> I think the opposite is the case: unqualified imports lead to less 
> code safety. 
>
> Am 18.08.2016 um 17:37 schrieb Will White :
>
> I prefer safe code to qualified imports.
>
> On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc wrote:
>>
>> "Qualified imports are preferred."
>>
>> http://elm-lang.org/docs/syntax#modules
>>
>> I try to avoid as much as possible importing everything from a 
>> module. 
>> If I would have IDE support for automatic imports I would never do a 
>> import 
>> Module exposing (..). 
>>
>> -- 
> 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...@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 unsubscr

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

[Will White]

I've searched for "import exposing (..)" but I couldn't find the thread. 
I'll carry on with import exposing (..), but I'll be sure (i.e. I'll have 
to remember!) to post back here if I encounter a problem.

On Thursday, August 18, 2016 at 4:18:56 PM UTC+1, Janis Voigtländer wrote:
>
> I can’t search for the thread right now, but I’m sure you can find it 
> yourself via the archive. In any case, one aspect of it (but I think there 
> were more) was this: https://github.com/elm-lang/elm-make/issues/61 
> ​
>
> 2016-08-18 17:08 GMT+02:00 Will White >:
>
>> What unexpected results? The compiler has your back if two unqualified 
>> functions have the same name.
>>
>> On Thursday, August 18, 2016 at 3:56:50 PM UTC+1, Janis Voigtländer wrote:
>>>
>>> That's not an answer to my question I understand as a problem 
>>> description. 
>>>
>>> Also, there have been earlier threads here that have discussed what can 
>>> go wrong if you unwittingly import with exposing everything. So, where not 
>>> remembering that one of those imports brought a certain function name into 
>>> scope, lead to unexpected results. If your concern is valid, theirs is at 
>>> least as much. 
>>>
>>> Am 18.08.2016 um 17:48 schrieb Will White :
>>>
>>> You have to remember to qualify.
>>>
>>> On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis Voigtländer 
>>> wrote:

 In what ways are qualified imports at odds with safe code?

 I think the opposite is the case: unqualified imports lead to less code 
 safety. 

 Am 18.08.2016 um 17:37 schrieb Will White :

 I prefer safe code to qualified imports.

 On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc wrote:
>
> "Qualified imports are preferred."
>
> http://elm-lang.org/docs/syntax#modules
>
> I try to avoid as much as possible importing everything from a module. 
> If I would have IDE support for automatic imports I would never do a 
> import 
> Module exposing (..). 
>
> -- 
 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...@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] Remove ways of importing except `import exposing (..)`?

[Nick H]

If you prefer not having to remember things, then you should use qualified
imports.

Stripping the namespace off of all your imported functions means that your
code no longer tells you where these functions come from. You will have to
remember this information yourself. This doesn't seem like much of a mental
burden at the moment, but it will likely become much more burdensome in 6
months when you are reading through your code again (e.g. "Now, which of
these 10 modules did that 'reticulateSplines' function come from?") And if
you never run into that annoyance, I guarantee that every other person who
reads your code will.

What's more, APIs that follow the design guidelines
 are going to
make your life even harder, because the functions will have names designed
to work with a qualifier. Look at your own example. If "toString" only
works on one type, then it is a terribly undescriptive name. But if the
module is named "Foo" and the type defined in that module is named "Foo",
then "Foo.toString" is not a terrible name.

>From the design guidelines:

> A function called State.runState is redundant and silly. More
> importantly, it encourages people to use import State exposing (..) which
> does not scale well. In files with many so-called "unqualified"
> dependencies, it is essentially impossible to figure out where functions
> are coming from. This can make large code bases impossible to understand,
> especially if custom infix operators are used as well. Repeating the module
> name actively encourages this kind of unreadable code.
> With a name like State.run the user is encouraged to disambiguate
> functions with namespacing, leading to a codebase that will be clearer to
> people reading the project for the first time. A great example from the
> standard library is Bitwise.and
>


On Thu, Aug 18, 2016 at 8:18 AM, Janis Voigtländer <
janis.voigtlaen...@gmail.com> wrote:

> I can’t search for the thread right now, but I’m sure you can find it
> yourself via the archive. In any case, one aspect of it (but I think there
> were more) was this: https://github.com/elm-lang/elm-make/issues/61
> ​
>
> 2016-08-18 17:08 GMT+02:00 Will White :
>
>> What unexpected results? The compiler has your back if two unqualified
>> functions have the same name.
>>
>> On Thursday, August 18, 2016 at 3:56:50 PM UTC+1, Janis Voigtländer wrote:
>>>
>>> That's not an answer to my question I understand as a problem
>>> description.
>>>
>>> Also, there have been earlier threads here that have discussed what can
>>> go wrong if you unwittingly import with exposing everything. So, where not
>>> remembering that one of those imports brought a certain function name into
>>> scope, lead to unexpected results. If your concern is valid, theirs is at
>>> least as much.
>>>
>>> Am 18.08.2016 um 17:48 schrieb Will White :
>>>
>>> You have to remember to qualify.
>>>
>>> On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis Voigtländer
>>> wrote:

 In what ways are qualified imports at odds with safe code?

 I think the opposite is the case: unqualified imports lead to less code
 safety.

 Am 18.08.2016 um 17:37 schrieb Will White :

 I prefer safe code to qualified imports.

 On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc wrote:
>
> "Qualified imports are preferred."
>
> http://elm-lang.org/docs/syntax#modules
>
> I try to avoid as much as possible importing everything from a module.
> If I would have IDE support for automatic imports I would never do a 
> import
> Module exposing (..).
>
> --
 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.
>>
>
> --
> 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 unsu

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

[Janis Voigtländer]

I can’t search for the thread right now, but I’m sure you can find it
yourself via the archive. In any case, one aspect of it (but I think there
were more) was this: https://github.com/elm-lang/elm-make/issues/61
​

2016-08-18 17:08 GMT+02:00 Will White :

> What unexpected results? The compiler has your back if two unqualified
> functions have the same name.
>
> On Thursday, August 18, 2016 at 3:56:50 PM UTC+1, Janis Voigtländer wrote:
>>
>> That's not an answer to my question I understand as a problem
>> description.
>>
>> Also, there have been earlier threads here that have discussed what can
>> go wrong if you unwittingly import with exposing everything. So, where not
>> remembering that one of those imports brought a certain function name into
>> scope, lead to unexpected results. If your concern is valid, theirs is at
>> least as much.
>>
>> Am 18.08.2016 um 17:48 schrieb Will White :
>>
>> You have to remember to qualify.
>>
>> On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis Voigtländer wrote:
>>>
>>> In what ways are qualified imports at odds with safe code?
>>>
>>> I think the opposite is the case: unqualified imports lead to less code
>>> safety.
>>>
>>> Am 18.08.2016 um 17:37 schrieb Will White :
>>>
>>> I prefer safe code to qualified imports.
>>>
>>> On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc wrote:

 "Qualified imports are preferred."

 http://elm-lang.org/docs/syntax#modules

 I try to avoid as much as possible importing everything from a module.
 If I would have IDE support for automatic imports I would never do a import
 Module exposing (..).

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

-- 
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] Remove ways of importing except `import exposing (..)`?

[Will White]

Perhaps I should have said "I prefer not having to remember to do things to 
qualified imports." I am genuinely interested to know what unexpected 
results others have had by import exposing (..), because at this point I'm 
always doing that (in order to avoid the problem I stated at the top).

On Thursday, August 18, 2016 at 4:08:01 PM UTC+1, Will White wrote:
>
> What unexpected results? The compiler has your back if two unqualified 
> functions have the same name.
>
> On Thursday, August 18, 2016 at 3:56:50 PM UTC+1, Janis Voigtländer wrote:
>>
>> That's not an answer to my question I understand as a problem 
>> description. 
>>
>> Also, there have been earlier threads here that have discussed what can 
>> go wrong if you unwittingly import with exposing everything. So, where not 
>> remembering that one of those imports brought a certain function name into 
>> scope, lead to unexpected results. If your concern is valid, theirs is at 
>> least as much. 
>>
>> Am 18.08.2016 um 17:48 schrieb Will White :
>>
>> You have to remember to qualify.
>>
>> On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis Voigtländer wrote:
>>>
>>> In what ways are qualified imports at odds with safe code?
>>>
>>> I think the opposite is the case: unqualified imports lead to less code 
>>> safety. 
>>>
>>> Am 18.08.2016 um 17:37 schrieb Will White :
>>>
>>> I prefer safe code to qualified imports.
>>>
>>> On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc wrote:

 "Qualified imports are preferred."

 http://elm-lang.org/docs/syntax#modules

 I try to avoid as much as possible importing everything from a module. 
 If I would have IDE support for automatic imports I would never do a 
 import 
 Module exposing (..). 

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

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

[Will White]

What unexpected results? The compiler has your back if two unqualified 
functions have the same name.

On Thursday, August 18, 2016 at 3:56:50 PM UTC+1, Janis Voigtländer wrote:
>
> That's not an answer to my question I understand as a problem description. 
>
> Also, there have been earlier threads here that have discussed what can go 
> wrong if you unwittingly import with exposing everything. So, where not 
> remembering that one of those imports brought a certain function name into 
> scope, lead to unexpected results. If your concern is valid, theirs is at 
> least as much. 
>
> Am 18.08.2016 um 17:48 schrieb Will White  >:
>
> You have to remember to qualify.
>
> On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis Voigtländer wrote:
>>
>> In what ways are qualified imports at odds with safe code?
>>
>> I think the opposite is the case: unqualified imports lead to less code 
>> safety. 
>>
>> Am 18.08.2016 um 17:37 schrieb Will White :
>>
>> I prefer safe code to qualified imports.
>>
>> On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc wrote:
>>>
>>> "Qualified imports are preferred."
>>>
>>> http://elm-lang.org/docs/syntax#modules
>>>
>>> I try to avoid as much as possible importing everything from a module. 
>>> If I would have IDE support for automatic imports I would never do a import 
>>> Module exposing (..). 
>>>
>>> -- 
>> 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.

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

[Will White]

What unexpected results? The compiler has your back if two unqualified 
functions have the same name.

On Thursday, August 18, 2016 at 3:56:50 PM UTC+1, Janis Voigtländer wrote:
>
> That's not an answer to my question I understand as a problem description. 
>
> Also, there have been earlier threads here that have discussed what can go 
> wrong if you unwittingly import with exposing everything. So, where not 
> remembering that one of those imports brought a certain function name into 
> scope, lead to unexpected results. If your concern is valid, theirs is at 
> least as much. 
>
> Am 18.08.2016 um 17:48 schrieb Will White  >:
>
> You have to remember to qualify.
>
> On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis Voigtländer wrote:
>>
>> In what ways are qualified imports at odds with safe code?
>>
>> I think the opposite is the case: unqualified imports lead to less code 
>> safety. 
>>
>> Am 18.08.2016 um 17:37 schrieb Will White :
>>
>> I prefer safe code to qualified imports.
>>
>> On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc wrote:
>>>
>>> "Qualified imports are preferred."
>>>
>>> http://elm-lang.org/docs/syntax#modules
>>>
>>> I try to avoid as much as possible importing everything from a module. 
>>> If I would have IDE support for automatic imports I would never do a import 
>>> Module exposing (..). 
>>>
>>> -- 
>> 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.

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

[Will White]

(Safe code being code where you don't have to remember to do things.)

On Thursday, August 18, 2016 at 3:48:09 PM UTC+1, Will White wrote:
>
> You have to remember to qualify.
>
> On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis Voigtländer wrote:
>>
>> In what ways are qualified imports at odds with safe code?
>>
>> I think the opposite is the case: unqualified imports lead to less code 
>> safety. 
>>
>> Am 18.08.2016 um 17:37 schrieb Will White :
>>
>> I prefer safe code to qualified imports.
>>
>> On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc wrote:
>>>
>>> "Qualified imports are preferred."
>>>
>>> http://elm-lang.org/docs/syntax#modules
>>>
>>> I try to avoid as much as possible importing everything from a module. 
>>> If I would have IDE support for automatic imports I would never do a import 
>>> Module exposing (..). 
>>>
>>> -- 
>> 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.

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

[Janis Voigtländer]

That's not an answer to my question I understand as a problem description. 

Also, there have been earlier threads here that have discussed what can go 
wrong if you unwittingly import with exposing everything. So, where not 
remembering that one of those imports brought a certain function name into 
scope, lead to unexpected results. If your concern is valid, theirs is at least 
as much. 

> Am 18.08.2016 um 17:48 schrieb Will White :
> 
> You have to remember to qualify.
> 
>> On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis Voigtländer wrote:
>> In what ways are qualified imports at odds with safe code?
>> 
>> I think the opposite is the case: unqualified imports lead to less code 
>> safety. 
>> 
>>> Am 18.08.2016 um 17:37 schrieb Will White :
>>> 
>>> I prefer safe code to qualified imports.
>>> 
>>> On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc wrote:
 
> "Qualified imports are preferred."
 http://elm-lang.org/docs/syntax#modules
 
 I try to avoid as much as possible importing everything from a module. 
 If I would have IDE support for automatic imports I would never do a 
 import Module exposing (..). 
 
>>> 
>>> -- 
>>> 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.

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

[Will White]

You have to remember to qualify.

On Thursday, August 18, 2016 at 3:40:21 PM UTC+1, Janis Voigtländer wrote:
>
> In what ways are qualified imports at odds with safe code?
>
> I think the opposite is the case: unqualified imports lead to less code 
> safety. 
>
> Am 18.08.2016 um 17:37 schrieb Will White  >:
>
> I prefer safe code to qualified imports.
>
> On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc wrote:
>>
>> "Qualified imports are preferred."
>>
>> http://elm-lang.org/docs/syntax#modules
>>
>> I try to avoid as much as possible importing everything from a module. 
>> If I would have IDE support for automatic imports I would never do a import 
>> Module exposing (..). 
>>
>> -- 
> 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.

Re: [elm-discuss] Remove ways of importing except `import exposing (..)`?

[Janis Voigtländer]

In what ways are qualified imports at odds with safe code?

I think the opposite is the case: unqualified imports lead to less code safety. 

> Am 18.08.2016 um 17:37 schrieb Will White :
> 
> I prefer safe code to qualified imports.
> 
> On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc wrote:
>> 
>>> "Qualified imports are preferred."
>> http://elm-lang.org/docs/syntax#modules
>> 
>> I try to avoid as much as possible importing everything from a module. 
>> If I would have IDE support for automatic imports I would never do a import 
>> Module exposing (..). 
> 
> -- 
> 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] Remove ways of importing except `import exposing (..)`?

[Will White]

I prefer safe code to qualified imports.

On Thursday, August 18, 2016 at 3:11:21 PM UTC+1, Peter Damoc wrote:
>
> "Qualified imports are preferred."
>
> http://elm-lang.org/docs/syntax#modules
>
> I try to avoid as much as possible importing everything from a module. 
> If I would have IDE support for automatic imports I would never do a import 
> Module exposing (..). 
>
>

-- 
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: More thorough side-effect isolation

[Marco Perone]

Thanks Kasey for your observations!

I agree with everything except for one thing. Regarding `process`, I don't 
think it should return a Cmd Command. Cmd generates asynchronous 
operations, and we receive a notification when they are completed, so I'd 
rather represent this message with an Event. I guess that `process` should 
return something like Command | Cmd Event, to allow both synchronous and 
asynchronous commands

On Wednesday, August 17, 2016 at 9:31:02 PM UTC+2, Kasey Speakman wrote:
>
> So, reading through your implementation:
>
> Bug: In `projection`, you're doing a foldl on your history, but you're 
> putting new events at the head of your history using cons (::). So your 
> history be replayed in reverse order. I think there was a quite humorous 
> Red Dwarf episode about that.
>
> Possible typo: `process` should return a Cmd Command instead of Cmd Event 
> if we're talking about the Process Manager pattern. I would also do a List 
> instead of Maybe. (You can Cmd.batch them, and Cmd.none is actually 
> implemented as Cmd.batch on an empty list)
>
> Also, `process` is called incorrectly if it only uses Events to make 
> decisions. It should be called with all history, not just the events 
> generated from the one command. With only current events, it might be 
> missing the information needed to know if a Command is warranted. RPG 
> example: your game didn't have full history, so even though you got a 
> GoblinSlayer sword 5 minutes ago, it didn't on turn Glow on when 
> GoblinsEnteredTheArea.
>
> `commandHandler` - I believe the definition of commandHandler as `Command 
> -> Events -> Events` is too narrow. A command handler is often responsible 
> for wrangling external resources (e.g. API calls). The only way to make 
> this possible is to return `Cmd Events`. I also imagine it possible to 
> perform some IO through Cmd and subsequently need to issue another Command 
> to do something else with logic or IO. (Generally, I think multiple API 
> calls would be handled better by an API gateway, but I wouldn't want to 
> limit possibilities here.) I think Cmd Msg or Cmd (List Msg) would be more 
> expected here.
>
> As previously mentioned, I don't think it's a good idea to carry around 
> the increment value and actually calculate it in the `eventHandler`. The 
> relating of Incremented to the plus operator and Decremented to minus is 
> logic, and logic should be under the command handler. Updating a model with 
> event data should be as dumb as possible, because it should not have the 
> possibility to fail when simply responding to facts. Not sure if plus/minus 
> overflow in Elm (in JS, they flip sign on overflow), but other kinds of 
> operators could.
>
> On Wednesday, August 17, 2016 at 11:32:27 AM UTC-5, Marco Perone wrote:
>>
>> Hi!
>>
>> I was eventually able to read carefully the thread and give some thoughts 
>> about it.
>>
>> @kasey, I had a look to your Gist and it looks really interesting! Some 
>> notes about it:
>>
>> - I think it would be better to store in the parameter of the Fact's the 
>> increment, and not the state of the application. It looks to me that you 
>> are mixing two concerns, i.e. the state of the applications and the events 
>> that happens to it
>>
>> - if I'm not mistaken, from you implementation it seems that only Act's 
>> (and not Fact's) can generate new Cmd's. I think that is some applications 
>> there could be the need to react automatically with a new Cmd to some 
>> events that happened
>>
>> To make everything clearer in my mind, I wrote my own implementation of 
>> something similar to what you did. You can find it here:
>>
>> https://github.com/marcosh/elm-escqrs/blob/master/EsCqrsMain.elm
>>
>> It should be just a functional transposition of a standard es/cqrs 
>> architecture (I actually used also es/cqrs jargon), adacted to the Elm 
>> Architecture.
>>
>> I'd really like to know what you think of it. Let me know if something is 
>> not clear enough
>>
>> On Sunday, August 14, 2016 at 7:37:25 AM UTC+2, Kasey Speakman wrote:
>>>
>>> So, I made a Gist 
>>>  of 
>>> the helper stuff which splits Facts and Acts. I call the helper Factor... 
>>> (Fact or Act ~=> Factor). There is a subsequent comment with an example 
>>> program explaining the helper's usage.
>>>
>>>

-- 
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] Remove ways of importing except `import exposing (..)`?

[Peter Damoc]

>
> "Qualified imports are preferred."

http://elm-lang.org/docs/syntax#modules

I try to avoid as much as possible importing everything from a module.
If I would have IDE support for automatic imports I would never do a import
Module exposing (..).

-- 
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] Remove ways of importing except `import exposing (..)`?

[Will White]

import ModuleWithToString

toString typeFromThatModule

Compiles with unexpected results that you have to catch.

import ModuleWithToString exposing (..)

toString typeFromThatModule

Doesn't compile: "use of toString is ambiguous: did you mean 
Basics.toString or ModuleWithToString.toString?"

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

Re: [elm-discuss] Re: Elm UI boilerplate

[Peter Damoc]

Hi Kasey,

Take this code as example:

import Html exposing (..)
import Html.App as App
import Html.Events exposing (..)

main =
  App.beginnerProgram
{ model = 0
, view = view
, update = \msg model -> model
}

type Msg = NoOp String

view : Int -> Html Msg
view model =
  div []
[ input [onInput NoOp ][]
]

if you type in the input of this short program you will see characters.
Those characters are not part of the model.
Every time you press something, the view is called again with the exact
same argument and what you see on the screen is different.

In order for this input component to work, there has to be state. State
that holds the characters typed, state that holds the cursor position, even
state that animates that cursor.

So, if elm views are pure, what does this make `Html msg`?

The easiest answer I could come up with is that `Html msg` behaves like the
record you give to a `Html.App.program`

Given this record, the runtime could create some state if it hasn't already
done this and use the provided functions to update it / represent it.

Of course, elm-html is not implemented like this but, from a type
conceptualization point of view, this is the easiest way that I could find
to explain the *behavior* or elm-html and still maintain the idea that the
view is pure.

And this brings us back to the issue of boilerplate. If elm-html can do
this automatic state and avoid the boilerplate, how can alternatives to
elm-html do the same thing?

Another way to think about it is, how would a pure Elm ui be implemented if
there would not be the support of state management that the dom does?
(Imagine a cross platform UI implemented in Elm on top of something like a
canvas )







On Thu, Aug 18, 2016 at 11:32 AM, Kasey Speakman 
wrote:

> I've hesitated to mention this since I'm a newcomer to Elm, but I'll throw
> it out there and see what you think.
>
> The way Elm currently renders subcomponents is because the view is a pure
> function, so all subparts must be pure functions. That's what makes
> stateful subcomponents irritating to work with... the boilerplate of
> accounting for them in the parent.
>
> As a thought experiment, what if Elm were to bring in support for UI
> components that were independent of Main? They get wired to received
> init/update/view independently of the parent. They get avenues to send
> messages to the parent and vice versa. They get some state from the parent
> on init. Etc. That path has already been well-traveled by most every other
> front-end so we can know the answer. Doing that is basically bringing in
> object orientation and all the accidental complexity that comes with it.
> Right now Elm steers us away from those problems by forcing our code to be
> deterministic, but with the trade-off of the parent being responsible for
> everything underneath (requiring the boilerplate).
>
> That's not an answer to the issue at hand. It's just an observation that
> Elm does provide a (perhaps non-obvious) benefit with the current way it
> does things. It still definitely has pain, but it's clear-cut as opposed to
> accidental and pervasive. So I think that's why we hear the advice from the
> more seasoned folks to start from a place of having the parent manage
> everything with the child being stateless. Only once it becomes impractical
> for the parent to maintain the child's state, then take the lumps to make
> it stateful. The message is: yes, there's pain... just avoid it until you
> can't.
>
> Now don't get me wrong, I want the ability to use UI toolkits without
> impacting "my" code. And I want to eradicate boilerplate. We just need to
> be mindful of the trade-offs in how that's accomplished. Myself, I'm still
> thinking on it.
>
>
> On Thursday, August 18, 2016 at 1:41:57 AM UTC-5, Oliver Searle-Barnes
> wrote:
>>
>> In my experience every large SPA I've worked on has ended up building a
>> set of it's own components similar to elm-mdl. They've usually been used
>> alongside other components that have been provided by libraries such as
>> elm-mdl but they're still a significant part of the codebase. From this
>> perspective, and judging by the questions I've seen in slack, this is
>> something that pretty much every Elm developer is going to need to resolve.
>>
>> It would also be great to have a healthy selection of UX components
>> available at http://package.elm-lang.org/. To get a concrete idea of
>> some of the sorts of components this might be take a look at
>> https://emberobserver.com/categories/components.
>>
>> Making it easy to author, share and consume UX components will only make
>> building Elm apps even more pleasurable :) I'd caution against treating it
>> as a special case for advanced use or the select few.
>>
>>
>> On Thursday, 18 August 2016 08:25:29 UTC+2, Peter Damoc wrote:
>>>
>>> A small clarification that came up in an earlier discussion.
>>>
>>> This is a boilerplate example for the case where you have many small
>>> components

Re: [elm-discuss] Re: Elm UI boilerplate

[Kasey Speakman]

I've hesitated to mention this since I'm a newcomer to Elm, but I'll throw 
it out there and see what you think.

The way Elm currently renders subcomponents is because the view is a pure 
function, so all subparts must be pure functions. That's what makes 
stateful subcomponents irritating to work with... the boilerplate of 
accounting for them in the parent.

As a thought experiment, what if Elm were to bring in support for UI 
components that were independent of Main? They get wired to received 
init/update/view independently of the parent. They get avenues to send 
messages to the parent and vice versa. They get some state from the parent 
on init. Etc. That path has already been well-traveled by most every other 
front-end so we can know the answer. Doing that is basically bringing in 
object orientation and all the accidental complexity that comes with it. 
Right now Elm steers us away from those problems by forcing our code to be 
deterministic, but with the trade-off of the parent being responsible for 
everything underneath (requiring the boilerplate).

That's not an answer to the issue at hand. It's just an observation that 
Elm does provide a (perhaps non-obvious) benefit with the current way it 
does things. It still definitely has pain, but it's clear-cut as opposed to 
accidental and pervasive. So I think that's why we hear the advice from the 
more seasoned folks to start from a place of having the parent manage 
everything with the child being stateless. Only once it becomes impractical 
for the parent to maintain the child's state, then take the lumps to make 
it stateful. The message is: yes, there's pain... just avoid it until you 
can't.

Now don't get me wrong, I want the ability to use UI toolkits without 
impacting "my" code. And I want to eradicate boilerplate. We just need to 
be mindful of the trade-offs in how that's accomplished. Myself, I'm still 
thinking on it.

On Thursday, August 18, 2016 at 1:41:57 AM UTC-5, Oliver Searle-Barnes 
wrote:
>
> In my experience every large SPA I've worked on has ended up building a 
> set of it's own components similar to elm-mdl. They've usually been used 
> alongside other components that have been provided by libraries such as 
> elm-mdl but they're still a significant part of the codebase. From this 
> perspective, and judging by the questions I've seen in slack, this is 
> something that pretty much every Elm developer is going to need to resolve. 
>
> It would also be great to have a healthy selection of UX components 
> available at http://package.elm-lang.org/. To get a concrete idea of some 
> of the sorts of components this might be take a look at 
> https://emberobserver.com/categories/components. 
>
> Making it easy to author, share and consume UX components will only make 
> building Elm apps even more pleasurable :) I'd caution against treating it 
> as a special case for advanced use or the select few. 
>
>
> On Thursday, 18 August 2016 08:25:29 UTC+2, Peter Damoc wrote:
>>
>> A small clarification that came up in an earlier discussion. 
>>
>> This is a boilerplate example for the case where you have many small 
>> components that are unavoidably stateful as it is the case with UI 
>> toolkits. 
>>
>> This is a topic that concerns very few people from an implementation 
>> point of view but stands to concern a lot of people from usage point of 
>> view. 
>>
>> Most of the components needs are covered by current technologies. 
>>
>> One more thing that might be worth mentioning: 
>> Adding a new field involves changing the code in 3 places for the 
>> with-parts version and it 5 places for the without-parts code. 
>>
>>
>> P.S. Many thanks to Josh for cleaning up the code of without-parts 
>> example.  
>>
>> -- 
>> 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.