Re: Gnome binding [was: Re: Licenses and Libraries]

[Manuel M. T. Chakravarty]

Havoc Pennington <[EMAIL PROTECTED]> wrote,

> On Wed, 22 Sep 1999, Hannah Schroeter wrote:
> > 
> > Frankly, I'd like it to use Corba from Haskell with ORBit
> > alone rather to have to install much additional Gnome stuff I'm
> > probably not using elsewhere anyway.
> 
> I just joined the list and the archives seem incomplete, so apologies if
> this has been covered. :-)
> 
> The right thing to do is to have Haskell modules for standalone ORBit and
> for GNOME as well. There are two key things in GNOME:
> 
>  - the CORBA spec doesn't establish mechanisms for authenticating 
>connections or finding the name server. GNOME adds "policy" on 
>this which is seperate from ORBit; in practice if you don't 
>use GNOME you have to implement this yourself

Currently, the object invocation is via name services tied
to an X session, but according to a recent message on one of
the Gnome mailing lists, the plan is to move to a more
flexible scheme.  Eventually - I hope - this will allow the
use of the basic Gnome CORBA infrastructure (ie, basically
the Gnorba library) without the rest - which is definitely
useful on say a headless server implementing Gnorba
services.

> ORBit is useful on its own, but the GNOME stuff is nice to have 
> available as an add-on module if you need that functionality.

I'll definitely keep an eye on not introducing additional
dependencies in the Haskell layer - like in the GTK+Haskell
binding, you can import and use the `Gdk' module without the
`Gtk' module.

Manuel

Re: Licenses and Libraries

[Hannah Schroeter]

Hello!

On Fri, Aug 27, 1999 at 09:41:22PM +0900, Manuel M. T. Chakravarty wrote:
> [...]

> > Better make it work with Corba, which is the basement of the IPC used
> > for Gnome, but not only that. For a first touch, one could use the
> > standard C mapping via the GHC FFI (is that implemented in other Haskell
> > implementations?).

> Sure Corba, but you need an ORB and I am thinking of using
> ORBit - thus, GNOME.  I prefer to say GNOME (in a
> non-marketing context), as GNOME implies more than Corba.
> For example, there is the name service in libGNORBA and the
> new document component model called Bonobo (where MS uses
> OLE2 and ActiveX).

Frankly, I'd like it to use Corba from Haskell with ORBit
alone rather to have to install much additional Gnome stuff I'm
probably not using elsewhere anyway.

> [...]

Regards, Hannah.

Re: Licenses and Libraries

[Havoc Pennington]

On Wed, 22 Sep 1999, Hannah Schroeter wrote:
> 
> Frankly, I'd like it to use Corba from Haskell with ORBit
> alone rather to have to install much additional Gnome stuff I'm
> probably not using elsewhere anyway.
> 

I just joined the list and the archives seem incomplete, so apologies if
this has been covered. :-)

The right thing to do is to have Haskell modules for standalone ORBit and
for GNOME as well. There are two key things in GNOME:

 - the CORBA spec doesn't establish mechanisms for authenticating 
   connections or finding the name server. GNOME adds "policy" on 
   this which is seperate from ORBit; in practice if you don't 
   use GNOME you have to implement this yourself

 - Bonobo is a component model which is to CORBA as OLE is to COM/DCOM. 
   This is a higher-level set of interfaces which communicate
   via CORBA; Bonobo allows you to connect graphical components and
   documents running in different processes, etc.

   CORBA doesn't give you this, it is just a communication layer, not 
   a component model.

ORBit is useful on its own, but the GNOME stuff is nice to have 
available as an add-on module if you need that functionality.

Havoc

  

RE: Licenses and Libraries

[trb]

Sigbjorn Finne (Intl Vendor) writes:
 > Here's a quick update on what I've been up to lately re: HDirect &
 > what the next release will support:
 > 
 >   * Java <--> Haskell (aka Lambada) support.
 >   * automatically generate Haskell stubs from .h files & support
 > for working with pristine .h files.
 >   * Corba client support (via the DII, so ORB indep.) I'll add 
 > Corba server support if there's any demand for it (== code/projects
 > that depend on it ; let me know.)

Building DII requests in C++ should be very clumsy, but in Haskell one could
probably define some nice combinators and make it relatively elegant.

I'm interested in CORBA server support (which I presume you would do via the
DSI). I don't have a pressing need, but will need it eventually for a
distributed transaction log, and some other inter-process-communication type
things. If it is not a lot of work it would be a shame to leave it out. OTOH by
the time I need it, Manuel's ORBit stuff might be ready.

Tim

Re: Licenses and Libraries

[Manuel M. T. Chakravarty]

[EMAIL PROTECTED] wrote,

> Manuel M. T. Chakravarty writes:
>  > [EMAIL PROTECTED] wrote,
>  > 
>  > > Manuel M. T. Chakravarty writes:
>  > >  > "Erik Meijer" <[EMAIL PROTECTED]> wrote,
>  > > [...]
>  > > > I understand that the fact that COM fixes the binary
>  > > > interface makes it much easier to deal with. 
>  > > 
>  > > I don't understand this - perhaps you could explain.
>  > 
>  > For Corba you usually have to select an ORB first and you
>  > need a language mapping - simply fewer variables with COM
>  > (you pay with loss of portability).
> 
> I think you need a language mapping anyway - I don't see how you can use COM
> without defining how to map Haskell to it.

True, but with Corba all IDL compilers for a given
programming language should use the same mapping, COM
doesn't seem to require this (but I guess the COM experts
know this better than I).  Therefore, you can just map it
somehow - but I should probably say that the H/Direct
designers being true believers ;-) in solidly specified
software provide a rather rigorous definition in the
H/Direct paper.

> As far as I can see, once you have selected an ORB, you
> mainly need to arrange argument marshalling and
> unmarshalling to and from the format desired by the
> ORB. Because of IIOP, the choice of ORB is not
> significant, unless you want to short-circuit calls for
> extreme speed ala ORBit. So it appears to me that, in this
> respect, COM is like CORBA restricted to only one brand of
> ORB.

This is probably a good comparison. However, I think in
practice your choice of ORB actually matters quite a lot in
CORBA - if you look at a list like 

  http://adams.patriot.net/%7etvalesky/freecorba.html

the features provided by different ORBs vary significantly.

To be honest, I am myself still undecided whether to prefer
CORBA's "everything goes and we fix only the framework"
approach or COM's "that's how it works, and you don't change 
a bit" philosophy.

Manuel

Re: Monads in plain english (Was: Re: Licenses and Libraries)

[Christian Sievers]

> > Indeed.  But if you get this far, understanding (>>=) quite trivial
> > (assuming you don't have problems with higher-order functions).
> Yes, it would be quite trivial.  But why bother?  You only need (>>=)
> if you want to declare your own instance of Monad, which probably doesn't
> need to be in an introductory course.

I think I would feel quite unsatisfied if I didn't know that 'do' is
not some strange feature which seems to be unrelated to the rest, but
only some syntactic sugar for very normal higher order combinators.

And even if propably none ever needs it, I feel much happier to know
that 'zipWith (>>=)' is there and doesn't have to be written in
do-syntax. This is what reassures me that 'IO a' is an abstract, but
otherwise normal data type.

It may be useful, in the beginning of a course, to tell the students
how to do some simple IO using 'do' in a recipe like manner. (But if
they are using an interpreter and don't have to write a main function,
you can as well leave this out.) But in order to explain monads even
to someone who wouldn't define his own, I'd surely not conceal (>>=).


Alll the best,
Christian Sievers

Re: Monads in plain english (Was: Re: Licenses and Libraries)

[Antti-Juhani Kaijanaho]

On Wed, Sep 01, 1999 at 08:26:09PM +0200, George Russell wrote:
> You only need (>>=)
> if you want to declare your own instance of Monad, which probably doesn't
> need to be in an introductory course.

I agree with your second point.  However, I use (>>=) for the same reason
I use (.) and why I often write C like this:

a = foo(bar(baz(xyzzy)));

So it comes down to personal preference.

-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

  ""
 (John Cage)

Re: Monads in plain english (Was: Re: Licenses and Libraries)

[Antti-Juhani Kaijanaho]

On Wed, Sep 01, 1999 at 11:16:05AM -0700, Nick Kallen wrote:
> >  a <- b
> >  c <- f a
> >
> > as
> >
> > c <- f b
> >
> > In Haskell I can't.  Why?  b is of type IO something, whereas f expects a
> > non-monadic argument.
> 
> I don't see why this is any different from say, Pascal, where you can't:
> 
> Writeln(Readln(a));

You don't?  My Pascal is rusty (I haven't written anything with it
in years), but IIRC ReadLn is a procedure and does not return a value.
The Haskell function getLine returns a value, and in the do notation

