[elm-discuss] Can I throw strings at the elm compiler

[Adam Fluke]

I couldn't find a way to do it, but I thought I would ask anyway. 

I would like to be able to ask, from node or bash, if a string would 
compile if it were written to a file. Something like `elm 
make-but-not-really "not valid string"` 

-- 
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] Can I throw strings at the elm compiler?

[Adam Fluke]

So I know that answer may be no, but I thought I'd ask incase I missed 
something. 

The short question version of the question:

Can I pass strings to the elm compiler to see if they will compile without 
writing to a file?

The long version of the question:

I love idea of machine generated code, and have been exploring applying 
evolutionary biology principles to code generation. In node, this required 
throwing things at unit tests, but it was really slow for a number of 
reasons. So the exploration has idled. Now I have been learning/toying with 
elm and thought, "This would be perfect for evolutionary code search, I 
only have to run tests on code that compiles, meaning 99% never going to 
work mutations are cheaply discarded, and the 1% can be tested."

The psuedo code in my head:

hey elm compiler



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

[elm-discuss] Re: How to write function that updates arbitrary element of a record

[Francesco Orsenigo]

Can't you just create a smaller component that does the validation on 
itself, and then compose several of them into a list/dictionary?

componentUpdate : (String -> Bool) -> Msg -> String
componentUpdate hasError msg oldString =
  case UserEntersSomething newString
if hasError newString then
  oldString
else
  newString

fields : Dict String (String -> Bool)
fields = Dict.fromList
  [("minutes", validateMinutes)
  ...
  ]


mainUpdate msg model =
  case ChildComponentMsg childName childMsg ->
Maybe.withDefault model <|
   Maybe.map2
 (\validationFunction childState -> { model | childStates = 
Dict.insert childName (updateChild validationFunction childMsg childState) }
 (Dict.get childName fields)
 (Dict.get childName model.childStates)


(Maybe pick a better way to write it, but the gist is: use the Elm 
Architecture pattern)

-- 
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] How to model a transient state?

[Jacky]

Thanks! "Marked" is clearer and reflect what's happening on the screen.

On Fri, Oct 21, 2016 at 3:55 AM, Nick H  wrote:

> What if you added a third value to the ReadState type?
>
> type ReadState = Read | Unread | Marked
>
> Then your filtered view will show both Unread and Marked. When the user
> refreshes, you can map all the Marked items to Read.
>
> On Thu, Oct 20, 2016 at 12:43 AM, Jacky See  wrote:
>
>> My current approach is to have a `readStateToBe` which contains the
>> pending update state.
>> and 'flush update' (write `readStateToBe` to `readState`) on appropriate
>> update branch (e.g. switching filter).
>>
>> --
>> 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 a topic in the
> Google Groups "Elm Discuss" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/elm-discuss/r1oWcVL95Fs/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Best Regards,
Jacky See

-- 
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] Proposal: Rename case..of -> match..with

[Kasey Speakman]

But `case` is a pattern matcher. Check out how it is used here in lieu of a 
parser.

https://github.com/knewter/time-tracker/blob/master/elm/src/Route.elm#L91

On Thursday, October 20, 2016 at 11:16:49 AM UTC-5, Joey Eremondi wrote:
>
> There's precedence in both directions, case comes from Haskell. So 
> changing it doesn't necessarily mean we'll match everyone else, pardon the 
> pun. 
>
> Being easier for non native English speakers seems pretty subjective, some 
> people might find case more intuitive as non native speakers. 
>
> To me, case is better at capturing the idea of programming by cases, that 
> it's a branching construct, not just a pattern matcher. 
>
> Both have pros and cons, and are roughly equal in my mind, but changing it 
> would break literally all Elm code ever, so I think the status quo wins in 
> this case. 
>
> On Oct 20, 2016 7:56 AM, "OvermindDL1"  
> wrote:
>
> On Thursday, October 20, 2016 at 8:46:42 AM UTC-6, Peter Damoc wrote:
>
>> On Thu, Oct 20, 2016 at 5:06 PM, Robin Heggelund Hansen <
>> skinn...@gmail.com> wrote:
>>
>>> The proposal, as the title of the post suggests, is to rename the 
>>> "case..of" expression to "match..with". 
>>>
>>
>> One added benefit that I'm seeing is that today, if I would have to 
>> describe "case...of", I would use the words "pattern matching". :) 
>>
>> I wonder if this has been discussed before.  I did a quick search but 
>> nothing jumped out as relevant. 
>>
>> > case..of to match..with renaming could be handled by elm-format.
>>
>> in theory, yes, it could be handled by a tool like elm-format but in 
>> practice, in order for it to be effective, it should be handled by 
>> something that is part of the elm-platform. 
>> this kind of a mechanical replacement would be OK if it would be handled 
>> right away and in an official manner. 
>> requiring installing extra tools that come with alpha warnings might be 
>> scary. 
>>
>
> If this were done (plenty of other precedence, OCaml uses `match ... with` 
> too), there could be a deprecation period where both are supported and 
> `case ... of` generated deprecation warnings... 
>
> -- 
> 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] elm-testable versus testing a lower-level function

[Andrew Bruce]

I'm new to Elm, and have been playing with test methodologies.

I'm wondering what the arguments for using elm-testable 
 are, as opposed to testing something 
that returned a `(Model, Maybe Cmd)`, for example.
I've dodged using elm-testable by having a mapping from a testable function 
that produces a `(Maybe Msg)` to `(Cmd Msg)`. Obviously this mapping isn't 
itself testable, but I can live with that. Am I missing something that's 
about to bite me?

For an example, this is 
testable: 
https://github.com/camelpunch/rascal-elm/blob/a8a5b064a76f360da6dd63b5e1b0b3a479d66948/src/Application.elm#L20

But this, which calls the the above, isn't, because it produces `Cmd` 
values that can't be easily asserted against in 
test: 
https://github.com/camelpunch/rascal-elm/blob/a8a5b064a76f360da6dd63b5e1b0b3a479d66948/src/Update.elm#L14
 
- but it's a fairly trivial mapping.

In general I'd prefer to update my own wrapper around Elm's changing API 
rather than elm-testable's, as I don't trust a nominally 'third party' 
library to stay in sync with Elm. Am I being paranoid? Perhaps there's a 
plan to make Elm's types more test-friendly?

P.S. Hi Aaron! This is some cool stuff you're working on.

-- 
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: Proposal: rename foldl til foldLeft and foldr to foldRight

['Andrew Radford' via Elm Discuss]

Changes like this I think make sense if it is part of a more general effort 
- i.e 'Elm is going to be known as the language with proper function 
names"i.e it sounds like a BDFL call. Has that every been stated by Evan or 
is it just something that appears to be in the same line of thinking as 
removing primes etc?

Not saying it's a bad idea BTW - especially since some people new to Elm 
won't be familiar with the terse style functions you see commonly in FP 
languages  -'foldr' 'cons' etc if they haven't used one of those languages


On Thursday, 20 October 2016 15:12:57 UTC+1, Robin Heggelund Hansen wrote:
>
> In Elm 0.18, primes are being removed as valid characters in a 
> variable/function name. The reason being, which I whole heartedly agree 
> with, that removing primes will incentivize people to write proper names, 
> and also because the difference between model and model' isn't always easy 
> to spot.
>
>

-- 
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] Structure for large Elm apps

[clouddie]

