Re: [elm-discuss] Emphasizing /r/elm more

[Peter Damoc]

On Tue, Jan 3, 2017 at 2:50 AM, Evan Czaplicki  wrote:

> I recently talked with folks who moderate the various Elm discussion
> forums about the challenges that come up and how we can do better.
>
> The short version is: *we should start migrating more discussion
> to /r/elm .*
>

Funny story, I wanted to take your suggestion and start a topic on /r/elm
about Web Components and my 2 years quest for an Elm based UI toolkit but
Focus kicked in automatically at 9 AM and locked me out of reddit until 1
PM. :)

But I have to agree, reddit is a lot better in terms of having
discussions.

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

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

Re: [elm-discuss] Re: Feature: 'where' expressions (continued from GitHub)

[Janis Voigtländer]

And do you like that version? It seems to not have the advantages usually 
claimed for "where" in this discussion. For example, you define "a" before 
using it. What about "intent first" here? And in some sense, this formulation 
now looks like a dual to the workaround Joey proposed with "let" to please 
"where" proponents. Isn't it strange that "a" and "work" look like they might 
be mutually recursive now, when they are actually not and when the 
"let"-formulation made that explicitly visible?

> Am 02.01.2017 um 23:10 schrieb Colin Woodbury :
> 
> @Janis, I suppose the `where` version of that formation would have to be:
> 
> f tree = work
>   where a = ...
> work = case tree of
>   Leaf x -> -- using a and b  
> 
> where b = ...
>   Node s t -> -- using a c
> 
> where c = ...
> 
> 
>> On Sunday, 1 January 2017 12:21:47 UTC-8, Janis Voigtländer wrote:
>> Janis, the following compiles for me: …
>> 
>> Right, where does not work for expressions, but for right-hand sides, of 
>> which pattern match branches are an instance.
>> 
>> The next question would be, still under the assumption that a choice has to 
>> be made between where and let because both won’t be made available at the 
>> same time, how well “where-only” would work if in addition one wants to have 
>> a local binding that spans all pattern match branches, i.e., something one 
>> would currently write in Elm like so:
>> 
>> f tree =
>>   let
>> a = ... something ...
>>   in
>> case tree of
>>   Leaf x -> let b = ... in ... using a and b ...
>>   Node s t -> let c = ... in ... using a and c ...
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [elm-discuss] Re: Emphasizing /r/elm more

[Nick H]

I have never really used Reddit, but I am happy to try it out! That second
bullet point in particular has really been wearing down my morale lately.

Don't forget, elm-discuss still has top billing on the community page


On Mon, Jan 2, 2017 at 8:23 PM, Mark Hamburg  wrote:

> The web interface to Reddit is abysmal. Email isn't great but Reddit seems
> incredibly tedious.
>
> On Mon, Jan 2, 2017 at 7:21 PM, Charlie Koster 
> wrote:
>
>> I just wanted to confirm one of your assertions anecdotally. In the past
>> week I wrote two Elm blog posts and opted to post them to /r/elm rather
>> than elm-discuss for precisely the first two bullet points you listed. A
>> linear discussion would have been largely unhelpful and distracting.
>>
>> I also wanted to reinforce the importance of good moderation. I've seen
>> small subreddits grow and die due to a lack of moderation, but the ones
>> that have good moderation that encourage productive discussion end up doing
>> well.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to elm-discuss+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[elm-discuss] Re: Type specific messages

[Max Goldstein]

This sounds fine to me. It's certainly a lot better than:

type Msg
  = SwitchCowToExpandedReadOnly
  | SwitchCowToCollapsedReadOnly
  | SwitchCowToReadWrite
  | SwitchChickenToCollapsedReadOnly
  | ...

I think it largely hinges on your ability to separate orthogonal behavior 
as separate types. If Animal and EditMode make sense as types, and you can 
write useful functions that only take one, then that's what you should do. 
If animals and edit modes and actions have interwoven dependencies, things 
are of course trickier.

-- 
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: Emphasizing /r/elm more

[Mark Hamburg]

The web interface to Reddit is abysmal. Email isn't great but Reddit seems
incredibly tedious.

On Mon, Jan 2, 2017 at 7:21 PM, Charlie Koster  wrote:

