Re: FP Naming/Directory Service

[Fergus Henderson]

On 25-Mar-1998, S. Alexander Jacobson <[EMAIL PROTECTED]> wrote:
> 
> In both the ODBC and DS cases, it would be useful if someone would define
> a standard Haskell interface to database or ds services.  
> Javasoft did not actually provide an ODBC implementation, instead they
> provided an interpretation of rel databases for java (JDBC).  The
> JDBC-ODBC bridge was straightforward, but the key point was to give java
> programmers a consistent way to access any relational database.  I mailed
> Dima in order to get the ODBC source, so for a particular task that may be
> useful, but his ODBC is a particular implementation of accessing
> rel-databases from Haskell.   

If you're looking for inspiration about what an ODBC interface should
look like in a declarative programming language, you might want to
take a look at the ODBC interface that is included in the Mercury distribution
,
or at the following paper, which describes our general approach:

   Kemp, Conway, Harris, Henderson, Ramamohanarao and Somogyi,
   "Database transactions in a purely declarative 
   logic programming language", 
   Technical Report 96/45, Department of Computer Science, 
   University of Melbourne, December 1996,
   http://www.cs.mu.OZ.AU/publications/tr_db/mu_96_45.ps.gz

Obviously there will be some differences in Haskell, but
I think quite a bit of the interface could carry over into Haskell.

-- 
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: FP Naming/Directory Service

[David Barton]

S. Alexander Jacobson writes:

   The difficulty is that we typically develop on Windows and Linux
   and deploy on linux or solaris.  The system I am working on
   involves using CGI/servlets to update a directory server and then a
   Java based produciton system (Jess, a CLIPS clone), to process the
   directory information.  Javasoft doesn't appear to have implemented
   an ADSI client.

   In general, IDL/CORBA would be prefereable to COM because it is
   more cross-platform (specifically it can operate as a client to
   Java servers).

Strongly, *strongly* agree --- and not just because of Java.  I know
that Microsoft has an incredible share of the market; however, using
standard formats rather than proprietary ones is always of benefit if
we are doing things cross-platform (which many of us do).

