i too merged typechecking and evaluation into a specializer, but that doesn't invalidate the idea of stages; e.g. the specializer explicitly only instantiates IL instructions, it never generates new IL - because of this, macro expansion is a separate stage before that.
-
-
Replying to @paniq @TimSweeneyEpic
stages are useful - what, for example, if you just want to expand all macros and look at the unspecialized IL? if you do it all in the same stage, you'll have to add unappetizing modes just to support this, if at all - it's possible you can't even do this anymore.
1 reply 0 retweets 0 likes -
Replying to @paniq @TimSweeneyEpic
but! i concealed the fact that it is possible to nest expand, compile & execute stages within the partial evaluator. but they're all separate passes. to merge them into one would make it increasingly difficult to reason about what's happening.
1 reply 0 retweets 0 likes -
Replying to @paniq @TimSweeneyEpic
and! i failed to mention that it is possible for macros to interrogate types of constant values that occur in the expressions they are expanding, as well as create new types at that point. (macros themselves are small compiled routines, so very much like compiler plugins)
1 reply 0 retweets 0 likes -
Replying to @paniq @TimSweeneyEpic
but at the moment the macro expands, the only environment it has is the lexical scope (and all parents), which it can also freely mutate / swap. the partial evaluation stack frame doesn't exist at that point.
1 reply 0 retweets 0 likes -
Replying to @paniq @TimSweeneyEpic
so there's a clear definition of what a macro does: in goes S-expr and lexical scope, out comes generic IL (template functions in CPS style). i don't want programmable IL transforms. it feels like that would be too much.
1 reply 0 retweets 0 likes -
Replying to @paniq @TimSweeneyEpic
there is a bit of cross-macro communication happening but it is either explicitly done via metadata in the expanded expression, or by setting new keys in the lexical scope. both ways are easy to inspect & debug, that was important to me.
1 reply 0 retweets 0 likes -
Replying to @paniq @TimSweeneyEpic
maybe the key question is: how stateful is your system? how much hidden state does it carry? is that hidden state inspectable at compile time, at user level?
1 reply 0 retweets 0 likes -
Replying to @paniq
The whole system is conceptually stateless, but uses a pure-ish notion of futures and refinements, which is necessary to resolve recursive things that occur out-of-order.
1 reply 0 retweets 2 likes -
Replying to @TimSweeneyEpic @paniq
Some challenges arise out of the desire to support open-world programming with strong names and Java-style forward compatibility rules. So, a macro seeing a field reference "x" doesn't yet know what means. Could be Engine::Vector::x, or a local variable x from an outer context.
2 replies 0 retweets 1 like
Other challenges arise from the need to obey Walder-style free theorems / universal properties, as a means of compiler-guaranteed erasure and data hiding. Runtime code can't cheat by asking a type for its metadata; you had to expose it at compile-time via macro.
-
-
Replying to @TimSweeneyEpic @paniq
The grand scheme here is a language with no undefined behavior that can run deterministically in a decentralized environment, where in concept everyone in the world is running and verifying a transactional shared state simulation. (No problem, right?)
1 reply 0 retweets 3 likes -
Replying to @TimSweeneyEpic
right, i remember you wanted to build something like that. i'm not even at the level where i have a need for this. i was pursuing a comparatively trivial goal, simple multi-stage programming (look, "stage" is even in the name!).
0 replies 0 retweets 0 likes
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.