panglesd's comments

Very cool!

Does it replace identical expressions in the same scope? Like:

    let tau = 3.14 +. 3.14

becomes

    let pi = 3.14
    let tau = pi +. pi

?

EDIT: Or even crazier with function:

    let _ = (x + 1) + (y + 1)

becomes

    let plus_one a = a + 1
    let _ = (plus_one x) + (plus_one y)

(I ask this just out of curiosity. Even the "simpler" version is very impressive!)

Interesting experiment.

Would love to see a multiplayer version of this game!

Maybe you are interested in slipshow: https://github.com/panglesd/slipshow/

Good question :) Many reasons, I could make a blog post about it!

First, let me start with the biggest drawback of using OCaml: it might prevent potential contributors from making contributions. That is very sad!

However, OCaml is the language I know the most. I use it at work and I'm very very satisfied with it. It's main strengths for me are its type system for maintainability, the tools around it (the lsp server, the build system dune, the autoformatter ocamlformat, ...) and the fact that it can compiles to Javascript! It also has some libraries of very high quality.

With a "single" codebase, leveraging the javascript ecosystem, I could make the compiler work as a statically linked binary, as a node script published on npm, inside a Tauri app, and inside a VSCode plugin. ("single" codebase in quote since I needed some specific code for each application, but the core logic is shared.)

For sure, the same could have been made with another language, but I knew OCaml, and knew I would have a pleasant experience using it for that.

(I even plan to rewrite the engine in OCaml. The engine was written in javascript quite quickly, at a time when I had no experience with largish projects. It is now very difficult to maintain and extend.)

Markdeep seems great!

Having modifiable source inside the html is a great idea. I'll still need to have a compile workflow to add image while keeping a standalone produced html file (and some other feature such as live-preview), but I'll definitely add this as a possible workflow.

Yes, that is exactly right!

This is one important thing for me: the produced file must be self contained. Even if images are included, they are embedded in the html file.

Thanks for the link, and the idea! Definitely a github action to automatically publish your Slipshow presentation on push would be a great workflow! (I'll open an issue for that!)

Yes, clearly this is not for every usecase.

I think math lectures often need quite some text support, they are the reason I created Slipshow.

Very cool! I had never seen something like that!

Sometimes, I used the analogy of a big papyrus roll (like this one: https://pgi-shop.de/en/papyrus-roll-20-x-80-double/) to explain what is Slipshow. But your analogy is much better!

I don't know Miro or Figjam very well, but I would say that:

- You can write a Slipshow presentation in Markdown, which can be more convenient than in those collaborative whiteboards (depending on the person): the source file is plain text. - Slipshow is made for presentations, so it is themed for that: the usual ratio for the screen, blocks such as example/theorem/definition, titles, ... - It is easy in Slipshow to reveal new content/go to a new position by simply pressing the "right arrow" key. - The output from Slipshow is a single file that you can view offline, send to your audience, ...

There might be more differences. For sure, those tools are different and adapted to a purpose, or a style of presenting. For some kind of presentations, Miro and Figjam might be much better than Slipshow!