Dave Barton <*>
[EMAIL PROTECTED] )0(
http://www.intermetrics.com/~dlb

Re: FP Naming/Directory Service

[S. Alexander Jacobson]

On Wed, 25 Mar 1998, Erik Meijer wrote:

> Hi Alex,
> 
> 
> >I just started playing with Haskell for CGI applications.
> >I would like to try writing a more serious CGI app, but
> >missing infrastructure makes it more difficult than conventional
> >approaches.
> >
> >In decreasing order of preference, is there an available implementation of:
> >* an equivalent to Java's Naming and Directory Services interface
> >* an LDAP client for some particular LDAP server
> 
> If you don't mind to restrict yourself to Windows, and these applications
> are available as COM Automation objects you
> are done. We already interfaced to the ADSI components,
> would  that be enough?

The difficulty is that we typically develop on Windows and Linux and
deploy on linux or solaris.  The system I am working on involves using
CGI/servlets to update a directory server and then a Java based produciton
system (Jess, a CLIPS clone), to process the directory information.
Javasoft doesn't appear to have implemented an ADSI client.  

In general, IDL/CORBA would be prefereable to COM because it is more
cross-platform (specifically it can operate as a client to Java servers).
 
> In theory we can interoperate with any plain COM component, but
> the technology for that is not yet stable. And as Alastair pointed
> out GreenCard can be used to interface to plain C libraries.

Yes, but the pointer page says that Greencard is likely to be replaced.
 
> To answer Tommy:
> > I think there are two major causes to this effect: one is the high
> > emphasize on theoretical aspects of the language and a disproportional
> > low effort on plain practial aspects.

In both the ODBC and DS cases, it would be useful if someone would define
a standard Haskell interface to database or ds services.  
Javasoft did not actually provide an ODBC implementation, instead they
provided an interpretation of rel databases for java (JDBC).  The
JDBC-ODBC bridge was straightforward, but the key point was to give java
programmers a consistent way to access any relational database.  I mailed
Dima in order to get the ODBC source, so for a particular task that may be
useful, but his ODBC is a particular implementation of accessing
rel-databases from Haskell.   

Javasoft's JNDI is similar.  Javasoft is not supplying a directory server
or even defining a particular directory interface e.g. LDAP or NDS or ADSI
instead it is defining a convenient and general way of accessing directory
service semantics within Java.  

A standard definition of what it means to talk to a persistent hashtable,
a directory server, or a relational database from Haskell would make it
much easier to reuse subsequent implementations (drivers) written in
Haskell or in Haskell calling C or whatever.

In principle, (I don't know if this is true), you could abstract your COM
code into a generic distributed object interpretation in Haskell.  One
could then implement a COM or Corba interface to the remote objects via
some driver.  Javasoft is doing something similar with RMI->Corba now (but
not well).

> I agree, if only I had the resources!
I am not saying that you need to implement all of this code.  If you just
define APIs and SPIs, other people can supply implementations.  Obviously
spec definition is also a lot of work.  I am just suggesting that it is
less than doing full implementations.

-Alex-
___
S. Alexander Jacobson   i2x Media  
1-212-697-0184 voice1-212-697-1427 fax

Re: FP Naming/Directory Service

[Dima Skvortsov]

I am newbie to functional programming although I have
a certain experience with industrial strength C/C++ programming.
I have started not so long ago a work on Haskell ODBC client.
I work on it in my spare time and there is a _very_ draft version available
now.
Green-Card was used to interface to ODBC library.
I am using Hugs 1.4 on a win95 machine and testing my client
against dbf ODBC driver :)
Although it seems to work.
It is possible now to connect/disconnect to data source,
run SQL statements with or without parameters,
obtain data from query.
I cannot put this stuff on ftp and I don't want to do it now
because it's too dirty yet.
Anyway I can mail it to someone who is interested.
It's about 150K zipped with dll's and I guess about 10K with
source code only (Haskell and Green-Card source files)
Any comments, ideas, suggestions will be greatly appreciated.

Re: FP Naming/Directory Service

[Erik Meijer]

Hi Alex,


>I just started playing with Haskell for CGI applications.
>I would like to try writing a more serious CGI app, but
>missing infrastructure makes it more difficult than conventional
>approaches.
>
>In decreasing order of preference, is there an available implementation of:
>* an equivalent to Java's Naming and Directory Services interface
>* an LDAP client for some particular LDAP server

If you don't mind to restrict yourself to Windows, and these applications
are available as COM Automation objects you
are done. We already interfaced to the ADSI components,
would  that be enough?

In theory we can interoperate with any plain COM component, but
the technology for that is not yet stable. And as Alastair pointed
out GreenCard can be used to interface to plain C libraries.

>* an XML editor

Perhaps you mean an XML parser/unparser. The MS XML parser
is an Automation object, so it can be scripted from Haskell. Implementing
a full XML parser and pretty-printer in Haskell is not hard. A generic XML
parser that ignores the DTD but parses any well-nested document can
be programmed using a few lines of parser combinators.

>* a generic ODBC/JDBC database client
>* an interface to berkeleyDB (or some persistent hashtable implementation)


This is high on our list too.

>I suppose that I could have Haskell talk to Jacl to access the Java
>implementations of these capabilities, but this seems like a hack.
>
>Any pointers?


Hop this helps, if you need more specifc information don't hesitate
to contact me.

To answer Tommy:

> I think there are two major causes to this effect: one is the high
> emphasize on theoretical aspects of the language and a disproportional
> low effort on plain practial aspects.

I agree, if only I had the resources!

Erik

FP Naming/Directory Service

[Tommy Thorn]

S. Alexander Jacobson wrote/a ecrit/skrev:
> I just started playing with Haskell for CGI applications.
> I would like to try writing a more serious CGI app, but
> missing infrastructure makes it more difficult than conventional
> approaches.

On a general note, I too try employ Haskell for more and more common-
day tasks (eg replacing a great number of shell/Perl hacks) and almost
daily face the lack of support, mostly in the form of missing
libraries.

I think there are two major causes to this effect: one is the high
emphasize on theoretical aspects of the language and a disproportional
low effort on plain practial aspects.  Contrast this with the
development of languages like Erlang and Java.  In the latter case the
language was carved in stone long time ago (*) and the effort
concentrated on producing a mind-bogling large library, covering all
sorts of applications.

Another causes is the simple observation that Java users largely
outnumber Haskell users.

The only option we have (IMHO) is to ease and streamline the process
of introducing new libraries and write and make available good
libraries as the needs are encountered.  In this respect, GreenCard
constitutes a key element.


(*) I'm not claiming that this is a good idea, even less that they
where successful.

> In decreasing order of preference, is there an available
> implementation of:
> * an equivalent to Java's Naming and Directory Services interface
> * an LDAP client for some particular LDAP server
> * an XML editor
> * a generic ODBC/JDBC database client
> * an interface to berkeleyDB (or some persistent hashtable
>   implementation)
> 
> I suppose that I could have Haskell talk to Jacl to access the Java
> implementations of these capabilities, but this seems like a hack.
> 
> Any pointers?

I don't the first three at all, so I can't comment on them.  AFAIK,
writing a library with more or less the same functionality as
ODBC/JDBC should be perfectly doable.  As for the latter, I imagine
that something very useful could be built in combination with the
Binary library from York (a should-be standard library, IMHO).

/Tommy

Re: FP Naming/Directory Service

[Alastair Reid]

"S. Alexander Jacobson" <[EMAIL PROTECTED]> writes:
> I just started playing with Haskell for CGI applications.
> I would like to try writing a more serious CGI app, but
> missing infrastructure makes it more difficult than conventional
> approaches.

I presume you've already got hold of Erik Meijer's cgi script stuff.
(If not, there's a copy in the current Hugs distribution at
 http://haskell.org/hugs.)

I'm afraid I'm not familiar with most of the other things you want.
I know GHC (another Haskell compiler) provides an ndbm interface
 but AFAIK it's not (currently) portable to other compilers.

> I suppose that I could have Haskell talk to Jacl to access the Java
> implementations of these capabilities, but this seems like a hack.

Nothing wrong with reusing existing code.  Here at Yale we're very 
interested in interoperability with C, C++, etc. because it's
unrealistic to expect every library to be (re)implemented in Haskell.

One approach to interoperability is GreenCard 
(http://www.dcs.gla.ac.uk/fp/software/green-card/)
- a tool/language for describing C functions in the way Haskell
programmers want to see them.

Another approach is to use IDL (cf COM, CORBA, etc) - which lets you
 describe functions (in any language) in a way that programmers (of
 any language) want to see them.  SimonPJ's
 paper about COM (see http://www.dcs.gla.ac.uk/~simonpj/) is a good
 place to look - but note that they're not distributing an
 implementation (yet!)

Of course, it might be that the Java libraries aren't powerful enough
to do the job or force an unnatural programming style on Haskell
programmers.  In that case, we should think about implementing them
ourselves.

-- 
Alastair Reid  Yale Haskell Project Hacker
[EMAIL PROTECTED]  http://WWW.CS.Yale.EDU/homes/reid-alastair/

FP Naming/Directory Service

[S. Alexander Jacobson]

I just started playing with Haskell for CGI applications.
I would like to try writing a more serious CGI app, but
missing infrastructure makes it more difficult than conventional
approaches.

In decreasing order of preference, is there an available implementation
of:
* an equivalent to Java's Naming and Directory Services interface
* an LDAP client for some particular LDAP server
* an XML editor
* a generic ODBC/JDBC database client
* an interface to berkeleyDB (or some persistent hashtable implementation)

I suppose that I could have Haskell talk to Jacl to access the Java
implementations of these capabilities, but this seems like a hack.

Any pointers?

-Alex-

___
S. Alexander Jacobson   i2x Media  
1-212-697-0184 voice1-212-697-1427 fax