[elm-discuss] Re: Linear algebra for 2d geometry?

[Zinggi]

There is also my little library 
<http://package.elm-lang.org/packages/Zinggi/elm-webgl-math/latest>, you 
might find it useful.

On Thursday, 4 May 2017 15:56:05 UTC+2, Rupert Smith wrote:
>
> I need to implement some 2d geometry transformations, and would like to 
> use 3x3 matrices for this. Does anyone have some experience or recommend 
> one library over another? I don't really need maximum performance at this 
> stage, the drawing I am rendering will be relatively static and not consist 
> of a huge number of parts. The output will be SVG.
>
> There is elm-community/linear-algebra, but that only has 4x4 matrices and 
> is a native module, making it a little harder to add to and publish my own 
> additions. A 4x4 can always be used where a 3x3 can though.
>
> There is eeue56/elm-flat-matrix, which sounds as though it will be fairly 
> efficient as a pure Elm implementation.
>
> There is benansell/elm-geometric-transformation, which does what I need 
> for now. It hides the internal representation and I just had a peek at the 
> source and it is not a 3x3 matrix but 2x2 with transformation scalars held 
> separately. Might be nice to work more directly with matrices from the 
> point of view of being able to extend the work and I am pretty familiar 
> with linear algebra.
>
> Any others or thoughts?
>

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

[Zinggi]

Sorry, but there were many wrong / half truths in here, so I had to respond 
;)

Elm does not allow user code to do side effects
>
This is wrong, that's what Task and ultimately Cmd are for. It's true that 
there is no way to do *uncontrolled* side effects, e.g. a function that 
sends an https request without having type Task/Cmd.

In Haskell, a function with side-effects is marked as "unsafe" if it 
> declares IO in it's signature
>
That's wrong. Functions returning IO are not unsafe, they are equivalent to 
elms Task. They represent, just as in elm, a description of a *controlled* 
side effect.
Haskell can do IO in an unsafe way (by using unsafePerformIO :: IO a -> a), 
but then the function no longer returns something of type IO.
(unsafePerformIO should only be used in very rare, extraordinary 
circumstances)

There's no `Cmd.andThen` to chain together commands
>
Thats true, but there is Task.andThen. The Http library has a toTask method 
for chaining. Most other libraries that perform side effects should also 
have a way to use them as a Task


I agree with point 2, decoders/encoders are a bit tedious.
But it's not too bad, you can even generate them automatically: 
https://eeue56.github.io/json-to-elm/

Back to the topic: I'd also be in favor of the task based Javascript inter 
op proposal.
This could simplify scenarios like these quite a bit.

