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

> > (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 :-)

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

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

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

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

[elm-discuss] Re: Code review request

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

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

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

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

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

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

(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

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

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

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

@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

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

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 >

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

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

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

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

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

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

[elm-discuss] Re: Code review request

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

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

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

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

[elm-discuss] Re: Code review request

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

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

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

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

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

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

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

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

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

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

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

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

(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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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