a <- getLine

looks to the naive beginner like that value is put into the a variable.
Indeed, something is put there, which adds to the confusion.

In contrast, in Pascal, you can't IIRC write

   a := ReadLn;
   
Actually, if you could, then your

   WriteLn(ReadLn);
   
would be perfectly OK, which *again* adds to the confusion.  The Haskell
do notation looks like imperative code (and in particular the arrow
looks like assignment) but it behaves in many respects quite differently.

> This distinction is made clear if the programmer is aware of why he's using
> <- and not =.

Yes.  By that time she could as well use (>>=).  We're talking about
whether do is better for the beginner than (>>=), not about the usefulness
of do to others.

> most imperative IO libraries make
> a similar distinction anyway since IO functions tend not to return values
> but modify a parameter (i.e., procedure vs. function is no worse!).

The procedure vs function distinction is very clear from the notation,
so it's not a valid point for comparison.

> Plus, you can just sidestep the whole issue: no explanation, just say that
> equality laws don't hold for <-.

Equality laws do not hold for imperative assignment either.

-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

  ""
 (John Cage)

Re: Monads in plain english (Was: Re: Licenses and Libraries)

[Antti-Juhani Kaijanaho]

On Wed, Sep 01, 1999 at 06:23:19PM +0200, George Russell wrote:
> It is indeed absolutely crucial to understand the difference between the
> types "IO a" and "a" (an "IO a" is a way of obtaining an a, an "a" _is_
> an a).  Also understand that in "do" expressions, "<-" represents actually
> getting an "a" from an "IO a".

Indeed.  But if you get this far, understanding (>>=) quite trivial
(assuming you don't have problems with higher-order functions).
After all, do /is/ just simple syntactic sugar.

-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

  ""
 (John Cage)

Re: Monads in plain english (Was: Re: Licenses and Libraries)

[George Russell]

Antti-Juhani Kaijanaho wrote:
[snip]
> Indeed.  But if you get this far, understanding (>>=) quite trivial
> (assuming you don't have problems with higher-order functions).
Yes, it would be quite trivial.  But why bother?  You only need (>>=)
if you want to declare your own instance of Monad, which probably doesn't
need to be in an introductory course.

Re: Monads in plain english (Was: Re: Licenses and Libraries)

[Antti-Juhani Kaijanaho]

Here's from someone who's still learning Haskell.

On Wed, Sep 01, 1999 at 03:24:48PM +0200, George Russell wrote:
> Thus all you 
> need to explain is "do" (which is in almost all respects identical to impure 
>sequencing 
> constructs in impure languages), and the IO typeconstructor.

I had many problems writing programs in the do notation until I understood
the underlying (>>=).  Why?  For example, in imperative languages I
can rewrite

 a <- b
 c <- f a
 
as 

c <- f b

In Haskell I can't.  Why?  b is of type IO something, whereas f expects a
non-monadic argument.  This confused me greatly, until I started thinking
of do as syntactic sugar for (>>=).  Thus, while "do" does help someone
who knows (>>=) to visualize the operations, you can never use do with
plain imperative intutition: for example, you can't think of "a <- b"
as assignment (which is the immediate analogy for someone who does not
know monads well).  Therefore, even using "do" requires one to understand
the play with types and actions as values, and from there it's trivial
to get to (>>=).

-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

  ""
 (John Cage)

Re: Monads in plain english (Was: Re: Licenses and Libraries)

[George Russell]

Antti-Juhani Kaijanaho wrote:
[snip]
> I had many problems writing programs in the do notation until I understood
> the underlying (>>=).  Why?  For example, in imperative languages I
> can rewrite
> 
>  a <- b
>  c <- f a
> 
> as
> 
> c <- f b
> 
> In Haskell I can't.  Why?  b is of type IO something, whereas f expects a
> non-monadic argument.  This confused me greatly, until I started thinking
> of do as syntactic sugar for (>>=).  Thus, while "do" does help someone
> who knows (>>=) to visualize the operations, you can never use do with
> plain imperative intutition: for example, you can't think of "a <- b"
> as assignment (which is the immediate analogy for someone who does not
> know monads well).  Therefore, even using "do" requires one to understand
> the play with types and actions as values, and from there it's trivial
> to get to (>>=).
It is indeed absolutely crucial to understand the difference between the
types "IO a" and "a" (an "IO a" is a way of obtaining an a, an "a" _is_
an a).  Also understand that in "do" expressions, "<-" represents actually
getting an "a" from an "IO a".  Then there is no confusion.  I think Antti-Juhani
Kaijanaho's confusion could have been resolved by thinking about the types
rather than about (>>=).

Re: Monads in plain english (Was: Re: Licenses and Libraries)

[George Russell]

If all you want to do is learn to program Haskell, then I think the existing 
explanations
of monads suffer too much from history.  A few years ago we had (>>) and (>>=), but no 
"do"
notation.  Afterwards "do" was invented, making everyone's life easier.  I suggest that
introductions to Haskell stop treating "do" as syntactic sugar for (>>) and (>>=), and 
instead
treat (>>) and (>>=) as syntactic sugar for "do" (if they teach them at all).  Thus 
all you 
need to explain is "do" (which is in almost all respects identical to impure 
sequencing 
constructs in impure languages), and the IO typeconstructor.  The latter is the only
real new construct (an "IO a" is a way of obtaining an a, not an a).  By the time 
novices learn monads they should already have learnt something about pure functional
programming, so they should be able to resist the temptation to write all their 
functions
as actions.

Of course, in more advanced courses you will probably have to explain (>>=), as 
otherwise
people can't define their own instances of Monad.  (Fortunately, one can write quite a 
lot
of Haskell without having to instance Monad.)  However there is no other reason I can 
see
for ever using (>>) and (>>=).  In my opinion, Haskell has far too many infix operators
which allow you to save a few characters at the expense of making your code much 
harder to
read.  This is bad style in Haskell just as much as in C.

RE: Monads in plain english (Was: Re: Licenses and Libraries)

[Nick Kallen]

>  a <- b
>c <- f a
>
> as
>
>   c <- f b
>
> In Haskell I can't.  Why?  b is of type IO something, whereas f expects a
> non-monadic argument.

I don't see why this is any different from say, Pascal, where you can't:

Writeln(Readln(a));

This distinction is made clear if the programmer is aware of why he's using
<- and not =. You're right that you have to become aware of the difference
between an action and a function call, but most imperative IO libraries make
a similar distinction anyway since IO functions tend not to return values
but modify a parameter (i.e., procedure vs. function is no worse!).

Plus, you can just sidestep the whole issue: no explanation, just say that
equality laws don't hold for <-.

This is obvious anyway, take:

a <- b
c <- b
d <- f a
e <- f c

is this equivalent to?:

d <- f b
e <- f b

Not if f has side-effects that affect the behavior of b.

Re: Monads in plain english (Was: Re: Licenses and Libraries)

[Hamilton Richards Jr.]

At 8:24 AM -0500 9/1/1999, George Russell wrote:
>...  I suggest that
>introductions to Haskell stop treating "do" as syntactic sugar for (>>)
>and (>>=), and instead
>treat (>>) and (>>=) as syntactic sugar for "do" (if they teach them at
>all).  Thus all you
>need to explain is "do" (which is in almost all respects identical to
>impure sequencing
>constructs in impure languages), and the IO typeconstructor.  ...

The new (i.e., second) edition of

Simon Thompson, "Haskell: The Craft of Functional Programming",
Addison-Wesley, 1999 (ISBN 0-201-34275-8)

takes exactly this tack. It works very nicely.

--HR




--
Hamilton Richards Jr.Department of Computer Sciences
Senior Lecturer  Mail Code C0500
512-471-9525 The University of Texas at Austin
SHC 434  Austin, Texas 78712-1188
[EMAIL PROTECTED]
--

RE: Licenses and Libraries

[Sigbjorn Finne (Intl Vendor)]

[Lots of heat being generated in this (deceptively named)
 thread - hopefully I can squeeze in another one before it is
 all consigned to the Bit Bucket in the Sky :-) ]

Here's a quick update on what I've been up to lately re: HDirect &
what the next release will support:

  * Java <--> Haskell (aka Lambada) support.
  * automatically generate Haskell stubs from .h files & support
for working with pristine .h files.
  * Corba client support (via the DII, so ORB indep.) I'll add 
Corba server support if there's any demand for it (== code/projects
that depend on it ; let me know.)