> I just wanted to confirm one of your assertions anecdotally. In the past
> week I wrote two Elm blog posts and opted to post them to /r/elm rather
> than elm-discuss for precisely the first two bullet points you listed. A
> linear discussion would have been largely unhelpful and distracting.
>
> I also wanted to reinforce the importance of good moderation. I've seen
> small subreddits grow and die due to a lack of moderation, but the ones
> that have good moderation that encourage productive discussion end up doing
> well.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[elm-discuss] New array implementation has reached version 2.0.0

[Robin Heggelund Hansen]

The new implementation of arrays in Elm has reached version 2.0.0 and is 
available on elm-package 
(http://package.elm-lang.org/packages/Skinney/elm-array-exploration/latest)

This could end up being merged into core at some point in the future. 
Please try this implementation in your own code. It should have less bugs 
than the current version in core. For some operations (slicing and append) 
it is slower, for other operations (equality and push) it is faster. I'd 
love to hear feedback :)

This new version makes the Array type opaque (breaking change). It also 
delivers performance improvements in the range of 1.25-5x for certain 
operations.

-- 
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: Emphasizing /r/elm more

[Charlie Koster]

I just wanted to confirm one of your assertions anecdotally. In the past 
week I wrote two Elm blog posts and opted to post them to /r/elm rather 
than elm-discuss for precisely the first two bullet points you listed. A 
linear discussion would have been largely unhelpful and distracting.

I also wanted to reinforce the importance of good moderation. I've seen 
small subreddits grow and die due to a lack of moderation, but the ones 
that have good moderation that encourage productive discussion end up doing 
well.

-- 
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: Separate files for type declarations and code

[Ygor Bruxel]

I use 3 files:

   - Model.elm -> Where the model goes
   - Update.elm -> Where the Msg Type is declared and the update function
   - View.elm -> The View

And for the root I have a Route.elm where I put the coding/decoding of the 
url and ad App(or Main).elm

The Rest part from the Kris Jenkins article I extract to a lib folder, just 
like my domain models. So I don't reference sibling components and avoid 
the circular dependency problem while promoting reusability of my code.

On Monday, January 2, 2017 at 1:57:15 PM UTC-2, Richard Gebbia wrote:
>
> Prolific Elm programmers seem to have come to the same conclusion as well: 
> http://blog.jenkster.com/2016/04/how-i-structure-elm-apps.html
>
> On Saturday, December 31, 2016 at 6:29:08 PM UTC-5, Brian Marick wrote:
>>
>> To avoid circular dependencies, I find myself putting type declarations 
>> in one file: 
>>
>> > module Animals.Pages.Declare exposing (..) 
>> > 
>> > type PageChoice 
>> >   = AllPage 
>> >   | AddPage 
>> >   | HelpPage 
>>
>> … and related code in another: 
>>
>> > module Animals.Pages.Define exposing 
>> > ... 
>> > toPageChangeCmd : PageChoice -> Cmd Msg 
>> > toPageChangeCmd page = 
>> >   let 
>> >... 
>> >   in 
>> > Navigation.newUrl url 
>>
>>
>> Is that typical, or am I missing something? 
>>
>>
>>

-- 
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] Emphasizing /r/elm more

[Evan Czaplicki]

I recently talked with folks who moderate the various Elm discussion forums
about the challenges that come up and how we can do better.

The short version is: *we should start migrating more discussion to /r/elm
.*

Now the long version!


How Things Are Now

Long-form discussion is split between elm-discuss and /r/elm
. There are a lot of regulars that spend
more time on elm-discuss, but I think it's fair to say that /r/elm is much
more easily accessible and "public facing" for newcomers. This creates some
problems.

Problems with elm-discuss:

   - Threads are linear, so it's hard for people to branch off into
   sub-discussions.
   - There's no voting mechanism in elm-discuss, so topics are sorted by
   "are people posting?" not by "do people care?"
   - Moderation to avoid spam is more difficult. All new users are
   moderated by default to avoid those awful spam robots that Google Groups
   does not catch.
   - It goes to people's already full inboxes. If you change this, you use
   the online interface, which is not amazing.

Problems from having two long-form forums:

   - Lots of valuable expertise *only* lives on elm-discuss. When new folks
   come to /r/elm, there are not as many folks with as much production
   experience.
   - Blog posts (frequently shared on /r/elm) miss out on a lot of valuable
   feedback.


How Things Could Be