Actually, just to testify on nested components : got severely burnt by this 
pattern as I spent my Sunday refactoring my app before discovering that one 
nested component had to update the state of an other one, and realized I 
just did not want to go through the whole sibling or child whatever pattern 
(https://www.brianthicks.com/post/2016/06/27/candy-and-allowances-part-ii-child-child-communication-in-elm/)
 
which seems way too complicated.

So I just refactored out my main file into Model, Msg, Update, View, and 
used helper functions, and now my mind is clear again. "Better flat than 
nested" might be a good idea after all...

Le lundi 17 octobre 2016 21:38:14 UTC+2, Eric G a écrit :
>
> I'm no expert, and would like clarification on this as well, but "pages of 
> an app" seems like the main place where using nested modules makes sense -- 
> unless your pages can be modeled more easily as variants of each other, as 
> sometimes happens. 
>
> My experience* has been that just about everywhere else it's easier to 
> have flat modules, using helper update functions, view functions with 
> generic msg types, config records, etc., and extracting common bits as 
> needed into separate modules. Sometimes I have nested msg types, and do the 
> Html.App.map / Cmd.map  internally, within one module. Richard Feldman had 
> a list of "steps to take before breaking code out into separate modules" 
> awhile back that I thought was helpful.
>
> As for that article you linked to, it seems overkill, esp. for what is 
> mostly a static site. All of the static pages can just be functions in 
> Main, just split out the ones that have actual actions like the Contact 
> page, and then only if it seems unwieldy to handle those in Main too.  
>
> Basically my advice is start with Main, or Main and one page module, and 
> see how far you get, rather than planning ahead what your file structure is 
> going to look like.
>
> (*My experience is limited to business-y company-internal applications, 
> someone else will have to say what works for games and other kinds of 
> applications.)
>
>
> On Monday, October 17, 2016 at 2:41:23 PM UTC-4, Marcus Roberts wrote:
>>
>> Is this article (and the one it refers to) taking a good or bad approach 
>> to program structure?
>>
>> http://7sharpnine.com/2016/10/03/building-an-spa-with-elm/ 
>> 
>>
>> I copied the structure as a way of seeing how a program might perhaps be 
>> broken down, but it feels like a very component based approach, given each 
>> level has its own update function.  I learnt a fair bit about mapping 
>> between message types, so it was useful.
>>
>> I've broken my app down into pages using this structure, and so each page 
>> has a view, model, etc.  Then the top level model has a model record for 
>> each page.  This seems to work as it means the page doesn't need to know 
>> how it's being used at the level above.  But the general conversations I 
>> see suggests this is not the right way to go and to break things down more 
>> into modules of related code.So I guess back to the original question, 
>> is this structure a good way to work? 
>>
>>
>>
>>
>> On Mon, Oct 17, 2016 at 7:50 AM, Peter Damoc  wrote:
>>
>>> update is a function that takes a message and a model and produces the 
>>> updated version of the model. In some cases, update also can produce some 
>>> requests for more input (http requests, requests for random numbers, ports 
>>> requests) this is why the top level update has (Model, Cmd Msg) as return. 
>>> Internal updates however, might not need these requests and can be 
>>> simpler. 
>>> What you see in the repository you linked is a pattern of nesting 
>>> "components" that is currently passively discouraged.  (there use to be a 
>>> set of examples around this but they are gone). 
>>>
>>> The official recommendation around scaling is to focus on breaking the 
>>> functionality into functions:
>>> https://guide.elm-lang.org/reuse/
>>>
>>>
>>>
>>>
>>> On Mon, Oct 17, 2016 at 12:00 AM, clouddie  
>>> wrote:
>>>
 Hi, are there official guidelines for structuring large scale apps ? 
 For instance, what is the community take on things like 
 https://github.com/rogeriochaves/structured-elm-todomvc/tree/modular ?
 This is quite neat although I cannot quite m'y head round the fact the 
 Update fonctions in TaskList deal with messages for Task ans TaskList, and 
 they do not respect thé standard (Model, Cmd Msg) signatures ?

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

>>>
>>>

[elm-discuss] Re: Metalinguistic abstractions over databases

[Kasey Speakman]

I like to put databases behind APIs. But I don't map URIs directly to 
database entities. I map URIs to use cases and queries. A use case could 
make multiple changes to the system, not just change one table. A query 
doesn't necessarily map to a single entity either. The result of one query 
might contain data from several entities.

So the key here is to use the API like an entry point into your system, NOT 
an entry point into your database.

On Wednesday, October 19, 2016 at 3:54:44 AM UTC-5, Peter Damoc wrote:
>
> *The problem *
>
> I know how to implement a REST API and interrogate that API from Elm but 
> that *seams very low level. *
>
> I was curious about a language abstraction that would isolate my Elm 
> program from the actual database strategy.  
>
> How do you approach dealing with the databases? What is your strategy? 
> What options are there?
> Do you have any pointers to interesting perspective/approaches? 
>
>
>
> -- 
> 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.

[elm-discuss] Re: Demo project that fails Google Closure Advanced Optimizations

[Robin Heggelund Hansen]

If you get the chance, try to change the generated code from the elm 
compiler and change statements that performs a `'ctor' in obj` tests. 
Change them to `typeof obj.ctor === 'undefined'` or some such. There is one 
in the eqHelp function (called by `=`) and one in the toString function.

The reason this will fail with google closure is that the ctor property is 
renamed when used with advanced optimizations, and so 'ctor' checks will 
fail.

torsdag 20. oktober 2016 21.42.55 UTC+2 skrev OvermindDL1 følgende:
>
> I know it fails on our large Elm project at work, we have to run with 
> standard optimizations of the Google Closure compiler, but I did not 
> research in to far since generated code is not code that I control and I 
> needed to get things done.  If I get time I'll try to run it again and get 
> some data on it.
>
>
> On Thursday, October 20, 2016 at 11:16:16 AM UTC-6, Robin Heggelund Hansen 
> wrote:
>>
>> I was wondering if anyone had a project that fails to run properly when 
>> applied with the Advanced Optimizations of the Google Closure Compiler?
>> I want to figure out what the problems are so that I can submit a PRs to 
>> fix the problem.
>> Pretty sure I've figured out what the problems are, but I need to 
>> replicate my success on larger projects than the few test cases I've made.
>>
>

-- 
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] How to model a transient state?

[Nick H]

What if you added a third value to the ReadState type?

type ReadState = Read | Unread | Marked

Then your filtered view will show both Unread and Marked. When the user
refreshes, you can map all the Marked items to Read.

On Thu, Oct 20, 2016 at 12:43 AM, Jacky See  wrote:

> My current approach is to have a `readStateToBe` which contains the
> pending update state.
> and 'flush update' (write `readStateToBe` to `readState`) on appropriate
> update branch (e.g. switching filter).
>
> --
> 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: Demo project that fails Google Closure Advanced Optimizations

[OvermindDL1]

I know it fails on our large Elm project at work, we have to run with 
standard optimizations of the Google Closure compiler, but I did not 
research in to far since generated code is not code that I control and I 
needed to get things done.  If I get time I'll try to run it again and get 
some data on it.


On Thursday, October 20, 2016 at 11:16:16 AM UTC-6, Robin Heggelund Hansen 
wrote:
>
> I was wondering if anyone had a project that fails to run properly when 
> applied with the Advanced Optimizations of the Google Closure Compiler?
> I want to figure out what the problems are so that I can submit a PRs to 
> fix the problem.
> Pretty sure I've figured out what the problems are, but I need to 
> replicate my success on larger projects than the few test cases I've made.
>

-- 
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] Proposal: rename foldl til foldLeft and foldr to foldRight

[Martin DeMello]

I would be strongly opposed to renaming either foldl or foldr to just fold;
that always confuses me when languages do it.

