robotlolita / furipota

(unmaintained) A discrete FRP DSL for describing better build pipelines.

Hi, I'm Quil✨

I'm a programmer, artist, writer, and programming language designer.
I love cats, magical girls, pastels, and cute things.

Quil is pronounced as the English letter "Q".
Or /kjuː/ in IPA.

furipota's Issues

Syntax highlighting for common editors

This is blocked until syntax stabilises.

• Emacs
• Vi(m)
• Visual Studio Code
• Atom

Implement Node-style resolution for Furipota modules

Currently we just rebase the path on top of the directory of the module that did the import.

MVP checklist

• Plugins
• Simple types (Text, Number, Boolean, Vector, Record)
• Core library
  • Debugging (trace)
  • File System (files, remove, make-directory, write, read, copy)
  • Core (tap, sequence, from-vector, get, at)
• Running definitions
• Procedures
• Listing available definitions when none is given
• run should take an arbitrary expression

Future syntax changes

• require @ for all option arguments (gets rid of the pesky record issues)
• Remove {}, add Record.empty
• support defining functions in records (less terrible match function)
• spread (...) in vectors
• open x in expr + conflict resolution

Options are not supported in nullary functions

Tests fail on windows because line breaks are different

`(f _ y) x` is interpreted as `f _ y x`

Holes break this.

Update Furipota to use Folktale 2

Folktale 2 breaks a few things in the previous releases. http://folktale.origamitower.com/docs/v2.0.0/migrating/from-early-v2.0.0/

Simplify things by using a CFG-based IR for interpretation

The interpreter is now running the AST directly. This is alright except for the amount of work that is needed to do things when modifying any part of the AST. Moving to a separate IR fixes this as only the compilation passes need to be changed.

(This would also allow implementing tail calls and avoid using JavaScript's stack in the interpreter, so you get a bigger stack for function calls! And optimising the interpretation if necessary later -- it'd be easy to JIT to JavaScript --, though I'm not really worried about that).

---

A better move is to just wait for an implementation of CoreVM then compile to that.

Figure out a safe way of running shell commands cross-platform

Why is Windows such a pain jesus

`f x @ y` only accepts a literal record on `y`

Reimplement on top of Purr

https://github.com/origamitower/purr will make everything much simpler rly

`let` in pattern matching is awkward

Support mutually recursive local definitions (let rec)

Currently let introduces a new scope, so it's not possible to write mutually recursive definitions:

let x = y in
let y = 1 in
x

Will give you a y is not defined error, since y is not in x's scope. The solution for this is to introduce all definitions at the same time (we don't need a rec modifier since all bindings are lazily evaluated anyway):

let x = y
let y = 1
in x