On Monday, 13 March 2017 18:11:15 UTC+1, Kasey Speakman wrote:
>
> The landscape as I see it: Elm does not allow user code to do side effects 
> (i.e. communication/IO). In Haskell, a function with side-effects is marked 
> as "unsafe" if it declares IO in it's signature e.g. `readFileText: string 
> -> IO string`. Since front-end IO is somewhat narrow in what is allowed, 
> instead of marking this with IO, Elm provides "safe" wrappers to do the 
> most common forms of front-end communication (i.e. HTTP). Most of the 
> libraries mentioned expose an HTTP API.
>
> The problem then is that Elm's HTTP library is not quite up to par. The 
> two largest problems I see right now:
>
> 1) There's no `Cmd.andThen` to chain together commands, so you can't 
> package up multiple calls as one operation on the client side. This forces 
> libraries to leak implementation details to the caller (e.g. pushing the 
> in-between-calls state management to host application) and therefore makes 
> them tedious to work with. I try not to design APIs where clients should 
> need to make multiple calls, but it's needed for external APIs like the 
> ones mentioned.
>
> 2) Dealing with JSON is too much boilerplate/hassle. Parsers are 
> intractable for common usage (but perhaps still required for advanced 
> usage). Elm needs a configurable automatic de/serializer built-in to 
> support HTTP. Initially, it could just be parsers generated at compile-time 
> (same as ports) for any declared type alias.
>
> I think alleviating these two issues would make it far easier and more 
> desirable to actually create Elm libraries for external services which 
> could be published on elm-package. I know I do not use Elm's built-in HTTP 
> library for these reasons, and use ports instead on what could otherwise be 
> a pure Elm app.
>
> On Monday, March 13, 2017 at 4:06:44 AM UTC-5, Oliver Searle-Barnes wrote:
>>
>> (prompted by discussion of firebase integration on elm-dev)
>>
>> Given that it would be really helpful to have more integration libraries 
>> available for Elm (auth0, firebase, aws...) I've been wondering if the 
>> current state of affairs is ideal for achieving:
>>
>> 1) Maximum number of integration libraries available for Elm
>> 2) All of those implemented in pure Elm
>>
>> Currently the path to get there appears to be:
>>
>> 1) Use an existing javascript library and wrap it using ports
>> 2) Reimplement the library in Elm
>>
>> 1 to 2 often represents a significant amount of development. Because 
>> ports preclude a library from being published in 
>> http://package.elm-lang.org/ and elm package doesn't support installing 
>> them from anywhere else there's a social pressure to not implement effect 
>> managers or release libraries that make use of ports. 
>>
>> Another path get to pure Elm libraries might be
>>
>> 1) Use an existing javascript library and wrap it using ports or native 
>> functions
>> 2) Release it as a library
>> 3) Gradually migrate the library over to pure Elm with the help of any 
>> members of the community that need it
>>
>> The concern here is obviously that your Elm code can now blow up and 
>> there's no way of knowing which code is unsafe. 
>>
>> What if unsafe because a first class concept in Elm? You could mark 
>> functions as "unsafe". Any function that calls an unsafe function would 
>> also be required to be declared as unsafe  e.g.
>>
>>
>> unsafe attemptAuth : LoginDetails -> Task String AuthStatus
>> unsafe attemptAuth loginDetails =
>> Native.WrappedLibrary.attemptAuth loginDetails
>>
>>
>>
>>
>> type Msg
>> = unsafe 

[elm-discuss] Re: Dealing with invalid state transitions

[Zinggi]

You could use this trick:

case (state, msg) of
(Displaying stuff, UpdateThis) -> ...
(Displaying stuff, UpdateThat) -> ...
(Loading, _) -> ...
_ -> ... {- only if needed -}


On Tuesday, 17 January 2017 15:03:05 UTC+1, Tomáš Znamenáček wrote:
>
> Hello!
>
> I have an app that loads some JSON from a website and displays it. The 
> state of the app could be modelled a bit like this:
>
> type State =
> Loading |
> Displaying Stuff
>
> type alias Stuff = { … }
>
> Now I am writing the update function to handle messages:
>
> update : Msg -> State -> (State, Cmd Msg)
> update msg state = case msg of
> UpdateThis -> …
> UpdateThat -> …
>
> My problem is that the state can be either Loading or Displaying, but most 
> of the messages only make sense in the Displaying state, leading me to code 
> like this:
>
> update : Msg -> State -> (State, Cmd Msg)
> update msg state = case msg of
> UpdateThis -> case state of
> Displaying stuff -> …
> _ -> (Failed "Invalid state", Cmd.none)
> UpdateThat -> case state of
> Displaying stuff -> …
> _ -> (Failed "Invalid state", Cmd.none)
>
> Obviously, this is dumb. How can I “divide” the loading and the displaying 
> part of the app? (Assuming that UpdateThis and UpdateThat can only arrive 
> in the correct, Displaying state.)
>
> Thank you!
>
> T.
>

-- 
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: YAML lib for Elm?

[Zinggi]

Probably not the answer you'd like, but there doesn't exist one.
Please do us all a favor and create one yourself ;) (probably with the help 
of this .)
If that's too much effort, you can use some JS lib 
 and use ports to bring it over to elm.


On Tuesday, 17 January 2017 13:44:41 UTC+1, fxmy wang wrote:
>
> Well short story would be: I need to parse some yaml. =)
>
> Long version: I'm using commentit.io for storing comments on my handmade 
> blog (powered by Elm of course). And commentit.io stores comments 
> the jekyll way. Hence in format of yaml like this 
> .
>
> So I need a way to parse and display comments for my blog.
>
> Cheers.
>
> 2017-01-17 10:12 GMT+08:00 Brian Hicks  >:
>
>> It doesn't look like there is, unfortunately. What are you trying to 
>> accomplish? Maybe there's another way around. :)
>>
>>
>> On Monday, January 16, 2017 at 12:00:45 AM UTC-6, fxmy wang wrote:
>>>
>>> Hello guys,
>>> Is there any yaml parser existing for Elm?
>>>
>>> Cherrs.
>>>
>> -- 
>> 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/s8dy6zlQaYM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [elm-discuss] What do you think Elm's biggest shortcomings are when it comes to natively supported API's?

[Zinggi]

> typed-arrays and ArrayBuffer.
That's basically it. Plus it would be nice if we could pattern match on 
binary files like in elixir/erlang.

On Monday, 12 December 2016 01:17:39 UTC+1, W. Brian Gourlie wrote:
>
> With regards to working with binary files, what all does that entail?  I 
> assume support for typed-arrays and ArrayBuffer... anything else?
>
> On Sunday, December 11, 2016 at 3:59:08 PM UTC-6, Zinggi wrote:
>>
>> (Elm discuss is fine for this. There are almost no open discussions on 
>> elm dev, as these are usually a waste of everyone's time.)
>>
>> For me, these things would be nice to have:
>>   * WebAudio API
>>   * File upload
>>   * Working with binary files, e.g. parsing
>>   * Persistent cache, offering access to local storage and maybe also 
>> IndexedDB
>>   (It's already there, but not released yet: 
>> https://github.com/elm-lang/persistent-cache)
>>   * Gamepad API
>>
>>
>> On Sunday, 11 December 2016 21:17:50 UTC+1, W. Brian Gourlie wrote:
>>>
>>> Per the elm-dev mailing list guidelines, I don't think this would be 
>>> appropriate there.  I'm also mostly interested in what other users feel are 
>>> shortcomings. Perhaps if I had a curated list of things, I could try and 
>>> bring it to the devs attention.  
>>>
>>> On Sunday, December 11, 2016 at 10:09:55 AM UTC-6, Duane Johnson wrote:
>>>>
>>>> I think this list is for discussion and is not as frequented by the elm 
>>>> core developers, so you might try 
>>>> https://groups.google.com/forum/?fromgroups#!forum/elm-dev
>>>>
>>>> They still show up here on occasion, but my impression is that they 
>>>> primarily hang out over there.
>>>>
>>>> On Sat, Dec 10, 2016 at 3:03 PM, W. Brian Gourlie <bgou...@gmail.com> 
>>>> wrote:
>>>>
>>>>> I've noticed a fair amount of discussion around various shortcomings 
>>>>> of Elm's native libraries. Particular examples that affect me are the 
>>>>> limited Websocket API and no native typed-array implementation.  The 
>>>>> former 
>>>>> is limits me quite a bit, while the latter is simply a nice-to-have. I've 
>>>>> seen clamoring for file upload support as well. In any event, it would be 
>>>>> interesting to get an idea of what people feel are the Elm's biggest 
>>>>> shortcomings in terms of natively supported features.
>>>>>
>>>>> One thing that is frustrating as an Elm user is feeling in the dark 
>>>>> when it comes to feature requests. I know the team likes to batch their 
>>>>> efforts, but it's disheartening to see something sit for months 
>>>>> unanswered. 
>>>>> I'm hoping for two things to come out of this post: Get an idea of what 
>>>>> the 
>>>>> biggest pain points are in terms of natively supported API's, and to get 
>>>>> an 
>>>>> idea of what the Elm devs think. Any feedback really would be nice!
>>>>>
>>>>> Brian
>>>>>
>>>>> -- 
>>>>> You received this message because you are subscribed to the Google 
>>>>> Groups "Elm Discuss" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>>> an email to elm-discuss...@googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>

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

Re: [elm-discuss] What do you think Elm's biggest shortcomings are when it comes to natively supported API's?

[Zinggi]

(Elm discuss is fine for this. There are almost no open discussions on elm 
dev, as these are usually a waste of everyone's time.)

For me, these things would be nice to have:
  * WebAudio API
  * File upload
  * Working with binary files, e.g. parsing
  * Persistent cache, offering access to local storage and maybe also 
IndexedDB
  (It's already there, but not released yet: 
https://github.com/elm-lang/persistent-cache)
  * Gamepad API


On Sunday, 11 December 2016 21:17:50 UTC+1, W. Brian Gourlie wrote:
>
> Per the elm-dev mailing list guidelines, I don't think this would be 
> appropriate there.  I'm also mostly interested in what other users feel are 
> shortcomings. Perhaps if I had a curated list of things, I could try and 
> bring it to the devs attention.  
>
> On Sunday, December 11, 2016 at 10:09:55 AM UTC-6, Duane Johnson wrote:
>>
>> I think this list is for discussion and is not as frequented by the elm 
>> core developers, so you might try 
>> https://groups.google.com/forum/?fromgroups#!forum/elm-dev
>>
>> They still show up here on occasion, but my impression is that they 
>> primarily hang out over there.
>>
>> On Sat, Dec 10, 2016 at 3:03 PM, W. Brian Gourlie  
>> wrote:
>>
>>> I've noticed a fair amount of discussion around various shortcomings of 
>>> Elm's native libraries. Particular examples that affect me are the limited 
>>> Websocket API and no native typed-array implementation.  The former is 
>>> limits me quite a bit, while the latter is simply a nice-to-have. I've seen 
>>> clamoring for file upload support as well. In any event, it would be 
>>> interesting to get an idea of what people feel are the Elm's biggest 
>>> shortcomings in terms of natively supported features.
>>>
>>> One thing that is frustrating as an Elm user is feeling in the dark when 
>>> it comes to feature requests. I know the team likes to batch their efforts, 
>>> but it's disheartening to see something sit for months unanswered. I'm 
>>> hoping for two things to come out of this post: Get an idea of what the 
>>> biggest pain points are in terms of natively supported API's, and to get an 
>>> idea of what the Elm devs think. Any feedback really would be nice!
>>>
>>> Brian
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Elm Discuss" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to elm-discuss...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

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

Re: [elm-discuss] Rename Just to Something, as the counterpart to Nothing?

[Zinggi]

I love this!
I've read through the whole thread, but for every suggestion so far I 
thought: "meh, 'Just a' sounds better".
But this looks even better!

On Friday, 25 November 2016 10:03:54 UTC+1, Witold Szczerba wrote:
>
> I have it, I have it, look at this:
>
> type Maybe a = Nothing | Maybe a
>
> It's very popular to name constructor after type in many languages.
>
> case msg of
> Maybe This -> ...
> Maybe That -> ...
> Nothing -> ...
>
> Also, "Just" is just fine as well.
>
> 24.11.2016 10:21 PM "Michael B"  
> napisał(a):
>
>> Maybe a = Nothing | Such a
>>
>> elm = Such wow
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

[elm-discuss] Re: The Style Elements Library: a different approach to styling

[Zinggi]

Wow, this looks awesome!
I'm definitely gonna try that on my next project.
This might actually make css great again ;)

On Thursday, 27 October 2016 15:20:14 UTC+2, Matthew Griffith wrote:
>
>
> It's easy to write valid CSS that is still broken and frustrating. What if 
> we could make frustrating CSS styles not expressible?
>
> I've been working on an experimental style library for making styles that 
> are harder to break and easier to use.
>
> There is also support for flow/flexbox style layouts, animations, 
> transitions, and media queries.
>
> It takes a different approach on attaching styles to html nodes. Instead 
> of using classes and ids, you create collections of styled html elements to 
> pull from to build your view (with support for classList style variations 
> that can be turned on/off).  
>
> Let me know your thoughts!
>
> Note:  I haven't published this on elm-package yet as I wanted to see if 
> there was any feedback that might alter what 1.0 looks like.
>
> The Style Elements library 
>
> Simple Example 
> 
>
> Complex Example 
> 
>

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

[elm-discuss] Re: Getting functions out of the model

[Zinggi]

These are some very good points.
I don't see how a library that doesn't store functions in the model could 
deal with these situations as easy as your library does.

The only possible solution I can think of is that you could extend the 
description of an animation to include possible future interruptions and 
delays.
e.g.

animationDescription =
  Animation {..., easing=something, onInterrupt= Delay 0.2 (Animation {..., 
easing=somethingElse}) }

I don't know whether this could cover all your use cases, and it might be 
difficult to use.


On Thursday, 13 October 2016 21:56:54 UTC+2, Matthew Griffith wrote:
>
>
> So it's not necessarily not having interruptible animations, it's more all 
> the code that you'll need to manage them.  
>
> In elm-style-animation you can just start a new animation and 
> interruptions are handled automatically.
>
> When you have description and state split, you have to juggle switching 
> out the animationDescription at the right time.
>
> view model =
>   animate animationDescription model.animationState
>
> becomes the following when you have multiple possible animation 
> descriptions.  Lets say we have model.animId to keep track of what 
> description is running so we can switch between them.
>
>
> view model =
> let 
> myAnimationDescription = lookup model.animId
> in
> animate animationDescription model.animationState
>
> Easy peasy.  
>
> What about when you want to have a delay and then an interruption, you 
> have to keep track of the delay and switching out animationDescription when 
> the interruption occurs.  Great, we can do that.
>
> You also have to implement logic that handles what happens when multiple 
> delayed interruptions are queued up.  So now you have a queue of animation 
> interruptions to manage.  Ok then.
>
> Basically all of this is totally writable code...it's just that that's a 
> large part of the built in functionality of the elm-style-animation 
> library.  Why write all that code if a library handles it out of the box?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thursday, October 13, 2016 at 3:25:17 PM UTC-4, Zinggi wrote:
>>
>> @Frederick
>> Yes, that's where I got my inspiration from ;)
>>
>> @Matthew
>> I don't think this is a problem, but I also don't understand what you 
>> mean by "you'd have to do all the interruptions manually".
>> Could you elaborate?
>> I haven't studies your library closely, so I don't know how your library 
>> currently deals with interruptions.
>>
>> I once created an animation library for react 
>> <https://github.com/Zinggi/RAnimation>, it kinda works like I described 
>> above and it does have interruptable animations.
>> But of course react doesn't map nicely to elm.
>>
>>
>> On Thursday, 13 October 2016 21:02:29 UTC+2, Frederick Yankowski wrote:
>>>
>>> The elm-autocomplete package does something much like you describe. 
>>> Configuration data, including some functions, is defined separately from 
>>> the model and is passed as an additional parameter to the update function.
>>>
>>>
>>> https://github.com/thebritican/elm-autocomplete/blob/4.0.1/src/Autocomplete.elm#L181
>>>
>>> On Thursday, October 13, 2016 at 1:34:29 PM UTC-5, Zinggi wrote:
>>>
>>> I think it would be nice to separate the *descriptions* of an animation 
>>>> from the *state* of an animation.
>>>>
>>> ​
>>>
>>

-- 
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: Getting functions out of the model

[Zinggi]

@Frederick
Yes, that's where I got my inspiration from ;)

@Matthew
I don't think this is a problem, but I also don't understand what you mean 
by "you'd have to do all the interruptions manually".
Could you elaborate?
I haven't studies your library closely, so I don't know how your library 
currently deals with interruptions.

I once created an animation library for react 
<https://github.com/Zinggi/RAnimation>, it kinda works like I described 
above and it does have interruptable animations.
But of course react doesn't map nicely to elm.


On Thursday, 13 October 2016 21:02:29 UTC+2, Frederick Yankowski wrote:
>
> The elm-autocomplete package does something much like you describe. 
> Configuration data, including some functions, is defined separately from 
> the model and is passed as an additional parameter to the update function.
>
>
> https://github.com/thebritican/elm-autocomplete/blob/4.0.1/src/Autocomplete.elm#L181
>
> On Thursday, October 13, 2016 at 1:34:29 PM UTC-5, Zinggi wrote:
>
> I think it would be nice to separate the *descriptions* of an animation 
>> from the *state* of an animation.
>>
> ​
>

-- 
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: Getting functions out of the model

[Zinggi]

I also thought about this problem for a bit.
I came up with a slightly different solution.

I was not only not happy with storing functions in my model, but also with 
storing static values in the model (e.g. stuff that wont change often).
I think it would be nice to separate the *descriptions* of an animation 
from the *state* of an animation.

So when you actually use an animation, you need to provide an animation 
description and an animation state, this might look kinda like this:

model =
  { animationState = Animation.new 0 }

update msg model =
  case msg of
Tick dt ->
  { model | animationState = Animation.tick dt model.animationState }

animationDescription =
  { startValue = 0, endValue = 10, speed = 2, easing = Easing.sinInOut, 
etc... }

view model =
  animate animationDescription model.animationState


On Thursday, 13 October 2016 08:29:19 UTC+2, Aaron VonderHaar wrote:
>
> As mentioned in some recent threads [1] [2], easing functions for 
> animations have been an example of where functions in the model are 
> currently used.  An alternative approach is to use a union type to indicate 
> the easing, but a suggested shortcoming of that approach is that there 
> would then be no way for downstream developers to use their own custom 
> easings.
>
> I was just thinking that this could be achieved as follows:
>
> ```
> type AdvancedEasing a
> = Linear | InQuad | OutQuad | ...
> | CustomEasing a
>
> type alias Easing = AdvancedEasing Never
>
> apply : Easing -> Float -> Float
>
> applyAdvanced : (a -> Float -> Float) -> AdvancedEasing a -> Float -> Float
> ```
>
> In this way, the custom easing functions (a -> Float -> Float) are moved 
> from the model to configuration.
>
> I was curious if anyone has experimented with this approach yet.
>
>
> [1]: https://groups.google.com/d/topic/elm-discuss/bOAHwSnklLc/discussion
> [2]: https://groups.google.com/d/topic/elm-discuss/9qV9iDcv-c8/discussion
>
>

-- 
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: Function equality again

[Zinggi]

I also think that comparing functions should just compare them by 
reference, this should cover the most common cases.

Another possible solution: What about a compile time error? Is this 
possible?

On Wednesday, 12 October 2016 18:48:12 UTC+2, Mark Hamburg wrote:
>
> As discussed elsewhere, the runtime exception related to function equality 
> comparisons is a lurking time bomb for code that is really only addressed 
> on a multi-developer project by being paranoid both about functions in data 
> structures and use of the equality operator. Both points of paranoia get in 
> the way of writing "good" code. There are other arguments around things 
> like serialization for avoiding using functions in some places, but there 
> are lots of other places where it is extremely useful to put functions in 
> data structures. (Imagine writing an effects manager if it couldn't store 
> functions in its data structures.) 
>
> Full equality tests are, as I understand it, undecidable. That doesn't 
> mean, however, that some limited analysis can't prove equality in most of 
> the conditions that matter. In fact, the existing code doesn't always throw 
> an exception. It only throws an exception if an "allocation identity" test 
> fails. One could extend this to looking at the "code pointer" and 
> allocation identity for the closure values and probably get many of the 
> remaining cases that mattered. It's just a matter of how far one wants to 
> push when trying to prove or disprove equality and I'm not arguing for a 
> particular limit here. 
>
> Rather, I think the central issue is around what happens when we give up. 
> At that point, there are two choices: throw a runtime exception as happens 
> now or return false. As mentioned above and discussed at further length 
> elsewhere, the runtime exception leads to paranoid coding. What are the 
> issues with returning false? The big problem with returning false is that 
> this means that some compiler optimizations might then change cases that 
> returned false without the optimizations into cases that returned true and 
> people become understandably uncomfortable with the possibility that 
> compiler optimizations could change the meaning of programs. And with that, 
> I've more or less wanted a "return false" answer but convinced myself that 
> throwing an exception wasn't unjustified and that maybe what we needed 
> instead was type system support to avoid the issue. 
>
> But then this morning's discussion of the virtual DOM had me realizing 
> that runtime optimizations around when the render-diff-patch algorithm gets 
> run create significant potential for variable program behavior. We embrace 
> these optimizations even though they introduce non-determinism. Now, its 
> non-determinism at the level of the physical DOM rather than the values 
> produced in Elm itself — i.e., runtime v linguistic non-determinism — but 
> its non-determinism in one of the most fundamental parts about how Elm is 
> generally used so that distinction seems somewhat arbitrary. 
>
> I think Elm makes the right call on the DOM. Maybe it should log cases 
> where the DOM logic can recognize that there might be a problem, but I 
> think this is overall a tradeoff worth making. 
>
> But by the same argument, I think Elm programs would be better if the 
> runtime exception for function equality comparisons was replaced with a 
> false result even though it might actually be true. And if it's really 
> irksome, then it could generate a log statement as well. 
>
> Mark 
>
>
>
>

-- 
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: Functional programming, or why should I use Elm instead of vanilla javaScript?

[Zinggi]

> And all this stuff about immutability, can be easily achieved in plain 
javaScript. 

You claim that you can achieve all the the things that elm does by being 
disciplined enough, but that's not true. Here are a few things that only 
elm can provide that JavaScript can't.
These things are only possible because of elms limitations:

  - Easy serialization/deserialization of application state *including 
state from external libraries*
  - *Enforced semantic versioning* for all packages
  - A sane package ecosystem
  - A time traveling debugger *that works no matter what code you write or 
libraries you use*
  - *No runtime exceptions*

So by removing a bunch of features from JavaScript, namely mutable 
variables and arbitrary side effects, elm can provide all the above. 

On Wednesday, 5 October 2016 19:50:52 UTC+2, Sarkis Arutiunian wrote:
>
> Recently I read article about Functional programming, all 5 parts 
> .
>  
> Yes it's pretty interesting article, written in interesting way. And I 
> really like pattern of 'functional programming', immutability and etc.
>
>
> But there is a question. Where the line between propriety and paranoia?
>
>
> I prefer use native javaScript for everything where I can do it without 
> any libraries. Yes exactly you should use some UI libraries like React and 
> some module bundler like webpack. But I think propriety of using this tools 
> is obvious. It's better to use JSX then use native js to create DOM or it's 
> better to use webpack at least to uglify and optimize your code because 
> some things just impossible to achieve without webpack.
>
> And we have absolutely opposite situation with Elm. Yes they have some 
> features to make function a little bit shorter than you'll do it in vanilla 
> javaScript and only in some case. It's not that difference like create 
> nodes with JSX or js.
>
>
> And all this stuff about immutability, can be easily achieved in plain 
> javaScript. Eventually is Elm code will be converted to plain javaScript 
> and not vice versa, so that's mean you can do all that stuff in javaScript 
> but for sure there are some features in javaScript which you can't do in 
> Elm. And using Elm you are limited with one pattern. And what if it's not 
> enough or it's not best solution in some case, what than? For example right 
> now I'm working on new CMS for one of my projects, on React/GraphQL/Nodejs 
> and hybrid storage MongoDb with mySQL. I would like to use this pattern in 
> some cases but I just can't use it everywhere, so that's mean I shouldn't 
> use Elm?
>
>
> Don't think that I'm against to Elm. I just want to see opinion of others. 
> And I want to see that line, between propriety and paranoia.
>
>
> Thanks.
>

-- 
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: keeping functions out of the model

[Zinggi]

This also has the added benefit that you can then use the same animation 
with different easing functions without having to duplicate the whole 
Animation record.

On Wednesday, 5 October 2016 10:01:25 UTC+2, Zinggi wrote:
>
> I think you could create an animation library that doesn't store any 
> functions in its model and still be able to let a user provide whatever 
> easing function they want.
>
> E.g. remove the ease key from your AnimRecord and let all functions that 
> currently take an Animation have an additional parameter easingFunction:
>
> animate : EasingFunction -> Time -> Animation -> Float
>
> This way a user of your library doesn't have to put any functions in their 
> model and you get both a function free model and endless customization by 
> providing whatever easing function a user needs.
>
> Am I missing something?
>
>
> On Wednesday, 5 October 2016 07:56:04 UTC+2, Max Goldstein wrote:
>>
>> Serialization: animations are view state. They can safely be left out of 
>> a serialized and persisted model.
>>
>> Print out the model: True, but if you're using animation in an app, 
>> you're beyond poking at the model in the REPL.
>>
>> Harder to equate: My animation library provides an "equals" function. In 
>> addition to sampling the easing function, it accounts for a few other ways 
>> animations can have different representations but be considered equal (e.g. 
>> start at time t with delay k == start at time t+k with no delay).
>>
>> "just store the things needed to create the function" -> This is 
>> essentially the "EasingDescription" idea I talked about above. The problem 
>> is that easing functions can be created in many way (sinusoids, 
>> polynomials, exponentials, bounces) and I want to allow the client to 
>> specify any function.
>>
>

-- 
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: keeping functions out of the model

[Zinggi]

I think you could create an animation library that doesn't store any 
functions in its model and still be able to let a user provide whatever 
easing function they want.

E.g. remove the ease key from your AnimRecord and let all functions that 
currently take an Animation have an additional parameter easingFunction:

animate : EasingFunction -> Time -> Animation -> Float

This way a user of your library doesn't have to put any functions in their 
model and you get both a function free model and endless customization by 
providing whatever easing function a user needs.

Am I missing something?


On Wednesday, 5 October 2016 07:56:04 UTC+2, Max Goldstein wrote:
>
> Serialization: animations are view state. They can safely be left out of a 
> serialized and persisted model.
>
> Print out the model: True, but if you're using animation in an app, you're 
> beyond poking at the model in the REPL.
>
> Harder to equate: My animation library provides an "equals" function. In 
> addition to sampling the easing function, it accounts for a few other ways 
> animations can have different representations but be considered equal (e.g. 
> start at time t with delay k == start at time t+k with no delay).
>
> "just store the things needed to create the function" -> This is 
> essentially the "EasingDescription" idea I talked about above. The problem 
> is that easing functions can be created in many way (sinusoids, 
> polynomials, exponentials, bounces) and I want to allow the client to 
> specify any function.
>

-- 
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: Any tricks for debugging?

[Zinggi]

Well elm-conf <http://www.elm-conf.us/> is happening right now, so we'll 
get more info very soon.

On Thursday, 15 September 2016 21:50:42 UTC+2, John Orford wrote:
>
> any ballpark guesses on when 0.18 will happen? before the end of the year 
> perhaps?
>
> On Thu, 15 Sep 2016 at 21:37 Zinggi <schrot...@gmail.com > 
> wrote:
>
>> You could wait some time on the 0.18 release which will most likely bring 
>> back the time traveling debugger, with object introspection.
>> This is much more comfortable than Debug.log.
>>
>> For now, you could use this library 
>> <http://package.elm-lang.org/packages/jinjor/elm-time-travel/latest> which 
>> also works quite nicely. (except if you have many messages per second, e.g. 
>> for game/animation things)
>>
>> Debug.log covers all the the other cases. However, if I wanted to print 
>> all messages, I'd do it like this:
>>
>> update msg model =
>> case Debug.log "Msg" msg of
>> Foo -> ...
>>
>>
>> On Thursday, 15 September 2016 12:24:46 UTC+2, Rupert Smith wrote:
>>>
>>> I am finding it useful to know which Msgs are being triggered through my 
>>> update functions, so have been putting in code like this:
>>>
>>> log =
>>> Debug.log "myModule"
>>>
>>> ...
>>>
>>> Add ->
>>> let d = log "add" in
>>>...
>>>
>>> Now I have decided it would be easier to just print all Msgs rather than 
>>> add this to specific ones:
>>>
>>> debug : a -> a
>>> debug a =
>>> Debug.log "myModule" a
>>>
>>>
>>> update : Msg -> Model -> ( Model, Cmd Msg )
>>> update action model =
>>> update' (debug action) model
>>> -- OR even update' (debug action) (debug model)
>>>
>>> update' : Msg -> Model -> ( Model, Cmd Msg )
>>>
>>> And am considering pulling up the 'debug' function into its own module, 
>>> so I can easily globally turn on/off debug tracing by switching it between 
>>> the identity function or the logging function.
>>>
>>> Just wondering if anyone has any helpfull debugging tricks they like to 
>>> use with Elm?
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

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

[elm-discuss] Re: Any tricks for debugging?

[Zinggi]

You could wait some time on the 0.18 release which will most likely bring 
back the time traveling debugger, with object introspection.
This is much more comfortable than Debug.log.

For now, you could use this library 
 which 
also works quite nicely. (except if you have many messages per second, e.g. 
for game/animation things)

Debug.log covers all the the other cases. However, if I wanted to print all 
messages, I'd do it like this:

update msg model =
case Debug.log "Msg" msg of
Foo -> ...


On Thursday, 15 September 2016 12:24:46 UTC+2, Rupert Smith wrote:
>
> I am finding it useful to know which Msgs are being triggered through my 
> update functions, so have been putting in code like this:
>
> log =
> Debug.log "myModule"
>
> ...
>
> Add ->
> let d = log "add" in
>...
>
> Now I have decided it would be easier to just print all Msgs rather than 
> add this to specific ones:
>
> debug : a -> a
> debug a =
> Debug.log "myModule" a
>
>
> update : Msg -> Model -> ( Model, Cmd Msg )
> update action model =
> update' (debug action) model
> -- OR even update' (debug action) (debug model)
>
> update' : Msg -> Model -> ( Model, Cmd Msg )
>
> And am considering pulling up the 'debug' function into its own module, so 
> I can easily globally turn on/off debug tracing by switching it between the 
> identity function or the logging function.
>
> Just wondering if anyone has any helpfull debugging tricks they like to 
> use with Elm?
>

-- 
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] Try out the 0.17.1 beta

[Zinggi]

If you need time travel right now, you can use this library:
http://package.elm-lang.org/packages/jinjor/elm-time-travel/1.0.8/

On Tuesday, 28 June 2016 21:34:33 UTC+2, Douglas Correa wrote:
>
> Evan, thanks for the new version,
>
> And I really like this part of README.md (
> https://github.com/elm-lang/elm-reactor/blob/master/README.md#note-about-time-travel
> ) 
>
> Time travel is very useful in "Redux world" and it would be in Elm too.
>
> Douglas
>
> On Tue, Jun 28, 2016 at 3:30 PM, Evan Czaplicki  > wrote:
>
>> The 0.17 release revealed a few rough spots. Particularly for new folks 
>> who were trying to install evancz/elm-html instead of elm-lang/html. So I 
>> did a bunch of bug fixes for stuff along these lines. The main changes are:
>>
>>- Default dependencies in elm-package.json are core *and*
>> elm-lang/html.
>>- Error messages for elm-package are improved (e.g. this 
>>
>> and this 
>>
>> 
>>)
>>- Packages download concurrently (a.k.a. faster)
>>- Make elm-reactor serve assets better. Was messing up CSS and HTML.
>>- Use ~/.elm/0.17.1/ so all globally cached things are isolated
>>- Binaries are much smaller (~120MB to ~40MB on OSX)
>>
>> I have some beta binaries ready. Please give them a try:
>>
>>- mac 
>>- windows 
>>
>> It is just a better version of 0.17, so you should be able to install and 
>> just have things be nicer. If you try it and want to go back to 0.17, just 
>> run the installers here . The most recent 
>> one takes precedence.
>>
>> I'm hoping to do a relatively quite announcement on twitter tomorrow, so 
>> let me know if you run into any problems!
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to elm-discuss...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[elm-discuss] Re: Dynamically load SVG files

[Zinggi]

Couldn't you just use an img tag with the path/to.svg in the src attribute?


On Monday, 30 May 2016 15:34:07 UTC+2, Håkon Rossebø wrote:
>
> I'm trying out some SVG maps from here:
>
> https://www.amcharts.com/svg-maps/?map=usa
>
> Seems to be too much to embed inline. What would be the best way of 
> loading SVG files dynamically?
>
>
>
>
>

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