[racket] CoreMIDI bindings

From: Ryan Culpepper (ryanc at ccs.neu.edu)
Date: Wed Jul 21 17:12:28 EDT 2010

On 07/21/2010 02:43 PM, Evan Hanson wrote:
> Makes sense. That's nice flexibility for module users.
> 
> Out of curiosity, how dynamic are module names? Can they be
> manipulated? Say you had two modules that each provide a function
> "connect". You would load them as mod1:connect and mod2:connect using
> prefix-in -- how might one design a form that would associate a call
> to connect inside a passed expression to a given module?
> 
> (define (within-module module-name fun)
>   (module-associate module-name fun) ... )
> 
> (within-module mod1:
>   (lambda (...)
>     (connect arg arg arg) ... )) ; --> equates to (mod1:connect ...)
> 
> This is miles from how it would work, I'm sure, but is it possible?

To a first approximation, module linkage is static, and programs don't
manipulate modules dynamically. (That's not entirely true, of course.
Racket has reflection, but your example doesn't sound like a good use
for it.)

There are a couple idioms that might be what you want, depending on who
does the choosing and how much code the choice affects.

1) Create a "dispatcher" procedure that decides which one to call based
on its arguments:

  (require (prefix-in mod1: "mod1.rkt")
           (prefix-in mod2: "mod2.rkt"))

  (define (connect which arg1 arg2)
    (cond [(eq? which 'mod1) (mod1:connect arg1 arg2)]
          [(eq? which 'mod2) (mod2:connect arg1 arg2)]
          [else (error 'connect "huh?")]))

2) Use a "parameter":

  (define current-connect (make-parameter mod1:connect))
  (define (connect arg) ((current-connect) arg))

  ;; out here, connect uses mod1:connect
  ...
  (parameterize ((current-connect mod2:connect))
    ;; in here, connect uses mod2:connect
    ...)

3) Use units (dynamically linkable components) to parameterize large
amounts of code over a single choice of implementation.

Ryan


> On Wed, Jul 21, 2010 at 2:45 PM, Todd O'Bryan <toddobryan at gmail.com> wrote:
>>> On Jul 21, 2010, at 2:51 PM, Evan Hanson wrote:
>>>
>>> Also, is this the kind of thing that should be namespaced? In
>>> contrast to other languages where namespacing is used heavily
>>> (sometimes even to a fault), it seems that many scheme libraries
>>> are quite flat. Is this simply left up to the user to manage, or does
>>> the module system take care of this, or is there something else
>>> I'm missing altogether? Forgive the naïveté if this should be clear to
>>
>> One way that name collisions get avoided is the
>>
>> (require (prefix-in pre: "imported-module.rkt"))
>>
>> form. Every name in the module is prefixed with pre: when you use it
>> in your module, so if you have any name collisions or want to remind
>> yourself where something came from, you just give the module an
>> appropriate prefix when you import it in.
>>
>> Todd
>>
> _________________________________________________
>   For list-related administrative tasks:
>   http://lists.racket-lang.org/listinfo/users


Posted on the users mailing list.