[elm-discuss] Re: elm-format did something change?

[Francesco Orsenigo]

>
> I suppose the question is, is there a consensus on which version is 
> considered to be the most 'definitive' for 0.18 code?
>

The last one.
Other than that, or what you consider "last" there is no consensus and it's 
fine.
In fact, you don't even have to use elm-format at all or feel pressured to 
update your old code.
Readability will be very similar regardless, and in the end that's what 
matters.

-- 
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] Announcement: (yet another) elm-gamepad

[Francesco Orsenigo]

http://package.elm-lang.org/packages/xarvh/elm-gamepad/latest

Gamepads cannot be implemented in pure Elm so I published a package and, in 
the docs, I tell the user "hey you need to manually add a port, you can 
find the code in the port/ directory".

I hope this is an acceptable compromise between keeping all of Elm's 
guarantees and enabling people to share unsafe code.
Regardless, I tried to keep the JS code at the absolute minimum and do all 
the real work in Elm.

Other library features:
* Recognises and supports W3C "standard gamepad" out of the box
* Allows full button remapping
* Includes function for serialising and deserialising button maps
* Includes the TEA functions and types for bare button remapping tool
* Has tests
* Keeps its implementation away from the API
* Works even on MS Edge ^_^

-- 
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: Would Enums make a good addition to Elm?

[Francesco Orsenigo]

>
> Also worth noting that (2) is already slated to be fixed directly. It's a 
> lower priority than other things in the hopper right now, but it'd probably 
> still be higher priority than adding an enum feature. 
>

This is fantastic news! 

-- 
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: State of CSS in Elm

[Francesco Orsenigo]

FWIW I am working on a major overhaul 
of https://github.com/xarvh/elm-styled-html

The core idea is that CSS should be just normal Elm code, so that any 
pattern, syntax and tool that you can use for normal Elm code, you can use 
for CSS: modularisation, common variables, generator functions, 
tree-shaking and basically any feature that will be added to the Elm 
compiler (code-splitting, lazy code loading, maybe compile-time inlining?). 
Plus, you kill a big chunk of your build pipeline.

The new version will add the styles lazily in the document header, and 
drops the class name hash in favour of just using the module name for 
namespacing to be faster and generate class names that are more readable 
and meaningful.

Also, we are using Elm with rtfeldman/elm-css in production, and we are not 
sure whether the latter is worth the effort, since it adds a lot of 
overhead to solve problems that are not really a big deal (at least for us) 
in CSS; because of this ideally I would like to support both elm-css style 
declarations, and plain strings declarations.




On Tuesday, May 31, 2016 at 7:26:37 PM UTC+10, Peter Damoc wrote:
>
> How do you handle styling in your Elm programs? 
>
> Do you use one of the following libraries?
>
> rtfeldman/elm-css
>
> seanhess/elm-style
>
> massung/elm-css
>
> Or do you do something completely different (manual style inlining, 
> classes and external css) ? 
>
> I tried using Sean's library but I quickly ran into pseudo-selectors 
> trouble wanting to implement a simple hover effect. 
>
> Somehow, keeping a set of hover states for some simple nav-link seams such 
> an overkill. 
>
> How do you handle such scenarios? 
>
>
>
> -- 
> 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: Where for local functions

[Francesco Orsenigo]

Hi Igor,

my understanding is that `where` has not been implemented and will not be 
implemented to 1) keep the syntax lean and 2) ensure a consistent coding 
style.
I don't think Elm should have a `where` clause.
Coming from Haskell and physics, I instinctively liked the `where` syntax 
better, but as soon as I got some experience with Elm, using let..in became 
natural.
More in general, in my experience this kind of aesthetic preference comes 
largely from habit.




On Sunday, June 18, 2017 at 8:00:42 PM UTC+10, Igor Bukanov wrote:
>
> Hello,
>
> past discussions about adding the where clause to Elm typically suggested 
> to use it as syntax sugar for the let. 
>
> As far understand, this is how things are done in Haskell. Moreover, using 
> the where is very natural there as syntax order follows the lazy evaluation 
> strategy making it easier to reason about things.
>
> This does not work for Elm as the language is strict. Yet strictness is 
> only relevant for expressions, not function definitions. So perhaps 
> restricting the where only for local function definitions similarly to 
> Idris (strict language) may work for Elm?
>
> Compare:
>
> let triple x = x * x * x
> in
> List.map triple listOfInts
>
> versus
>
> List.map triple listOfInts
> where
> triple x = x * x * x
>
> For me the let version looks uglier as the syntax order is reverse of the 
> evaluation.
>
> For this reason I have noticed that I do not like to move complex lambdas 
> into local functions. Rather I wait until they become even more complex. 
> Then I make them top-level functions defined *after* the function that uses 
> them.
> 
> 
>
>

-- 
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: Adding CSS produced by a view function to the document's

[Francesco Orsenigo]

The idea is to keep a set of all the rules added to the header, add only 
those that are missing and never remove any.
This will not work for for rules whose definitions are changed dynamically, 
but seems like an acceptable trade off.

The ability to calculate all the styles that *might* appear would have the 
same limitation.


On Friday, June 9, 2017 at 2:41:32 PM UTC+10, Aaron VonderHaar wrote:
>
> I experimented with some ways to have view functions that return both Html 
> and the necessary styles.  I found I could make it work, but I ultimately 
> abandoned the idea because of a fundamental problem:
>
> view model =
> if model.showWidget then
> Widget.view model.widgetData
> else
> text ""
>
> In the code above, depending on the model, you may or may not call 
> Widget.view.  If your view functions are some new type that includes the 
> necessary styles, then you now have a problem that you will only know about 
> the styles for views that are currently visible, which means that your 
> final stylesheet will constantly be changing as the model changes.
>
> What we really want is to get all the styles for all Html that *might* 
> appear, not for all Html that currently appears.  I suspect an API could be 
> designed that would allow such Html+styles views to be composed in a way 
> that could provide *all*possible*styles*, but I expect it would probably be 
> a significant departure from how Html-only views work, so I haven't pursued 
> that idea further.
>
> At NoRedInk, we have an idea for a way to look at an entry point Elm file 
> and traverse all of the imported modules, collect all of the top-level 
> Stylesheets (similar to what the latest elm-test does for Test 
> definitions), and compile a .css file that we can reference in the  
> (but this would be done outside of Elm).  However, that idea is also 
> currently in a state of haven't-yet-pursued-further.
>
> On Thu, Jun 8, 2017 at 4:38 AM, Kevin Yank  > wrote:
>
>> The style-elements 
>>  
>> package introduced at Elm Europe today needs to solve this problem too. For 
>> now, it too is just rendering an invalid 

