On 12/13/06, Taral <[EMAIL PROTECTED]> wrote:
On 12/13/06, Alfonso Acosta <[EMAIL PROTECTED]> 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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to