cassowarii/alma

poetic concatenative programming language

alma's Issues

Closures can't nest

Currently, the code

func bind: -> a b [ [ + a b ] ].
func main: apply apply bind 6 4.

hits an assertion violation rather than returning 10 as it is supposed to. This is because the compiler currently assumes that if a block doesn't use any free variables directly, it's therefore "safe" and doesn't need to save its closure. But this is false, because even if a block doesn't have any free variable names directly inside it, it might contain blocks or functions or something that do contain free variables. So I've gotta be more careful in checking that.

in interactive mode, need to keep use-functions around until the end

this would fix the double-free/memory leaking problem when we free the User Func Registry, and also would make it not crash when trying to call a let-function from a previous line. consider this failure:

-- alma v0.1 ‘Worker Bee’ --
alma> use func x: 3 ; in [x]
	stack: [ x ]
alma> apply
alma: eval.c:82: eval_node: Assertion `node->type != word_node && "word-node in eval stage"' failed.
zsh: abort (core dumped)  ./alma

this can probably be fixed by saving the functions created by use. not sure why they aren't being saved, tho??

fix error spew on syntax error

some of the bison code gets really confused when there was a prior error and prints out "this shouldn't happen" messages, etc., which looks bad. should probably figure this out

Add another compiler pass to fix free-var levels

As of now, it (accidentally) assumes that functions yet-to-be-declared have a free var index of 0 (i.e. they always have free variables.) This is... fine, since there's nothing wrong with saving an extra closure that we don't actually need, but it'd be nice to check named-func free-variable-indices in a separate pass after they've all been declared, so we don't waste cycles on saving stuff we don't need.

interactive mode

right now, interactive mode doesn't work because reentrant flex/bison is freakin' terrible. would be good to eventually get something working though.

(idea: rewrite the whole parser by hand?? alma grammar isn't that complicated (there are like 4 discrete constructs), and it would allow doing some slightly-more-complicated things with the grammar... hmm)

Named functions need closures too

Consider the following contrived example:

func problem: -> a (let func f: a. in [f]).

At present, this doesn't work right because only blocks can create closures, but sometimes variables can be closed over in named functions too as above.

Calling a function shouldn't pass the current varbuffer

Right now, when eval finds a func_node, it calls it with the current varbuffer. but this makes the function's arguments go all screwy:

func f x: print x.
func g y: f + 1 y.
func main: g 3.

will print 3, not the expected 4.