Right now I'm just suggesting that folks who are regulars here get on
/r/elm and see if you like it. I'd like to start by shifting the center of
gravity for community discussion.

Longer term though, things could look more like how Rust does it. It seems
like /r/rust  is the center of gravity for
community discussion. See their sidebar! They moderate content well and have
some laughs
.
(I personally think it's very important for moderators to be active in
guiding people towards *friendly* discussion! That's super hard on
elm-discuss.)

They also have an interesting approach to answering beginner questions

that
I think it'd be good to try out!

-- 
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: Christmas holiday projects.

['Rupert Smith' via Elm Discuss]

On Monday, January 2, 2017 at 11:30:27 PM UTC, Rupert Smith wrote:
>
> it is quite easy to map a Java Bean to this once you know how!
>

Very inefficient, but it works:

https://github.com/rupertlssmith/elm-java/blob/master/elm-render/src/main/java/com/thesett/elm/ElmRenderer.java#L89
 

-- 
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: Christmas holiday projects.

['Rupert Smith' via Elm Discuss]

On Monday, January 2, 2017 at 11:02:51 PM UTC, Emmanuel Rosa wrote:
>
> Yes, it's message based. A Verticle receives messages from the Vert.x 
> event bus, does it's computation (producing side-effects if needed) and 
> then produces messages. Hmm... I'll certainly be pondering this idea :)
>

Are the input and output message types the same? I guess not, so your 
update function might look a bit different to what we are used to.

update : inmsg -> model -> (model, outmsg)

perhaps? 

Actually, I don't even know if a Verticle has a state at all? In which case 
you might get away with the JsonProgram type I defined ServerSide.Static:

type alias JsonProgram =
Program Value Value Never

This takes some Json Value as input and produces a Json Value as output. If 
you can map your input and output messages to Json.Encoder.Value - it is 
quite easy to map a Java Bean to this once you know how!

-- 
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: Christmas holiday projects.

[Emmanuel Rosa]

Yes, it's message based. A Verticle receives messages from the Vert.x event 
bus, does it's computation (producing side-effects if needed) and then 
produces messages. Hmm... I'll certainly be pondering this idea :)

On Monday, January 2, 2017 at 5:39:59 PM UTC-5, Rupert Smith wrote:
>
> On Monday, January 2, 2017 at 1:23:52 PM UTC, Emmanuel Rosa wrote:
>>
>> Interesting. Would the technique work for business logic only (no UI)? 
>> I'm interested in creating pure functional Vert.x Verticles, so my idea is 
>> to write them in Frege. But, if it can be done with Elm... :)
>>
>
> Yes, I think it could. What I have done is to come up with an appropriate 
> program type for static Html, which takes a Json as input and produces a 
> Html Never as output, and has no update function. 
>
> I'd start with figuring out what your program type for "business logic 
> only" is going to be. I don't know Vert.x but is it message passing based? 
> So perhaps your business logic goes in an update function that responds to 
> and produces messages?
>
>  
>

-- 
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: Christmas holiday projects.

['Rupert Smith' via Elm Discuss]

On Monday, January 2, 2017 at 3:24:46 AM UTC, Richard Haven wrote:
>
> Sounds fantastic.
>
> About having to "warm up" the JIT runtime: 
>
> "Trying to outsmart a compiler [or runtime] defeats much of the purpose of 
> using one." -- Kernighan & Plauger 
>

It would be great if the JVM could store the stats it gathers during warm 
up to a file, so that on subsequent runs no warm up is needed - or perhaps 
just cache the binary machine code it produces so no JIT is needed on 
subsequent runs if .class files are not changed.

-- 
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 "faster than JavaScript" (version 0.18) - NOT - Parts I and II...

[GordonBGood]

On Tuesday, 3 January 2017 01:14:57 UTC+7, Bob Zhang wrote:
>
> Hi Gordon,
>Thanks for your lengthy reply. 
>I didn't try to convince you that OCaml is better than Haskell, they 
> are different styles : ). It just feel a little weird that "when you want 
> performance, you should switch from a statically typed language(elm here) 
> into a dynamically typed language(js)", a decent compiler should produce 
> much more efficient js output than hand written js, note that I have been 
> working on BuckleScript compiler for only one year, there are still many 
> low hanging fruits there and you can expect even better performance in the 
> near future.
>

