I stumbled upon a problem with the lifetime of `defer` in relation with
quoted expressions.
I'm developing a Scheme-like language where all static code in a function
is a cascade of expressions.
A `do` quote is implemented as a `quote <expr 1..n-1> in <expr n> end`
Thus, at the root of each function there's a single `return <expr>`
statement.
Now, the problem is that all queued invocations of `defer` only fire when
the function is exited - but since `quote-in` is used to denote scope, it
would naturally often be useful to use defer like this:
quote
var x = begin_frame()
defer in end_frame(x)
in
do_stuff_with(x)
-- end_frame(x) is called here
end
of course I could implement my own version of `defer` that rewrites the
expression like this
quote
var x = begin_frame()
var y = do_stuff_with(x)
end_frame(x)
in
y
end
but that means I can't use `defer` at all in my block-free code.
Now, I see that it is important to have a statement-block oriented `defer`
that works the way it does. But I think it would be useful to have an
equivalent `defer` keyword that defers a call until an expression has been
evaluated --
There might be yet another solution to the same problem:
I noticed that `do` blocks evaluate to expressions with the type `{}`.
If there were a keyword analog to `return` that allowed to exit a statement
list with a value, say, like this:
-- prints the value returned by do_stuff_with(x)
print
do
var x = begin_frame()
defer end_frame(x)
doreturn do_stuff_with(x)
-- end_frame(x) is called here
end
then that would allow to use two kinds of expressions-with-statements, one
with defer trigger (defer execute, strong block), one without (defer pass,
weak block).
or perhaps even better, or at least easier: `do` blocks could always infer
their type from the last statement and return that one as their expression
value, if used as such. That behavior should be perfectly backwards
compatible and evaluate to a non-op if `do` is not used as an argument.
Just some thoughts. You probably have better ideas?
Cheers,
Leonard
_______________________________________________
terralang mailing list
terralang@lists.stanford.edu
https://mailman.stanford.edu/mailman/listinfo/terralang
