Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)
On 14-Aug-1998, Timothy Robin BARBOUR [EMAIL PROTECTED] wrote:
"David" == David Glen JEFFERY [EMAIL PROTECTED] writes:
David Depending on how you do it, the choice of ORB may not be
David such a huge issue. Our (infantile) Mercury implementation
David does not talk to the ORB directly, but rather goes via C++
David stubs and skeletons. In this way, we have a very small
David module of ORB-specific (initialisation etc.) code, but the
David rest of our implementation should (we believe ;-) ) work
David with any C++ compliant ORB.
How do you produce the stubs and skeletons ? Do you generate them from
IDL ?
Yes, we have and IDL parser which generates a few files.
We generate a thin layer over the C++ binding at the moment.
Stubs and skeletons are generated as typeclasses.
For the skeleton the Mercury object must be put into a C++ object, and
the methods of the C++ object call the methods of the Mercury object.
For the stubs, an instance of the typeclass is generated that holds
a reference to the C++ object, and just calls the C++ methods.
How does Mercury call C++ anyway - what about the C++ name mangling ?
extern "C" { . }.
Mercury doesn't have a native C++ interface, we go via C.
At the moment it's a bit kludgey, you need to put things into separate
files. But since it's all machine generated it isn't too much of a
problem.
We hope in future to interface a bit more directly from C++, so
that you can at least put C++ in your Mercury source code. It's
probable that it will have to be compiled in a separate file, however.
(I don't know whether this will make it to the haskell mailing
lists -- I've tried subscribing several times and had no luck so
far).
Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)
"Sigbjorn" == Sigbjorn Finne [EMAIL PROTECTED] writes: Sigbjorn Advice on what's the most appropriate ORB to target Sigbjorn would be greatly appreciated, there's already quite a Sigbjorn selection to choose from (ORBit, Mico, omniORB etc.) omniORB2 is CORBA-2 and IIOP compliant (and tested with other ORBs), appears to be still tracking the CORBA standard, is GPL'ed, multi-threaded, and fast (possibly the fastest CORBA-2 ORB in existence). omniORB2 supports most platforms. It seems that the GNOME project (the main competitor to Berlin) was using MICO (see my expression of doubt about its performance, in another posting), but they now seem to be using ORBit. I couldn't quite tell who is developing ORBit, but Red Hat seems to be involved. Anyway, ORBit seems to be still work in progress (which may not matter if it is ready when the Haskell binding is ready). I noticed one suggestion on the ORBit page for a way to eliminate argument marshalling when calling within the same language, which suggests it may eventually be very fast, if development goes far enough. ILU and Arachne are not full CORBA-2 implementations, and the GNOME project rejected ILU because its licensing was insufficiently free. That leaves TAO, ISP, and Electra. I could not find Electra - it seems to have disappeared from the net. TAO is still work in progress. ISP has some interesting extensions to simplify memory management, but I could not reach its home page just now. This page has a comparison and summary of free CORBA implementations for Linux: http://linas.org/linux/corba.html (The author favours omniORB and MICO, and shows some figures where MICO is five times as slow as omniORB, but the figures date from October 1997.) Tim -- -- T.R.BARBOUR Email : [EMAIL PROTECTED] -- Department of Computer Science The University of Melbourne Parkville, Victoria 3052 Australia --
Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)
"Marko" == Marko Schuetz [EMAIL PROTECTED] writes: Marko FYI, there is also MICO: Marko http://www.vsb.cs.uni-frankfurt.de/~mico/ The MICO home page says: The difference to other free imlementations is, that MICO is developed for educational purposes [...] As opposed to use as a tool ? We were inspired by Tanenbaum's MINIX project which is something similar in the UNIX community. I don't think MINIX was terribly successful as a tool, since I'm typing this on a Linux box. [...] o omit bells and whistles: only implement what is required for CORBA compliant implementation. Runtime efficiency is not an issue. Perhaps I mis-read this, but it sounds as if the designers of MICO do not consider efficiency important. CORBA has plenty of potential for slowness, without being encouraged. The omniORB2 page has performance measurements that show it as being faster than most other ORBs. See http://www.orl.co.uk/omniORB/omniORBPerformance.html Tim -- -- T.R.BARBOUR Email : [EMAIL PROTECTED] -- Department of Computer Science The University of Melbourne Parkville, Victoria 3052 Australia --
Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)
From: Daan Leijen [EMAIL PROTECTED] [...] Allthough we have made a binding now for COM, it would indeed be great if we could also have a CORBA binding; it is of vital importance that Haskell can talk with the outside world and the more languages it knows, the better :-) Since there is a serious lack of programmers, it would be very nice if someone would like to adapt H/Direct and the COM run-time modules to create a CORBA binding on a UNIX system; any volunteers ? How big an effort would it be? Do you have any estimate? Manuel The actual work of adapting the compiler and changing/creating the run-time support can probably done in a couple of weeks. However, this implies that you know *a lot* about CORBA and know *exactly* how to design the Haskell model. The CORBA spec. is huge and there are many ORB's around. It could take quite some time before you are familiar enough with it, to know what to do. My guess is that it would take at least 4 months with someone who is an expert at haskell and familiar with component frameworks. Anyway, H/Direct is not even officially released yet, and I would highly recommend it as a starting point for a CORBA binding. Cheers, Daan.
Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)
From: Daan Leijen [EMAIL PROTECTED] [...] Allthough we have made a binding now for COM, it would indeed be great if we could also have a CORBA binding; it is of vital importance that Haskell can talk with the outside world and the more languages it knows, the better :-) Since there is a serious lack of programmers, it would be very nice if someone would like to adapt H/Direct and the COM run-time modules to create a CORBA binding on a UNIX system; any volunteers ? How big an effort would it be? Do you have any estimate? Manuel
Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)
Manuel M. T. Chakravarty writes: [snip] 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. It doesn't mean anything more than it says: we will provide a binding to COM first, before going on to other component technologies, resources being finite and all that. And since the range of types supported by OSF DCE IDL (which the Microsoft IDL Compiler uses to describe COM interfaces) and OMG's CORBA IDL are largely compatible, it will not constitute a rewrite of the compiler. How this can be construed to mean that this effort is founded on proprietary standards (hence being 'useless'), I do not understand. 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. If you want to align yourself with some component technology, such as COM, you'll better talk their common interface language, no? The IDL that Microsoft supports is OSF DCE IDL (developed for specifying RPC-based interfaces), but extended with a couple of new declarations to support describing software component interfaces (i.e., the extensions are there out of *necessity*.) Microsoft's use of IDL preceeded the availability of something like CORBA's IDL, which is one reason why COM interfaces aren't specified using CORBA syntax. But, frankly, the language doesn't matter - if NoddyBasic had been used, that's what we would have to support too! If Microsoft should decide to change their IDL, our compiler would have to change too, same as if OMG should publish an IIOP-3 spec that made a number of changes to their IDL. 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 Somehow providing your own custom interface language doesn't have much merit here in my opinion, see above (and the experiences made with Green Card.) --Sigbjorn
Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)
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
Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)
From: Timothy Robin BARBOUR [EMAIL PROTECTED] "Sigbjorn" == Sigbjorn Finne [EMAIL PROTECTED] writes: Sigbjorn As part of H/Direct, we're going to support something Sigbjorn similar to JNI for the new Hugs/GHC system, see Sigbjornhttp://www.dcs.gla.ac.uk/fp/software/hdirect [...] Sigbjorn This document expresses the interface in terms of a Sigbjorn bunch of COM interfaces, but that's just one way of Sigbjorn packaging up the provided API. What about a CORBA interface. CORBA is an open, vendor-independent standard. There is a good open-source ORB, namely omniORB , see http://www.orl.co.uk/omniORB/omniORB.html omniORB is CORBA-2.0 and IIOP compliant and is GPL licensed. The Berlin GUI project (an open-source, CORBA-based, next-generation windowing system), see http://www.berlin-consortium.org/ will use omniORB. If there were a Haskell CORBA mapping, then Berlin components would be accessible from Haskell, and Haskell could be used for scripting Berlin components. This would be very helpful in GUI matters. omniORB could be used as the ORB for a Haskell CORBA mapping. The main work would be arranging generation of Haskell stubs and skeletons. The Haskell Server page claims that one advantage of COM is that it "ships for free with windows". This suggests that the existence of a genuinely free CORBA ORB has been overlooked. Yes, and there is another red hering. The Haskell Server page also says that COM is great, because 90% of all computers run Windows. However, the important question is, how many precent of all Haskell users run Windows? I am pretty sure that most of us use some flavour of Un*x... 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. Cheers, Manuel
Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)
On 09-Aug-1998, Erik Meijer [EMAIL PROTECTED] wrote: Hi Tim, The Haskell Server page claims that one advantage of COM is that it "ships for free with windows". This suggests that the existence of a genuinely free CORBA ORB has been overlooked. IMHO ignoring CORBA is cutting Haskell off from the open software world (including about 7 million Linux users), and from those who dislike/fear Microsoft or just want a non-proprietary standard. We have been blinded by the MS propaganda I guess, but now I agree with you completely that we are missing a big market by doing only COM I couldn't agree more. In fact, a colleague (Tyson Dowd) and I are in the middle of implementing a CORBA binding for Mercury. Although we may look at COM in the future, we feel that CORBA is the more important target for the moment. (...and it means that we can develop it under Linux ;-) ). As Sigbjorn said in his reply, it is hard to decide which ORB to use, and I did not know about omniORB. Depending on how you do it, the choice of ORB may not be such a huge issue. Our (infantile) Mercury implementation does not talk to the ORB directly, but rather goes via C++ stubs and skeletons. In this way, we have a very small module of ORB-specific (initialisation etc.) code, but the rest of our implementation should (we believe ;-) ) work with any C++ compliant ORB. FWIW, we are using omniORB for the moment. Great new project for the new academic year! Indeed. dgj -- David Jeffery ([EMAIL PROTECTED]) | Arithmetic is being able to count PhD student,| up to twenty without taking off Department of Computer Science | your shoes. University of Melbourne, Australia | -- Mickey Mouse
Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)
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. Lets clarify some points: - H/Direct is a OSF DCE IDL compiler which can not only generate COM specific bindings but also for example bindings for general C libraries or dynamic libraries or some CORBA binding. Thanks to sigbjorn's expertise, it is a very modular and adaptable compiler that is freely available and it should be pretty easy to add a CORBA binding. - HaskellServer is an interface specification that allows other software components to use Haskell programs by accessing the interpreter/compiler. It has an IDL specification and allthough the only implementation now is for COM, nothing prevents you from writing an implementation under UNIX with ORBIX ! (btw. I changed the design a lot the past few weeks, and I will update the documentation the coming weeks; thereby deleting the COM agains CORBA section, this is just my personal view of things and should probably not belong in that document.) - HaskellScript *is* a COM specific piece of software that lets Haskell programs be used as a generic scripting language for programs like MS Word or Internet explorer; much like JavaScript and VBScript. It is COM specific because it uses ActiveX interfaces which specify a general infrastructure in which components can interact. (ie. drawing, persistance, events). However, this work *could* be done just as easy for UNIX CORBA *if* there were standard interfaces for implementing a scripting binding. [Note that it is ActiveX that makes COM a very attractive platform. Because of ActiveX, many ready to use components are available, like ADO for accessing databases, IE for accessing the internet and DirectAnimation for doing fancy animations. Without such an infrastructure, no market for reusable components can exist. (http://www.internetworld.com/print/1997/12/08/software/19971208-critic.html ) ] Allthough we have made a binding now for COM, it would indeed be great if we could also have a CORBA binding; it is of vital importance that Haskell can talk with the outside world and the more languages it knows, the better :-) Since there is a serious lack of programmers, it would be very nice if someone would like to adapt H/Direct and the COM run-time modules to create a CORBA binding on a UNIX system; any volunteers ? All the best, Daan.
Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)
Manuel M. T. Chakravarty 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. Sigh, it's not *based* on proprietary standards - whatever gave you that idea? 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 that still won't make you happy, then the sources are freely available, so you're welcome to contribute bits that would increase your level of happiness re: Hugs/GHC interoperation. --Sigbjorn
Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)
Hi Tim, The Haskell Server page claims that one advantage of COM is that it "ships for free with windows". This suggests that the existence of a genuinely free CORBA ORB has been overlooked. IMHO ignoring CORBA is cutting Haskell off from the open software world (including about 7 million Linux users), and from those who dislike/fear Microsoft or just want a non-proprietary standard. We have been blinded by the MS propaganda I guess, but now I agree with you completely that we are missing a big market by doing only COM so a CORBA binding is now high on my priority list. As Sigbjorn said in his reply, it is hard to decide which ORB to use, and I did not know about omniORB. Great new project for the new academic year! Erik
Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)
Timothy Robin BARBOUR writes: "Sigbjorn" == Sigbjorn Finne [EMAIL PROTECTED] writes: Sigbjorn As part of H/Direct, we're going to support something Sigbjorn similar to JNI for the new Hugs/GHC system, see Sigbjornhttp://www.dcs.gla.ac.uk/fp/software/hdirect [...] Sigbjorn This document expresses the interface in terms of a Sigbjorn bunch of COM interfaces, but that's just one way of Sigbjorn packaging up the provided API. What about a CORBA interface. CORBA is an open, vendor-independent standard. There is a good open-source ORB, namely omniORB , see Sure, you could package up this with a CORBA interface too. However, this interface will just expose a low-level invocation interface ala JNI, which is somewhat primitive if you're planning to implement CORBA objects in Haskell. For that, you'll want an IDL compiler capable of generating stubs that takes care of dressing up your Haskell code as a CORBA object. I'm just about to start implementing IDL compiler support for generating Haskell COM object stubs, but once that is finished, I'd like to extend H/Direct to also deal with CORBA and OMG's IDL syntax. (I believe there are others also working on making Haskell more CORBA-friendly.) Advice on what's the most appropriate ORB to target would be greatly appreciated, there's already quite a selection to choose from (ORBit, Mico, omniORB etc.) --Sigbjorn
Re: Haskell, CORBA and Java (Was: Re: Current state of GUI...)
"Sigbjorn" == Sigbjorn Finne [EMAIL PROTECTED] writes: Sigbjorn As part of H/Direct, we're going to support something Sigbjorn similar to JNI for the new Hugs/GHC system, see Sigbjornhttp://www.dcs.gla.ac.uk/fp/software/hdirect [...] Sigbjorn This document expresses the interface in terms of a Sigbjorn bunch of COM interfaces, but that's just one way of Sigbjorn packaging up the provided API. What about a CORBA interface. CORBA is an open, vendor-independent standard. There is a good open-source ORB, namely omniORB , see http://www.orl.co.uk/omniORB/omniORB.html omniORB is CORBA-2.0 and IIOP compliant and is GPL licensed. The Berlin GUI project (an open-source, CORBA-based, next-generation windowing system), see http://www.berlin-consortium.org/ will use omniORB. If there were a Haskell CORBA mapping, then Berlin components would be accessible from Haskell, and Haskell could be used for scripting Berlin components. This would be very helpful in GUI matters. omniORB could be used as the ORB for a Haskell CORBA mapping. The main work would be arranging generation of Haskell stubs and skeletons. The Haskell Server page claims that one advantage of COM is that it "ships for free with windows". This suggests that the existence of a genuinely free CORBA ORB has been overlooked. IMHO ignoring CORBA is cutting Haskell off from the open software world (including about 7 million Linux users), and from those who dislike/fear Microsoft or just want a non-proprietary standard. If there were a CORBA interface to Haskell, I would be contacting the Berlin developers and suggesting they try writing parts of Berlin in Haskell (they can already use C, C++, Java, Ada, Lisp, Scheme, Perl, Python etc. since these languages have CORBA mappings). What a pity. I have just introduced CORBA to a large stock-broking software company which I am consulting to. If Haskell had a CORBA mapping I might eventually be able to persuade them to try writing some application components in Haskell. It would also help in the latter case if ghc were clearly and unambiguously GPL. It is hard enough to introduce new technology, without licensing concerns. I have already given up an opportunity to use hugs in a commercial setting because of its "free for non-commercial use" license. I used perl instead, since it would have been politically impossible to introduce a suspiciously modern tool that required contacting some academics to see if the use was acceptable. Tim -- -- T.R.BARBOUR Email : [EMAIL PROTECTED] -- Department of Computer Science The University of Melbourne Parkville, Victoria 3052 Australia --