Re: [elm-discuss] Adding CSS produced by a view function to the document's

[Francesco Orsenigo]

Coupling view and style is not the problem, it's the *goal*.

Right now, you can't declare CSS in the place where you use it: you need to 
create a separate stylesheet with references, use those references in your 
view and then put the stylesheet somewhere.
This is not how we write all the rest of our code.
Imagine if every time you declare a function, you also had to put manually 
that function in a "list of all functions" and then add a step in your 
build pipeline to insert that list in your bundle just so that you can 
execute it.
This is what we currently do with CSS, and results in many of the problems 
that we have with it.


In private, Peter Damoc kindly suggested that my best shot would be the 
view-stored-inside-the-model approach.
Absent any better suggestion, I will pursue that.


On Tuesday, June 6, 2017 at 4:47:44 PM UTC+10, Peter Damoc wrote:
>
> It seams that you have driven yourself into a corner because of a series 
> of choices that you made with your code architecture. 
>
> The best way forward is to refactor you code so that you decouple the 
> style from the view. 
> You should be able to get both of them from the model independently. 
>
> Once you've done that, you will just need to call the style function with 
> the new model in `update` and push the output through the port. 
> On the other side of the port you might want to experiment with a check 
> against a saved value as to not trigger needless parsing of the mounted 
> CSS. 
>
>
>
>
>
> On Mon, Jun 5, 2017 at 1:46 PM, Francesco Orsenigo <francesco...@gmail.com 
> > wrote:
>
>> I am experimenting with view functions that produce both html content and 
>> the style that should be applied to that markup, as in
>>
>> myView : Model -> ( Html msg, List CssRule )
>>
>> So far, I have been rendering the above by creating a 

[elm-discuss] Adding CSS produced by a view function to the document's

[Francesco Orsenigo]

I am experimenting with view functions that produce both html content and 
the style that should be applied to that markup, as in

myView : Model -> ( Html msg, List CssRule )

So far, I have been rendering the above by creating a 

[elm-discuss] Re: Best practices to create examples for an elm package?

[Francesco Orsenigo]

A personal pain point of mine is when the examples just import TheModule 
exposing (..) rather than just using fully qualified references 
TheModule.aFunction .

First of all, because that's not how the library will be used.

Second, and more important, unless you know already what the library 
exports, for every symbol you encounter you need to go through the whole 
example code to check whether it was declared in the example or it comes 
from the library: if you CANNOT find it in the example, then it means it 
comes from the library.
The situation is even worse if the library exports more than a module and 
all are imported with (..).

I think this unnecessarily increases the time and cognitive load required 
to understand a library (which is often times already a demanding task).



On Monday, May 8, 2017 at 1:58:26 PM UTC+10, Matthieu Pizenberg wrote:
>
> Exploring a bit the packages repository, I've come accross the following 
> options:
>
> 1. no examples/ dir, all in readme and documentation. 
> (elm-array-exploration, ...)
> 2. examples/ dir with nothing more than `.elm` files (elm-decode-pipeline, 
> elm-monocle, ...)
> 3. examples/ dir with an `elm-package.json` file (elm-transducers, ...)
> 4. examples/ dir with a `package.json` node builder (elm-kinto, ...)
>
> I personally have a mix of (2) and (3). However I feel like they all have 
> issues.
>
> 1. Sometimes, having a "ready to build" example is useful.
> 2. It relies on building from the root directory of the package (where the 
> `elm-package.json` file lives). It also means that the example file can 
> "cheat" by accessing non exposed modules.
> 3. If you add your `src/` dir in the json, then you can also "cheat" like 
> in 2. If you do not, and you use your package as if it was loaded from elm 
> packages, then you cannot verify that your latest modifications (not pushed 
> yet) are working with your examples.
> 4. Well, it's a bit too heavy of a machinery most of the times. Plus it 
> also requires an `elm-package.json` file anyway so the same issues as (2) 
> and (3) apply.
>
> *Do you think there is a best practice? Are there alternatives to those 
> four?*
>

-- 
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: Best practices to create examples for an elm package?

[Francesco Orsenigo]

> I have my examples/elm-package.json include ../src, and have my CI script 
> build all the examples so that I remember to update the examples of the API 
> changes.
>
> Also, imo it's good to have a separate examples/elm-package.json because 
> you often want other dependencies to make a realistic example.
>

Agreed 100% with Aaron.
 

-- 
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 Textfield + a barcode scanner

[Francesco Orsenigo]

Witold, could you put together a minimal Elm app + Selenium script that
reproduces the problem?
This might be a significant issue, since it would impact the possibility to
end-to-end test Elm apps.

On Sun, Apr 30, 2017 at 8:28 AM, Witold Szczerba <witoldsz@gmail.com>
wrote:

> This was my case with Selenium WebDriver and Chrome. The end-to-end tests
> of my Elm application are failing because of this.
> It was reported back in 2014: https://github.com/elm-
> lang/elm-compiler/issues/835
> The issue is closed, but the bug is still present.
>
> You want to know my workaround? It "just-works" on Firefox, so this is the
> browser I use for e2e tests…
>
> On Sat, Apr 29, 2017 at 11:57 PM, Francesco Orsenigo <
> francesco.orsen...@gmail.com> wrote:
>
>> This is an interesting problem and I wonder if it would happen also with
>> some other form of automated input (say, selenium).
>>
>> It might very well be a problem with Elm.
>>
>>
>>
>> On Saturday, April 29, 2017 at 12:51:48 AM UTC+10, Chris Van Vranken
>> wrote:
>>>
>>> I'm using a barcode scanner to enter data into an elm textfield.  The
>>> barcode scanner basically works like a keyboard with a user that makes very
>>> rapid keystrokes.  This rapid entry causes random characters to be missing
>>> in the textfield.  If the scan is supposed to enter "50494'', one or more
>>> of these characters will often be missing.  Using the debugger I see that
>>> my model has values for that field that change from "5" to "50" to "504" to
>>> "509" to "5094", but it should be "5" to "50" to "504" to "5049" to
>>> "50494"  So it ends up replacing "504" with "509" instead of with "5049".
>>> I believe this is a threading issue where two events are firing in parallel
>>> instead of in sequence, and both events are starting with the same model
>>> data ("50") with the output of one event replacing the output of the other,
>>> when instead the output model for one event should be the input for the
>>> next event.  Is this a bug in Elm?  How do I fix this?
>>>
>>> Thanks,
>>> Chris
>>>
>> --
>> 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/Oy35n_BHUGM/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.
>

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

[elm-discuss] Re: Elm Textfield + a barcode scanner

[Francesco Orsenigo]

This is an interesting problem and I wonder if it would happen also with 
some other form of automated input (say, selenium).

It might very well be a problem with Elm.



On Saturday, April 29, 2017 at 12:51:48 AM UTC+10, Chris Van Vranken wrote:
>
> I'm using a barcode scanner to enter data into an elm textfield.  The 
> barcode scanner basically works like a keyboard with a user that makes very 
> rapid keystrokes.  This rapid entry causes random characters to be missing 
> in the textfield.  If the scan is supposed to enter "50494'', one or more 
> of these characters will often be missing.  Using the debugger I see that 
> my model has values for that field that change from "5" to "50" to "504" to 
> "509" to "5094", but it should be "5" to "50" to "504" to "5049" to 
> "50494"  So it ends up replacing "504" with "509" instead of with "5049". 
>  I believe this is a threading issue where two events are firing in 
> parallel instead of in sequence, and both events are starting with the same 
> model data ("50") with the output of one event replacing the output of the 
> other, when instead the output model for one event should be the input for 
> the next event.  Is this a bug in Elm?  How do I fix this?
>
> Thanks,
> Chris
>

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

[Francesco Orsenigo]

Eirik, I think it's a bit unfair to call it "One Correct Way™".
The idea is "One Really Good Way that is Reasonably Future-Proof™".
Maybe this hasn't been communicated effectively.

Also, in production we keep getting run-time errors with third-party
libraries that use React, so my experience disagrees with your assessment
about the npm ecosystem.
We use Elm in production, these errors do not happen and that is of massive
value for us.


It's not that there's one way of doing it, but that once a bad way of doing
> it is widespread


^ This.
Do things once and do them well.

This said, I agree with Mark regarding the presence of too many bugs and
the necessity of a roadmap.



On Thu, Apr 27, 2017 at 5:57 AM, Eirik Sletteberg  wrote:

> I used the persistent-cache code once. I just copied the source code into
> my project. The library readme makes some bold statements, like "it is the
> right technical choice" to expose a LRU cache for localStorage in Elm. It
> certainly wasn't the right choice for my use case, where "least recently
> used" wasn't a relevant factor regarding which elements to retain in
> localStorage; there were a few very important keys, and a couple of "less
> important" keys. The Task-based LocalStorage API that is included in
> persistent-cache works very well. It works very well because it mirrors the
> native API. As a developer, I also prefer the freedom to make my own
> technical choices that are right given the circumstances. I need the power
> of the Web API, I just want it with types and without runtime exceptions.
>
> There is an underlying premise of Elm that there is One Correct Way™ to
> solve a problem in an application written in Elm, it takes "a long time" to
> discover the One Correct Way™, and Evan is the only person capable of
> doing it. (An exaggeration of course) As far as web APIs are concerned,
> there is only one Correct Way™ we all have to deal with, which is W3C
> standards, as they are implemented in the browsers. Maybe it's possible to
> take WebIDL definitions and convert them to Elm bindings, then one would
> have a type-safe, exception-free interface to the browsers, without all the
> maintenance overhead.
>
> BDFL for both a language and its ecosystem is perfectly fine for a project
> philosophy, but it is intrinsically linked to having a small niche
> community. Then again, broad adoption may not be a significant priority for
> Elm during the next few years, so that might be a good thing. In the case
> of commercial software development, cash is king, and delivering working
> features is the top priority. Nobody cares that your car is shiny and
> polished, if it cannot drive in reverse. The article Choose Boring
> Technology  comes to mind.
>
> Bottom line, there is a huge untapped potential here, people are excited
> about Elm, want to use it in production, but then there are small things
> like missing support for localStorage, file uploads, audio playback, binary
> data, being able to control event.preventDefault(). Many of those are
> problems that people would fix themselves and publish as a package. All it
> takes is to trust the broader community. Even if you end up with 5
> different libraries dealing with cookies, one of them will probably
> prevail, and all 5 of them will learn from each other's advantages and
> drawbacks. I don't buy the argument that opening up the ecosystem will ruin
> Elm's guarantees - I would trust the robustness of a third party cookie
> package with 5000 GitHub stars and 100 merged pull requests just as much as
> (or more than) I trust the Elm core. Just look at what npm did for the
> JavaScript community. Look at the success of React and Redux, which are
> more or less based on TEA. But they have excellent JS interop and an open
> ecosystem. Wouldn't it be great if Elm were just as widespread? And had
> just as many contributors?
>
>
> onsdag 26. april 2017 19.28.59 UTC+2 skrev Wojtek Piekutowski følgende:
>>
>> The thing is that this exact kind of cache (LRU) might not work for all
>> people, so it'd be great to have barebones interface to
>> localStorage/sessionStorage/etc. Then higher level abstractions, like
>> persistent-cache, could be easily built on top of it.
>>
>> On Wed, 26 Apr 2017 at 18:24, Mark Hamburg  wrote:
>>
>>> Exactly and look at the months old comment at the top of the read me:
>>>
>>> NOT RELEASED YET — I hope to release it relatively soon, but I cannot
>>> make any promises. Until then, please use ports if you want to use
>>> localStorage.
>>>
>>>
>>> On Wed, Apr 26, 2017 at 9:22 AM Rex van der Spuy 
>>> wrote:
>>>
 On Wednesday, April 26, 2017 at 5:07:39 AM UTC-4, Wojtek Piekutowski
 wrote:
>
>
>  https://github.com/elm-lang/persistent-cache?
>

  Wow, that's exactly what I need!








 --


 You 

[elm-discuss] Re: Moving on

[Francesco Orsenigo]

I have felt very much as Duane describes, powerless and at the mercy of the 
whims of a few unreachable No Red Ink devs.
I could not contribute my elm-audio library and found myself frustrated by 
the lack of progress along many fronts.
However, I have since come to reconsider this.

The point is, the elm devs are taking a very conservative, very careful 
approach: do things once and do them right.

I've come to really appreciate this, even if it clashes with my instinct of 
wanting all and wanting it now.
I do wish there were more people working on bugs tho.



On Monday, April 24, 2017 at 11:45:57 PM UTC+10, Duane Johnson wrote:
>
> Hi all,
>
> I've decided to move on from Elm. I've only been successful in 1 of 3 
> projects. I'm now in a role where I need to make an important decision 
> regarding the transition of a codebase from Angular to something else, and 
> I don't feel like I can responsibly recommend Elm as the replacement. So I 
> need to focus my time and effort elsewhere.
>
> If someone could please remove me as a moderator of elm-discuss it would 
> be appreciated.
>
> If anyone is interested in taking the `canadaduane/typed-svg` project 
> over, I'd be happy to help transition it to willing hands.
>
> Thanks,
> Duane Johnson
> aka canadaduane
>
>

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

[Francesco Orsenigo]

Yes I did.
It does not support keyboard.
As I wrote, "implementing keyboard support requires side effects and state".

On Mon, Apr 24, 2017 at 3:50 AM, Lourens Rolograaf <rologr...@gmail.com> wrote:
> Hi Fransesco, did you read this?
> https://medium.com/elm-shorts/a-reusable-dropdown-in-elm-part-1-d7ac2d106f13
> part 2
> https://medium.com/elm-shorts/a-reusable-dropdown-in-elm-part-2-9659ef988441
>
>
> Op donderdag 20 april 2017 23:45:07 UTC+2 schreef Francesco Orsenigo:
>>
>>
>> I would add a dropdown.
>> Even a simple dropdown poses some interesting challenges to the
>> architecture:
>> - Dropdowns are ubiquitous in web apps.
>> - Dropdowns interact: when opening one, any other dropdown must close.
>> - Implementing keyboard support requires side effects and state.
>> - Dropdowns can have many different options; it can be disabled, it can
>> have a button to clear its selection, it can require a selected value or the
>> selected value can be a Maybe.
>> - Dropdowns requires styling: how do you distribute style with an Elm
>> package? More importantly, how do you organize it within the app?
>>
>>
>> We might want to also consider a numerical input element.
>> - How do I ensure that the input element always produces a number while,
>> at the same time, allowing the user to use Backspace to delete the last
>> cipher in the input?
>> There are going to be different ways of doing this, it would be very good
>> to be able to compare examples.
>>
>>
>>
>>
>>
>> On Wednesday, April 19, 2017 at 7:11:05 PM UTC+10, Peter Damoc wrote:
>>>
>>> Hello community,
>>>
>>> Scaling Elm apps seams to be a recurring topic.
>>>
>>> I was wondering if maybe we could negotiate a minimal set of
>>> functionality, something similar to ToDoMVC, that could be implemented using
>>> different approaches to explore what could be the best way to structure the
>>> code.
>>>
>>> What should this minimal example cover and what this minimal example
>>> should be (topic)?
>>>
>>> I'll start the list with some bits of functionality that I would like:
>>>
>>> - multiple pages with common structure (sidebar/navbar)
>>> - navigation without reloading the app (SPA routing without the hash)
>>> - authentication
>>> - complex widget reuse (a module/widget that generates side-effects; e.g.
>>> a weather widget, some stock ticker, an ad provided by a third party)
>>> - styling (CSS)
>>>
>>> I would also like the example to cover real world concerns of:
>>> - using a build manager to integrate with other technologies
>>> - development mode - deployment build
>>> - testing
>>>
>>> As for topic, I was thinking about an interface to the MusicBrainz
>>> Database (a simplified interface).
>>>
>>> What do you think?
>>> What bits of functionality would you like to see exemplified?
>>> Are you aware of any other project (in other languages) that exemplifies
>>> a minimal set of functionality and could be used as a template?
>>>
>>>
>>> --
>>> There is NO FATE, we are the creators.
>>> blog: http://damoc.ro/
>
> --
> 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/WDDrFq-uP58/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.

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

[Francesco Orsenigo]

I would add a dropdown.
Even a simple dropdown poses some interesting challenges to the 
architecture:
- Dropdowns are ubiquitous in web apps.
- Dropdowns interact: when opening one, any other dropdown must close.
- Implementing keyboard support requires side effects and state.
- Dropdowns can have many different options; it can be disabled, it can 
have a button to clear its selection, it can require a selected value or 
the selected value can be a Maybe.
- Dropdowns requires styling: how do you distribute style with an Elm 
package? More importantly, how do you organize it within the app?