Oh, you don't need to convince me about statically typed languages as I 
dislike dynamic typing except (perhaps) for using in "quick-and-dirty" 
applications using languages such as Python.  The only way I would use 
JavaScript would be to get its native speed, which is why I am looking for 
an alternative, and would much prefer that Elm would do it itself (reason 
for the thread), but it appears that will not be the case for quite some 
time.

Its interesting that you feel you can get yet more performance out of 
BuckleScript.
 

>   Some minor corrections to your comment 
>   - I am quite familiar with Haskell, OCaml, and F# (did 3 years research 
> in PL, I learned F# first, Haskell later and OCaml as the last one), the 
> expressivity of type system in my opinion  follow as below:
>   Haskell ~ OCaml > F# >> Elm
>

Yes Bob/Hongbo, my learning progression was the same as yours:  F# was 
first as an introduction to functional programming, then to see what the 
source of all the furor was about I learned Haskell (still learning the 
more advanced aspects), then heard good things about OCaml and knowing that 
F# syntax was somewhat derived from it, used it a little too but am nowhere 
near the stage of learning as with the other two.  I just recently 
discovered Elm and decided to investigate whether it was at a stable enough 
stage to be able to use.
 

>   (OCaml has a fairly advanced object system with structural typing and 
> row polymorphism which is incredibly useful to build FFI to JS objects)
>
> Yes, I can see that OCaml's features, just if I were looked for maximum 
> flexibility of type system I would prefer Haskell, but it isn't really a 
> big concern for the kinds of things I would use Elm for, which system is 
> adequate.  This is why I could accept Fable ever BucketScript if it were as 
> well developed as to ease of use and speed and stable even though not as 
> expressive just because I know it better and like its relative simplicity.
>
>   - If syntax matters a lot, you may be interested in ReasonML, Facebook 
> are working on a new syntax for OCaml and it works seamlessly with 
> BuckleScript, some core ReactJS developers are also working on high quality 
> ReactJS bindings
>
 
I have heard of ReasonML and the others, but don't really want to learn 
another language; Elm was easy but that is what has turned me away from 
PureScript as well as PS not being as stable nor currently producing nearly 
as fast code.  My intentions are pretty clear:  find an implementation of a 
language I already know and like to compile to fast JavaScript for the 
critical code only until Elm improves.
 

>   Happy New York and enjoy your favorite language!
>

Happy New Year to you, and I'm still looking for my favourite language ;) 

-- 
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: Feature: 'where' expressions (continued from GitHub)

[Colin Woodbury]

@Janis, I suppose the `where` version of that formation would have to be:

f tree = work
  where a = ...
work = case tree of
  Leaf x -> -- using a and b   
   
where b = ...
  Node s t -> -- using a c 
   
where c = ...


On Sunday, 1 January 2017 12:21:47 UTC-8, Janis Voigtländer wrote:
>
> Janis, the following compiles for me: …
>
> Right, where does not work for expressions, but for right-hand sides, of 
> which pattern match branches are an instance.
>
> The next question would be, still under the assumption that a choice has 
> to be made between where and let because both won’t be made available at 
> the same time, how well “where-only” would work if in addition one wants 
> to have a local binding that spans all pattern match branches, i.e., 
> something one would currently write in Elm like so:
>
> f tree =
>   let
> a = ... something ...
>   in
> case tree of
>   Leaf x -> let b = ... in ... using a and b ...
>   Node s t -> let c = ... in ... using a and c ...
>
> ​
>

-- 
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: The Style Elements Library: a different approach to styling

[Matthew Griffith]

Hello!

Essentially there are some things I'd like to do that I wouldn't be able to 
express in elm-css (With this being said, elm-css is super-awesome, and 
this style-elements library is still experimental).  I'm writing an article 
that goes more into detail but here's a general overview.  

First, this library is both about providing a better interface to CSS and 
sometimes _removing_ parts that generally only exist to cause trouble.  If 
this is just a collection of mixins for elm-css, then the library can't 
really "remove" a property.

Secondly, there's a new version of this library in the works that has a 
different approach to how we bind a style to an html element.  That may 
seem like there's only one way to do it (via classes), but I have an 
interesting approach to try out.  I'm hoping to have something working by 
mid-January to show what I mean.

Thirdly, I'm planning a sweet integration with elm-style-animation 
 that can only be done 
