On Fri, Apr 4, 2014 at 12:54 PM, david j <[email protected]> wrote: > Agreed. I can see the purpose of a first-class debugger+reflection API, > for supervisor meta-software or library introspection tools... >
Having written a couple of commercial debuggers, I disagree. Yes, you need mechanisms by which debuggers can examine data and (in some cases) inject code. Debuggers are relatively special-purpose tools. If that's the main application, the APIs don't need to be either pleasant or high-level. But the main point is that the APIs are made available to the *controlling* program, not the *subject* program. That is: we neither expect nor want a program to have the authority to debug or modify *itself*. I do think there is a distinct lack of proper first-class compile time > metaprogramming facilities in languages (something more like in D or > Nemerle). For example, sometimes I'll workaround Java/C#'s lack of > compile-time-metaprogramming by using reflection -- but only because it's > simpler than adding and supporting a code-generator program to the build. > Let me give a counter-example to this that I'm adapting from Engler's work on tick-c. Think about loop unrolling. The loop bound is often a run-time constant. The compiler knows what unrollings are feasible, but it cannot choose the right one until runtime. The tick-c idea is that it should instead (statically) emit code that (dynamically) emits the appropriately unrolled loop and then executes it. Think of this as one form of continuous compilation. It's empirically useful. As with debugging, this is a very specialized API that need not be available to the application. In this case, the invoker of the API is the compiler's runtime component, not the application. Unlike debugging, this one is a slippery slope, because the API is available to code that is executing at runtime. The distinction between "runtime code for the compiler" and "runtime code for the application" seems like one that *may* turn out to be hard to track, and therefore may become prone to abuse. It may be better to view this as something we want to add support for in the bytecode language and then view as a JIT problem. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