We might want to also consider a numerical input element.
- How do I ensure that the input element always produces a number while, at 
the same time, allowing the user to use Backspace to delete the last cipher 
in the input?
There are going to be different ways of doing this, it would be very good 
to be able to compare examples.





On Wednesday, April 19, 2017 at 7:11:05 PM UTC+10, Peter Damoc wrote:
>
> Hello community, 
>
> Scaling Elm apps seams to be a recurring topic. 
>
> I was wondering if maybe we could negotiate a minimal set of 
> functionality, something similar to ToDoMVC, that could be implemented 
> using different approaches to explore what could be the best way to 
> structure the code. 
>
> What should this minimal example cover and what this minimal example 
> should be (topic)?
>
> I'll start the list with some bits of functionality that I would like: 
>
> - multiple pages with common structure (sidebar/navbar)
> - navigation without reloading the app (SPA routing without the hash) 
> - authentication 
> - complex widget reuse (a module/widget that generates side-effects; e.g. 
> a weather widget, some stock ticker, an ad provided by a third party)
> - styling (CSS)
>
> I would also like the example to cover real world concerns of: 
> - using a build manager to integrate with other technologies 
> - development mode - deployment build
> - testing 
>
> As for topic, I was thinking about an interface to the MusicBrainz 
> Database (a simplified interface).
>
> What do you think? 
> What bits of functionality would you like to see exemplified? 
> Are you aware of any other project (in other languages) that exemplifies a 
> minimal set of functionality and could be used as a template?  
>
>
> -- 
> 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: Post Examples of Painful Record Updates Here!

[Francesco Orsenigo]

@Martin Bailey

if I found myself with 50 messages in the model update I'd take as a sign 
that I need to abstract things more.

Regarding the update of nested attributes, I agree that there is not a good 
way to do it, hence this thread. =)



@Michael Jones

Maybe something like this could work for you:

case lol of
Submit locationList ->
let
results =
validateEditLocationListForm model.locationListData

( newLocationListData, cmd ) =
if List.length results > 0 then
( { locationListData | errors = Just results }, 
Cmd.none 
)
else
( { model | locationListData = data }, 
postUpdateLocationList locationListData locationList )
in
( { model | locationListData = newLocationListData }, cmd )




-- 
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: Post Examples of Painful Record Updates Here!

[Francesco Orsenigo]

Hi Martin, I wonder if for your case a different way to organise your code 
would be viable:

-- Family.elm
updateFamily msg family =
  case msg of
ChangeName newName -> ( { family | name = newName }, Cmd.none )
Save -> ( model, saveFamily family )


selectedView family =
UI.form
[ UI.class "fluid"
, UI.onSubmit <| SaveFamily model.family
]
[ UI.input
[ UI.label "Name"
, UI.value model.family.name
, UI.onInput ChangeName
]
]


-- Update.elm
update msg model =
  case msg of
FamilyMsg familyMsg ->
  let
(newFamily, familyCmd) = Family.update familyMsg model.family
  in
( { model | family = newFamily }, Cmd.map FamilyMsg familyCmd )



This is how we organise the code in production and it scales really well; 
it also has the advantage of removing as much logic as possible from the 
view and keeping it in the update.
The last block's boilerplate can be further reduced using an helper like 
`mapBoth` 
from http://package.elm-lang.org/packages/Fresheyeball/elm-return/latest 
(or implementing it yourself, it's a couple of lines).






On Monday, March 6, 2017 at 5:56:42 AM UTC+11, Martin Bailey wrote:
>
> Here are some real world examples of record updates that could be 
> streamlined at the language level, including attempts to simplify UI code 
> defining record updates.
>
> -- Update.elm
> update : Msg -> Model -> ( Model, Cmd Msg )
> update msg model =
> case msg of
> Update updater ->
> ( updater model, Cmd.none )
> SaveFamily family ->
> ( model, Cmd.saveFamily family )
> _ ->
> ( model, Cmd.none )
>
> -- View.elm
> selected_family : Model -> UI.Node Msg
> selected_family model =
> UI.form
> [ UI.class "fluid"
> , UI.onSubmit <| SaveFamily model.family
> ]
> [ UI.input
> [ UI.label "Name"
> , UI.value model.family.name
> , UI.onInput <| \val -> Update <| familyUpdater (\family -> { 
> family | name = val })
> ]
> ]
>
> familyUpdater : (Family -> Family) -> Model -> Model
> familyUpdater updater model =
> { model | family = updater model.family }
>
> -- familyUpdater looks simple enough, but at production scale with 
> multiple embedded records, a few of these functions must be chained 
> together to complete what could be a simple update such as 
> model.family.contact.address.street = "Main Street"
> -- Multiple specific Msg types such as UpdateFamily can be created to 
> "clean" the view, but then it becomes really hard to achieve separation of 
> concern as the Update function grows with out-of-context logic. Those 
> updater functions are then moved to the Update file or you have to use many 
> layers of let bindings. There are two concerns here, the update behavior 
> being defined in the context of the form or becoming overly complex due to 
> embedded records. The latter is more important.
> -- Here's an example from another real world app :
>
> RcvGeocode geocode ->
> let
> address =
> extractAddress geocode
>
> updated =
> address |> updateAddress |> updateContact |> updateProfile 
> |> updateUser model
> in
> ( { updated | geocode = geocode }, Cmd.none )
>
> -- This would look much nicer in my opinion :
>
> RcvGeocode geocode ->
> ( { model | user.profile.contact.address = extractAddress geocode 
> }, Cmd.none )
>

-- 
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] Record syntax overhaul

[Francesco Orsenigo]

I'm posting this here rather than in elm-dev because the discussion might 
get both long and broad.
Also, as much as I would like to help out, I understand that only Evan 
changes the compiler.

The matter has been discussed already, and it might be useful to get an 
idea of the prior thoughts:

This is a previous discussion that evaluated a few different proposals:
https://github.com/elm-lang/elm-compiler/issues/984

This is a very useful summary of the ideas considered:
https://gist.github.com/rtfeldman/f4b04468f3d865c4135153fea29d23f7

What follow is my personal experience; the TL;DR version is "Any proposed 
overhaul of record syntax should consider not only instance manipulation, 
but also record type manipulation".

---

The issues I personally encountered are:

1)
There is a common pattern where a library (ex, elm-markdown) will provide a 
default config, to be extended by the user.

import Slides

myCustomSlidesConfig =
 { Slides.defaultConfig | someAttribute = myCustomvalue }

The above does not work because the left side of the { record | attribute = 
value, ...} syntax does not accept expressions.
The current workarounds are either:

import Slides

slidesDefaultConfig =
  Slides.defaultConfig

myCustomSlidesConfig =
 { slidesDefaultConfig | someAttribute = myCustomvalue }

or

import Slides exposing (slidesDefaultConfig)

myCustomSlidesConfig =
 { slidesDefaultConfig | someAttribute = myCustomvalue }

Not a big deal TBH, but annoying.

2) 
Record type manipulation is limited.
It is normal for the front end to get some record from the database, 
display it, edit it or create a new one and push it back to the db.
The record types necessary for these operations are very similar but need 
to have very specific differences.
When the record comes from the db and is displayed, it has usually several 
definite values.
However when editing it, many (but not necessarily all) of those values 
could be "Maybe x" rather than "x".
If I am creating a new record in the front end, chances are that it will 
not have an "id" field.

However, the options that I have to define a record as function of another 
are very limited.
I can't remove fields but only add them, and even that is very limited.

In my current project, I need to edit a "Rule" record.
The app has already a "Rule" type, which *must* have an "id", because 
that's how the data arrives from the DB and is displayed to the user.
However, the form to edit a Rule will need a different type, because 
depending on whether I am creating a new rule or editing an existing one, 
it may or may not have an "id".
I have to duplicate every attribute of the "Rule" type but "id : String" 
into a "RuleContent" type.

3)
Then, unless I want to get crazy with updating nested record properties, I 
need to extend my form Model with RuleContent.
This is the best workaround I have found so far:

type alias RuleContentAnd a =
  {a |
attributes...
  }

type alias RuleContent = RuleContentAnd {}




type alias Model =
  RuleContentAnd
{ someUiAttributes
,  ...
}

This works, but currently it removes the ability to use "ResultContent" as 
a constructor (which is very useful when writing decoders).
If manipulating nested records was easier, this would be less of a problem 
because then the Model could just contain a "ruleContent : RuleContent" 
attribute.
As Elm is right now, nested records require me to write an updater helper 
"updateRuleContentAttributeX : TypeOfX -> Model -> Model" for every 
attribute in "RuleContent", leading to even more duplication.


I might be wrong, but I think that points 2) and 3) describe use cases 
(Display / Edit / Create something from/on a DB) that are probably the most 
common in web applications.
If this is the case, it might be worth to consider not only how to better 
manipulate record instances, but also record types.

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

[elm-discuss] Re: elm-repl cannot find module Tuple

[Francesco Orsenigo]

Delete elm-stuff/ and reinstall all packages.
I assume you are upgrading from 0.17.


On Thursday, November 17, 2016 at 1:24:50 PM UTC+11, David Legard wrote:
>
> Started an elm-repl session and the message came up 
>
> I cannot find the module Tuple. 
>
>
> Module 'Repl' is trying to import it.
>
>
> Any ideas?
>

-- 
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: Why Range syntax got removed in favor of List.range

[Francesco Orsenigo]

Yup.
It is just not used often enough to warrant special syntax.

On Tue, Nov 15, 2016 at 10:09 AM, Witold Szczerba
 wrote:
> I think List.range is just fine. No need for special syntax and strange
> function names like ".." (hard to browse, find online, etc.).
>
> On Mon, Nov 14, 2016 at 10:29 PM, أحمد حبنكة 
> wrote:
>>
>> What do you think about my suggestion in previous reply ? replacing
>> List.range with List.(..) operator ?
>>
>>
>> بتاريخ الاثنين، 14 نوفمبر، 2016 2:43:49 ص UTC+2، كتب Max Goldstein:
>>>
>>> Sometimes it's useful to pass arguments to List.range and have it be
>>> empty when a > b.
>>>
>>> Perhaps there should be List.rangeWithStep 5 1 -1 to solve your problem.
>>
>> --
>> 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/z8t8u2f3iWk/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.

-- 
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 Range syntax got removed in favor of List.range

[Francesco Orsenigo]

Why would you want two different (and entirely equivalent) solutions to the 
same problem?


On Monday, November 14, 2016 at 8:37:34 AM UTC+11, Andrew Radford wrote:
>
> Yeah It would be great if there was [x..y] and Range
>
>>
>>>

-- 
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 do you test a TEA `update` function?

[Francesco Orsenigo]

Fair enough!

On Thu, Nov 10, 2016 at 3:23 AM, Mark Hamburg <mhamburg...@gmail.com> wrote:
> We didn't do it to enable testing. We did it because it also regularizes a
> lot of other module interactions. Improving testing is a bonus.
>
> Mark
>
> On Nov 8, 2016, at 1:31 PM, Francesco Orsenigo
> <francesco.orsen...@gmail.com> wrote:
>
>
> Ok, but is it justified to make your code more complicated just to enable
> testing?
>
> --
> 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/IYp-bI93AnY/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.

-- 
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 do you test a TEA `update` function?

[Francesco Orsenigo]

Ok, but is it justified to make your code more complicated just to enable 
testing?

-- 
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: Convincing my team that Elm isn't just going to die like CoffeeScript

[Francesco Orsenigo]