martin

On Thu, Oct 20, 2016 at 8:32 AM, Max Goldstein 
wrote:

> Normally I'm opposed to syntax or name changes. But I think this or some
> variation is a good idea. (Maybe foldl becomes fold, since it's usually the
> one you want.)
>
> That said, it's all subject to Evan's approval.
>
> --
> 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: Metalinguistic abstractions over databases

[John Kelly]

I'm sorry to link drop, but I've been doing a bit of work on a library to 
remove some of the boilerplate when writing client code for a REST API. The 
library is currently locked in / specific to what is called PostgREST, but I 
imagine that the patterns could be applied to any REST backend. Check it out: 
https://github.com/john-kelly/elm-postgrest/ 

The core idea is to remove the boilerplate of always having to define encoder, 
decoder and schema. Would love to chat.

-- 
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: Proposal: rename foldl til foldLeft and foldr to foldRight

[Robin Heggelund Hansen]

Please stay on topic. This thread is strictly about the naming of foldl and 
foldr, nothing else.

torsdag 20. oktober 2016 19.24.47 UTC+2 skrev Ambrose Laing følgende:
>
> One could define fold as a generic operation that replaces the empty list 
> with a constant (for example an identity element) and replaces the "cons" 
> operator with a function that takes an element and a partial result.  This 
> is consistent with other ways to define generalized folds over recursive 
> data structures.  For example for trees you can replace the leaf node with 
> a constant and replace the internal node with a binary function.  The key 
> idea here is that fold directly reflects the natural structure of the 
> underlying data structure.  ie, the way you would draw a picture of the 
> underlying data structure is exactly the picture of the execution order. 
>  If we are consistent with this, then fold will be defined for lists to be 
> the same as foldRight for lists.  For more detailed exposition to motivate 
> this definition, see the paper "Merging Monads and Folds for Functional 
> Programming", by Meijer and Jeuring. 
> 
>
> One could also define a fold (as scala does) to be not-necessarily-linear 
> -- the execution order is unspecified and left up to the implementer.  So 
> in scala, a fold can split up a list into many pieces (sublists) and 
> process the sublists in parallel, and then fold them up to obtain the final 
> answer.  In this case, it is not necessaria foldLeft or a foldRight.  It 
> could actually be a fold-from-the-middle or even 
> fold-from-many-places-in-the-middle.  In order to make sure the answer is 
> well-defined, the folding operator is required to be associative.
>
> IMO it would be a good idea to avoid confusion with these alternative 
> semantics by not reusing the name "fold" at all, or else adopting one of 
> the conventional meanings (if we can agree what the most common meaning is).
>
> On Thursday, October 20, 2016 at 11:32:12 AM UTC-4, Max Goldstein wrote:
>>
>> Normally I'm opposed to syntax or name changes. But I think this or some 
>> variation is a good idea. (Maybe foldl becomes fold, since it's usually the 
>> one you want.)
>>
>> That said, it's all subject to Evan's approval. 
>>
>

-- 
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: Proposal: rename foldl til foldLeft and foldr to foldRight

[Ambrose Laing]

One could define fold as a generic operation that replaces the empty list 
with a constant (for example an identity element) and replaces the "cons" 
operator with a function that takes an element and a partial result.  This 
is consistent with other ways to define generalized folds over recursive 
data structures.  For example for trees you can replace the leaf node with 
a constant and replace the internal node with a binary function.  The key 
idea here is that fold directly reflects the natural structure of the 
underlying data structure.  ie, the way you would draw a picture of the 
underlying data structure is exactly the picture of the execution order. 
 If we are consistent with this, then fold will be defined for lists to be 
the same as foldRight for lists.  For more detailed exposition to motivate 
this definition, see the paper "Merging Monads and Folds for Functional 
Programming", by Meijer and Jeuring. 


One could also define a fold (as scala does) to be not-necessarily-linear 
-- the execution order is unspecified and left up to the implementer.  So 
in scala, a fold can split up a list into many pieces (sublists) and 
process the sublists in parallel, and then fold them up to obtain the final 
answer.  In this case, it is not necessaria foldLeft or a foldRight.  It 
could actually be a fold-from-the-middle or even 
fold-from-many-places-in-the-middle.  In order to make sure the answer is 
well-defined, the folding operator is required to be associative.

IMO it would be a good idea to avoid confusion with these alternative 
semantics by not reusing the name "fold" at all, or else adopting one of 
the conventional meanings (if we can agree what the most common meaning is).

On Thursday, October 20, 2016 at 11:32:12 AM UTC-4, Max Goldstein wrote:
>
> Normally I'm opposed to syntax or name changes. But I think this or some 
> variation is a good idea. (Maybe foldl becomes fold, since it's usually the 
> one you want.)
>
> That said, it's all subject to Evan's approval. 
>

-- 
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] React for Elm programmers

[Thomas Ballinger]

Nothing came up from a cursory Google search, does anyone know of or have 
interest in a resource like "React for Elm Programmers?"

I've just done a few Elm projects, but now as I explore the React ecosystem 
I'm wishing I had access to explanations in terms of Elm concepts I'm more 
familiar with.

-- 
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] Proposal: Rename case..of -> match..with

[Joey Eremondi]

There's precedence in both directions, case comes from Haskell. So changing
it doesn't necessarily mean we'll match everyone else, pardon the pun.

Being easier for non native English speakers seems pretty subjective, some
people might find case more intuitive as non native speakers.

To me, case is better at capturing the idea of programming by cases, that
it's a branching construct, not just a pattern matcher.

Both have pros and cons, and are roughly equal in my mind, but changing it
would break literally all Elm code ever, so I think the status quo wins in
this case.

On Oct 20, 2016 7:56 AM, "OvermindDL1"  wrote:

On Thursday, October 20, 2016 at 8:46:42 AM UTC-6, Peter Damoc wrote:

> On Thu, Oct 20, 2016 at 5:06 PM, Robin Heggelund Hansen <
> skinn...@gmail.com> wrote:
>
>> The proposal, as the title of the post suggests, is to rename the
>> "case..of" expression to "match..with".
>>
>
> One added benefit that I'm seeing is that today, if I would have to
> describe "case...of", I would use the words "pattern matching". :)
>
> I wonder if this has been discussed before.  I did a quick search but
> nothing jumped out as relevant.
>
> > case..of to match..with renaming could be handled by elm-format.
>
> in theory, yes, it could be handled by a tool like elm-format but in
> practice, in order for it to be effective, it should be handled by
> something that is part of the elm-platform.
> this kind of a mechanical replacement would be OK if it would be handled
> right away and in an official manner.
> requiring installing extra tools that come with alpha warnings might be
> scary.
>

If this were done (plenty of other precedence, OCaml uses `match ... with`
too), there could be a deprecation period where both are supported and
`case ... of` generated deprecation warnings...

-- 
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] Proposal: rename foldl til foldLeft and foldr to foldRight

[Max Goldstein]

Normally I'm opposed to syntax or name changes. But I think this or some 
variation is a good idea. (Maybe foldl becomes fold, since it's usually the one 
you want.)

That said, it's all subject to Evan's approval. 

-- 
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: ports and reserved words

[Frederick Yankowski]

I had a similar problem with a field named `default`. I think you have to 
avoid all Javascript reserved words for records passed through ports. 
 http://www.w3schools.com/js/js_reserved.asp

It is an unfortunate leak of Javascript constraints into the Elm world. It 
does seem that the compiler could warn about such cases as it knows exactly 
which types of values are going over ports. 

