Basically, I want Jupyter-stype notebooks to be my primary dev environment. The blog goes in that direction, but calling code via
let result = assembly |> extract<string -> Async<unit>> "This.Is.A.Namespace.HelloHost.myFunc"
is just yuck. What I want probably requires language level changes.In a REPL, you're given a buffer to enter text into, and it evaluates it as you submit this buffer.
This is fine if you live in an age before graphical editors, but today we have tools with a better REPL-like experience.
In VS Code, I can use extensions to show realtime values next to every line of my program, and indicators of whether a branch/code path was ever hit.
This allows me to use an entire file as a visual REPL with instant feedback.
Using an actual REPL sucks compared to being able to regularly edit a file in your editor and get all of this + more without being handicapped to a terminal buffer.
Notebooks are also a worse experience for the same reason. You need to manually trigger "cells", which return a single value/visualization, or add a bunch of print statements.
JavaScript:
Python:
https://marketplace.visualstudio.com/items?itemName=xirider....
Scala:
https://scalameta.org/metals/docs/editors/vscode/#worksheets
You can find something like this for most languages, either in VS Code or Jetbrains IDE's
I think the fascination with REPLs, especially in the Python world, is that it allows one to produce flashy web page snippets or Jupiter notebooks that look like work while they are really trivial (there is a similarity here to pg's remark that Java is partly popular because the boilerplate looks like work).
Also, this doesn't really allow for everything else Lisp has that go well with the REPL: conditions and restarts, interactive inspection of values and stack frames, etc.
You're in luck!
https://marketplace.visualstudio.com/items?itemName=ms-dotne...
Works best with Plotly support as well: https://plotly.net
It's not too hard to iterate through all classes/functions/constructs in an assembly and create a cache. Additionally, the generic type parameters can be avoided by adding a parameter that looks like what you want to pull out. I'm on mobile, but you could make a library that does something like (excuse the C# syntax):
Lib.Cache(assembly);
var myFunc = Lib.Pull(myFunc => async (int a, string b) => "");
That could throw an exception if there's a naming conflict and it's not able to find the function with only the name and signature. A second parameter could take part of a namespace/class name in that case. This is pseudo code, but I'm pretty sure I could get something similar up and running.Side note: If anyone is using F# and hiring, shoot me an email!
It's possible but what's wrong with the generic type parameter? It's an unequivocal way of specifying of what type is expected on the other side.
My aim here was different. I wanted to enable extending compiled F# apps with F# scripts. Think of scripts being plugins implementing a specific public interface the hosting app defines.