if I, as a library, have complete control over if a style is rendered 
inline or as a stylesheet.  Actually the plan is to dynamically switch 
between the two based on what the user wants.

I really appreciate the interest :)





On Monday, January 2, 2017 at 2:58:03 PM UTC-5, Kadzuya OKAMOTO wrote:
>
> Awesome! I completely agree with the policy to simplify CSS.
>
> I guess the policy may be also realized by providing a set of functions in 
> a manner of `rtfeldman/elm-css`'s `Mixin`s.
> What is the dominant benefits of making another library rather than 
> providing set of `rtfeldman/elm-css` `Mixin`s?
>
>
> On Thursday, October 27, 2016 at 10:20:14 PM UTC+9, Matthew Griffith wrote:
>>
>>
>> It's easy to write valid CSS that is still broken and frustrating. What 
>> if we could make frustrating CSS styles not expressible?
>>
>> I've been working on an experimental style library for making styles that 
>> are harder to break and easier to use.
>>
>> There is also support for flow/flexbox style layouts, animations, 
>> transitions, and media queries.
>>
>> It takes a different approach on attaching styles to html nodes. Instead 
>> of using classes and ids, you create collections of styled html elements to 
>> pull from to build your view (with support for classList style variations 
>> that can be turned on/off).  
>>
>> Let me know your thoughts!
>>
>> Note:  I haven't published this on elm-package yet as I wanted to see if 
>> there was any feedback that might alter what 1.0 looks like.
>>
>> The Style Elements library 
>>
>> Simple Example 
>> 
>>
>> Complex Example 
>> 
>>
>

-- 
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] Game entities design question

[Yoav Luft]

Hello Elm people!

I'm making a 2D video game to familiarize myself with Elm and I have a 
design issue I would like to hear your advice on.

In my game I have different UI entities with different behaviours, for 
example:

   - Some are collidable with the player / other entities, but other are 
   not.
   - Some move in the game world while other not (the view port might 
   change, but their game world position does not).
   - Some have AI logic that controls how they move, others are dumb.
   - Some interact with the mouse cursor while others do not.

I'm not sure how to model the different entities. In OOP scenario I would 
use a hierarchy of types and mixin types. In Aspect oriented programming I 
would compose them from different aspects. I'm not sure what I should do in 
Elm.

I have some constraints, for example, I need to hold all entities (accept, 
maybe, background entities without any interaction at all) in one data 
structure that will make collision detection easy, like a quadtree. They 
all need to be rendered when they are in the view port. I might need to 
implement some kind of path-finding algorithm.


I tried using this syntax:

type alias Positioned a =
  { a | x : Float, y : Float }

But I can't make a List or Tree of "Positioned a" and then pattern match on 
"a". Or at least, if I can I couldn't figure out a way to make it work.


Any suggestions would be appreciated!


-- 
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] Feature: 'where' expressions (continued from GitHub)

[Bob Hutchison]

Greeting, and a happy new year to all the readers of this thread;

The terms ‘let’ and ‘where’ are kinda widely understood among the *general 
public*, in Canada at least. The two terms are introduced in elementary school 
mathematics simultaneously with variables — I think grade three.

A simple google search for "let and where in mathematical notation” will give 
you plenty of hits.

For example (just search for the words ‘where’ and ‘let’):

* http://web.cs.ucdavis.edu/~amenta/w10/writingman.pdf "A Guide to Writing 
Mathematics”

* http://www.learningideas.me.uk/clearmaths/ "How to write mathematics clearly"

And on and on.

This is not some kind of highly specialised jargony thing, it a common usage.

Nor is this some legalistic setting where [oops, inadvertent use of the word] 
“‘where’ like in Haskell” means “‘where’ precisely and exactly as in Haskell” 
and not “‘where’, sorta like in Haskell but not necessarily exactly like and I 
don’t have either the time nor (I thought) the need to be totally precise in 
this informal discussion especially since there’s no clear evidence that it 
won’t be a total waste of my time to be so precise”.