On Wednesday, October 19, 2016 at 4:48:42 PM UTC-5, Craig Bilner wrote:
>
> I'm probably missing something obvious here but when my port is a record 
> with an attribute of `class` it comes through as `undefined`. Is there some 
> documentation somewhere outlining reserved words in this area? Should the 
> compiler throw?
>
>

-- 
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] Proposal: Rename case..of -> match..with

[Peter Damoc]

On Thu, Oct 20, 2016 at 5:06 PM, Robin Heggelund Hansen <
skinney...@gmail.com> wrote:

> The proposal, as the title of the post suggests, is to rename the
> "case..of" expression to "match..with".
>

One added benefit that I'm seeing is that today, if I would have to
describe "case...of", I would use the words "pattern matching". :)

I wonder if this has been discussed before.  I did a quick search but
nothing jumped out as relevant.

> case..of to match..with renaming could be handled by elm-format.

in theory, yes, it could be handled by a tool like elm-format but in
practice, in order for it to be effective, it should be handled by
something that is part of the elm-platform.
this kind of a mechanical replacement would be OK if it would be handled
right away and in an official manner.
requiring installing extra tools that come with alpha warnings might be
scary.


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

[elm-discuss] Re: Metalinguistic abstractions over databases

[OvermindDL1]

On Thursday, October 20, 2016 at 3:55:45 AM UTC-6, Rupert Smith wrote:
>
> On Wednesday, October 19, 2016 at 8:23:46 PM UTC+1, OvermindDL1 wrote: 
>>
>> Absinthe handles all the nasty parts of GraphQL though, the combining of 
>> queries, the real-time type documentation generation, etc... etc...
>>
>
> What database do you use? Is it always a SQL database or can Absinthe work 
> with noSQL too?
>
> Also, when it combines queries, does it translate that down into an 
> efficient SQL join? Or does it process the joins outside of the database, 
> in the server code? 
>

It is storage agnostic, and technically you do not even need a storage, 
remember that GraphQL calls are basically just RPC, you could have a `fib` 
GraphQL call that just calculates that.

The database I use is PostgreSQL via the Ecto library though.  Absinthe is 
database and all agnostic, however it does have a section at 
http://absinthe-graphql.org/guides/ecto-best-practices/ talking about the 
best ways to use it with ecto for optimization purposes, and they do have 
planned more detailed ecto integration in the future, but for now it is 
do-it-yourself (which I prefer, means I can use my permission system to 
only return specific things that they have access to).  Absinthe itself 
does not combine queries, it has no clue what a query is, it just gives the 
graphql 'function call' setup to you, what the user requested, what they 
passed in, etc...  With proper Ecto work all the joins are in-database. 
 With ecto it is trivial to build up database joins in piecemeal, so it 
works fantastically with graphql.

-- 
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: why no more primes on 0.18 ?

[OvermindDL1]

On Wednesday, October 19, 2016 at 7:39:25 PM UTC-6, Nathan Schultz wrote:
>
> Primes I'll miss for convenience, like when naming an inner tail-recursion 
> function to distinguish it from its wrapper. But it's not a big deal.
>

The convention for that in a few other languages is the name 'aux', such as 
in this copy/paste, perhaps that same convention could be brought in for 
that purpose?

  let rle list =
let rec aux count acc = function
  | [] -> [] (* Can only be reached if original list is empty *)
  | [x] -> (x, count + 1) :: acc
  | a :: (b :: _ as t) ->
 if a = b then aux (count + 1) acc t
 else aux 0 ((a, count + 1) :: acc) t  in aux 0 [] 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: Do the same with ELM?

[Erkal Selman]

I also think that an easy way for sharing examples is a very effective to 
make elm popular.
Mike Bostock did it very well with 
D3.js: https://bost.ocks.org/mike/example/

>From his talk:

I use examples so often that I created bl.ocks.org to make it easier for me 
> to share them. It lets you quickly post code and share examples with a 
> short URL. Your code is displayed below; it’s view source by default. And 
> it’s backed by GitHub Gist , so examples have a 
> git repository for version control, and are forkable, cloneable and 
> commentable.


We also have to have this kind of thing. 

@Antonio: sorry but the contribution instructions are too complicated: 
http://blog.krawaller.se/jscomp/index.html 
I am not going to do it. :)
But you can do it if you want. (or anybody else) 



On Thursday, October 20, 2016 at 3:58:51 PM UTC+2, António Ramos wrote:
>
> I´m so in love with ELM,
> @Erkal please submit this code to 
> http://blog.krawaller.se/jscomp/pages/composition.html
>
> Thank you
>
> 2016-10-20 14:56 GMT+01:00 Erkal Selman 
> :
>
>> Thanks Marco, here is the corrected version:
>>
>> *import Html exposing (text, div, input, button, p, span)*
>> *import Html.App exposing (beginnerProgram)*
>> *import Html.Attributes exposing (..)*
>> *import Html.Events exposing (onInput, onClick)*
>>
>>
>> *main =*
>> *beginnerProgram*
>> *{ model = { state = WaitingForSubmit, inputStr = "", 
>> submittedValue = "" }*
>> *, update = update*
>> *, view = view*
>> *}*
>>
>>
>>
>> *-- MODEL*
>>
>>
>> *type alias Model =*
>> *{ state : State*
>> *, inputStr : String*
>> *, submittedValue : String*
>> *}*
>>
>>
>> *type State*
>> *= WaitingForSubmit*
>> *| WaitingForConfirm*
>>
>>
>>
>> *-- UPDATE*
>>
>>
>> *type Msg*
>> *= NewContent String*
>> *| Submit*
>> *| Cancel*
>> *| Confirm*
>>
>>
>> *update msg model =*
>> *case msg of*
>> *NewContent str ->*
>> *{ model | inputStr = str }*
>>
>> *Submit ->*
>> *{ model | state = WaitingForConfirm }*
>>
>> *Cancel ->*
>> *{ model | state = WaitingForSubmit }*
>>
>> *Confirm ->*
>> *{ model*
>> *| state = WaitingForSubmit*
>> *, inputStr = ""*
>> *, submittedValue = model.inputStr*
>> *}*
>>
>>
>>
>> *-- VIEW*
>>
>>
>> *view { state, inputStr, submittedValue } =*
>> *div []*
>> *[ input [ onInput NewContent, value inputStr ] []*
>> *, case state of*
>> *WaitingForSubmit ->*
>> *span []*
>> *[ button [ disabled (inputStr == ""), onClick Submit 
>> ] [ text "Submit" ] ]*
>>
>> *WaitingForConfirm ->*
>> *span []*
>> *[ button [ onClick Cancel ] [ text "Cancel" ]*
>> *, button [ onClick Confirm ] [ text "Confirm" ]*
>> *]*
>> *, p [] [ text ("Submitted value: " ++ submittedValue) ]*
>> *]*
>>
>> On Thursday, October 20, 2016 at 3:49:49 PM UTC+2, Marco Perone wrote:
>>>
>>> you could just add a `value` to your input field like
>>>
>>> input [ onInput NewContent, value inputStr ]
>>>
>>> and then reset the `inputStr` value when you confirm the submission
>>>
>>> Confirm ->
>>> { model
>>> | state = WaitingForSubmit
>>> , inputStr = ""
>>> , submittedValue = model.inputStr
>>> }
>>>
>>> On Thursday, October 20, 2016 at 2:57:54 PM UTC+2, Erkal Selman wrote:

 You can paste the following into http://elm-lang.org/try :


 *import Html exposing (text, div, input, button, p, span)*
 *import Html.App exposing (beginnerProgram)*
 *import Html.Attributes exposing (..)*
 *import Html.Events exposing (onInput, onClick)*


 *main =*
 *beginnerProgram*
 *{ model = { state = WaitingForSubmit, inputStr = "", 
 submittedValue = "" }*
 *, update = update*
 *, view = view*
 *}*



 *-- MODEL*


 *type alias Model =*
 *{ state : State*
 *, inputStr : String*
 *, submittedValue : String*
 *}*


 *type State*
 *= WaitingForSubmit*
 *| WaitingForConfirm*



 *-- UPDATE*


 *type Msg*
 *= NewContent String*
 *| Submit*
 *| Cancel*
 *| Confirm*


 *update msg model =*
 *case msg of*
 *NewContent str ->*
 *{ model | inputStr = str }*

 *Submit ->*
 *{ model | state = WaitingForConfirm }*

 *Cancel ->*
 *{ model | state = WaitingForSubmit }*

 *Confirm ->*
 *{ model*
 *| state = 

Re: [elm-discuss] Proposal: Rename case..of -> match..with

[António Ramos]

I´m a "no Elm experience people" and i dont like "match with".

to type "case of" i need 6 keystrokes(without spaces) to type "match with"
i need 9 .

i would prefer to remove the "of" and just leave it as "case ?!?  ->"
instead of "case ?!? of ->"

Regards to whomever lives to type less and love more... ;)

