Varying

[Richard Feldman]

Looking over Hassan's sweet Reddit example, with Task, Stream, and input, I noticed that the term Varying is sort of sticking out as troublesome now that the terminology bar has been raised by the others. :)

When I got to the end I looked at this and found it was significantly harder to follow than the code before it:

main : Varying Html
main =
  Varying.map view
    (Varying.fromStream (Err Http.Timeout) results)

In particular Varying.fromStream seems confusing: why do I need to combine a Stream with a constant value to get a Varying? Surely the Stream already varied before I did that, and why am I adding a constant value in order to get something that "varies" more than what I had before? "Varying Html" looks kinda cool as a type annotation for main, but the metaphor seems to break down very soon afterward in practice.

I'm hardly in love with this as an alternative, but I do think it's clearer:

main : InitializedStream Html

main =

InitializedStream.map view

(InitializedStream.fromStream (Err Http.Timeout) results)

It's definitely more verbose than I'd like, but I can read that code and immediately understand how InitializedStream and Stream relate to one another. I think Varying is proving problematic for me because this relationship is obscured.

Anyone else feel this way about Varying?

[Hassan Hayat]

How about just going back to Signal?  

I dunno, I kinda miss it. :(

[John Mayer]

I'd refactor this using foldp. I know this is a toy app, but it doesn't really make sense that your initial state is a timeout.

type Model = Loading | ReadyWith HttpResult

Start with an initial loading page state and have it flip to a populated when your results come in.

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

[Hassan Hayat]

Thanks for the input, John.

So I did a bit of refactoring and put in some effort to make everything look nice.

I separated the model from the JSON parsing. I then made explicit actions and an explicit model. I think that now the code is clearer. Longer and more verbose, sure. 

https://gist.github.com/TheSeamau5/80fdcb8c2f7e599c5099

[Jeff Smits]

I have nothing against keeping Signal. 

InitializedSteam is something I suggested I think.. Now looking at it again, I'd be more for Stream.Initialized. But Signal is still better. 

--

[Evan Czaplicki]

I think "stream" misses an important detail, which is "how the heck can you map3 over streams?" The point of splitting out these concepts is to have a distinct concept of "stream of discrete events" separate from "a time varying value".

Also, when I describe signals, I always say "it's a time-varying value" or "it's a value that changes over time". I feel like calling it a "varying value" is much more direct.

Finally, what does it mean to "initialize" a stream of events? Is there an initial event? Is the initialization also discrete? This name does not make sense to me given what it actually means.

[UEHARA Junji]

Hi,

I have little messy impression about to use Varying and Stream appropriately,

and convert visa versa, and I imagine newbies of Elm feels so.

Is it impossible to define Varying and Stream as predefined type class "signal",

like number/comparable/appendable ? Those are we know hard coded type class of Elm.

So, map*s is to be defined on the predefined type class "signal".

UEHARA Junji

[petar...@googlemail.com]

I don't really like Varying and Stream, I much prefer the Signal approach. I get a feeling that we are trying to solve a different problem than the one originally stated (allowing an initial value for a Signal).

[Sebastian Graf]

I find Signal clearer than Varying. It may be because I have some minor background in signal processing, but mostly because I find Varying to be very vague.

To explain my point: Varying doesn’t seem to be a proper noun in itself, since it is just derived from vary and not the root word itself (don’t nail me on linguistics :D). Granted, we are beginning to talk about Mappables and Appendables as abstractions, but Varying Html doesn’t quite fit imo: Im reading Varying as an adjective rather than as a noun.

On another note: Varying has a meaning in the graphics scene, it even was a keyword in early versions of GLSL for interpolated fragment shader input data. They ditched it for consistent in and out keywords though. This may be important for later interaction with WebGL (programmers).

When using varying as a term, we don’t say anything about what the value varies relative to (as should be evident by the GLSL example). Signal does a fine job here: It doesn’t actually say that it is varying over time, but it has a real-world analogy that immediately suggest change over time (actually this doesn't hold for image signals as I just realize), plus always having a value to sample from. If this is not immediately clear to newcomers, then we could always tell them to regard signals as a value varying over time, so that we can focus on one discrete time-step a time.

Of course, Signal isn’t bullet proof either: It suggests continuity (as in audio signal) where in reality we model discrete signals. Also, I may be biased because we stuck to it for so long.

I’m not saying that we should stick to Signal, just that I’d like to ditch Varying.

​

[Alex Neslusan]

I kind of agree with this post.

[Evan Czaplicki]

To explain my point: Varying doesn’t seem to be a proper noun in itself, since it is just derived from vary and not the root word itself (don’t nail me on linguistics :D). Granted, we are beginning to talk about Mappables and Appendables as abstractions, but Varying Html doesn’t quite fit imo: Im reading Varying as an adjective rather than as a noun.

Variable is an adjective in normal english, but programmers don't seem to have a problem with it. I don't see how "varying" is that much different. In some sense, we have a much safer kind of variable here, in that you never forget to handle changes. That seems like a cool connection to me.

On another note: Varying has a meaning in the graphics scene, it even was a keyword in early versions of GLSL for interpolated fragment shader input data. They ditched it for consistent in and out keywords though. This may be important for later interaction with WebGL (programmers).

Yeah, I'm not sure how to feel with this overlap. My overall feeling is that the number of people who know the OpenGL term is pretty small, probably small enough that it's not a big deal and they'd be able to compartmentalize the two ideas.

Of course, Signal isn’t bullet proof either: It suggests continuity (as in audio signal) where in reality we model discrete signals. Also, I may be biased because we stuck to it for so long.

When I look at these two, it's hard for me to think that Signal is easier for beginners.

 

main : Signal Html

main : Varying Html 

I’m not saying that we should stick to Signal, just that I’d like to ditch Varying.

How? It seems like our options are Signal, Stream/Varying, or Events/Signal and no one agrees about what is the best combination. To be conservative, we could stick with Signal in 0.15 and then slowly migrate over to different names. I think that's the safe route, but I also think it's a little too cautious.

 

​

On Monday, 16 March 2015 23:34:46 UTC+1, Richard Feldman wrote:

Looking over Hassan's sweet Reddit example, with Task, Stream, and input, I noticed that the term Varying is sort of sticking out as troublesome now that the terminology bar has been raised by the others. :)

When I got to the end I looked at this and found it was significantly harder to follow than the code before it:

main : Varying Html
main =
  Varying.map view
    (Varying.fromStream (Err Http.Timeout) results)

In particular Varying.fromStream seems confusing: why do I need to combine a Stream with a constant value to get a Varying? Surely the Stream already varied before I did that, and why am I adding a constant value in order to get something that "varies" more than what I had before? "Varying Html" looks kinda cool as a type annotation for main, but the metaphor seems to break down very soon afterward in practice.

I'm hardly in love with this as an alternative, but I do think it's clearer:

main : InitializedStream Html

main =

InitializedStream.map view

(InitializedStream.fromStream (Err Http.Timeout) results)

It's definitely more verbose than I'd like, but I can read that code and immediately understand how InitializedStream and Stream relate to one another. I think Varying is proving problematic for me because this relationship is obscured.

Anyone else feel this way about Varying?

--

[Jeff Smits]

On Mon, Mar 23, 2015 at 3:37 PM, Evan Czaplicki <eva...@gmail.com> wrote:

It seems like our options are Signal, Stream/Varying, or Events/Signal and no one agrees about what is the best combination. To be conservative, we could stick with Signal in 0.15 and then slowly migrate over to different names. I think that's the safe route, but I also think it's a little too cautious.

Since no one can agree on what's best, I think sticking with Signal is the best route for now. Gives us some more time to think it over and find a way back to structured discussion of pros and cons.

[Rintcius Blok]

Do you mean sticking with Signal without Stream or with Stream? I'm still hoping Stream (maybe with another name) will make it in 0.15, since the split makes a lot of sense to me. I think you explained it quite nice here . If you mean without Stream then I'm not sure how e.g Port would be defined (maybe I look at it in the wrong way but a Signal doesn't seem right to be part of a Port)

[Jeff Smits]

I presumed Evan would have a way to define stuff when we stick with Signal.

--

[dedo]

EventStream


and

Property

... are the names used by bacon.js, they work for me.

I do not like 

Varying Html

... and to me either

Property Html

 or

Dynamic Html

 would be better.

[Evan Czaplicki]

I have shared an idea for minimally invasive changes that let us do what we want. I have also tried to break down all the pros and cons of the approaches we've thought of.

If we want to continue discussing this stuff, we should do it in a structured way that outlines pros/cons and does meaningful comparisons between approaches.

The meta point dedo is making is "what happens if we compare to all the other reactive things out there?" which I don't think we have explicitly discussed on the list.

• I considered Property before Varying, but I thought it was pretty bad. Like 90 different things are called properties (CSS properties, object properties, algebraic properties, real-estate properties, etc.) and I suspect people like it in bacon.js because they have used bacon.js. Similarly, I suspect a lot of the "I don't like Varying" is about the fact that we all already know the concept of "Signal".
• "Dynamic" is interesting to me, I don't think I've heard that suggestion before. It makes me think of dynamic typing a bit, like in C#, but maybe that direction is good.
  

My personal plan for proceeding is to write up documentation for a couple different versions and see which works the best. This worked well for Promise/Command/Task so maybe it'll work here.

[Jeff Smits]

Sounds good. I don't want to write off this distinction between Stream and Varying as a bad idea. I think it's great.
It looks like it's mostly* a naming issue, and this community can to agonise over names ad absurdum :)

* Some reservations are about ease of learning the one Signal concept over the two distinct but related Stream and Varying concepts, but the split can be defended with data like how many peoples were/are confused over the exact semantics of foldp, initialising ports, asking of a signal that fires once at program start, etc.