Multiple outputs and inputs per cell

[fonsp]

A cell input like:

🍕 = 1
🥞 = 2

should not be legal, because it is not a single expression. This might be unexpected (and part of the learning curve) for new users, and we could accept it without breaking the paradigm by:

• Splitting up the expression into two cells.
• Giving the cell two outputs, which are stacked on top of each other with a clear division between them.

A nice hybrid solution is to do the first option, and to design the editor layout in such a way that all cells fluently follow each other. (If code is folded).

Note:
The cell

🍕 = 1; 🥞 = 2

which is syntactic sugar for

begin
    🍕 = 1
    🥞 = 2
end

is a single expression, which is not an assignment, but an evaluation that performs two global assignments. Parsing this cell should be legal (as a single expression), but running it might give an error (depending on what we decide to do with globals).

[malyvsen]

I don't see a reason why this shouldn't be legal from a paradigmatic point of view. I think this should be equivalent to two cells, one doing x=1, and the other y=2 (no emoji keyboard yet, sorry).
It's not only more intuitive for new users, but also convenient, allowing to eg. bulk show/hide some related statements by showing/hiding a code cell.

[malyvsen]

From a "how do we do this" point of view: I'd have variables rather than cells be the nodes of the dependency graph. Each cell can then execute imperative code; once it's done, the global variables it set are checked for changes, and changes are propagated down the graph.

[fonsp]

Internally splitting it up into two cells is a cool solution! About having the core track variables instead of cells: not all cells define variables - some are just expressions with output, package imports, etc. so you would have to track all of them too. But let's leave this for later?

[malyvsen]

More general then - we should track expressions.
But yes, makes sense to leave this for later, and for now have 1 expression per cell.

[fonsp]

The issue of multiple expression per cell is solved: it is not legal. (To be clear, you can wrap multiple top-level expressions into a single begin ... end or let ... end block.) The question is now how to show a nice error to the user (#39).

We might re-open this one day, by making multiple expressions return multiple outputs.

[jebej]

I'm sure this must have been discussed already, but why not allow multiple lines, and then just do the equivalent of implicitly wrapping in a begin ... end block, instead of having the user do it manually?

This would not require having multiple outputs, and seems to make sense.

[fonsp]

Hey!

This is a good question, it comes up often and I have spent some time thinking about it.

Your suggested solution might be implemented some day, but I'd like to keep the current behaviour for now. The main reason is:

Reactive notebooks work best if you split your code into multiple cells.

For example, if you have a single cell defining 20 parameters for your model, then changing one parameter will cause the re-evaluation of every cell that (indirectly) depends on any parameter. This might be slow, making it less fun to play with your model (disaster!), and it's confusing - you feel like reactivity is not doing what it should do.

Solution

So you should make as many cells as you can! Problem solved? Well not quite, we get the feedback that cells can take up too much vertical space, and is more cumbersome to work with.
I have implemented a lot of features to make this experience better, and I have more plans, notably this one. Already implemented are:

• decreased vertical spacing between cells.
• include the top-level assignee x in the case of x = 123 in the output - Julia only ouputs the value. This way you can hide the code and still see what variable is defined.
• keyboard shortcuts to jump between cells (PageUp and PageDown).
• selecting multiple cells to move/fold/delete them all at once.

Two more arguments

Like I mentioned before, it might be confusing that changing

a = 1
b = 2

to

a = 1
b = 345

will also re-run all cells that depend on a. I feel like explicitly writing those into a single block makes this more clear.

Also, I have a more geeky argument:
Julia is a Lisp - each code block has a value. I think this is really charming, and for this reason, a cell in Pluto is a unit: one cell has one expression, returning one object (hence displaying one thing).

But the main thing is: I want UI to motivate you to split your code into cells - it's still WIP but I think it will be nice.