All running here locally, but some polish still required.

--sigbjorn

Re: Licenses and Libraries

[trb]

Manuel M. T. Chakravarty writes:
 > [EMAIL PROTECTED] wrote,
 > 
 > > Manuel M. T. Chakravarty writes:
 > >  > "Erik Meijer" <[EMAIL PROTECTED]> wrote,
 > > [...]
 > > > I understand that the fact that COM fixes the binary
 > > > interface makes it much easier to deal with. 
 > > 
 > > I don't understand this - perhaps you could explain.
 > 
 > For Corba you usually have to select an ORB first and you
 > need a language mapping - simply fewer variables with COM
 > (you pay with loss of portability).

I think you need a language mapping anyway - I don't see how you can use COM
without defining how to map Haskell to it.

As far as I can see, once you have selected an ORB, you mainly need to arrange
argument marshalling and unmarshalling to and from the format desired by the
ORB. Because of IIOP, the choice of ORB is not significant, unless you want to
short-circuit calls for extreme speed ala ORBit. So it appears to me that, in
this respect, COM is like CORBA restricted to only one brand of ORB.

Tim

Re: Licenses and Libraries

[Manuel M. T. Chakravarty]

[EMAIL PROTECTED] wrote,

> Manuel M. T. Chakravarty writes:
>  > "Erik Meijer" <[EMAIL PROTECTED]> wrote,
> [...]
> > I understand that the fact that COM fixes the binary
> > interface makes it much easier to deal with. 
> 
> I don't understand this - perhaps you could explain.

For Corba you usually have to select an ORB first and you
need a language mapping - simply fewer variables with COM
(you pay with loss of portability).

>  > As I wrote
>  > in response to Daan, I am seriously thinking about getting
>  > H/Direct to work with GNOME. Maybe this way we can arrive
>  > at something that is more or less portable at least on the
>  > Haskell level.
> 
> Presumably you mean ORBit, rather than GNOME. 

I say GNOME because I mean a binding to all the important
GNOME services - not only ORBit, but also the GNOME
libraries.

> According to its documentation, ORBit supports IIOP,
> therefore Haskell would interface to any other language
> via ORBit. For example, to have Haskell call COBOL (ugh!),
> one would simply let ORBit talk IIOP to DAIS (an ORB with
> a COBOL binding) or vice-versa.

That's not what I meant.  I was thinking about an
abstraction layer that can hide (some of) the differences
between COM and GNOME, so that a Haskell program can be
(source) portable across them (be warned, I didn't have a
serious lock into this, it is just an appealing idea).

>  > My point is that in most cases, I don't have control over
>  > the .h files.  I get them with the library.  If I edit them, 
>  > I have to do this for every new version.  This would be
>  > quite tedious for something like the GTK+ binding.
>  > 
>  > In contrast, the Haskell-side is completely under my control 
>  > and I am actually quite happy to get an error message that
>  > forces me to look at the code when something on the C side
>  > changes. 
> 
> Will you always get an error message if the C signature
> changes without a corresponding change in the Haskell
> signature, or is it possible you will just get a
> segmentation fault? 

You get a compile time error - either when running C->HS or
when running the output through the Haskell compiler.

>  > The first and foremost thing is that writing an IDL for GTK+
>  > is a lot of work - we are talking more than 400 kbytes .h
>  > files here.  There are of course some functions that need a
>  > lot of special treatment in the interface, but many of the
>  > functions have rather uniform marshaling requirements.  So,
>  > what I wanted was not touching the .h files (or respecifying
>  > them in IDL), but only tweaking on the Haskell-side where
>  > this is necessary.  That's exactly the reason why I came up
>  > with the design that I descibe in that paper.
> 
> One would expect GTK to have a CORBA (i.e. IDL) interface for its use in the
> GNOME project, but I couldn't see any sign on www.gtk.org .

As far as I know there is none.  Actually, the topic came up
on the GTK+ mailing list a while ago and there didn't seem
to be much enthusiasm for writing one.  (There is a
interface specification file in a Lisp-like syntax, which is
used in the Guile and, I think, also Python binding of GTK+
- it didn't seem to be directly useful for Haskell when I
had a look at it at the beginning of writing the binding.)

Manuel

Re: Licenses and Libraries

[trb]

Manuel M. T. Chakravarty writes:
 > "Erik Meijer" <[EMAIL PROTECTED]> wrote,
[...]
 > > There is a real danger if in an officially published paper
 > > someone gives the impression that H/Direct is only about
 > > interfacing Haskell to COM, because readers that will hear
 > > about H/Direct for the first time via that paper could
 > > become. When discussing related work you have to be 300%
 > > extra careful because you are potentially influencing the
 > > mindset of your readers.
 > 
 > IMHO, the H/Direct papers nurture this impression.  To be
 > honest, although I realised that H/Direct can generate plain 
 > C bindings, I always thought that the only thing you (= the
 > authors of the papers) really care about is the COM
 > support.  From the discussions about H/Direct on the mailing 
 > lists, I believe that I am not the only person who
 > interpreted the papers in this way.

I made the same interpretation. I had the strong impression that OMG IDL support
did not exist at present. If I now understand correctly, OMG IDL is currently
accepted by H/Direct (has anyone tested this ?) and what is lacking is a Haskell 
language binding for CORBA.

 > I understand that the fact that COM fixes the binary
 > interface makes it much easier to deal with. 

I don't understand this - perhaps you could explain.

 > As I wrote
 > in response to Daan, I am seriously thinking about getting
 > H/Direct to work with GNOME. Maybe this way we can arrive
 > at something that is more or less portable at least on the
 > Haskell level.

Presumably you mean ORBit, rather than GNOME. According to its documentation,
ORBit supports IIOP, therefore Haskell would interface to any other language via 
ORBit. For example, to have Haskell call COBOL (ugh!), one would simply let
ORBit talk IIOP to DAIS (an ORB with a COBOL binding) or vice-versa.

 > My point is that in most cases, I don't have control over
 > the .h files.  I get them with the library.  If I edit them, 
 > I have to do this for every new version.  This would be
 > quite tedious for something like the GTK+ binding.
 > 
 > In contrast, the Haskell-side is completely under my control 
 > and I am actually quite happy to get an error message that
 > forces me to look at the code when something on the C side
 > changes. 

Will you always get an error message if the C signature changes without a
corresponding change in the Haskell signature, or is it possible you will just
get a segmentation fault ? In this case, it might be preferable to have IDL as
the official interface, with the C and (preferably) Haskell interfaces generated
from the IDL (except that IDL is not sufficiently rich for interfacing to a
language like Haskell).

 > The first and foremost thing is that writing an IDL for GTK+
 > is a lot of work - we are talking more than 400 kbytes .h
 > files here.  There are of course some functions that need a
 > lot of special treatment in the interface, but many of the
 > functions have rather uniform marshaling requirements.  So,
 > what I wanted was not touching the .h files (or respecifying
 > them in IDL), but only tweaking on the Haskell-side where
 > this is necessary.  That's exactly the reason why I came up
 > with the design that I descibe in that paper.

One would expect GTK to have a CORBA (i.e. IDL) interface for its use in the
GNOME project, but I couldn't see any sign on www.gtk.org .

Tim

Re: Licenses and Libraries

[Manuel M. T. Chakravarty]

Hannah Schroeter <[EMAIL PROTECTED]> wrote,

> On Mon, Aug 23, 1999 at 12:03:25AM +1000, Manuel M. T. Chakravarty wrote:
> > [...]
> 
> > Anyway, I am still thinking about adapting H/Direct to work
> > with GNOME (www.gnome.org - the GNU answer to COM, DCOM, and
> > ActiveX) when I am through with GTK+.
> 
> Better make it work with Corba, which is the basement of the IPC used
> for Gnome, but not only that. For a first touch, one could use the
> standard C mapping via the GHC FFI (is that implemented in other Haskell
> implementations?).

Sure Corba, but you need an ORB and I am thinking of using
ORBit - thus, GNOME.  I prefer to say GNOME (in a
non-marketing context), as GNOME implies more than Corba.
For example, there is the name service in libGNORBA and the
new document component model called Bonobo (where MS uses
OLE2 and ActiveX).

GHC's FFI currently is only supported by GHC - think of GHC
as the test implementation.  Hugs' FFI is not unlike that
FFI and it is planned that in future versions Hugs supports
the same FFI (at least the dynamic part).  It is, however,
extremely important to have a standard FFI in Haskell and I
hope very much that there is enough momentum to get the FFI
into the next standard.[1]

Manuel

[1] I know that I am repeating myself - that's the point ;-)

