Faye & Maddy's untitled interactive programming environment

An untitled project for interactive programming, note-taking, sane AI workflows, and whatever else you can dream of, à la Emacs!

unimplemented! (verse-block){:type "verse-block", :affiliated {}, :contents-begin 400, :contents-end 829, :position {:start {:line 9, :column 1, :offset 386}, :end {:line 17, :column 1, :offset 841}}, :children ([:b ("faye")] ": would you be interested in doing a little PL project with me :)\n" [:b ("faye")] ": we would both need to learn a lot i think, but it would be fun.\n" [:b ("madeleine")] ": YESYESYESplease!\n" [:b ("madeleine")] ": what do you have in mind?? }:O\n" [:b ("faye")] ": well, i sort of want to explore what an interactively explorable system like pharo would look like with a type system that provides correctness like haskell's\n" [:b ("madeleine")] ": faye i love you more than life\n")}

file:~/Pictures/wilshire-if-tyler-were-a-lesbian-pl-nerd.png

The big questions

Where does the static end and the living process begin?

What does static analysis even look like in a Pharo/Emacs-like live environment? They feel fundamentally at odds, despite having benefits somewhat disjoint to one another.

Lisp?

Are we making a Lisp? Should we make a Lisp? The kind of introspection that makes for a nice interactive environment is fundamentally quite lispy, as far as I'm thinking. Might be good to look into the oddball lisps such as Dylan. I also need more experience with Smalltalk — might change my perspective here, haha.

Scrapbook

unimplemented! (verse-block){:type "verse-block", :affiliated {}, :contents-begin 1634, :contents-end 1793, :position {:start {:line 32, :column 1, :offset 1620}, :end {:line 36, :column 1, :offset 1805}}, :children ([:b ("faye")] ": i'm wondering how to start breaking the project down\n" [:b ("faye")] ": we should maybe put together a scrapbook of language features and ideaa we really like :)\n")}

Dependent types

Dependent type theory

  • Programs before proofs! No universes, no totality-checking. Dependent-Haskell–style, perhaps a little Idris-style.

  • Types as first-class values genuinely sounds like a good fit for a live, introspecting environment.

"No meaningless states"

  • See Hazel, a live functional programming environment.

  • Just because errors can be spotted statically doesn't mean they should halt compilation.

  • Type errors? Warn, but don't error until evaluation. Unknown identifier? Deal with it later. Etc!!!

Typed holes

  • Facilitates smooth conversation with the type-checker.

Structural editing

Algebraic effects?? Purity???

  • I think MTL-style monads are a no-go.

  • Look into the current state of the art for effects.

  • Emacs' abundant state-sensitivity sucks dick!!

  • Thinking in pure functions is very comfy.

  • Haskell's effectful is a joy to work with, and would be amazingly comfortable in a language developed with effects in mind.

Macros?

Maybe. lol.

Reagent/Humble-inspired UI framework?

Data structures

This is quite basic compared to the other "big ideas," but performant, correct data structures should be incredibly ergonomic. Haskell can be a little annoying, requiring several dependencies and imports just to use hashmaps, maps, vectors, and sets. This is a feature of Clojure that I think is taken for granted; the right thing is deliberately made to be the easiest thing.

See also