Aren't most of these "java additions" MS J++ or MS specific
rather than java/jdbc "run-anywhere" though?
Hoping that this isnt the case
Chris
> -----Original Message-----
> From: Frank Atanassow [mailto:[EMAIL PROTECTED]]
> Sent: 19 July 2000 10:22
> To: S. Alexander Jacobson
> Cc: Manuel M. T. Chakravarty; [EMAIL PROTECTED]
> Subject: RE: Haskell jobs (fwd)
>
>
> S. Alexander Jacobson writes:
> > Off the top of my head here are some Haskell specific
> things that we need:
>
> > * HSP pages (like ASP or JSP or PHP)
>
> Erik Meijer has done this. Can't find the preprint online,
> though. (Erik?)
>
> > * in memory Haskell server analogous to JServ that talks to apache
>
> mod_haskell?
>
http://losser.st-lab.cs.uu.nl:8080/
> * Haskell access to a pool of database connections
Daan Leijen's HaskellDB?
http://haskell.cs.yale.edu/haskellDB/
> * Haskell access to Java classes
Erik's Lambada
http://www.cs.uu.nl/people/erik/Lambada.html
> * Encapsulation of Haskell as Java classe
I don't know what that means, exactly. You mean a Hugs-like implementation
in
Java? Not a bad idea... do you need that, though, now that GHC can produce
Java bytecode? Anyway, once the Java backend stabilizes, you would (in
principle, at least :) be able to cross-compile GHC into a Java binary, and
then use its upcoming interactive frontend. You still wouldn't have
programmatic hooks (i.e., a Java-level rather than console-level interface)
to
the front-end, but it would become much easier to add.
> And all of this has to be relatively zipless and compatible with an
> existing JServ/JSP/Apache installation.
Eh? "zipless"?
--
Frank Atanassow, Dept. of Computer Science, Utrecht University
Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands
Tel +31 (030) 253-1012, Fax +31 (030) 251-3791