Re: Licenses and Libraries

[Hannah Schroeter]

Hello!

On Mon, Aug 23, 1999 at 12:03:25AM +1000, Manuel M. T. Chakravarty wrote:
> [...]

> Anyway, I am still thinking about adapting H/Direct to work
> with GNOME (www.gnome.org - the GNU answer to COM, DCOM, and
> ActiveX) when I am through with GTK+.

Better make it work with Corba, which is the basement of the IPC used
for Gnome, but not only that. For a first touch, one could use the
standard C mapping via the GHC FFI (is that implemented in other Haskell
implementations?).

Regards, Hannah.

Re: Licenses and Libraries

[Fergus Henderson]

On 22-Aug-1999, Erik Meijer <[EMAIL PROTECTED]> wrote:
> How many times do I have to repeat that H/DIRECT IS NOT TIED TO MS OR COM,
> once again H/DIRECT IS NOT TIED TO MS OR COM!

It would probably be more effective if you could list for us
the non-MS non-COM platforms that H/Direct supports.

Unless, of course, that list is empty.

-- 
Fergus Henderson <[EMAIL PROTECTED]>  |  "I have always known that the pursuit
WWW:   |  of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED]| -- the last words of T. S. Garp.

Re: Licenses and Libraries

[Manuel M. T. Chakravarty]

"Erik Meijer" <[EMAIL PROTECTED]> wrote,

> First of al I want to apologize, especially to Manuel, for
> the immoderate amount of emotion in my previous
> message. 

Already forgotten.

> As a scientist I find it rather frustrating that H/Direct
> is associated so strongly with COM (which is very cool but
> timely) and not thought of as a general foreign function
> interface (which is timeless).

I can understand this and it was definitely not my intention
to add to your frustration.

> There is a real danger if in an officially published paper
> someone gives the impression that H/Direct is only about
> interfacing Haskell to COM, because readers that will hear
> about H/Direct for the first time via that paper could
> become. When discussing related work you have to be 300%
> extra careful because you are potentially influencing the
> mindset of your readers.

IMHO, the H/Direct papers nurture this impression.  To be
honest, although I realised that H/Direct can generate plain 
C bindings, I always thought that the only thing you (= the
authors of the papers) really care about is the COM
support.  From the discussions about H/Direct on the mailing 
lists, I believe that I am not the only person who
interpreted the papers in this way.

Anyway, I promise to make it superclear in the next version
of my paper that H/Direct is *not* only about interfacing
COM.

> It might be interesting to know that the Netscape Gekko
> browser is build out of COM-compatible components, and
> that the JNI interface is also (nearly) COM
> compatible. 

That's interesting, I didn't know that.

> IMHO, the whole OLE framework is technically
> brilliant and deserves much more appreciation from us
> hackers. In fact, I think that because most explanations
> of OLE use C/C++, the inherent elegance gets burried under
> the accidental complexity of pointers, arrays, HRESULTS,
> etc. and it could be done much nicer in Haskell.

I believe this and I actually very much like the H/Direct
papers, especially Heaven and Hell.  It is only rather
unfortunate that this technology is tied to a single
platform - I don't care who the vendor of this single
platform is, but being tied to a single platform is a Bad
Thing.  One reason for me to choose GTK+ as the GUI for
which to write a binding was that it runs on basically all
Unix machines *plus* Win32 and a Mac port is in the works.

I understand that the fact that COM fixes the binary
interface makes it much easier to deal with.  As I wrote
in response to Daan, I am seriously thinking about getting
H/Direct to work with GNOME.  Maybe this way we can arrive
at something that is more or less portable at least on the
Haskell level.

> > I admit that the wording is ambiguous, but the intended
> > meaning is that "access to existing libraries implemented in
> > the language C" is the most frequent application of a FLI -
> > which is true.
> 
> I think that this really depends in which world you
> live. In Unix/Linux-land components are usually
> distributed as C source files. In Windows-land you either
> get a DLL or a COM component with a type library (a binary
> representation of its IDL description), in which case you
> have no idea in which language the component is
> implemented. Most probably Visual Basic! (but perhaps
> Haskell or SML, who knows).  

Sure, but I believe that also on Win, most libraries
(especially the system-level and basic libraries) are *also*
available from C (I mean any of the C development systems) -
or am I mistaken?  This would be sufficient.

> > The difference is that a programmer writing a Haskell
> > binding to a C library already knows C and Haskell, but not
> > necessarily IDL.  Moreover, in my approach the already
> > existing prestine C header file is used, which *always* is
> > available for a C library.  The IDL file you usually have to
> > write yourself and constantly keep up to date with new
> > releases of the C library.
> 
> But you "pollute" the Haskell-side with your hooks. I'd
> rather keep the Haskell side pristine and edit the .h file
> by adding a few [in] and [out] attributes (i.e. you don't
> have to write the IDL from scratch) or just use the IDL or
> type library or meta data that comes with the modified
> library that is distributed in binary form.  

My point is that in most cases, I don't have control over
the .h files.  I get them with the library.  If I edit them, 
I have to do this for every new version.  This would be
quite tedious for something like the GTK+ binding.

In contrast, the Haskell-side is completely under my control 
and I am actually quite happy to get an error message that
forces me to look at the code when something on the C side
changes. 

> > Nevertheless, it didn't help me when I wanted to code the
> > GTK+ binding - partially because it was too beta and
> > partially because it just automates the wrong things.  So, I
> > coded on the raw FFI (GHC's new one) by hand, and while
> > doing this, I realised what kind of to

Re: Licenses and Libraries

[Michael T. Richter]

>> How many times do I have to repeat that H/DIRECT IS NOT TIED TO MS OR COM,
>> once again H/DIRECT IS NOT TIED TO MS OR COM!

> It would probably be more effective if you could list for us
> the non-MS non-COM platforms that H/Direct supports.

> Unless, of course, that list is empty.

I was wondering if it would be possible for the people fighting over the
semantics of H/Direct's capabilities to please stop polluting what has
until now been an otherwise quite civilized mailing list?  Private e-mail
seems to be the way to go here.

--
Michael T. Richter<[EMAIL PROTECTED]>http://www.igs.net/~mtr/
  PGP Key: http://www.igs.net/~mtr/pgp-key.html
PGP Fingerprint: 40D1 33E0 F70B 6BB5 8353 4669 B4CC DD09 04ED 4FE8 

Re: Licenses and Libraries

[Tyson Dowd]

On 23-Aug-1999, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> Sun, 22 Aug 1999 00:30:29 +0200, Erik Meijer <[EMAIL PROTECTED]> pisze:
> 
> > Well, in some sense .h files are a dedicated interface language
> > (and IDl is nothing more than a header file with some directional
> > attributes).
> 
> I already know C and .h format. Where can I learn IDL?

There are lots of links in the H/Direct documentation.

-- 
The quantum sort: 
while (!sorted) { do_nothing(); }
Tyson Dowd   <[EMAIL PROTECTED]>   http://tyse.net/

Re: Licenses and Libraries

[Tyson Dowd]

On 23-Aug-1999, Mr. Laszlo Nemeth <[EMAIL PROTECTED]> wrote:
> Paul Hudak wrote:
> 
> > P.S. I really like the idea someone suggested of maintaining a list of
> > open projects, who's working on what, etc. as in the Linux community. 
> 
> One major difference between the Linux community and the Haskell
> community is that in LinuxLand the reward is the name, recognition,
> while the people in Haskell community tend to be in academia. They
> want POPL papers! Putting your still half baked but most cherished
> 'BEST IDEA FOR YEARS' on a list may inspire someone else to write the
> POPL paper you wanted to write, which means no brownie point for
> you...

This is a problem with research areas, but not necessarily with
implementation, samples, libraries etc.  It's difficult to get a
POPL paper for Yet Another Interface To An Existing Library.
But it's a still an extremely useful thing to have.

-- 
The quantum sort: 
while (!sorted) { do_nothing(); }
Tyson Dowd   <[EMAIL PROTECTED]>   http://tyse.net/

Re: Licenses and Libraries

[Sven Panne]

Erik Meijer wrote:
> [...] I think that this really depends in which world you live. In
> Unix/Linux-land components are usually distributed as C source files.
> In Windows-land you either get a DLL or a COM component with a type
> library (a binary representation of its IDL description), [...]

The first sentence exactly states the problem: There are basically two
groups at the moment, one small M$-driven, knowing almost everything
about COM/OLE/[insert your favourite M$ acronym here], and the other
probably much larger group sitting in front of their *nix-boxes, being
overwhelmed and frustrated by the sheer amount of M$ documentation when
everything they wanted was to write a simple C library binding with
H/Direct. Please note that I'm not flaming against M$ or H/Direct, but
I'm simply not willing to read huge documents which are 99%
inappropriate for the things I want to do. H/Direct is extremely cool
and misses only few things on the technical side, but it *really*
lacks documentation of the kind "Interfacing to C via H/Direct for
Dummies", the small examples subdirectory is simply not enough. What
is needed is e.g. a simple recipe for the manual conversion of .h files
into .idl files, which of the dozens of ihc's command line options you
need for this simple interfacing to C, etc. Without this, I guess, most
*nix people will stick to Green Card and/or the FFI.

Cheers,
   Sven
-- 
Sven PanneTel.: +49/89/2178-2235
LMU, Institut fuer Informatik FAX : +49/89/2178-2211
LFE Programmier- und Modellierungssprachen  Oettingenstr. 67
mailto:[EMAIL PROTECTED]D-80538 Muenchen
http://www.informatik.uni-muenchen.de/~Sven.Panne

Re: Licenses and Libraries

[Manuel M. T. Chakravarty]

"Daan Leijen" <[EMAIL PROTECTED]> wrote,

> Sigbjorn Finne has done a lot of work to make sure that H/Direct can handle
> any standard and dialect of IDL that is around, including
> OMG/Corba IDL's.  H/Direct can generate interface code to
> any C library that is described with IDL (which is
> normally just adding some attributes to the C header file)
[...]
> Secondly, it is quite easy to extend H/Direct to support
> other protocols (like GNOME).

I know that and how H/Direct supports...I don't dare to say
it...COM and plain C.  However, what I am unclear about is
how does it support OMG's CORBA IDL?  As you mention in the
H/Direct paper, COM fixes a language-independent, binary
interface, but CORBA IDL doesn't do that.  Did you define a
CORBA language mapping for Haskell?  If not, how can you
support CORBA?  To support GNOME, the next step is to
support the binary interface defined by ORBit (GNOME's
Object Request Broker).  I guess that this means tweaking
the marshaling code generation.  This you think is easy?

(I'd be really interested to get some more information about
this, because, as I mentioned, I am interested in adding
such support.)

All the best,
Manuel

Re: Licenses and Libraries

[Erik Meijer]

Hi fellow Haskellers,

First of al I want to apologize, especially to Manuel, for the immoderate amount of 
emotion in my previous message. It was not professional at all; email is lightly 
inflammable :-) As a scientist I find it rather frustrating that H/Direct is 
associated so strongly with COM (which is very cool but timely) and not thought of as 
a general foreign function interface (which is timeless). 