2016-10-20 15:06 GMT+01:00 Robin Heggelund Hansen :

> First of, I would like to say that for me personally, this proposal
> doesn't matter.
> This proposal is written because I believe people with little to no Elm
> experience will understand the construct better.
>
> The proposal, as the title of the post suggests, is to rename the
> "case..of" expression to "match..with". The reason being that I believe the
> words better matches what the construct does. As a non-native English
> speaker, case..of doesn't immediately make sense. However, match..with
> makes perfect sense.
>
> Match..with is what the same construct is called in F#, so it has that
> going for it.
>
> Case..of to match..with renaming could be handled by elm-format.
>
> As said, to me personally and, I believe, other seasoned elm devs, this
> won't matter that much.
> The question therefore becomes, how big of a difference will it make to
> new and future elm developers?
>
> --
> 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] Proposal: rename foldl til foldLeft and foldr to foldRight

[Robin Heggelund Hansen]

In Elm 0.18, primes are being removed as valid characters in a 
variable/function name. The reason being, which I whole heartedly agree 
with, that removing primes will incentivize people to write proper names, 
and also because the difference between model and model' isn't always easy 
to spot.

In the same spirit, I propose that we change the name of foldl to foldLeft, 
and the name of foldr to foldRight. The difference between foldl and foldr 
isn't to spot at a cursory glance. foldLeft is also more self-describing 
than foldl, it also matches what I say when I read foldl aloud while 
explaining code to others.

FYI: Scala has also called their functions foldLeft and foldRight.

I think this proposal would benefit both seasoned and new Elm developers.

-- 
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: Do the same with ELM?

[António Ramos]

I´m so in love with ELM,
@Erkal please submit this code to
http://blog.krawaller.se/jscomp/pages/composition.html

Thank you

2016-10-20 14:56 GMT+01:00 Erkal Selman :

> Thanks Marco, here is the corrected version:
>
> *import Html exposing (text, div, input, button, p, span)*
> *import Html.App exposing (beginnerProgram)*
> *import Html.Attributes exposing (..)*
> *import Html.Events exposing (onInput, onClick)*
>
>
> *main =*
> *beginnerProgram*
> *{ model = { state = WaitingForSubmit, inputStr = "",
> submittedValue = "" }*
> *, update = update*
> *, view = view*
> *}*
>
>
>
> *-- MODEL*
>
>
> *type alias Model =*
> *{ state : State*
> *, inputStr : String*
> *, submittedValue : String*
> *}*
>
>
> *type State*
> *= WaitingForSubmit*
> *| WaitingForConfirm*
>
>
>
> *-- UPDATE*
>
>
> *type Msg*
> *= NewContent String*
> *| Submit*
> *| Cancel*
> *| Confirm*
>
>
> *update msg model =*
> *case msg of*
> *NewContent str ->*
> *{ model | inputStr = str }*
>
> *Submit ->*
> *{ model | state = WaitingForConfirm }*
>
> *Cancel ->*
> *{ model | state = WaitingForSubmit }*
>
> *Confirm ->*
> *{ model*
> *| state = WaitingForSubmit*
> *, inputStr = ""*
> *, submittedValue = model.inputStr*
> *}*
>
>
>
> *-- VIEW*
>
>
> *view { state, inputStr, submittedValue } =*
> *div []*
> *[ input [ onInput NewContent, value inputStr ] []*
> *, case state of*
> *WaitingForSubmit ->*
> *span []*
> *[ button [ disabled (inputStr == ""), onClick Submit
> ] [ text "Submit" ] ]*
>
> *WaitingForConfirm ->*
> *span []*
> *[ button [ onClick Cancel ] [ text "Cancel" ]*
> *, button [ onClick Confirm ] [ text "Confirm" ]*
> *]*
> *, p [] [ text ("Submitted value: " ++ submittedValue) ]*
> *]*
>
> On Thursday, October 20, 2016 at 3:49:49 PM UTC+2, Marco Perone wrote:
>>
>> you could just add a `value` to your input field like
>>
>> input [ onInput NewContent, value inputStr ]
>>
>> and then reset the `inputStr` value when you confirm the submission
>>
>> Confirm ->
>> { model
>> | state = WaitingForSubmit
>> , inputStr = ""
>> , submittedValue = model.inputStr
>> }
>>
>> On Thursday, October 20, 2016 at 2:57:54 PM UTC+2, Erkal Selman wrote:
>>>
>>> You can paste the following into http://elm-lang.org/try :
>>>
>>>
>>> *import Html exposing (text, div, input, button, p, span)*
>>> *import Html.App exposing (beginnerProgram)*
>>> *import Html.Attributes exposing (..)*
>>> *import Html.Events exposing (onInput, onClick)*
>>>
>>>
>>> *main =*
>>> *beginnerProgram*
>>> *{ model = { state = WaitingForSubmit, inputStr = "",
>>> submittedValue = "" }*
>>> *, update = update*
>>> *, view = view*
>>> *}*
>>>
>>>
>>>
>>> *-- MODEL*
>>>
>>>
>>> *type alias Model =*
>>> *{ state : State*
>>> *, inputStr : String*
>>> *, submittedValue : String*
>>> *}*
>>>
>>>
>>> *type State*
>>> *= WaitingForSubmit*
>>> *| WaitingForConfirm*
>>>
>>>
>>>
>>> *-- UPDATE*
>>>
>>>
>>> *type Msg*
>>> *= NewContent String*
>>> *| Submit*
>>> *| Cancel*
>>> *| Confirm*
>>>
>>>
>>> *update msg model =*
>>> *case msg of*
>>> *NewContent str ->*
>>> *{ model | inputStr = str }*
>>>
>>> *Submit ->*
>>> *{ model | state = WaitingForConfirm }*
>>>
>>> *Cancel ->*
>>> *{ model | state = WaitingForSubmit }*
>>>
>>> *Confirm ->*
>>> *{ model*
>>> *| state = WaitingForSubmit*
>>> *, submittedValue = model.inputStr*
>>> *}*
>>>
>>>
>>>
>>> *-- VIEW*
>>>
>>>
>>> *view { state, inputStr, submittedValue } =*
>>> *div []*
>>> *[ input [ onInput NewContent ] []*
>>> *, case state of*
>>> *WaitingForSubmit ->*
>>> *span []*
>>> *[ button [ disabled (inputStr == ""), onClick
>>> Submit ]*
>>> *[ text "Submit" ]*
>>> *]*
>>>
>>> *WaitingForConfirm ->*
>>> *span []*
>>> *[ button [ onClick Cancel ] [ text "Cancel" ]*
>>> *, button [ onClick Confirm ] [ text "Confirm" ]*
>>> *]*
>>> *, p [] [ text ("Submitted value: " ++ submittedValue) ]*
>>> *]*
>>>
>>> A question: Is there a way to clear the input field (on confirm) without
>>> using ports?
>>>
>>> On Thursday, October 20, 2016 at 12:48:40 PM UTC+2, António Ramos wrote:

 http://blog.krawaller.se/posts/composition-in-cyclejs-choo-

