[eclipsefp-develop] Native libs (was: Getting started)

[Leif F. <hi...@le...>]

>>- It works on Windows where the Haskell code is linked into a dll; but for
>>Linux we'll have to wait until the PIC (position-independent code) support
>>is ready. So we're Windows-only with everything that requires the parser.
> 
> 
> Didn't get what do you meant with position-independent code...
Linking the Haskell and c code into a .so library, i.e. the equivalent 
to a dll on windows. I had a little experience with dlls, but none with 
such libs on Linux, maybe I missed something. But as far as I 
understood, we would have to use the -fPIC flag in GHC, which does not 
work for Linux yet.

But if anybody knew a way to do it for Linux, that would be great of 
course. You could have a look at how I did the linking for Windows (had 
to do a bit of googling until I found out how it works). The Haskell and 
c code is in net.sf.eclipsefp.haskell.core.parser.win32/src/, and the 
lines I used to build the dll in 
net.sf.eclipsefp.haskell.core.parser.win32/INTERNAL/conf/build.bat. I 
run the .bat as an external tool builder in Eclipse.

I'm very much for platform independence. I think we should at least aim 
to have support for Windows, Linux and Mac. For this I just decided to 
hope that that feature in ghc would soon be available.

> I think Windows dependency is the worst issue. Platform independence
> should be one of our main concerns here if we want to get a large
> number of users. What are the alternatives we have for it? I have
> thought of at least three and I list them here with the main
> disadvantages:
> 
> 1. To take the same approach with other platforms (to port the
> library): this doesn't achieve all that platform independece, but can
> be pratical depending on our target public.
> 
> 2. To re-implement the parser in Java: maybe this is much work to do.
> But we can always take a incremental approach and there is the
> haskell-src for us to use as a starting base. This would be almost a
> translation process.
> 
> 3. To implement a haskell to Java bytecode compiler, so that we can
> run the same haskell-src parser inside the Java Virtual Machine: much
> more work than in the number 2 alternative, but yields a much useful
> result. There is an issue here although: functional language to
> 'object-oriented' machines is very unstable at the moment and this
> would be more like a research project.
> 
> Any other ideas?
We had a bit of brainstorming about that issue on this list a while ago 
(almost exactly a year ago, actually). Since then we had a small parser 
written in Java (written by Andrei) and more recently the bridge to 
haskell-src.

Since I tried my hand on the latter, I think it is ok to handle native 
libs, provided they are portable. By this I mean that the Haskell and c 
code is one and the same and is just compiled and linked into different 
libs at build time. I can live well with that approach. (Under the 
condition that we get Linux libs in the near future.) So I'm leaning to 
alternative 1).

One obvious advantage is that we can code some of the interesting bits 
in Haskell, while leveraging the Eclipse platform for UI and 
language-independent things (i.e. everything that comes for free like 
CVS support, Help system etc.). The latter is my main speciality, so I'm 
of course very glad if someone takes interest in other areas, like you 
do with debugging (where it is my turn to do some more homework still ;-).

Ciao,
Leif