[plt-scheme] units and macros (unit/lang ?)

From: John Clements (clements at brinckerhoff.org)
Date: Sat Nov 22 18:19:45 EST 2003

On Thursday, Nov 20, 2003, at 21:29 US/Eastern, Daniel Mahler wrote:

>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>
> The problem is that I want pluggable components, not harwired ones.
> I am thinking of dsomething like a monad transformer framework,
> with a pttern like:

Here are two unsatisfactory answers:

1) Do you really need to "hot-swap"?  That is, if you broaden your 
evaluation model to encompass the IDE, you can "re-plug" just by 
changing the module reference.  In fact, you can do a wee bit better 
than this if you abstract over the change to the code and concomitant 
recompilation, as DrScheme allows you to do (not painlessly, but it 
should be possible).

Okay, that was somewhat unsatisfactory.  Here's another one.

2) separate the "macro" part out of bind.  That is, provide a single 
'bind' macro which, say, thunks both its arguments and expands 
(unhygienically, of course...) into a call to, say, 
'bind-implementation', which is provided by the currently-plugged unit.

Honestly, I think #1 is definitely the one I would choose.

Perhaps there's a more palatable #3... but the basic issue is that you 
can't expand the code until you know what the macros are.  That is, if 
you allow arbitrary macros to be supplied at runtime, there's not much 
work you can do before runtime, and you're essentially just using 
'eval'.

Perhaps this could be made to work if you could know in advance which 
identifiers were going to be bound to macros (definitely possible), and 
somehow constrain the shapes of those macros.  For instance, the 'bind' 
macro promises not to introduce any new identifiers or expand into a 
definition.  Something like that.  That's pure speculation on my part, 
though.

john



Posted on the users mailing list.