[elm-discuss] Re: Do the same with ELM?

[Erkal Selman]

Thanks Marco, here is the corrected version:

*import Html exposing (text, div, input, button, p, span)*
*import Html.App exposing (beginnerProgram)*
*import Html.Attributes exposing (..)*
*import Html.Events exposing (onInput, onClick)*


*main =*
*beginnerProgram*
*{ model = { state = WaitingForSubmit, inputStr = "", 
submittedValue = "" }*
*, update = update*
*, view = view*
*}*



*-- MODEL*


*type alias Model =*
*{ state : State*
*, inputStr : String*
*, submittedValue : String*
*}*


*type State*
*= WaitingForSubmit*
*| WaitingForConfirm*



*-- UPDATE*


*type Msg*
*= NewContent String*
*| Submit*
*| Cancel*
*| Confirm*


*update msg model =*
*case msg of*
*NewContent str ->*
*{ model | inputStr = str }*

*Submit ->*
*{ model | state = WaitingForConfirm }*

*Cancel ->*
*{ model | state = WaitingForSubmit }*

*Confirm ->*
*{ model*
*| state = WaitingForSubmit*
*, inputStr = ""*
*, submittedValue = model.inputStr*
*}*



*-- VIEW*


*view { state, inputStr, submittedValue } =*
*div []*
*[ input [ onInput NewContent, value inputStr ] []*
*, case state of*
*WaitingForSubmit ->*
*span []*
*[ button [ disabled (inputStr == ""), onClick Submit ] 
[ text "Submit" ] ]*

*WaitingForConfirm ->*
*span []*
*[ button [ onClick Cancel ] [ text "Cancel" ]*
*, button [ onClick Confirm ] [ text "Confirm" ]*
*]*
*, p [] [ text ("Submitted value: " ++ submittedValue) ]*
*]*

On Thursday, October 20, 2016 at 3:49:49 PM UTC+2, Marco Perone wrote:
>
> you could just add a `value` to your input field like
>
> input [ onInput NewContent, value inputStr ]
>
> and then reset the `inputStr` value when you confirm the submission
>
> Confirm ->
> { model
> | state = WaitingForSubmit
> , inputStr = ""
> , submittedValue = model.inputStr
> }
>
> On Thursday, October 20, 2016 at 2:57:54 PM UTC+2, Erkal Selman wrote:
>>
>> You can paste the following into http://elm-lang.org/try :
>>
>>
>> *import Html exposing (text, div, input, button, p, span)*
>> *import Html.App exposing (beginnerProgram)*
>> *import Html.Attributes exposing (..)*
>> *import Html.Events exposing (onInput, onClick)*
>>
>>
>> *main =*
>> *beginnerProgram*
>> *{ model = { state = WaitingForSubmit, inputStr = "", 
>> submittedValue = "" }*
>> *, update = update*
>> *, view = view*
>> *}*
>>
>>
>>
>> *-- MODEL*
>>
>>
>> *type alias Model =*
>> *{ state : State*
>> *, inputStr : String*
>> *, submittedValue : String*
>> *}*
>>
>>
>> *type State*
>> *= WaitingForSubmit*
>> *| WaitingForConfirm*
>>
>>
>>
>> *-- UPDATE*
>>
>>
>> *type Msg*
>> *= NewContent String*
>> *| Submit*
>> *| Cancel*
>> *| Confirm*
>>
>>
>> *update msg model =*
>> *case msg of*
>> *NewContent str ->*
>> *{ model | inputStr = str }*
>>
>> *Submit ->*
>> *{ model | state = WaitingForConfirm }*
>>
>> *Cancel ->*
>> *{ model | state = WaitingForSubmit }*
>>
>> *Confirm ->*
>> *{ model*
>> *| state = WaitingForSubmit*
>> *, submittedValue = model.inputStr*
>> *}*
>>
>>
>>
>> *-- VIEW*
>>
>>
>> *view { state, inputStr, submittedValue } =*
>> *div []*
>> *[ input [ onInput NewContent ] []*
>> *, case state of*
>> *WaitingForSubmit ->*
>> *span []*
>> *[ button [ disabled (inputStr == ""), onClick Submit 
>> ]*
>> *[ text "Submit" ]*
>> *]*
>>
>> *WaitingForConfirm ->*
>> *span []*
>> *[ button [ onClick Cancel ] [ text "Cancel" ]*
>> *, button [ onClick Confirm ] [ text "Confirm" ]*
>> *]*
>> *, p [] [ text ("Submitted value: " ++ submittedValue) ]*
>> *]*
>>
>> A question: Is there a way to clear the input field (on confirm) without 
>> using ports?
>>
>> On Thursday, October 20, 2016 at 12:48:40 PM UTC+2, António Ramos wrote:
>>>
>>>
>>> http://blog.krawaller.se/posts/composition-in-cyclejs-choo-react-and-angular2/
>>>
>>> 2016-10-20 11:48 GMT+01:00 António Ramos :
>>>
 can anyone dare to code the same app in elm?

 http://blog.krawaller.se/posts/composition-in-cyclejs-choo-react-and-angular2/~
 i would like to see it and learn from you guys because i just "hate" 
 javascript...

 Regards
 António

>>>
>>>

-- 
You received this message because you are subscribed to 

Re: [elm-discuss] Re: Re-position element once its dimension is known

[Jacky]

You still need to do edge detection.
e.g. the dropdown is originally displayed below the button,
when the button is near the page bottom, the dropdown need to be above
instead.

On Thu, Oct 20, 2016 at 9:04 PM, Erkal Selman  wrote:

> Instead of getting the position, why not putting the dropdown menu into
> the same div with its button?
>
>
> On Thursday, October 20, 2016 at 10:08:55 AM UTC+2, Jacky See wrote:
>>
>> I'm doing some dropdown UI where I would like to re-calculate position of
>> the element once it appeared on screen.
>> Something like http://github.hubspot.com/drop/docs/welcome/
>>
>> While I can get the triggering element position on click, I'm thinking
>> how should get the offsetWidth/offsetHeight
>> of the dropdown once it is shown and feed it back to update again. Any
>> idea?
>>
> --
> 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/BS0YEAb9SaU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> elm-discuss+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Best Regards,
Jacky See

-- 
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: Do the same with ELM?

[Marco Perone]

you could just add a `value` to your input field like

input [ onInput NewContent, value inputStr ]

and then reset the `inputStr` value when you confirm the submission

Confirm ->
{ model
| state = WaitingForSubmit
, inputStr = ""
, submittedValue = model.inputStr
}

