Re: [Haskell-cafe] Dynamic types through unsafeCoerce

13 Dec 2006

      On 12/13/06, Taral  wrote:
...
On 12/13/06, Alfonso Acosta  wrote:
...
-- hd and id are (void *) in C and modelled as type parameters in Haskell
data Descriptor id hd =
     Descriptor {uniqueID               :: LadspaIndex,
                          label                  :: String,
                          properties             :: LadspaProperties,
                          name, maker, copyright :: String,
                          portCount              :: LadspaIndex,
                          portDescriptors        :: [PortDescriptor],
                          portNames              :: [String],
                          portRangeHints         :: [PortRangeHint],
                          implementationData     :: id,
                          instantiate            :: Descriptor id hd
-> LadspaIndex ->
                                                   Maybe hd,
...
Oh, LADSPA. Suddenly everything make so much more sense.
I'm glad it does, I probably should have just started a thread asking
for advice for the translation of the struct. It's important to let
people know the source of the problem when asking.

I didn't mention it cause that question was already in HLADSPA's
initial release announcement post
(http://www.mail-archive.com/haskell-cafe@haskell.org/msg17620.html )
and didn't cause any excitement in the list :P.
...
First, the implementationData is useless to you. Put it in a closure
when building this object:
That has been one of doubts from the begining (please check the
message mentioned above)

I decided to leave it, for compatibility with LADSPA (but you might be
right saying that it's useles and should be removed).

Again, I continue saying that the more a binding resembles the
original library, the easier it would be for a developer who is
familiar with the original library to begin using it.
...
ladspa_descriptor = do
    ...
    let implementationData = ...
    return Descriptor { ... referencing implementationData ... }
No need to export that to the user only to have them pass it back in.
Actually the library requires some C wrapping glue code (which does
the memory management, inits GHC's RTS and does the marshalling) so I
can just omit it and fill in in the wrapper with a NULL value.
...
Second, you don't want the consumer to pick the hd type. If you're
willing to accept extensions (I think you are), make it existential:
data Descriptor = forall hd. Descriptor { ... }
This will ensure that you can't pass the handles from one plugin to
the methods of another.
This is exactly how it was implemented in the initial release :)
(please check the HLADSPA announcement for details). The Descriptor
posted here is a naive translation from a C struct