Once a programming language exposes a Turing complete macro system, the need arises for a Smalltalk-like meta-object protocol so that nested macros can negotiate with each other and the compiler itself. This is where things get tricky.
-
Show this thread
-
Replying to @TimSweeneyEpic
i have such a system, and i don't know what you are talking about
1 reply 0 retweets 0 likes -
Replying to @paniq @TimSweeneyEpic
there should be no need for nested macros to "negotiate with each other"; each macro should be treated as a black box, a builtin abstraction.
1 reply 0 retweets 0 likes -
Replying to @paniq @TimSweeneyEpic
furthermore, macros should, whenever possible, be designed to avoid cyclic dependencies, especially when loosely coupled. this produces dependency trees which are easy to understand.
1 reply 0 retweets 0 likes -
Replying to @paniq
Take the C++ generative programming proposal for example. I want to define a new class-like thing uberclass {..} which builds in support for garbage collection. It's not enough to traverse just the syntax inside ..; I need to get metadata about types, so I can wrap them.
3 replies 0 retweets 1 like -
Replying to @TimSweeneyEpic
i see. but the type system and the (classical) macro system are two different things. macros are expanded during syntax tree generation, and at that point, types are not known yet. macros can however generate template declarations and functions which cover type dependent tasks
2 replies 0 retweets 0 likes -
Replying to @paniq
Even with macros being functions from syntax to syntax, they often need to interact locally with the compiler as they're running, for example to determine the scope of a name, or the type of a declared variable. Especially in an open world context.
1 reply 0 retweets 0 likes -
Replying to @TimSweeneyEpic
but if macros already depend on partial evaluation, that completely distorts what macros are supposed to be; all they are supposed to do is to extend syntax - all introspective work should be handed off to templates.
1 reply 0 retweets 2 likes -
Replying to @paniq @TimSweeneyEpic
perhaps i'm a bit old-fashioned for insisting on distinct bauhaus-style translation stages, i don't know. i fear the potential for an organic mess that produces constant misunderstandings and edge cases.
1 reply 0 retweets 2 likes
Stages? I had to merge lexing and parsing to support markup. I had to merge typechecking and evaluation to support dependent types, and now macro evaluation is merged in there too. So there are only 2 stages between text and abstract interpretation.
-
-
Replying to @TimSweeneyEpic
sure, lexing and parsing are also one pass in my system, but they're still clearly hierarchically separated; there's no backchannel from the parser to the lexer.
1 reply 0 retweets 0 likes -
Replying to @paniq @TimSweeneyEpic
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.
1 reply 0 retweets 0 likes - 12 more replies
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.