[plt-scheme] code organization question

From: Yoav Goldberg (yoav.goldberg at gmail.com)
Date: Mon Oct 17 19:27:54 EDT 2005

Thanks for all the pointers! I'm familiar with some of them, and will
eagerly read the rest.

> Maybe there is a design alternative Yoav could try in MzScheme following
> the idea of 'psuedo' contructors as the user level interface to the
> sound type rather than proper constructors. Library implementers would
> then provide an implementation of the pseudo constructors for their
> particular sound type.
Could you elaborate on that one please? What are these
'pseudo-constructors' you talk about?

My problem with the "sound" type is that it can contain several types
at the same slot, and so having a "builtin" default constructor seems
At the rest of my code, I use default constructors rather intensively,
for example, formally, a "tonal-pitch" is constructed with:
      (make-diatonic-pitch 'A)
      (make-pitch-alteration 'bb))
  (make-octave 4))
Which is really cumbersome, but since a tonal pitch is always made of
a pitch-class and and octave, and since pitch-class is always made of
diatonic-pitch and pitch-alteration, I arranged the constructors so I
can just use (make-pitch (make-pitch-class 'A 'bb) 4) or even
(make-pitch '(A bb) 4) , and they will just work (I chose those lists
and not just text strings, because I don't need to parse them, and I
can let each constructor just worry about it direct components, and
let it work recursively). But this doesn't work with the "sound" type,
as I don't know which "pitch" it will be fed.

I considered using PLT's "units" for this, but I found the
documentation for it to be very sparse, and read that this system is
going to be changed soon, so I'm a little skeptic about using it.
Could anyone from the PLT team elaborate on the status of "unit.ss"?
Is it really what I should be using here? When is the code going to be
changed, and how backward compatible it will be?


Posted on the users mailing list.