There is a real danger if in an officially published paper someone gives the 
impression that H/Direct is only about interfacing Haskell to COM, because readers 
that will hear about H/Direct for the first time via that paper could become. When 
discussing related work you have to be 300% extra careful because you are potentially 
influencing the mindset of your readers. 

Of course I should have pointed this out gently and not blow up on Manuel. Next time I 
see him, I will buy him a beer (or two).

> And, by the way, should you like to apologize for calling me
> fanatic, I think, I'll happily accept the apology.

I meant "fanatic" in the sense of passionate or enthousiastic (so consider it as a 
compliment), not in the sense of extremistic or maniacal (in which case I am sincerely 
sorry for saying that). 

> Obviousy, references [6] and [5] are to support the claim
> that there is COM support for Haskell.  Furthermore, [5] is
> the "Calling Hell from Heaven and Heaven from Hell" paper,
> which discusses nothing but H/Direct's COM support (plus
> GHC's new FFI).

In retrospect I think that the emphasis on COM was rather unfortunate from a marketing 
point of view (as I tried to explain above). The reason for doing so anyway are that 
(a) COM is a language independent *binary* interface and (b) there are many, very many 
interesting COM components available. Both (a) and (b) are false for CORBA (but note 
that Sigbjorn has made a CORBA binding as well) but true for Java via JNI (as Claus 
already taught us ages ago, but I was temporarily blinded by my COM fanatism :-).

The reason that [5] discusses COM support (more precisely wrapping Haskell programs as 
COM components) is because that is technically interesting. The basic "C" (more 
precisely dynamic link library) binding is just part of that and was already described 
in the first H/Direct paper.

It might be interesting to know that the Netscape Gekko browser is build out of 
COM-compatible components, and that the JNI interface is also (nearly) COM compatible. 
IMHO, the whole OLE framework is technically brilliant and deserves much more 
appreciation from us hackers. In fact, I think that because most explanations of OLE 
use C/C++, the inherent elegance gets burried under the accidental complexity of 
pointers, arrays, HRESULTS, etc. and it could be done much nicer in Haskell.

> I admit that the wording is ambiguous, but the intended
> meaning is that "access to existing libraries implemented in
> the language C" is the most frequent application of a FLI -
> which is true.

I think that this really depends in which world you live. In Unix/Linux-land 
components are usually distributed as C source files. In Windows-land you either get a 
DLL or a COM component with a type library (a binary representation of its IDL 
description), in which case you have no idea in which language the component is 
implemented. Most probably Visual Basic! (but perhaps Haskell or SML, who knows). 

I think that the latter is better; when I use a component I am usually (but not 
always) only interested in it public interface. Only when something goes wrong or when 
I want to modify the component, I start getting interested in its implementation. But 
I would prefer to pay some money to the person from whom I bought the component 
because it might be implemented in C++ or something in which I lack programming skils.

> The difference is that a programmer writing a Haskell
> binding to a C library already knows C and Haskell, but not
> necessarily IDL.  Moreover, in my approach the already
> existing prestine C header file is used, which *always* is
> available for a C library.  The IDL file you usually have to
> write yourself and constantly keep up to date with new
> releases of the C library.