On Tuesday, November 8, 2016 at 2:45:26 AM UTC+11, Ian Dickinson wrote:
>
>
>> With respect, I'm not sure that the essence of JS fatigue is new features 
> of the language itself, although I suppose ES5 to ES2015 is quite a big 
> change. As I hear it, it's rather the explosion of build tools, library 
> managers, static analysers, code architectures, front-end frameworks and 
> Alt-JS syntaxes that compile to JS. Too many choices, that keep changing 
> too fast! If you're convinced by Elm, then sure, it's the answer to a lot 
> of those choices. But if you're still at the point of making that choice, 
> Elm just adds one more set of options to most of those categories, and - 
> from one perspective - adds to JS fatigue.
>

I think JS Fatigue is not much a matter of "too many options" but rather a 
problem of "wiring all that stuff up", and having to rewire everything 
again the next time you want to change one of the basic libraries.
I really liked coding in Elm even when I was struggling with the language 
itself, because I didn't have to think about all of that wiring stuff.

It felt a much closer experience to coding in, say, python or even node, 
which have definitely too many libraries with overlapping scopes, but do 
not suffer (too badly) of a "wiring things together" problem.

-- 
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] How do you test a TEA `update` function?

[Francesco Orsenigo]

How do you write unit tests to ensure that an `update : Msg -> Model -> ( 
Model, Cmd Msg )` function is producing the correct commands?
What if the function is supposed to produce several commands batched 
together?

Same thing for a `view : Model -> Html Msg`.
Suppose I want to test whether, given a particular model, it will display 
the correct number of list items.
Do people write tests for this?
Right now the only way to write this kind of tests I can think of is 
creating the whole html tree as I expect it to be rendered, and comparing 
it via == with the function output.

-- 
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: Convincing my team that Elm isn't just going to die like CoffeeScript

[Francesco Orsenigo]

CoffeeScript and Elm address two vastly different problems.

CoffeeScript addressed "Writing JS is a pain in the ass": it was syntactic 
sugar and the need for it drastically lessened with ES6.
CS was killed by the new JS extensions.

Elm addresses run time errors and JS Fatigue, neither of which JS can 
address organically. In fact, the more JS evolves, the more its syntax is 
extended, the worse JS Fatigue becomes.

IMHO, Elm will fade only when there will be another language that 
simplifies the whole build pipeline and is more appealing to newbies.

At the last Melbourne Meetup we had twice as many RSVPs as the Clojure 
meetup and three times as many as the Haskell one.

>

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

[Francesco Orsenigo]

Primes can be confusing even when doing pure maths (I studied physics), 
it's just so easy to miss them, so good riddance.

When it comes to model names, I always try to 1) pipe my functions so that 
I need the least intermediate variable names and 2) use descriptive names 
no matter what; for example, after I applied the tick function, i get a 
`tickedModel`. If I need more than one or two intermediates, I rework 
things so I can pipe.

(Also, if I use `newModel` I never use `model` but rather `oldModel` to 
kill *any* possibility for ambiguity)


On Thursday, October 20, 2016 at 7:56:11 AM UTC+11, mbr wrote:
>
> Naming sometimes can be hard.
>
> While I agree that model03 or model''' is a code smell.
> But often you are just transforming some data and the intermediate 
> variables names are meaningless (besides reminding us that they are related)
> I've seen things like newModel being used everywhere and then later a 
> newestModel 
> shows up.
>
>
> I do also agree that triple primes is a sign that your function should be 
> split. 
> On the other hand, 3 lines functions everywhere adds too much indirection 
> and, IMO, are code smell as well.
>
> Another things about primes, is that its used in calculus all the time as 
> well and I feel nostalgic about it. Silly right?
>
> What I really wish, is that things like type_ is used instead of type' 
> but the ability for us to use primes on out variables name not be removed 
> from the language.
>
>
>
>
>
>
> On Wednesday, October 19, 2016 at 3:06:58 AM UTC-4, Peter Damoc wrote:
>>
>> Elm optimizes for learning and in doing so, encourages people to write 
>> clear code. 
>>
>> I too had a brief love affair with primes after watching Leslie Lamport 
>> videos about TLA+ and discovering that they are allowed in Elm. 
>>
>> I was encouraged to move away from them and favor a more explicit name 
>>  like newModel. I did it and never looked back. 
>>
>> I found that if I needed more than one prime, it was a very good sign 
>> that I might need to use functions. 
>> Instead of naming my intermediary values something silly and useless like 
>> model03, I named the process something meaningful and then chained the 
>> processes with |> 
>>
>>
>>
>> On Wed, Oct 19, 2016 at 4:28 AM, mbr  wrote:
>>
>>> just learned that primes and backticks won't be on elm 0.18.
>>>
>>> What are the reason for their removal? 
>>>
>>> I will miss the primes quite a bit. Am I the only one here that feels 
>>> this way ?
>>>
>>> For instance, I would have to write headerModel___ and headerModel__ 
>>> instead of headerModel''' and headerModel''
>>> In the prime case I count the 'while on the underscore case I will 
>>> compare its length.
>>>
>>> at the end of the day, I will just skip the underscore and use number 
>>> like headerModel03 and headerModel02.
>>>
>>> And my case for backticks, I understand it will make the andThen API 
>>> easier, but why completely remove it from the language ?
>>>
>>> I guess my main question is, What is the motivation for their removal ?
>>>
>>> -- 
>>> 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.
>>>
>>
>>
>>
>> -- 
>> 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: Anyone working on audio stuff?

[Francesco Orsenigo]

I did this https://github.com/xarvh/elm-audio



On Sunday, October 9, 2016 at 11:24:10 AM UTC+11, ratvis wrote:
>
> Either just HTLM5 audio element or web-audio? I kind of thought after .17 
> came out, some more stuff would come out. 
> Just a wrapper thing around html5 audio (onPause, onEnded,...) would 
> enable people to do fun stuff. 
>

-- 
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 use elm-style-animation to make smoothly moving clock hand

