Typed closure conversion

Typed closure conversion is a really lovely explanation of the structure of a closure-converted function. Every closure has its own particular environment structure that binds the particular set of free variables that occur in its body. But this means that if you represent a closure directly as a pair of an environment record and a closed procedure (which is explicitly parameterized over the environment record), then the representations of functions that are supposed to have the same type can end up with incompatible environment types. For example, the program

let val y = 1
in
  if true then
      λx.x+y
  else
      λz.z
end

converts naively to the transparent representation

let val y = 1
in
  if true then
      (λ(env, x).x+#y(env), {y=y})
  else
      (λ(env,z).z, {})
end

The problem here is the type of the environment has leaked information about the internals of the procedure into the external interface. So Minamide et al use existential types as a nice, lightweight type abstraction for hiding the environment layout as an abstract type. So you instead get the opaque representation

let val y = 1
in
  if true then
      pack {y:int} with (λ(env,x).x+#y(env), {y=y})
      as ∃t.((t × int) → int) × t
  else
      pack {} with (λ(env,z).z, {})
      as ∃t.((t × int) → int) × t
end

Update: fixed the types in the existentials-- since I'm using an uncurried representation the argument type is a pair, not an arrow type.

PLT System Facilities (Software Components): Module name resolvers

Because of eval, one program's "compile time" is another program's run-time. Even though they are not first-class, this also applies to PLT Scheme modules, since they too can be dynamically compiled, loaded and linked. As I've described before, namespaces are the general construct for managing multiple instances of modules and maintaining their top-level bindings. But I still haven't described how dynamic invocation of modules happens.

Module loading is managed by the system's module name resolver. The primary responsibility of the module name resolver is to map distinct but equivalent references to modules into canonical forms. For example, it's possible to refer to the PLT Scheme string library with either of the two forms:

(lib "string.ss" "scheme")
scheme/string

The standard module name resolver translates these to an absolute path to the module's source file in the filesystem.

The other responsibilities of the standard module name resolver are:

• to ensure that a module is only loaded once,
• to make sure each module is loaded the first time it is needed, and
• to check for and prevent cyclic loading dependencies between modules.

The module name resolver is a pretty low-level part of the PLT system. For the most part, programmers stick to using dynamic-require to interact with modules dynamically. This dynamically ensures a module is loaded and optionally selects one of its exports by name (by querying its namespace). But the module name resolver is directly accessible and can be dynamically invoked to ensure a module is loaded and resolve its name to canonical form. The module name resolver is even configurable, and can be swapped out with a custom resolver--though I have not seen this done in user code.

Matthew Flatt running for SIGPLAN member-at-large

I like Matthew's statement, so I want to call it out here:

As a SIGPLAN member at large, I would be a voice for those who believe that conferences have become too important relative to journals. Our conferences have taken over the prestige that other disciplines reserve for journals, so that our conferences tend toward more conservative acceptances and more complex reviewing processes (including double-blind submission and author-response periods), which work against the goal of broadcasting new research directions and ambitious new ideas. In comparison, our journal system, which offers the time and expertise needed for the careful review of enduring results, is left under-used and under-supported (especially by paper referees) despite the admirable efforts of journal editors. I have no easy fixes, nor do I think that immediate radical change is appropriate, but I think we should do all we can to nudge the balance back in favor of journals.

Memo to myself: directions for `svn unfail'

Sorry for this-- I keep losing this information so I'm just sticking this note to myself up here. Who knows, if other people run into this it might be of use to them, too.

If you find you're inexplicable being asked to authenticate when doing an svn up and it won't accept your password, (particularly after renaming or moving a file in the repository), here's the solution:

...if "svn up" doesn't work, you can make "svn switch" to the same url, it will update all with no problems.

Dear David Herman

Dear David Herman,

We have the same name. You seem to think you have my gmail address. Periodically I get email intended for you. It may be that you're giving out my address to people--or so I imagine, because every so often, I also get a message from Google saying that someone is initiating the process to reset my password. Naturally, I don't proceed. I don't want to reset my password. I'd prefer you stopped trying to.

I have no particular way of contacting you, because all I know is that your name is my name too, and I think you live in San Francisco (based on your mail that I've received). Which is all the more confusing, given that I spend a lot of time in the Bay Area. But I digress.

Mr. Herman, I'm afraid we can't share this gmail account. You seem to like the version without a dot, whereas I prefer the version with a dot, but either way, Google says it's mine. Sorry. I got there first.

Best regards,
David Herman