WIP: Claims and Wishes

[paulsonnentag]

After my visit to Dynamicland I was very inspired by all the cool things they have beyond what Paper Programs currently offers, most importantly the claims and wishes system. I've decided to implement my own version of that I've called it FactLog. I would like to get your feedback about it.

How the Claims and Wishes system works in Dynamicland

@osnr wrote a great blog post explaining his GeoKit project, you should definitely read it to get a more in depth introduction to how the claims and wishes system works in dynamicland.

Here is the short cheat sheet:

FactLog in PaperPrograms

I've tried to emulate the syntax in Dynamicland with JavaScript, this is what it looks like. If you want to see some real examples you should look at the "/client/projector/core" folder or the bouncy example

Wish

Wish `${you} is labelled ${'quack'}` ;

Claim

Claim `${you} is a ${'duck'}` ;

When

When `{a} is a ${'airplane'}, 
             {a} points ${'down'} at {p}` (({ p }) => {

  Wish `${p} is labelled ${'it\'s a bird!'}`
})

Changes

• the programs all run in the same context instead of the

  • disadvantages:
    • harder to deal with error messages
    • programs with inifinite loops can crash the projector
  • advantages:
    • no message passing overhead
    • easy to implement core functionality in papers (example: canvas paper)

• improve developer experience in editor (this part is still very buggy)

  • replaced monaco with codemirror because of better documentation I mostly switched because I wanted to have inline widgets https://codemirror.net/doc/manual.html#addLineWidget
  • inline logging, display latest value of expression inline. Example:

    var value = 123
    log(value) // 123

  • display number of matches inline for whens

This is still a work in progress, there are a lot of ugly hacks and the setup crashes sometimes.

[shaunlebron]

I've actually been working on this for my own edification the past few months—and it looks very similar to this. It was a lot of work, but I just don't feel comfortable releasing it. I guess we should talk about it again though.

Previous discussion on problems with implementing Realtalk. @janpaul123 said:

Implementing something Realtalk-esque might be going a bit too far.

[paulsonnentag]

I've reached out to @osnr to get in contact with the people at Dynamicland. I think it's a good idea to have a dialog but I don't think it's a good idea to build a completely different system in Paper Programs just for the sake of doing things differently. I think the Claims and Wishes systems is very powerfull and there is still a lot of room for experimentation.

Some examples of things I would like to experiment which are different from the current version of Dynamicland (at least to my knowledge) :

• Have the ability to do queries over time in the spirit of elephant 2000

  For example: If I want to use a marker to leave a line trace as I move it around I could write something like this

  When `${you} has {marker}` () => {
     WithAll `${marker} has {position}, at point in time {t}` (matches) => {
            const points = matches.map(({point}) => point)
            Wish `${you} has illumination ${Ill.path({points, color: 'red'})}`
     } 
  }

• Experiment with different editors. Instead of looking at the source allow users to build things by looking at the current claims that have been made about a paper and create whens from turning claims into querries by replacing specific values with variables. This could be a block based graphical interface (ideally with actual physical blocks)

  For example: You have the paper 123 with the following claims

• {123} has width {100}

• {123} has height {200}

• {123} has center point {{x: 50, y: 150}}

You can pull out the claim '{123} has center point {{x: 50, y: 150}}' and replace the specific value '123' with a variable to get all things which have a center point.

I have a tremendous amount of respect for Bret Victor and his team for the work they have done. But unfortunately I'm not close to Oakland so contributing to Dynamicland directly is not an option for me.

A more specific question for you @shaunlebron: Have you implemented ToKnowWhens?

[janpaul123]

I've reached out to @osnr to get in contact with the people at Dynamicland. I think it's a good idea to have a dialog but I don't think it's a good idea to build a completely different system in Paper Programs just for the sake of doing things differently. I think the Claims and Wishes systems is very powerfull and there is still a lot of room for experimentation.

Thanks for reopening this conversation, and working on this! It would be good to talk to @osnr as I haven't really been in touch with the Dynamicland folks lately, since I've been focusing on my job more instead. I'd be personally comfortable with implementing things like this now that they've secured some funding again, which means that Paper Programs is not an existential threat. But definitely check with them to see if they have any suggestions or concerns.

I like the overall approach you took here. Keeping it true to JS syntax is nice for sure, though it is a bit of a weird syntax. 😄 I'll let you know if I get any ideas.

Let me know when you want me to have a deeper look at the source code!

[janpaul123]

And also curious about your implementation @shaunlebron!

[cesmoak]

A couple thoughts on the implementation:

1. Should we have syntactic sugar for something like an "else" clause for queries? Specifically, several times I have wanted the ability to say "when a query returns no results..." This can currently be done with WithAll and a check for no matches. This could be a simple change to the existing When query to add a second callback for this case.
2. Having written a bit of code using this current implementation, I found myself writing {value} when I intended to write ${value} fairly frequently. Syntax highlighting typically saved me. I wonder if the syntax should be different for query variables, using a different kind of bracket (e.g., (value)), or requiring a different starting character (e.g., *{value} or ?{value}) to better clarify the difference in meaning.

Notes for future documentation:

1. It was not clear to me until I read the code that facts (claim/wish) made in frame 1 were only then available to queries (when/withall) in frame 2. This makes sense, but should be documented in any kind of tutorial that is eventually made.
2. It should be made clear that the same fact made multiple times (with the same values or different) adds to the database, instead of replacing or being discarded.