[Haskell-cafe] Dynamic types through unsafeCoerce

[Alfonso Acosta]

On 12/13/06, Taral <taralx at gmail.com> wrote:
> On 12/13/06, Alfonso Acosta <alfonso.acosta at gmail.com> 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