reflection or types, either/or?
Conversation
this split is so deep that it feels like two separate programmer personalities to me
1
Replying to
I think that's mostly an outcome of programming language designs, what features are made accessible and effective in a given environment.
At intersection, there is stuff like using macros as type systems or vice versa.
ccs.neu.edu/home/stchang/p
1
1
Replying to
The key thing seems to be to allow the feedback loop or not, i.e. keep things staged, or let the system self-modify and update its own semantics.
This shows up in Erlang hot code loading for instance.
1
I ran into this also trying to "unroll" Forth, which is highly reflective and self-modifying, and so was very hard to fit into the Racket staged system.
1
But yeah you're right. This isn't about types per se. It's about updating the interpreter while it is running vs. sticking to a fixed (though multi-staged) semantics.
Replying to
There is another option: a user-defined, multi-staged semantics. This is the direction I'm taking with my Glas language, for example.
When programs are imported as immutable data, the importing module can freely examine, typecheck, rewrite, optimize, etc. the program value.
1
1
Relatedly, if sub-programs are represented as concrete values, then higher-order programs can be distinguished typefully based on whether they directly observe those values vs. just integrate them blindly.
Shifts a concern of 'abstraction' from module system to type system.
1
1
Show replies