From: Sigbjorn Finne <[EMAIL PROTECTED]>
> Lennart Augustsson writes:
> >
> > > I am quite unhappy to see these developments (e.g.,
> > > H/Direct) being based on some proprietary standards, as it
> > > means that they are rather useless to me.
> > I agree!
> >
>
> Mud sticks, so may I suggest you actually take the time to read the
> available docs before passing on such comments publically? For
> instance,
>
> http://www.dcs.gla.ac.uk/fp/software/hdirect/design-1.html
>
> Or is that too much to ask?
No, but actually, it is this very document (plus the one
about Haskell Server), which made me post my comment. The
document that you reference starts as follows:
The wish is to be able to use Haskell as a software
component language. That is, be able to both use and create
software components conveniently using Haskell. H/Direct is
a set of tools and libraries that aims to provide support
for this to the Haskell programmer, and, for now, the
software component technology that we consider is the
Component Object Model (COM).
Although, you continue with
Ideally, it should be possible to substitute COM for any
other component technology. Experience may prove
otherwise, but implementing an interface to one component
technology is a non-trivial amount of work, so, as a
starting point, we're targetting COM.
For me that reads like it works for COM and you do not
exclude that it is possible to rewrite it for another
component technology. And this impression is reinforced by
the next paragraph,
A prerequisite for interfacing to a software component is
some mechanism for communicating what functionality the
component offers. H/Direct makes use of an Interface
Definition Language(IDL) to specify component interfaces,
and provides an IDL compiler that supports both the creation
and use of software components.
There's a couple of IDL flavours around. We're
implementing one that is compatible with the IDL
accepted by the Microsoft IDL compiler (MIDL), a
superset of the IDL defined by OSF's DCE spec.
So, it seems that it works for MIDL and COM, which are
definitely proprietary, and you seem yourself unsure about
how far it is from other standards.
Maybe I just completely misunderstood the cited paragraphs;
in this case, I would happily receive any clarifying
explanation. Your recent posting seems to be to that
effect. You wrote,
> The IDL compiler uses an FFI substrate that allow Haskell
> to call external functions with a C calling interface (or a variation
> thereof), and vice versa, Haskell functions (or closures) can be
> dressed up with a C calling interface. On top of that, we've currently
> got a compiler grokking OSF DCE IDL (which, by my reckoning, is not
> proprietary) extended with a couple of MS ODL declarations to allow
> certain kinds of COM idioms to be specified conveniently. This gives
> us access to COM, which I think is a step in the right direction.
>
> A different front-end would be to support CORBA on top of the FFI (see
> followup I posted yesterday about this) - it's no big deal.
If it is really just ``a couple of MS ODL declarations'',
which are easily replaced with something non-proprietary,
the situation would indeed be quite different from what I
understood from the `H/Direct' document. It might be
helpful to clarify in the `H/Direct' document, how big a
portion of H/Direct relies on proprietary standards and how
big the delta to non-proprietary standards is. For me, it
is still not really clear.
Don't get me wrong, it is great that you are doing all this
work on interfacing and COM; I am just a bit anxious about
the generality of the approach -- from what I read so far.
Cheers,
Manuel
