Unconditional bind does not behave correctly after running a second time

[nmsmith]

An unconditional bind will "de-bind"/stop working when the code block is run a second time. I've demonstrated the bug here, showing it occurring both on my local server (up-to-date with master) and at play.witheve.com.

This occurs whether you're pressing the run button, or pressing Cmd + Return / Ctrl + Enter.

As shown in the video, the local server and play.witheve.com exhibit different behaviour when ticking and unticking blocks. The website's behaviour is correct. I'm not sure why or how they are different -- perhaps the website is running an older version?

Update: Replacing all the binds with commits results in the correct behaviour on the website, but my local version is unresponsive to ticking and unticking -- all commits just stay visible unless you hit "Reset".

Tested in Chrome and Safari on macOS.

[olafleur]

To answer your question : as far as I can see, the deployed version is not the same as the last commit in master.

[ibdknox]

We're working on getting play.witheve.com updated, so that should be taken care of in the next day or two (just need to make sure our changes all still work in the non-server case).

This happens because right now we've chosen to treat unconditional bind and unconditional commit as things that only happen once. It certainly does seem like that's not really the correct interpretation of bind without a search and it's pretty trivial to adjust that behavior, but it has some broader consequences. Right now, binds and commits are allowed to play in the same space, so if I bind something, then commit over top of it, I will see the committed thing. If we make bind truly unconditional then it becomes impossible to have a block shadow a bind. That may be fine and may in fact be what we want, but it does remove some patterns that seem kind of nice.

For example, if we make binds behave this way universally, the following code will always produce two background colors:

search
  foo = [#foo]
bind @browser
  [#div foo style: [background: "blue"] text: "my cool foo"]

active foos should have a background of red

search
  foo = [#foo #active]
  [#div foo style]
bind @browser
  style.background := "blue"

This certainly reduces the compositional nature of blocks, but it maintains a much simpler base set of semantics around what bind means. It's not clear what the right tradeoff there is, or if there's maybe some other way to think about bind/composition to make a better one.

[ibdknox]

This was also brought up in Puzzles and Paradoxes V

[wtaysom]

Is there a typo in your background color example? I see that "blue" is mentioned twice. As for, "If we make bind truly unconditional then it becomes impossible to have a block shadow a bind." This is actually, exactly what makes sense to me. If you want a relationship that can change over time, use a commit.