On Thursday, October 20, 2016 at 2:57:54 PM UTC+2, Erkal Selman wrote:
>
> You can paste the following into http://elm-lang.org/try :
>
>
> *import Html exposing (text, div, input, button, p, span)*
> *import Html.App exposing (beginnerProgram)*
> *import Html.Attributes exposing (..)*
> *import Html.Events exposing (onInput, onClick)*
>
>
> *main =*
> *beginnerProgram*
> *{ model = { state = WaitingForSubmit, inputStr = "", 
> submittedValue = "" }*
> *, update = update*
> *, view = view*
> *}*
>
>
>
> *-- MODEL*
>
>
> *type alias Model =*
> *{ state : State*
> *, inputStr : String*
> *, submittedValue : String*
> *}*
>
>
> *type State*
> *= WaitingForSubmit*
> *| WaitingForConfirm*
>
>
>
> *-- UPDATE*
>
>
> *type Msg*
> *= NewContent String*
> *| Submit*
> *| Cancel*
> *| Confirm*
>
>
> *update msg model =*
> *case msg of*
> *NewContent str ->*
> *{ model | inputStr = str }*
>
> *Submit ->*
> *{ model | state = WaitingForConfirm }*
>
> *Cancel ->*
> *{ model | state = WaitingForSubmit }*
>
> *Confirm ->*
> *{ model*
> *| state = WaitingForSubmit*
> *, submittedValue = model.inputStr*
> *}*
>
>
>
> *-- VIEW*
>
>
> *view { state, inputStr, submittedValue } =*
> *div []*
> *[ input [ onInput NewContent ] []*
> *, case state of*
> *WaitingForSubmit ->*
> *span []*
> *[ button [ disabled (inputStr == ""), onClick Submit 
> ]*
> *[ text "Submit" ]*
> *]*
>
> *WaitingForConfirm ->*
> *span []*
> *[ button [ onClick Cancel ] [ text "Cancel" ]*
> *, button [ onClick Confirm ] [ text "Confirm" ]*
> *]*
> *, p [] [ text ("Submitted value: " ++ submittedValue) ]*
> *]*
>
> A question: Is there a way to clear the input field (on confirm) without 
> using ports?
>
> On Thursday, October 20, 2016 at 12:48:40 PM UTC+2, António Ramos wrote:
>>
>>
>> http://blog.krawaller.se/posts/composition-in-cyclejs-choo-react-and-angular2/
>>
>> 2016-10-20 11:48 GMT+01:00 António Ramos :
>>
>>> can anyone dare to code the same app in elm?
>>>
>>> http://blog.krawaller.se/posts/composition-in-cyclejs-choo-react-and-angular2/~
>>> i would like to see it and learn from you guys because i just "hate" 
>>> javascript...
>>>
>>> Regards
>>> António
>>>
>>
>>

-- 
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: Do the same with ELM?

[António Ramos]

As a side note we need "elmbin"  to share and collect stuff like we do with
https://jsbin.com for example..

2016-10-20 13:57 GMT+01:00 Erkal Selman :

> You can paste the following into http://elm-lang.org/try :
>
>
> *import Html exposing (text, div, input, button, p, span)*
> *import Html.App exposing (beginnerProgram)*
> *import Html.Attributes exposing (..)*
> *import Html.Events exposing (onInput, onClick)*
>
>
> *main =*
> *beginnerProgram*
> *{ model = { state = WaitingForSubmit, inputStr = "",
> submittedValue = "" }*
> *, update = update*
> *, view = view*
> *}*
>
>
>
> *-- MODEL*
>
>
> *type alias Model =*
> *{ state : State*
> *, inputStr : String*
> *, submittedValue : String*
> *}*
>
>
> *type State*
> *= WaitingForSubmit*
> *| WaitingForConfirm*
>
>
>
> *-- UPDATE*
>
>
> *type Msg*
> *= NewContent String*
> *| Submit*
> *| Cancel*
> *| Confirm*
>
>
> *update msg model =*
> *case msg of*
> *NewContent str ->*
> *{ model | inputStr = str }*
>
> *Submit ->*
> *{ model | state = WaitingForConfirm }*
>
> *Cancel ->*
> *{ model | state = WaitingForSubmit }*
>
> *Confirm ->*
> *{ model*
> *| state = WaitingForSubmit*
> *, submittedValue = model.inputStr*
> *}*
>
>
>
> *-- VIEW*
>
>
> *view { state, inputStr, submittedValue } =*
> *div []*
> *[ input [ onInput NewContent ] []*
> *, case state of*
> *WaitingForSubmit ->*
> *span []*
> *[ button [ disabled (inputStr == ""), onClick Submit
> ]*
> *[ text "Submit" ]*
> *]*
>
> *WaitingForConfirm ->*
> *span []*
> *[ button [ onClick Cancel ] [ text "Cancel" ]*
> *, button [ onClick Confirm ] [ text "Confirm" ]*
> *]*
> *, p [] [ text ("Submitted value: " ++ submittedValue) ]*
> *]*
>
> A question: Is there a way to clear the input field (on confirm) without
> using ports?
>
> On Thursday, October 20, 2016 at 12:48:40 PM UTC+2, António Ramos wrote:
>>
>> http://blog.krawaller.se/posts/composition-in-cyclejs-choo-r
>> eact-and-angular2/
>>
>> 2016-10-20 11:48 GMT+01:00 António Ramos :
>>
>>> can anyone dare to code the same app in elm?
>>> http://blog.krawaller.se/posts/composition-in-cyclejs-choo-r
>>> eact-and-angular2/~
>>> i would like to see it and learn from you guys because i just "hate"
>>> javascript...
>>>
>>> Regards
>>> António
>>>
>>
>> --
> 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: Re-position element once its dimension is known

[Erkal Selman]

Instead of getting the position, why not putting the dropdown menu into the 
same div with its button?

On Thursday, October 20, 2016 at 10:08:55 AM UTC+2, Jacky See wrote:
>
> I'm doing some dropdown UI where I would like to re-calculate position of 
> the element once it appeared on screen.
> Something like http://github.hubspot.com/drop/docs/welcome/
>
> While I can get the triggering element position on click, I'm thinking how 
> should get the offsetWidth/offsetHeight
> of the dropdown once it is shown and feed it back to update again. Any 
> idea?
>

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

[elm-discuss] Re: Do the same with ELM?

[Erkal Selman]

You can paste the following into http://elm-lang.org/try :


*import Html exposing (text, div, input, button, p, span)*
*import Html.App exposing (beginnerProgram)*
*import Html.Attributes exposing (..)*
*import Html.Events exposing (onInput, onClick)*


*main =*
*beginnerProgram*
*{ model = { state = WaitingForSubmit, inputStr = "", 
submittedValue = "" }*
*, update = update*
*, view = view*
*}*



*-- MODEL*


*type alias Model =*
*{ state : State*
*, inputStr : String*
*, submittedValue : String*
*}*


*type State*
*= WaitingForSubmit*
*| WaitingForConfirm*



*-- UPDATE*


*type Msg*
*= NewContent String*
*| Submit*
*| Cancel*
*| Confirm*


*update msg model =*
*case msg of*
*NewContent str ->*
*{ model | inputStr = str }*

*Submit ->*
*{ model | state = WaitingForConfirm }*

*Cancel ->*
*{ model | state = WaitingForSubmit }*

*Confirm ->*
*{ model*
*| state = WaitingForSubmit*
*, submittedValue = model.inputStr*
*}*



*-- VIEW*