[Francesco Orsenigo]

Subscribe to `AnimationFrame.times` 
,
 
store the time it gives you in the model, and render the clock with that 
time, adjusted for whatever speed or starting time you need.

-- 
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: Modeling cross-references

[Francesco Orsenigo]

If the random access happens only on user input, ie it's not something you 
need to do several thousands times per second, stick to Lists.
If you need a particular sorting order, stick to Lists.

You can use `Dict.foldl/r` to map a dictionary to a list in a single step, 
rather than first converting and then mapping.
This should give you a rendering performance similar to that of `List.map`.

All in all, if performance is the problem, I'd try both approaches and see 
which one works better.
(You could even write a thin layer between your app and the container, so 
that you can switch from List to Dict without touching much of your code).



Re "value types", if I understand correctly, if you have complex behavior 
to model on that I'd use a Union Type.
I'd expect the user to want to specify a "genere" which is not in a list of 
preset, which mean you'd want to leave it a String.




On Sunday, September 25, 2016 at 8:54:50 AM UTC+10, Eric G wrote:
>
> Thanks for this question and the suggestions - very useful to issues I am 
> dealing with now. 
>
> Some questions:
>
> - Is it better to use Dicts as the basic 'table' structure, if frequently 
> rendering lists of items filtered and sorted in various ways? In short, is 
> it better to convert a `List (ID, Item)` to a Dict for finding items, or 
> convert a `Dict ID Item` to a List for rendering them?  I kind of am 
> leaning towards `List (ID, Item)` as the persistent data structure esp. for 
> data that is frequently rendered in lists, but would really appreciate 
> hearing what peoples' actual experiences have been.
>
> - How are people modelling so-called 'value types' ?  For example in the 
> Albums/Artists if you had a `genre` type assigned to Albums. The genre 
> types change infrequently, but perhaps the application still needs some 
> kind of user interface to change them, which suggests they should be stored 
> as data, e.g. `List (ID, String)`, with no special behavioral significance 
> to the app.  On the other hand, in some cases you have value types that 
> *do* have behavioral significance, such as e.g. User Roles, and it is 
> tempting to want to have these map to Elm types instead of strings when you 
> `case` on them in view and update. But this means duplication of server- 
> and/or datastore- side data, and you still have to map your Elm types back 
> to IDs.
>
> Anyway, some rambling thoughts but curious if people have dealt with these 
> kinds of issues.  
>

-- 
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: Modeling cross-references

[Francesco Orsenigo]

I'm writing a real time strategy game and I'm using numeric ids on 
everything.

For example, each unit has an Id, and the command to attack another unit 
contains the target unit id.
I keep all units in a (Dict UnitId Unit), so I can access each quickly.
It's not as handy (or fast) as having pointers, but it is more robust: say 
the target unit is destroyed, the attacking unit will be left with Nothing 
to attack rather than a seg fault/reference error.


On Friday, September 23, 2016 at 8:24:38 AM UTC+10, Dénes Harmath wrote:
>
> Hi everybody,
>
> in a typical model, there are cross-references: e.g. we have artists and 
> albums, and the album refers to its artist. How do we model this in Elm? A 
> possible approach is giving unique identifiers to objects and store the 
> referred object's identifiers similar to the TodoMVC example - is this 
> mechanism extracted to some library in a type-safe way?
>
> Thank you in advance,
> thSoft
>

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

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

[Francesco Orsenigo]

Are you going to write such plugin for every possible editor?
Is every newbie going to have such plugin?
What about browsing code from GitHub?

A language's readability should not depend on tooling.

On Mon, Aug 22, 2016 at 5:52 PM, William Bailey  wrote:
> For years I coded in Java using IntelliJ.  It was super easy in that IDE to
> hover on any symbol, system or otherwise, and learn all about it.  Or hit
> ctrl-B (eg) to drill into the source. Again, worked fine for system
> libraries and was really useful for seeing how the under-the-covers stuff
> worked.
>
> When I started coding in go-lang a couple years ago, people were griping
> about having to manually remove unused imports as the compiler would not
> allow that.  But now, most editors have plug-ins that do that automatically.
>
> So... I think focusing on what the core language should and should not allow
> here is misguided.  Just need better IDE tools.
>
> --
> 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/ydhKsvJtDZw/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.

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

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

[Francesco Orsenigo]

Not at all.
You'd use qualified imports.

`import Html exposing (div, span, text, input, form)`

or

`import Html as H`
and then `H.div` `H.text` and so on.

One of the strength of Elm is keeping everything very explicit, which
makes it super newbie friendly.



On Mon, Aug 22, 2016 at 3:08 PM, Will White <will.n.wh...@gmail.com> wrote:
> I don't think it should be disallowed entirely. Disallowing it would make
> Html and other familiar things like that harder to read, without helping
> understanding.
>
> On Monday, August 22, 2016 at 11:10:38 AM UTC+1, Francesco Orsenigo wrote:
>>
>> The only issue I have with imports is that any code that contains several
>> unqualified imports is a pain in the ass to learn.
>>
>> Example:
>> https://github.com/Bogdanp/elm-combine/blob/2.2.1/examples/Python.elm
>>
>> As a newbie, it's immensely frustrating being unable to easily track which
>> of the `import Whatever exposing (..)` is actually providing a specific
>> symbol.
>> It should be disallowed entirely.
>> I don't mind writing more if it makes my code more readable.
>
> --
> 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/ydhKsvJtDZw/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.

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

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

[Francesco Orsenigo]

The only issue I have with imports is that any code that contains several 
unqualified imports is a pain in the ass to learn.

Example: https://github.com/Bogdanp/elm-combine/blob/2.2.1/examples/Python.elm

As a newbie, it's immensely frustrating being unable to easily track which 
of the `import Whatever exposing (..)` is actually providing a specific 
symbol.
It should be disallowed entirely.
I don't mind writing more if it makes my code more readable.

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