Hi, nice project! Datalog/prolog-like facts+rules is a great way to work with data, web-based notebooks are an ideal experience for exploring and sharing it, and I've been interested in trying out svelte + tailwindcss, so your project is surprisingly synchronous for me. Thank you for sharing it!

While exploring the project I noticed a couple small things so I fixed them and put them in separate commits for you to review:

Smaller one first: I factored the divider buttons to generate from a list. This should make it easier to add/remove buttons for new types of cells in the future and I think it's a tiny bit easier to read (also maybe an opportunity to generate from centrally registered cell types in some future version?). This is my first time using Svelte so I wanted to poke some (very!) minor low-hanging fruit first. 😸 Note that I moved the <hr> to the bottom of the div to reproduce identical button classes with :not(:first-child); I believe the result is the same.

Second, I noticed that you had to be unusually precise to trigger the opacity hover in order to see the divider buttons, in fact I was confused for a few minutes trying to figure out how to add new cells before I discovered that you just have to hover in the right place. So I adjusted the styles to make the divider hover target easier to activate, specifically:

• Remove CellDivider h-2 so the div takes up the whole space between cells
• Remove margin on Cells
• Use negative margin on divider to slightly overlap neighboring cells' padding. Keeps both compact spacing and easy hover target.
• Increase divider z-index so the overlap works correctly

With some added borders to visualize, before:

Here you can see that you have to hover the buttons directly or that tiny sliver around the <hr> for the buttons to become visible.

After:

Now, hovering anywhere on the overlapped area triggers the hover effect of the divider which makes it much easier to find. I checked and none of the regular cells use this area so this change shouldn't impede their functionality. This does have a small effect on the vertical spacing of neighboring cells (3% taller based on the screenshots), but it is not very noticeable and worth the UX imo.

I'm sorry for writing so many words for such a small PR but I don't have time to make it shorter, please forgive me! 😅🙏 What do you think?

Steps to reproduce:

1. Create a code cell.
2. Write invalid code, such as: 1, 2, 3. The code block is highlighted in orange.
3. Click the down arrow to toggle the visibility of the code block, rendering it not visible.
4. Click the right arrow to toggle visibility of the code block, rendering it visible.
5. The code block is empty, while expected to contain 1, 2, 3.

I will finish the tutorial and fill in the missing section with more complex data analyses, as well as nicer examples of data visualizations using Observable Plot.

This starter notebook will be finished when I have time, and I'll advertise the project after that.

See also: #5.

(It would also be good to write a "How it works" section to the README explaining the Rust Datalog compilation and reactive WebAssembly components + Web Workers.)

Right now, the Percival compiler simply parses inputs as a character stream with parser combinators. Although this is simple and was sufficient for the purposes of the basic language, some error messages are a little bit suspect, especially ones that mention "expected ... in input." For example, the error below is misleading. It should suggest either an import, rule, or end-of-file.

By switching to a two-phase lexical and syntactic analysis step on a stream of tokens, rather than characters, the parser will be much more flexible, while also having clearer error messages.

Previously, I was using a hack in runtime.ts, adding some lines that were necessary because certain libraries were not present in the non-worker bundle. This makes tests get confused because they discover the libraries mid-execution and reload the page, breaking Puppeteer.

By updating the optimizeDeps config option of Vite, I can tell Vite which entry points to crawl for pre-bundled dependencies at boot time, avoiding this reloading issue entirely.

I would love to run Datalog on my phone. This requires some small tweaks to the current UI:

• [ ] Make all elements visible without hovering for mobile devices (or for all devices?). This includes the gutter and buttons.
• [ ] Add a "run code" button. Shift + enter doesn't work on mobile; even if it did, a "run" button would be more convenient.

I suspect this is something rather obvious to someone more familiar with the JavaScript build tools:

when running npm run dev.

npm run serve allows cell execution (as expected) -- I'm not exactly sure why this throws during dev.

Orient sidebar buttons vertically, as described in https://github.com/ekzhang/percival/pull/16#issuecomment-1120137337. This will conflict with 16; that PR should probably be merged first and I'll rebase this one on top of it after.

Changes:

• Orient buttons vertically, with the chevron in the top right corner. This makes it easier to add more buttons, and also makes the buttons clickable on mobile.
• Adjust the spacing of the sidebar and Notebook so that the sidebar and buttons are always visible, even with a very narrow view. It's a tiny bit off-center at this width but worth actually being able to interact with the UI.
• Add small border to the right of the sidebar, visible on cell hover, and small cell padding left to space it. This makes it easier to see which input and output views are part of the same cell; this was visually confusing at first and will get worse as we add more views to cells.
• Remove FaChevronDown in favor of a conditional rotate-90 transform class when the input is shown. Combined with transition-all this nicely animates the chevron when you click on the sidebar.
• Only show delete button when input is visible, this helps prevent taps on the invisible delete button on mobile (for closed cells at least), and works around an issue on closed markdown cells with one line where the delete button sticks out below the bottom of the sidebar.
• Adjust the positioning calculation of the sidebar so that the left side reaches just to the edge of the view, not far past. This will make it easier to position items in the sidebar in general, and covers the case where the page is very zoomed out and 2000px is not enough. Generally this is minor but feels more 'correct' to me.

This PR updates Plot cells to work as more fully-featured JS cells.

• Plot cells can take multiple input dependencies: (dep1, dep2) => ... or no inputs, () => ....
• Plot cells can be async, allowing them to access modules with await import(...): async dep => (await import('https://esm.sh/...'))(dep).
• Plot cells can write a reactive result, using assignment syntax: resultName = () => [{ x: 1 }, { x: 2 }]. Currently this emits one relation, not a set of relations like code cells. A future change could use syntax like { table1, table2 } = () => ... to emit multiple relation outputs.
• Cell outputs with outerHTML are rendered as HTML (as before). Array outputs are rendered as relations. Otherwise, the output is rendered as JSON. If #16 is merged, I'll replace the simple JSON renderer with the JSON tree inspector used there.

After these changes "plot" vs "code" seem like misnomers - perhaps we should rename these concepts to "datalog" and "js". However, that's a bigger policy/design change.

Percival makes Datalog so much more accessible! Now instead of needing to pick an implementation, install it, read the manual, figure out syntax highlighting in your editor, etc etc etc - we can just visit https://percival.ink. There's a bunch of examples, syntax highlighting, and a quick syntax to fetch data. That's great.

But though you've broken the barrier to access a Datalog implementation, there's more we can do to make Datalog useable.

1. Bring JS into the Percival notebook: We should add JS code blocks that can consume relations and emit new data to the DAG. This will allow learners to use Percival for analysis even if they're Datalog beginners. The user can attempt analysis in Datalog, and bail out to JS if they hit a roadblock. As they gain fluency, users gradually transition to Datalog.

   If we allow cells to return Promise, Percival becomes end-user extendable via ES6 modules. We can now import anything from NPM - not just CSV & JSON data.

   The simplest implementation of this idea would be to parse plot cells of the form output_name = (more, than, one, arg) => ....

2. Bring Datalog rules out of Percival into the wider JS world: publish percival-wasm and/or src/lib/** as experimental packages on NPM. Advanced users can build on top of the work here incentivizes further contribution. The risk of publishing to NPM a backwards compatibility burden. But, given the niche nature of Datalog today, I don't expect this to be a substantial issue if we publish using alpha tags like 0.0.0-alpha001

For both (1) and (2), I'm personally excited to explore integrating Percival <--> ObservableHQ.

• We use Plot already. We could also use @observablehq/inspector and @observablehq/stdlib in plot/JS code blocks.
• Observable's runtime is open source. We could investigate replacing the notebook toposort engine with @observablehq/runtime. This could allow importing Observable notebooks into Percival.
• If we publish runtime.build to NPM, we can import Percival and run datalog within ObservableHQ notebooks. But, we won't have syntax highlighting :(

I think it would be neat to be able to load, save, edit, and commit percival files directly against a git repo.

Something like isomorphic-git could be useful here:

https://github.com/isomorphic-git/isomorphic-git

It seems there are some potential complications to supporting a git workflow, especially related to CORS.

Thoughts?