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

Thanks, I have been thinking along the #2 lines as fallback option.
I do want the hot swapping [since this is a fun project, I can't
really claim to need it] the whole idea is to have one or two base units
and a whole bunch of transformers, which export (a superset of) the same interface as
the import but add layers of behaviour to the imported operations.
One can then get a wide variety of behaviours
by different composition orders, and possibly have several
compound-units, all exporting their own version of bind, at the same
time (even option #2 only allows one dynamically
composed bind macro at any one time).
I did a purely function based version of this some time ago
and it worked rather nicely, but some of the syntax started to look
rather baroque, and macros would have cleaned it up a lot.
Some PLT papers from a few years ago suggested ther was some research
on getting macros and units to play nice with each other.

thanks
D

John Clements writes:
 > 
 > 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
 >