Re: [Haskell-cafe] Dynamic types through unsafeCoerce

13 Dec 2006

      On 12/13/06, Taral  wrote:
...
Third, we can split handles out as actual objects now:
This idea resembles how a descriptor is modelled in the last version
of HLADSPA. The difference is that a handle is modelled as a type
class and not a record (see
http://www.student.nada.kth.se/~alfonsoa/HLADSPA/HLADSPA-0.2.1/src/HLADSPA.h...
)
...
data Handle =
    Handle {descriptor :: Descriptor,
            activate :: IO (),
            -- (LadspaIndex,PortData) indicates the portnumber and its data
            run :: LadspaIndex -> [(LadspaIndex,PortData)] -> IO
[(LadspaIndex, PortData)],
            deactivate :: IO (),
            cleanup :: IO (),
           }
I wouldn't quite call this a Handle ... actually it only contains the
functions which operate over a handle (I would better call it
Instance).  It lacks the handle itself (the state passed to, and
possibly altered by, the functions of an instance) and makes the
instance stateless.

e.g. you modified

             run                    :: hd                       ->
                                        LadspaIndex              ->
                                        [(LadspaIndex,PortData)] ->
                                        ([(LadspaIndex,PortData)], hd),

into

             run :: LadspaIndex -> [(LadspaIndex,PortData)] ->
IO[(LadspaIndex, PortData)]

Now the behaviour of run over the input audio doesn't depend on any
state. That state is a must (and that's why handles are used).
Otherwise things such as a delay effect wouldn't be able to remember
how many samples it did process already between calls to run and thus
wouldn't be feasible to implement.
...
Then you'll want helpers that use Control.Exception.bracket ...
Well, I couldn't find that function in hoogle and it's not present at
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception...

But I think that you are suggesting is to leave activate or deactivate
undefined in the record if they are not required. Then it should be
checked wheter they are undefined or not controlling if a exception is
raised when attempting to access them.

I don't see how that is an advantage compared to using Maybe. Actually
Nothing is more expressive than omitting the functions and furthermore
I don't think that leaving record fiedls undefined is a good practice
in general.
...
You can also optionally use cleanup as the finalizer for the
ForeignPtr underlying Handles ...
I don't see what you mean here. I'm not using ForeignPtrs at all.

Re: [Haskell-cafe] Dynamic types through unsafeCoerce

Alfonso Acosta