Initialisation data

[Peter Damoc]

Is there an argument against Elm providing something like a record of initial values for certain things. 

It would be super helpful to have something like 

initialValues : { windowSize : (Int, Int), mousePosition : (Int, Int), startTime : Time}  

Ideally, this would be in Basics so that it wouldn't require another import.   

--

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

[Jamison Dance]

You can provide initial values to `Elm.embed` and the like. They come in as ports. See http://jamison.dance/12-21-2015/providing-initial-arguments-to-an-elm-app/ for more details. Is this what you mean?

[Max Goldstein]

Peter, what problem exactly are you trying to solve? Does it relate to needing these values to sensibly initialize the model?

Regarding mouse position in particular, there is no way to know what the current mouse position is at page load. You have to wait for it to move. 

[Peter Damoc]

Yes, it relates to easiness of initialisation. 

I was answering a question related to Random.initialSeed and in the documentation it says: "A good way to get an unexpected seed is to use the current time."

In most cases this might be required only at init time. 
The solution I found so far is to reuse the Effects.tick to trigger an Action that actually does the initialisation but this feels convoluted.

The window dimension is very important because you can have a MainView that selects custom views based on size of the window.

I did not knew that Mouse position is so tricky but, out of the three, this is the least mission critical of all. 

On Sun, Feb 14, 2016 at 5:12 PM, Max Goldstein <maxgol...@gmail.com> wrote:

Peter, what problem exactly are you trying to solve? Does it relate to needing these values to sensibly initialize the model?

Regarding mouse position in particular, there is no way to know what the current mouse position is at page load. You have to wait for it to move. 

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

[Peter Damoc]

Thank you for your answer, Jamison! 

Using ports or JS is only possible in the main file. 

If one develops components, these options are not available. 

--

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.

[Jason Underdown]

I've been struggling with the same exact problem. This comes up whenever you have a module that needs random values. I know how to use ports to seed the random number generator with the system time, but how do you filter that initialization data down to lower modules/components.

[Max Goldstein]

I was answering a question related to Random.initialSeed and in the documentation it says: "A good way to get an unexpected seed is to use the current time."

 Oh. My. God. That documentation is wrong, wrong wrong.

 

I've been struggling with the same exact problem. This comes up whenever you have a module that needs random values. I know how to use ports to seed the random number generator with the system time, but how do you filter that initialization data down to lower modules/components.

Stop using core/Random, stop using the current time, elm package install mgold/elm-random-pcg, and follow the instructions here.

And if you have many components, don't pass down the time, split the seed and pass that.

And if you have any other initialization data, pass it down through function calls. Take the boilerplate of passing parameters to functions and don't try to get fancy.

[Peter Damoc]

Max, can you give more information about why would it be wrong to use the current time for the initialSeed? 

I'm asking because it seams to be like a sensible suggestion for code without access to ports.
 

--

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.

[d13]

I'm also curious about this.

As a beginner, it seems strange to me that such a fundamental feature such as random number generation can only be implemented by using an entirely different language (JavaScript).

Do experienced Elm developers not see this as a flaw in the language?

[Jason Underdown]

Let me take a stab at that. 

Elm developers do not see this as a flaw in the language but rather a conscious design choice. By design, Elm is pure, meaning that every function must always return the exact same value when given the same input. As a corollary, there can be no functions which take no parameters and return different results with each invocation like the JavaScript API Date.getTime() does. The reason for this is to make it easy to reason about code. Unfortunately this does make some things harder in Elm than in other languages. Random number generation is one of those things that is a little harder.

The problem with components which maintain state is that it becomes very difficult to reason about your code, because calling a function may have side effects other than the return value. The difficulties tend to grow exponentially with the size of your codebase. Evan consciously chose to make Elm pure to make it impossible to introduce errors which are a result of side effects. Elm developers tend to be people who have dealt with the headaches of large JavaScript codebases and want a better way. It is worth it to pay a little more up front in development time in order to have a system which you can maintain and even change without the worry that you will break something unintentionally. I highly recommend watching Richard Feldman's StrangeLoop talk about this.

Realize that the model in Elm's "model, view, update" architecture is not updated in place, rather a new copy with new values is made every time update is called. So modules in Elm are stateless. The fact that a new copy is made with each update also allows for the time traveling debugger.

In regards to initial seeds for random number generation, of course Max is absolutely right, seeding a random number generator with the current time will not give you cryptography level randomness, but it is not a horribly unreasonable choice for some simple apps. Having just said that, Max linked to a great way to seed the random number generator using ports and JavaScript's Math.random() API which is very easy and much better than using the current time. I intend to follow his suggestion. And thank you Max, being able to fission the seed will allow me to accomplish what I want to do.

[Nick H]

Re: Peter, seeding with timestamps

Here are a couple reasons I can think of to avoid doing this

- If two instances of your program get run at the same time, they are going to generate the same series of random numbers.

- I don't know the mathematics behind them, so I can't be very specific, but timestamps don't have a lot of variety in them (for example, you'll never seed the random number generator with a timestamp for the year AD 30,917). All RNG algorithms have biases, and a common property is that using similar seeds leads to similar sequences of random numbers (for some definition of "similar"!).

Re: d13, having to seed using ports

I think this ties into the larger issue of improving Elm's "coverage" of browser functionality. This is priority #1 for the next version of Elm, so I am optimistic that it will get better in the future. In the meantime, since Elm programs need to be bootstrapped with JavaScript anyway, I haven't found it that annoying to pass a couple values into the program from Elm.embed

--

[Max Goldstein]

@Peter: The RNG is very susceptible to giving similar answers for similar seeds. For example, If you use any seed less than 53668 and generate one bool, it will be True. I expect, but have not confirmed, similar behavior with seeds the size of the current unix time. Nick makes a similar point, "All RNG algorithms have biases", but trust me way I say core/Random has very noticeable biases!

If you do not have access to ports, and cannot accept a seed during initialization from someone who does, then I understand the desire to use the current time. However, the current time can only be obtained through a signal, which completely destroys the purpose of a pure random number generator.

I don't think either of these reasons alone are insurmountable, but combined, it's just a massive headache.

@d13: See Jason's excellent answer.

@Jason: Thanks for that post. Glad fissioning is helpful.

@Nick: Good point about concurrent instances... or components. And regarding the mathematics, each bit of the initialization value should have a 50/50 chance of being a 1. Timestamps (in human-sized time) don't have this property.

One way around this problem would be to have a seed initialized in a sensibly random way at program start. The seed would be immutable for the duration of the program but change with subsequent programs. There hasn't bee a whole lot of support for this idea, but maybe you all can bring it up again?