[plt-scheme] code organization question

On Oct 16, 2005, at 7:23 PM, Yoav Goldberg wrote:

> 1/ some kind of a wrapper macro:
> (with-constructors ((pitch: make-pitch) (duration: 
> make-duration-from-wholes))
>      ;; sound making code
> )
>
> 2/ making the various constructors parameters, and make the user set
> them (or use parameterize) after he "require"s sound.
>
> 3/ making sound a unit
>
> I think (1) is a rather lousy option, and tend toward one of the other 
> 2.
> Which do you think is better? Or do you see any option which is better
> altogether?

Your problem suggests the above three solutions plus the parser 
solution. I assume you have considered it and discarded it. You may 
even be thinking that parsing is close to 1).

1. Your problem is one that comes up time and again. Let me ask the 
following:

Will your 'clients' (users are drug users, right? :) of the sound 
module instantiate it several times within the __same__ program? In 
other words, is your 'module' parameterized over pitch and duration? If 
so, you are probably best off using units because this is precisely 
what we created them for.

If these various 'instantiations' do not co-exist, you may still use 
units if there is a lot of mutually recursive linking going on.

2. If the linking is really just concerned with the two constructors, I 
recommend using a higher-order linking protocol with modules. Export a 
function from your module that consumes the pitch and duration params 
and creates the functions that make-sound needs. Of course you are also 
exporting the latter but you won't call it until you have called the 
former.

3. You can avoid some of the syntactic overhead with macros in this 
second approach.

The unit system is indeed in flux but it is not clear when we will 
provide a solution and how compatible it will be with the old one. The 
concepts will be the same and you will benefit from having understood 
the current implementation. But having said that, we have had two 
rounds of discussions internally yet to this day, all we know is that 
it is in flux.

Scott Owens (Utah) is working on this problem under the guidance of 
Matthew with some input from Ryan Culpepper, who is working with me at 
Northeastern. A first hint at what this might look like is in their 
paper at this year's GPCE workshop in Tallinn.

> Also, if you think I'm "getting it all wrong", and you can think of a
> totally different design, please let me know as well.

I don't think you are getting it all wrong. I do thank you for the 
tolerance with which you received all the non-solicited advice on other 
music systems :-)

Hope this helps -- Matthias