display-once semantics intended? about owlet HOT 3 OPEN

I'm having a hard time finding where in the code it enforces this display-once semantics. For example,

val myString = string("mystring,"")
val myString2 = myString
val both = myString &> mystring2
render(both,..)

This will only will render the myString component once which means that (rightfully so) it treats myString2 as identical to myString and therefore seems to ignore one of them?

In other words, it seems that myString &> myString2 is equivalent to myString &> myString and that therefore the &> operation is idempotent?

from owlet.

Yes it is intended.

An Owlet is actually a bifunctor, but you can only map on the right value(signal), left (node) map is always identity, so the actual value of node never change no matter how many times you map it.

The other way of thinking is imagine using spreadsheet

You create an input in a1 cell
and than create an a2, it's value is fx=a1

In the spreadsheet you only got one input box a1, a2 is output fx cell not input

Not sure if it make sense to you?

from owlet.

Yes, it makes sense now that you mention that Owlet (at least how it is currently implemented) is a bifunctor. However, let's think about this for a bit:

output(a) &> output(a) behave as expected in the sense that the Owlet a is displayed twice. My argument is that there should be a similar notion of, for example, input(a) &> input(a) where the ability to change value associated with Owlet a is available at two places on the page. Of course to prevent errors/race-conditions and such, the user should only be able to ever actually interact with one of the inputs at a time (e.g. if the user interacts with the first one, then the 2nd one is perhaps "disabled" or maybe (temporarily) switches its rendering to something more akin to output(a) until the user has finished interacting with the input.

In other words if we could come up with a clever way to add a function input(..) then we can still preserve the semantics of the spreadsheet model like you are envisioning while opening up the possibility of the value being "editable" in more than one location (for example, across a network boundary!?). The library would hide the complexities around the race conditions associated with the user editing the value in more than one place (e.g. it would ensure that only the most recent edit "wins" in the case of a synchronous local computation, or uses some other consensus mechanism in the case of an asynchronous one across a network boundary or something -- details on this front could actually be pluggable I think).

I hope the intuition as to why this would be useful is beginning to come across? If not, I'll try to come up with a more concrete example.

Bottom line: spreadsheet programming where all the components are on the same page is neat, but spreadsheet programming where (some of) the components are spread out across the network/internet (if possible) is "really neat" to think about :-)

from owlet.