hello stefan,
out of order:
> i've attached a new version of Sound.SC3.UGen.Record.Pitch, with the
> arguments reordered as to henning's suggestion ...
applied & pushed, thanks.
> what are the namespace issues? shouldn't qualified modules imports
> avoid name clashes?
yes, qualified names help, though i don't think you'd want to have to
write a distinct qualified import for every ugen? (ie. fine if only a
few ugens have records as arguments but problemeatic if all or many
do?)
i was actually thinking though of the 'update' sytax being only
syntax, ie.
data A = A {a :: Int, b :: Int} deriving (Show)
-- cannot write f as:
--f g x n = x { g = n }
-- instead either
f_a x n = x { a = n }
f_b x n = x { b = n }
-- or
data AA = Aa | Ab
f Aa x n = x { a = n }
f Ab x n = x { b = n }
r = A 0 0
t = (f_a (f_b r 2) 1, f Aa (f Ab r 2) 1)
> yes, that's a little shorter. however, for consistency, i'd vote for
> the more explicit `defaults', because a module might export a set of
> different default constructors (like presets).
but you would still have a default 'default', which you could make a
member of the typeclass?
> yes, i agree it's probably only useful for a select number of ugens.
perhaps, certainly it is useful in these cases, but i also think there
are could be interesting alternative ways of structuring the unit
generator constructor functions, & an accurate database would make
experimentation simpler. of course, if the 'input' input signals are
to be treated differently from the 'control' input signals, that is
another layer of information to encode.
regards,
rohan
ps. actually, seeing it written down in that context record seems not
the best name for that sub-tree, since it suggests recording to disk
etc. (and the two meanings record & record are pronounced differently
which is actually what i noticed). unfortunately i don't have a
better suggestion.
_______________________________________________
haskell-art mailing list
haskell-art@lists.lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art