[Colin, your energy displayed in your December 31 post 
https://groups.google.com/d/msg/elm-discuss/KiKF6K9gBKU/jzMuSTZmEwAJ is amazing]

Nobody is asking for rocket science. There is no evidence, and I find it hard 
to believe that any will ever be produced, that there’s anything special about 
(an english speaking) JavaScript programmer that makes comprehension of ‘where’ 
difficult.

If anyone’s interested in anecdotal evidence, I can tell you my experience as a 
40+ year professional programmer upon discovering the ‘where’ clause in 
Haskell. And the tick in variable names. And the backtick for infix notation. 
But I’m clearly not in Elm’s target demographic. So I won’t.

Cheers,
Bob

> On Jan 2, 2017, at 2:07 AM, Janis Voigtländer  
> wrote:
> 
> It’s how they are implemented in Haskell, and people asking for where in Elm 
> typically do so by saying “we want where like in Haskell”. One could probably 
> come up with new parsing rules that allow where to be used anywhere in an 
> expression, thus also for example for local bindings inside a 
> lambda-abstraction. But that would require new design work to make sure 
> everything fits together and the syntax remains unambigous and usable. That 
> probably presents an even bigger hurdle for acceptance into Elm than “just” 
> wanting to get Haskell-style where in.
> 
> 
> 2017-01-02 5:57 GMT+01:00 David Andrews :
> Is there something fundamental about `where` clauses which would prevent them 
> from parsing as expressions, or is this an artifact of how they are 
> implemented in Haskell?
> 
> On Sun, Jan 1, 2017 at 9:21 PM Janis Voigtländer 
>  wrote:
> 
> 
> Janis, the following compiles for me: …
> 
> 
> 
> Right, where does not work for expressions, but for right-hand sides, of 
> which pattern match branches are an instance.
> 
> 
> 
> The next question would be, still under the assumption that a choice has to 
> be made between where and let because both won’t be made available at the 
> same time, how well “where-only” would work if in addition one wants to have 
> a local binding that spans all pattern match branches, i.e., something one 
> would currently write in Elm like so:
> 
> 
> 
> f tree =
> 
>   let
> 
> a = ... something ...
> 
>   in
> 
> case tree of
> 
>   Leaf x -> let b = ... in ... using a and b ...
> 
>   Node s t -> let c = ... in ... using a and c ...
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> 
> 
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> 
> 
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Elm Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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: Separate files for type declarations and code

[Richard Gebbia]

Prolific Elm programmers seem to have come to the same conclusion as well: 
http://blog.jenkster.com/2016/04/how-i-structure-elm-apps.html

On Saturday, December 31, 2016 at 6:29:08 PM UTC-5, Brian Marick wrote:
>
> To avoid circular dependencies, I find myself putting type declarations in 
> one file: 
>
> > module Animals.Pages.Declare exposing (..) 
> > 
> > type PageChoice 
> >   = AllPage 
> >   | AddPage 
> >   | HelpPage 
>
> … and related code in another: 
>
> > module Animals.Pages.Define exposing 
> > ... 
> > toPageChangeCmd : PageChoice -> Cmd Msg 
> > toPageChangeCmd page = 
> >   let 
> >... 
> >   in 
> > Navigation.newUrl url 
>
>
> Is that typical, or am I missing something? 
>
>
>

-- 
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] Weird bug where messages passed to the wrong 'component'

[Simon]

Impressive, even if it does not - at first sight - feel like it addresses 
my issue (as I have no lazy code)