But you "pollute" the Haskell-side with your hooks. I'd rather keep the Haskell side 
pristine and edit the .h file by adding a few [in] and [out] attributes (i.e. you 
don't have to write the IDL from scratch) or just use the IDL or type library or meta 
data that comes with the modified library that is distributed in binary form. 

> > Moreover, your binding hooks are nothing but a dedicated
> > interface description language!
> 
> True, but a very simple one when compared to others.

In its full generality IDL is rather complex, but my experience is that for 80 percent 
of all components you just need 20 percent of the power of IDL (maybe it is even 
closer to 95/5).

> > This FFI is not specific to GHC, we proposed it as the
> > standard basic FFI for Haskell. 
> 
> 

Re: Licenses and Libraries

[Manuel M. T. Chakravarty]

"Erik Meijer" <[EMAIL PROTECTED]> wrote,

> In H/Direct you define the interface of some software
> component in IDL (we have supported both MS-IDL and
> OMG-IDL from the beginning). 

The H/Direct paper says (Section 2.2),

  We focus on the IDL used to describe COM interfaces [10],
  which is closely based on DCE IDL [7].  Another popular
  IDL dialect is the one defined by OMG as part of the CORBA 
  specification [11], and we intend to provide support for
  this using the translation from OMG to DCE IDL defined by
  [13, 12].

So, did you support OMG IDL from the beginning or did you
only *intend* to support it from the beginning?

> The crucial point is that the
> component need not be written in C, it can be written in
> Cobol, Fortan, SML, ... (talking about being
> generic). Interfacing to just C is not enough. 

True, but my point is interfacing to C does the job in a
sufficiently significant number of cases to justify
dedicated support - as you admitted when you advertised that 
H/Direct will support reading .h files in the future.

> I gues that Manual is temporarily blinded by his free
> software fanatism (judging from his homepage
> ), and

Like you, I am an outspoken proponent of the software
development model that I believe is technically superior -
however, my enthusiasm does not make me call other people
"fanatic" on public mailing lists...

> as a result his paper contains quite some untrue
> statements with respect to the MS-centricity of H/Direct: 

I can not remember having mentioned MS at all (apart when
quoting from your email).

> * page 1: "... to COM support [6,5]." (citing the H/Direct papers)
> OK, one more time H/DIRECT IS NOT TIED TO MS OR COM.

I did not claim this (and there is no reason to shout).  Let
us look at the text that you are quoting in context:

  Hence, it is not surprising that a number of methods have
  been proposed for integrating foreign code into functional
  programs, and in particular, for using imperative code
  with Haskell [12]---approaches range from inline calls to
  C routines [11] to COM support [6, 5].

Obviousy, references [6] and [5] are to support the claim
that there is COM support for Haskell.  Furthermore, [5] is
the "Calling Hell from Heaven and Heaven from Hell" paper,
which discusses nothing but H/Direct's COM support (plus
GHC's new FFI).

> * page 1: "Despite all this previous work, there is an
>   interesting approach which has not been explored so
>   far,.., access to existing libraries implemented in
>   the language C. 
> 
> You could say that all FFI prior to H/Direct were about
> interfacing to C culminating in GreenCard. 

Let's again look at the text that you omitted from your
quotation:

  Despite of all this previous work, there is an interesting
  approach, which has not been explored so far and which,
  moreover, is especially attractive for the most frequent
  application of a \emph{foreign language interface (FLI)}:
  access to existing libraries implemented in the language
  C.

I admit that the wording is ambiguous, but the intended
meaning is that "access to existing libraries implemented in
the language C" is the most frequent application of a FLI -
which is true.

> * throughout the paper: you say that in your approach the
>   programmer does not have to learn a dedicated interface
>   language.  
> 
> Well, in some sense .h files are a dedicated interface
> language (and IDl is nothing more than a header file with
> some directional attributes). 

The difference is that a programmer writing a Haskell
binding to a C library already knows C and Haskell, but not
necessarily IDL.  Moreover, in my approach the already
existing prestine C header file is used, which *always* is
available for a C library.  The IDL file you usually have to
write yourself and constantly keep up to date with new
releases of the C library.

> Moreover, your binding hooks are nothing but a dedicated
> interface description language!

True, but a very simple one when compared to others.

> * page 9: "The design of a matching structure in Haskell
>   requires algorithmic insight that hardly can be
>   automated; neither can the structure be encoded in
>   IDL. So, after all, the required marshalling has to be
>   handcoded in Haskell." 
> 
> We have never claimed that this is the case. In fact, we
> have always said that the generated Haskell stubs are just
> the starting point of a long abstraction process to give a
> nice interface to a software component (see the papers
> "Haskell as an automation controller" and "Client-side
> scripting using HaskellScript"). 

And I have never claimed that you have claimed so -
actually, I would have been very surprised if you had.

> * last page: "... GHC's new FFI ..." 
> 
> This FFI is not specific to GHC, we proposed it as the
> standard basic FFI for Haskell. 

I know, I used this phrase only due to lack of a different
name for the FFI - any sugges

Re: Licenses and Libraries

[Matthias Kilian]

>   the product. I really do not need any interface to Cobol or
>   any other exotic language language but C. This would solve
>   most of _my_ problems and for this I would heartily welcome
>   anything simpler than H/Direct - no matter whether it came
>   from one camp or another.

FYI: There's a tool, SWIG available that eases the construction of interfaces
from C to several languages (Perl, Tcl, Python, Guile, an experimental
interface to Java is also available). AFAIK a new realase of SWIG is planned to
appear in late 1999. This will have more flexible interfaces for new frontends
and backends. Perhaps it is possible to write a backend for Haskell, be it the
FFI used by GHC, be it OMG IDL or whatever.

For more information, see http://www.swig.org.

Kili

Re: Monads in plain engllish (Was: Re: Licenses and Libraries)

[Lennart Augustsson]

felix wrote:

> Everything just looks
> so darn complicated - even if you are basically just doing the same thing:
> CONS, APPLY,
> and LAMBDA.

Why CONS?  APPLY and LAMBDA is all you need. :-)


--

-- Lennart

Re: Licenses and Libraries

[Mr. Laszlo Nemeth]

Paul Hudak wrote:

> P.S. I really like the idea someone suggested of maintaining a list of
> open projects, who's working on what, etc. as in the Linux community. 

One major difference between the Linux community and the Haskell
community is that in LinuxLand the reward is the name, recognition,
while the people in Haskell community tend to be in academia. They
want POPL papers! Putting your still half baked but most cherished
'BEST IDEA FOR YEARS' on a list may inspire someone else to write the
POPL paper you wanted to write, which means no brownie point for
you...


> But, we need a worker bee to do that too :-)

Not necessarily. If there was an 'Ultimate Collection of Haskell
Related Material' repository (haskell.org(?)) where anyone could check
code/docs/drafts in, one could imagine an automatic browsing tool
instead of the worker bee. Though, this imaginary tool still have to
be implemented in the first place...

Laszlo

Monads in plain engllish (Was: Re: Licenses and Libraries)

[felix]

-Original Message-
From: Keith Wansbrough <[EMAIL PROTECTED]>
To: Ted Carroll <[EMAIL PROTECTED]>
Cc: Mark P Jones <[EMAIL PROTECTED]>; [EMAIL PROTECTED]
<[EMAIL PROTECTED]>; [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: 23 August 1999 14:38
Subject: Re: Licenses and Libraries


>[..]
>> Ted C.
>>
>> P.S.  If somebody could explain Monads in plain english it might not
>> hurt either.
>
>Someone already has:
>
>http://www.dcs.gla.ac.uk/~nww/Monad.html
>
>--KW 8-)

Yes, that text is not bad, but I think it still has a problem (one I found
in two or
three other introductory texts of monads): it stops right before getting
really interesting!
The examples are probably well thought out, but they are either just toy
stuff or they
are to special. There are so many questions still open: how to declare an
instance of
the 'Monad' class (for using 'do'-constructs) combined with a plain
state-monad, for example.
The standard-prelude doesn't really contain any good examples. 'IO' is too
abstract
to be of any use. Yes, I can figure all that out (and I do, with some work)
but most certainly
someone else already did that.

Don't get me wrong here: I think Haskell is the culmination of decades of
Programming-
Language reasearch, but, coming from the LISP direction, I really have
trouble to adapt to
the totally different terminology found in functional programming.
Everything just looks
so darn complicated - even if you are basically just doing the same thing:
CONS, APPLY,
and LAMBDA.

felix

P.S.: Can someone point me to a good book on functional programming ? One
which
doesn't bore you with trivialities, but comes right to the point and
explains everything
with real-world examples ? Just the one book specially written for a stupid
LISPer
with bad grades in mathematics, like me ? :-)

Re: Licenses and Libraries

[Marcin 'Qrczak' Kowalczyk]

Sun, 22 Aug 1999 00:30:29 +0200, Erik Meijer <[EMAIL PROTECTED]> pisze:

> Well, in some sense .h files are a dedicated interface language
> (and IDl is nothing more than a header file with some directional
> attributes).

I already know C and .h format. Where can I learn IDL?

-- 
 __("+++$ UL++>$ P+++ L++>$ E-
  ^^W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP->+ t
QRCZAK  5? X- R tv-- b+>++ DI D- G+ e> h! r--%>++ y-

Re: Monads in plain engllish (Was: Re: Licenses and Libraries)

[Theo Norvell]

On Mon, 23 Aug 1999, felix wrote:

> >> P.S.  If somebody could explain Monads in plain english it might not
> >> hurt either.
> >
> >Someone already has:
> >
> >http://www.dcs.gla.ac.uk/~nww/Monad.html
> >
> >--KW 8-)
> 
> Yes, that text is not bad, but I think it still has a problem (one I found
> in two or three other introductory texts of monads): it stops right
> before getting really interesting!

Along the same lines and subject to many of the same criticisms is
   http://www.engr.mun.ca/~theo/Misc/haskell_and_monads.htm.
Any comments on improving it would be welcome.

Cheers,
Theo Norvell

Re: Licenses and Libraries

[Manuel M. T. Chakravarty]

Jan Skibinski <[EMAIL PROTECTED]> wrote,

> On Mon, 23 Aug 1999, Manuel M. T. Chakravarty wrote:
> 
> > That's interesting, indeed.  I am also close to finishing
> > the first version of a tool that simplifies Haskell access
> > to C libraries by extracting interface information from C
> > headers.  Actually, I have just completed the draft of a
> > paper about the tool that I plan to present at IFL'99 next
> > month: 
> > 
> >   ``C -> Haskell, or Yet Another Interfacing Tool''
> >   http://www.score.is.tsukuba.ac.jp/~chak/papers/Cha99b.html
> 
>   It would be nice having it supported by Hugs as well.

I'll happily support every Haskell system that provides a
functionality similar to

  http://www.dcs.gla.ac.uk/fp/software/hdirect/ffi.html

