On 22-Apr-08, at 1:51 AM, Derek Peschel wrote:
On Mon, Apr 14, 2008 at 11:14:26PM -0400, Marc Feeley wrote:
And if you are wondering how the ##car procedure is implemented, then it goes roughly like this:
Why have a ##car Scheme procedure at all, if the calls to ##car in situations like your other example are inlined by the compiler? The only reason I can think of is "so calls to ##car work from procedures without extended bindings".
That's one case, but more importantly it allows you to develop/debug with the interpreter (which does not inline ##car, etc) programs that will eventually be compiled.
If that's the reason, are those calls inlined also? That is, does the extended-bindings declaration cause optimization across procedures?
extended-bindings declares to the compiler: "Trust me, at run time the global variable ##car will contain the procedure ##car". The compiler can ignore such declarations and perform a true function call instead of inlining the procedure ##car (in practice the compiler always inlines, but the point is that the inlining is completely transparent to the user, except for making the program run faster).
About the ## prefix in general, I thought of another question. Which procedures' interfaces (argument number and types) are guaranteed not to change, and which have no guarantee? Obviously standard procedures are constrained by the standard, but there's the rest of the public namespace to consider, the entire ## namespace, and other namespaces (though in practice I doubt people have to worry about them).
There are no guarantees in life! Interfaces have changed over the many releases of Gambit. In general, I try to be as backward compatible as possible. The rule of thumb is: if it is documented, then I will try hard to preserve the same interface in the future (i.e. only interface extensions are done).
Marc