On Saturday, 31 December 2016 21:21:09 UTC+1, Mark Hamburg wrote:
>
> Tracked down and reported against the virtual DOM but the short summary 
> for anyone else seeing routing problems — though possibly not the ones that 
> started this thread — is that DOM updates have trouble if you have a lazy 
> node that resolves to an Html.map node. Don't do that. At least until 
> there's a fix. If you want to be lazy, stick a div in or avoid the map by 
> pushing the tagger function further down.
>
> Mark
>
> On Dec 14, 2016, at 10:23 PM, Mark Hamburg  > wrote:
>
> I'm looking at a bug tonight that looks very much like a tagger got 
> dropped in processing messages coming up the HTML tree. This is with 
> various bits of Html.Keyed paranoia. I'm thinking more and more strongly 
> that there are bugs in the tagging logic in the virtual DOM. I guess I know 
> what I'm hunting for over Christmas...
>
> Mark
>
> On Wed, Dec 14, 2016 at 7:17 AM, Mark Hamburg  > wrote:
>
>> I was dealing with a case where a textfield from a login screen would 
>> blur after the screen had been removed and replaced by the main content. 
>> (Literally. I was looking at the new content.) The blur message would get 
>> tagged as headed for the content area which would then lead to a crash when 
>> the message wasn't understood.
>>
>> My fix was to put an Html.Keyed at the top of the tree to reflect what 
>> state the app was in. (And then in a bit of paranoia, I looked for other, 
>> similar places further down and added Html.Keyed protection there as well.)
>>
>> Mark
>>
>> On Dec 13, 2016, at 10:24 PM, Simon  
>> wrote:
>>
>> Thanks, I suspected that keyed would be part of the solution.
>> Any sense on whether I need to apply it only to the components being left 
>> (easy) with no need on those that the code is switching to (much leasy in 
>> my case)?
>>
>>
>> On Wednesday, 14 December 2016 03:55:29 UTC+1, Mark Hamburg wrote:
>>>
>>> I just dug into what I think is essentially the same bug. My guess was 
>>> that textfields were getting removed from the DOM and then firing their 
>>> blur events up through the event mapping chain — which had been updated to 
>>> match the new view tree structure. It's on my list to try to build a small 
>>> example of the bug after my team gets through its next milestone.
>>>
>>> In the meantime, I worked around this by making fairly aggressive use of 
>>> Html.Keyed to prevent pieces of the DOM from being reused.
>>>
>>> Mark
>>>
>>> On Dec 13, 2016, at 9:56 AM, Simon  wrote:
>>>
>>> Sorry about using the C word!
>>>
>>> I had an error several months ago (0.16/0.17) where the wrong data would 
>>> be attached to message, causing all sorts of weirdness. It happened after a 
>>> successful logon and as the App tried to redirect to the main view. I have 
>>> a vague feeling that in the end all I needed to do was update 
>>> elm-lang/virtual-dom.
>>>
>>> Anyway, it has come back. It has something to do with when the browser 
>>> puts in login information for you. I can create the error by deleting the 
>>> auto-input and inserting my password and clicking enter to submit.
>>>
>>> Then what I see in my logs is this message
>>>
>>> `User.SwitchGroup: Blur "password"`
>>>
>>> Whereas SwitchGroup has type `String -> Msg` and `Blur "password"` are 
>>> artefacts of the elm-form library that was used in the Login component and 
>>> is not used in the User one.
>>>
>>> Does this remind anyone of something they have experienced, solved, and 
>>> remembered how they solved it?
>>>
>>> -- 
>>> 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] Separate files for type declarations and code

[Simon]

I do it, but call it xx.Model.elm

On Sunday, 1 January 2017 00:37:41 UTC+1, Martin DeMello wrote:

I do the same thing in both ocaml and elm code. It's a pretty common 
> pattern.
>
> martin
>
> On Dec 31, 2016 3:29 PM, "Brian Marick"  
> wrote:
>
>> To avoid circular dependencies, I find myself putting type declarations 
>> in one file:
>>
>> > module Animals.Pages.Declare exposing (..)
>> >
>> > type PageChoice
>> >   = AllPage
>> >   | AddPage
>> >   | HelpPage
>>
>> … and related code in another:
>>
>> > module Animals.Pages.Define exposing
>> > ...
>> > toPageChangeCmd : PageChoice -> Cmd Msg
>> > toPageChangeCmd page =
>> >   let
>> >...
>> >   in
>> > Navigation.newUrl url
>>
>>
>> Is that typical, or am I missing something?
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
> ​

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

[elm-discuss] Re: Christmas holiday projects.

[Emmanuel Rosa]

Interesting. Would the technique work for business logic only (no UI)? I'm 
interested in creating pure functional Vert.x Verticles, so my idea is to 
write them in Frege. But, if it can be done with Elm... :)

Vert.x already uses Nashhorn for their JavaScript support. To perhaps... 
Elm could be compiled with a "Vert.x platform" so that it follows the 
Verticle "architecture" rather than TEA.

On Sunday, January 1, 2017 at 7:13:12 PM UTC-5, Rupert Smith wrote:
>
> On Sunday, January 1, 2017 at 12:00:28 AM UTC, Emmanuel Rosa wrote:
>>
>> I'm a JVM guy, so my plan is to go functional all the way down the stack 
>> by using Frege on the JVM side; although Ceylon looks interesting too.
>>
>
> BTW, I've got Elm running on the JVM via Nashorn:
>
> https://github.com/rupertlssmith/elm-java
>

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