As I wrote in the paper: It is about time that Haskell gets
a standardised foreign function interface.  And GHC's new
FFI is a very nice design (it is actually quite close to
Hugs `primitive' feature).  

Manuel

Re: Licenses and Libraries

[Keith Wansbrough]

[..]
> Ted C.
> 
> P.S.  If somebody could explain Monads in plain english it might not
> hurt either.

Someone already has:

http://www.dcs.gla.ac.uk/~nww/Monad.html

--KW 8-)

Re: Licenses and Libraries

[Jan Skibinski]

Several respondents pointed out to me my unfortunate choice
of words, which implied that H/Direct is either related to
MS-specific tools or MS-specific applicability. I apologize
for this.

But H/Direct focuses _also_ on COM, and for this a specific
approach and choice of tools has been made. At least - this
is what I understood from a series of articles on the subject.
Nothing wrong with that save the resulting complexity of
the product. I really do not need any interface to Cobol or
any other exotic language language but C. This would solve
most of _my_ problems and for this I would heartily welcome
anything simpler than H/Direct - no matter whether it came
from one camp or another.

Jan

Re: Licenses and Libraries

[Daan Leijen]

> "Daan Leijen" <[EMAIL PROTECTED]> wrote,
>
> > Sigbjorn Finne has done a lot of work to make sure that H/Direct can
handle
> > any standard and dialect of IDL that is around, including
> > OMG/Corba IDL's.  H/Direct can generate interface code to
> > any C library that is described with IDL (which is
> > normally just adding some attributes to the C header file)
> [...]
> > Secondly, it is quite easy to extend H/Direct to support
> > other protocols (like GNOME).

 "Manuel M. T. Chakravarty" <[EMAIL PROTECTED]> wrote,

> I know that and how H/Direct supports...I don't dare to say
> it...COM and plain C.  However, what I am unclear about is
> how does it support OMG's CORBA IDL?  As you mention in the
> H/Direct paper, COM fixes a language-independent, binary
> interface, but CORBA IDL doesn't do that.  Did you define a
> CORBA language mapping for Haskell?

Hi Manuel,

Unfortunately, there is more than one IDL around, they all look
the same and can basically express the same things.
Fortunately, H/Direct can get its input from both OMG /CORBA and
MS dialect IDL and extract the right semantic information.
In a sense, it doesn't matter in what language you describe your
interface as long as it gives enough information to generate marshalling
code. (that's why it is possible to even use C header files, allthough you
need some heuristics and/or extra directives, as you show in your paper).

We have not defined a CORBA *mapping* however. C and COM are
specific protocols for which we defined a mapping and generate marshall
code.
To *specify* an interface in C or COM, you can use any sort of IDL,
including OMG/CORBA IDL.
(btw. since the 'C' binding is actually a (dynamic or static) library
binding, it
supports also languages like pascal, fortran and many others with standard
calling conventions (cdecl, pascal, stdcall, fastcall,...))

The bad thing is that Corba is not a binary protocol and thus H/Direct needs
a different backend/mapping for each different Corba vendor. Many languages
provide
a Corba binding by providing their own Corba environment and interacting
with other Corba environments via the IIOP (internet) protocol of Corba
which
*is* a binary standard.
(Things are not really that bad since it seems that vendors start to
standarize on
object layout).

> If not, how can you
> support CORBA?  To support GNOME, the next step is to
> support the binary interface defined by ORBit (GNOME's
> Object Request Broker).  I guess that this means tweaking
> the marshaling code generation.  This you think is easy?

Supporting Corba would be a lot harder as said above. One approach could be
to just support one environment, I can't recall the name but there is one
excellent
free implementation around of corba (minicorba  or something ?)

Supporting Orbit however seems quite easy and it would be very cool to have
around, allowing for a comparison between COM and ORBit.
You should contact Sigbjorn Finne on the exact details but if
ORBit looks like COM (which is probably true) than it wouldn't
too much work.

> (I'd be really interested to get some more information about
> this, because, as I mentioned, I am interested in adding
> such support.)

It would be very nice to have someone adding these features to
H/Direct, especially since you are working with big frameworks
like GTK. This would have been a nice test of H/Directs abilities
and in a sense it is disappointing to learn that H/Direct didn't fit
your needs completely. I hope to learn how H/Direct can be improved
to take away the need for yet another FFI, which was our primary motivation
for building H/Direct.

All the best,
Daan.

> All the best,
> Manuel
>

Re: Licenses and Libraries

[Manuel M. T. Chakravarty]

"Erik Meijer" <[EMAIL PROTECTED]> wrote,

> I can reveal a little secret (Sigbjorn is far away in the
> Norwegian woods :-) namely that soon H/Direct will
> directly support .h files, which means that it will even
> be easier than before to get automate all the boring work
> in making standard C libraries available to Haskell. Just
> drag and drop it onto H/Direct and off you go. 

That's interesting, indeed.  I am also close to finishing
the first version of a tool that simplifies Haskell access
to C libraries by extracting interface information from C
headers.  Actually, I have just completed the draft of a
paper about the tool that I plan to present at IFL'99 next
month: 

  ``C -> Haskell, or Yet Another Interfacing Tool''
  http://www.score.is.tsukuba.ac.jp/~chak/papers/Cha99b.html

> Hopefully this will convince the COM criticasters and MS
> sceptists that H/Direct is cool indeed.

I for one never doubted that H/Direct is cool.  This is not
a matter of being critical towards COM; it is a matter of
"COM doesn't run on my Linux box" (nor does it run on SunOS,
HP/UX, etc).

Anyway, I am still thinking about adapting H/Direct to work
with GNOME (www.gnome.org - the GNU answer to COM, DCOM, and
ActiveX) when I am through with GTK+.

Manuel

Re: Licenses and Libraries

[Daan Leijen]

> On Mon, 23 Aug 1999, Manuel M. T. Chakravarty wrote:
>
> >   ``C -> Haskell, or Yet Another Interfacing Tool''
> >   http://www.score.is.tsukuba.ac.jp/~chak/papers/Cha99b.html
> >

Thanks for making the paper available, I enjoyed it a lot.

> Bravo!
>
> I fully endorse your main motivations from your paper:
> 1. Simplification by avoidance of special devoted languages
>and doing everything in Haskell instead.
> 2. Trying to make it generic enough, so it is not tied
>up to MS world (I am - as well as you are, far from
>criticising H/Direct: it has it niche, which is fine
>and cool).

As one of the designers of the new FFI and H/Direct, I do want
to say that there is *nothing* MS or COM specific about H/Direct or the FFI
!

Sigbjorn Finne has done a lot of work to make sure that H/Direct can handle
any
standard and dialect of IDL that is around, including OMG/Corba IDL's.
H/Direct can generate interface code to any  C library that is described
with IDL (which is normally just adding some attributes to the C header
file)
This works all fine on Linux or whatever system.

Besides that, H/Direct supports the MS dialect of IDL and can generate COM
interface code. However this is just one part of H/Direct which is
orthogonal
to the C support. Secondly, it is quite easy to extend H/Direct to support
other
protocols (like GNOME).


All the best,
Daan.

Re: Licenses and Libraries

[Jan Skibinski]

On Mon, 23 Aug 1999, Manuel M. T. Chakravarty wrote:

> That's interesting, indeed.  I am also close to finishing
> the first version of a tool that simplifies Haskell access
> to C libraries by extracting interface information from C
> headers.  Actually, I have just completed the draft of a
> paper about the tool that I plan to present at IFL'99 next
> month: 
> 
>   ``C -> Haskell, or Yet Another Interfacing Tool''
>   http://www.score.is.tsukuba.ac.jp/~chak/papers/Cha99b.html
> 

Bravo!

I fully endorse your main motivations from your paper:
1. Simplification by avoidance of special devoted languages
   and doing everything in Haskell instead.
2. Trying to make it generic enough, so it is not tied
   up to MS world (I am - as well as you are, far from
   criticising H/Direct: it has it niche, which is fine
   and cool).
 
I believe that your experience with Gtk+hs has given you a good
insight into posible practical problems with callbacks, etc. A
good testing grounds. I am looking forward to see it completed.

It would be nice having it supported by Hugs as well.

Jan
 

Re: Licenses and Libraries

[Erik Meijer]

How many times do I have to repeat that H/DIRECT IS NOT TIED TO MS OR COM, once again 
H/DIRECT IS NOT TIED TO MS OR COM!

In H/Direct you define the interface of some software component in IDL (we have 
supported both MS-IDL and OMG-IDL from the beginning). The crucial point is that the 
component need not be written in C, it can be written in Cobol, Fortan, SML, ... 
(talking about being generic). Interfacing to just C is not enough.

I gues that Manual is temporarily blinded by his free software fanatism (judging from 
his homepage ), and as a result 
his paper contains quite some untrue statements with respect to the MS-centricity of 
H/Direct:

* page 1: "... to COM support [6,5]." (citing the H/Direct papers)

OK, one more time H/DIRECT IS NOT TIED TO MS OR COM.

* page 1: "Despite all this previous work, there is an interesting approach which has 
not been explored so far,.., access to existing libraries implemented in the 
language C.

You could say that all FFI prior to H/Direct were about interfacing to C culminating 
in GreenCard.

page 1: "Interfaces to operating system services as well as to system-level and 
higher-level libraries are usually available from C, ...".

If "usually" means Unix/Linux then you are right. 

* page 3: "This is all very well for the main application area of H/Direct --namely 
writing COM components in Haskell-- but seems a bit heavy when merely interfacing to 
an existing C library.

The main application area of H/Direct is to provide a language independent FFI; 
H/DIRECT IS NOT TIED TO MS OR COM. 

* throughout the paper: you say that in your approach the programmer does not have to 
learn a dedicated interface language. 

Well, in some sense .h files are a dedicated interface language (and IDl is nothing 
more than a header file with some directional attributes). Moreover, your binding 
hooks are nothing but a dedicated interface description language! 

* page 9: "The design of a matching structure in Haskell requires algorithmic insight 
that hardly can be automated; neither can the structure be encoded in IDL. So, after 
all, the required marshalling has to be handcoded in Haskell."

We have never claimed that this is the case. In fact, we have always said that the 
generated Haskell stubs are just the starting point of a long abstraction process to 
give a nice interface to a software component (see the papers "Haskell as an 
automation controller" and "Client-side scripting using HaskellScript").

* last page: "... GHC's new FFI ..." 

This FFI is not specific to GHC, we proposed it as the standard basic FFI for Haskell. 
At this moment it has only been implemented for GHC, but work is underway to support 
ing under Hugs as well. 

I agree completely :-) that it is *very* important to have a standard FFI that is 
supported by all Haskell implementations.

A more general question, which is not immediately clear is how you specify the 
additional information to map a C signature to Haskell. For instance

  int foo (int* x);

can be mapped to many different Haskell signatures

  foo :: Int -> IO Int   -- int foo ([in]int* x)
  foo :: Int -> IO (Int,Int)-- int foo ([in,out]int* x)
  foo :: IO (Int,Int) -- int foo ([out]int* x)
  foo :: Addr -> IO Int-- int foo ([in,ptr]int* x)
  foo :: [Int] -> IO Int -- int foo ([in,max_is(10)]int* x)

or when the return value is some status code (as is the case in COM)

  foo :: Int -> IO () -- int foo ([in]int* x)
  foo :: Int -> IO (Int) -- int foo ([in,out]int* x)
  foo :: IO (Int)  -- int foo ([out]int* x)
  ...

Yours,

Erik

Re: Licenses and Libraries

[S. Alexander Jacobson]

On Thu, 19 Aug 1999, Erik Meijer wrote:
> > Whatever happened to the auto-import of java classes?
> 
> That's what I am supposed to be working on while Sigbjorn is enjoying
> the fjords. We have a nasty bug having to do with the (what we thought
> as) clever way of representing JNI objects in Haskell. There is an
> elegant solution using implicit arguments, but alas that is only
> supported by Hugs :-)

Last I heard (a while ago), there were issues with name mangling (to
handle java overloading semantics).

I suggested to Sigbjorn that MPTC would reduce name mangling to:
__, but I was not sure whether the
HDirect spec mandated support of Haskell98.
Then I never heard back.

What are implicit arguments?  Do they mean that you can even avoid
explicityly specifying arity?  That would be elegant indeed!

-Alex-

___
S. Alexander Jacobson   Shop.Com
1-212-697-0184 voiceThe Easiest Way To Shop

Re: Licenses and Libraries

[S. Alexander Jacobson]

Whatever happened to the auto-import of java classes?

-Alex-

On Thu, 19 Aug 1999, Erik Meijer wrote:

> > And, as a practical step, writing libraries seems like
> > an excellent way to get involved --- especially if they're useable with
> > multiple implementations.
> 
> I can reveal a little secret (Sigbjorn is far away in the Norwegian woods :-) namely 
>that soon H/Direct will directly support .h files, which means that it will even be 
>easier than before to get automate all the boring work in making standard C libraries 
>available to Haskell. Just drag and drop it onto H/Direct and off you go. Hopefully 
>this will convince the COM criticasters and MS sceptists that H/Direct is cool indeed.
> 
> Erik 
> 

___
S. Alexander Jacobson   Shop.Com
1-212-697-0184 voiceThe Easiest Way To Shop

Re: Licenses and Libraries

[Ted Carroll]

I'm not a marketing person and I don't play one on TV --

This seems like a classic case of moving from early adopter/technologist
type of market to a broader/more conservative market.  The biggest thing
that has to be done to get Haskell accepted in the the market segment
that we're discussing is to get people to use it successfully (and tell
other people about it, but first things first).  Right now, nobody in
that segment of people uses Haskell.  I don't think there is a single
package installed by default on a Redhat system that is written in
Haskell.  

Once these folks are using the language, the fixes will come.  One of
the principles often cited buy open source contributors is that the best
software comes from developers who are trying to "scratch their own
itch".  Right now nobody, outside the relatively few people on this
list, has an itch.  No itch, no development.

Anyway, back to getting people in that segment to use Haskell -- It
seems to me that the best way to do that is to build a killer
application written in Haskell.  Something concrete.  Off the top of my
head a good vector graphics program like Corel Draw would be a possible
candidate.  This program would have to be indistinguishable from other
applications.  In other words it couldn't look "weird".  People that had
an itch with respect to the application would need to learn Haskell and
would probably develop an itch our two with the Haskell tools they were
using.

Thanks for listening,

Ted C.

P.S.  If somebody could explain Monads in plain english it might not
hurt either.

Mark P Jones wrote:
> 
> | Getting the licensing right is an important goal, but if anyone thinks
> | that a more liberal license will result in prolific Haskell library
> | development, forget it.  We need worker bees...
> 
> Agreed.  In fact the only reason I mentioned licensing at all in
> my original posting was to make the comparison to Linux.  In fact,
> although I haven't kept records, my sense as far as Hugs is concerned
> is that the number of external patches and bug fixes that we receive
> has actually gone *down* since we moved to the new license ...
> 
> The essence of all this is in trying to figure out where we can find our
> worker bees, how do we move from cathedral to bazaar, etc.  Is that
> possible?  What can we do to stimulate and encourage it?  I'm glad to
> see that this thread has already generated some interesting observations
> and suggestions.  And, as a practical step, writing libraries seems like
> an excellent way to get involved --- especially if they're useable with
> multiple implementations.
> 
> All the best,
> Mark

RE: Licenses and Libraries

[Mark P Jones]

| Getting the licensing right is an important goal, but if anyone thinks
| that a more liberal license will result in prolific Haskell library
| development, forget it.  We need worker bees...

Agreed.  In fact the only reason I mentioned licensing at all in
my original posting was to make the comparison to Linux.  In fact,
although I haven't kept records, my sense as far as Hugs is concerned
is that the number of external patches and bug fixes that we receive
has actually gone *down* since we moved to the new license ...

The essence of all this is in trying to figure out where we can find our
worker bees, how do we move from cathedral to bazaar, etc.  Is that
possible?  What can we do to stimulate and encourage it?  I'm glad to
see that this thread has already generated some interesting observations
and suggestions.  And, as a practical step, writing libraries seems like
an excellent way to get involved --- especially if they're useable with
multiple implementations.

All the best,
Mark

Re: Licenses and Libraries

[Paul Hudak]

Getting the licensing right is an important goal, but if anyone thinks
that a more liberal license will result in prolific Haskell library
development, forget it.  We need worker bees...

  -Paul

P.S. I really like the idea someone suggested of maintaining a list of
open projects, who's working on what, etc. as in the Linux community. 
But, we need a worker bee to do that too :-)

Re: Licenses and Libraries

[Erik Meijer]

> Whatever happened to the auto-import of java classes?

That's what I am supposed to be working on while Sigbjorn is enjoying the fjords. We 
have a nasty bug having to do with the (what we thought as) clever way of representing 
JNI objects in Haskell. There is an elegant solution using implicit arguments, but 
alas that is only supported by Hugs :-)

So keep tuned,

Erik

Re: Licenses and Libraries

[Erik Meijer]

> And, as a practical step, writing libraries seems like
> an excellent way to get involved --- especially if they're useable with
> multiple implementations.

I can reveal a little secret (Sigbjorn is far away in the Norwegian woods :-) namely 
that soon H/Direct will directly support .h files, which means that it will even be 
easier than before to get automate all the boring work in making standard C libraries 
available to Haskell. Just drag and drop it onto H/Direct and off you go. Hopefully 
this will convince the COM criticasters and MS sceptists that H/Direct is cool indeed.

Erik