*view { state, inputStr, submittedValue } =*
*div []*
*[ input [ onInput NewContent ] []*
*, case state of*
*WaitingForSubmit ->*
*span []*
*[ button [ disabled (inputStr == ""), onClick Submit ]*
*[ text "Submit" ]*
*]*

*WaitingForConfirm ->*
*span []*
*[ button [ onClick Cancel ] [ text "Cancel" ]*
*, button [ onClick Confirm ] [ text "Confirm" ]*
*]*
*, p [] [ text ("Submitted value: " ++ submittedValue) ]*
*]*

A question: Is there a way to clear the input field (on confirm) without 
using ports?

On Thursday, October 20, 2016 at 12:48:40 PM UTC+2, António Ramos wrote:
>
>
> http://blog.krawaller.se/posts/composition-in-cyclejs-choo-react-and-angular2/
>
> 2016-10-20 11:48 GMT+01:00 António Ramos  >:
>
>> can anyone dare to code the same app in elm?
>>
>> http://blog.krawaller.se/posts/composition-in-cyclejs-choo-react-and-angular2/~
>> i would like to see it and learn from you guys because i just "hate" 
>> javascript...
>>
>> Regards
>> António
>>
>
>

-- 
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] JSComp with elm

[António Ramos]

http://blog.krawaller.se/jscomp/index.html

I see that elm has a lot more code than the others to do the same tasks.

regards

-- 
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: Do the same with ELM?

[António Ramos]

http://blog.krawaller.se/posts/composition-in-cyclejs-choo-react-and-angular2/

2016-10-20 11:48 GMT+01:00 António Ramos :

> can anyone dare to code the same app in elm?
> http://blog.krawaller.se/posts/composition-in-cyclejs-
> choo-react-and-angular2/~
> i would like to see it and learn from you guys because i just "hate"
> javascript...
>
> Regards
> António
>

-- 
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] Do the same with ELM?

[António Ramos]

can anyone dare to code the same app in elm?
http://blog.krawaller.se/posts/composition-in-cyclejs-choo-react-and-angular2/~
i would like to see it and learn from you guys because i just "hate"
javascript...

Regards
António

-- 
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: Atom Editor Race Condition (elm-format on save)

[Duane Johnson]

Thanks for the explanation and suggestion! I have `elm-format` (the atom
package) installed now.

On Thu, Oct 20, 2016 at 4:11 AM, halohalospecial 
wrote:

> Hi!
>
> After invoking the "save" command, `linter-elm-make` will execute the
> elm-make process behind the scenes (the specific event in Atom is
> `onDidSave`).  AFAIK, `atom-beautify` is also waiting for the `onDidSave`
> event.  It now depends on which of these 2 packages will handle that event
> first and which will finish first since they are both are async (using
> promises).
>
> I would suggest using https://atom.io/packages/elm-format instead.  The
> difference with `atom-beautify` is that `elm-format` (the Atom package)
> listens on `onWillSave` instead (triggered before saving) and waits for the
> elm-format process to finish (sync).  It is then guaranteed that the code
> will be formatted before linting kicks in.  If you still experience the
> same behavior, try submitting an issue to `linter-elm-make`.
>
> Cheers!
>
> --
> 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: Atom Editor Race Condition (elm-format on save)

[halohalospecial]

Hi!

After invoking the "save" command, `linter-elm-make` will execute the 
elm-make process behind the scenes (the specific event in Atom is 
`onDidSave`).  AFAIK, `atom-beautify` is also waiting for the `onDidSave` 
event.  It now depends on which of these 2 packages will handle that event 
first and which will finish first since they are both are async (using 
promises).

I would suggest using https://atom.io/packages/elm-format instead.  The 
difference with `atom-beautify` is that `elm-format` (the Atom package) 
listens on `onWillSave` instead (triggered before saving) and waits for the 
elm-format process to finish (sync).  It is then guaranteed that the code 
will be formatted before linting kicks in.  If you still experience the 
same behavior, try submitting an issue to `linter-elm-make`.

Cheers!

-- 
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: Metalinguistic abstractions over databases

['Rupert Smith' via Elm Discuss]

On Wednesday, October 19, 2016 at 8:23:46 PM UTC+1, OvermindDL1 wrote: 
>
> Absinthe handles all the nasty parts of GraphQL though, the combining of 
> queries, the real-time type documentation generation, etc... etc...
>

What database do you use? Is it always a SQL database or can Absinthe work 
with noSQL too?

Also, when it combines queries, does it translate that down into an 
efficient SQL join? Or does it process the joins outside of the database, 
in the server code? 

-- 
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: Atom Editor Race Condition (elm-format on save)

['Rupert Smith' via Elm Discuss]

On Thursday, October 20, 2016 at 9:39:44 AM UTC+1, Duane Johnson wrote:
>
> I have my Atom Editor configured with the following plugins:
> - atom-beautify
> - language-elm
> - linter
> - linter-elm-make
>
> The atom-beautify plugin is configured to "Beautify On Save". Normally, 
> after I save an elm file, they elm-format step is triggered, and the linter 
> tells me if there are any errors. I've learned to trust these awesome elm 
> compiler messages.
>
> Occasionally, after larger edits, I save my file and the linter reports a 
> spurious error. If I save a second time, the error goes away and I get the 
> green "[checkmark] No Issues".
>
> Has anyone else seen this? I'm guessing that some kind of race condition 
> exists between one or more of these packages, so that when I save, one part 
> of the checking occasionally finishes before the other. However, I'm not 
> well-versed in the details of these packages to know what might be racing.
>

I found linter-elm-make to be glitchy as hell. It reports issues that are 
not there any more, then after a lengthy update of maybe up to a minute it 
finally catches up. Its really not a usable experience at all. It is 
useful, particularly its ability to point out unused imports. I disabled it 
and only enable it occasionally when I am having a bit of a tidy up. 

-- 
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] Why aren't doc PRs merged?

['Rupert Smith' via Elm Discuss]

On Tuesday, October 18, 2016 at 11:17:41 PM UTC+1, Shump wrote:
>
> I believe there already is a "community edition"  over at 
> https://www.elm-tutorial.org/en/


Does anybody know if pull requests are being incorporated for elm-lang.org?

In particular, as a newbie I have noticed that the syntax guide does not 
document all of the syntax...

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

-- 
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] Atom Editor Race Condition (elm-format on save)

[Duane Johnson]

I have my Atom Editor configured with the following plugins:
- atom-beautify
- language-elm
- linter
- linter-elm-make

The atom-beautify plugin is configured to "Beautify On Save". Normally,
after I save an elm file, they elm-format step is triggered, and the linter
tells me if there are any errors. I've learned to trust these awesome elm
compiler messages.

Occasionally, after larger edits, I save my file and the linter reports a
spurious error. If I save a second time, the error goes away and I get the
green "[checkmark] No Issues".

Has anyone else seen this? I'm guessing that some kind of race condition
exists between one or more of these packages, so that when I save, one part
of the checking occasionally finishes before the other. However, I'm not
well-versed in the details of these packages to know what might be racing.

Thanks,
Duane Johnson

-- 
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-position element once its dimension is known

[Jacky See]

I'm doing some dropdown UI where I would like to re-calculate position of the 
element once it appeared on screen.
Something like http://github.hubspot.com/drop/docs/welcome/

While I can get the triggering element position on click, I'm thinking how 
should get the offsetWidth/offsetHeight
of the dropdown once it is shown and feed it back to update again. Any idea?

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

Re: [elm-discuss] How to model a transient state?

[Jacky See]

My current approach is to have a `readStateToBe` which contains the pending 
update state.
and 'flush update' (write `readStateToBe` to `readState`) on appropriate update 
branch (e.g. switching filter).

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