[Haskell-cafe] Re: ldap-haskell questions (+ rant!)

Donn Cave donn at drizzle.com
Wed Jul 26 13:50:38 EDT 2006

On Wed, 26 Jul 2006, Ferenc Wagner wrote:
> I ended up binding ldap_initialize, which supports ldaps:
> URL-s, and was achievable in a 10 line absolutely
> nonintrusive patch (darcs sent).  Good enough for me ATM.

Yes, actually that's not just a good solution to your problem but
a good idea anyway, since ldap_init() has been deprecated in recent
OpenLDAP releases - I believe I had to define -DLDAP_DEPRECATED=1
to build ldap-haskell.

I have made a little progress on the work I intended to do, and as
of last night I have ldap_start_tls_s working.  We need that to
use SSL (or rather TLS) with servers that don't bind to a separate
SSL port.

To raise a perhaps philosophical point, how do Haskell programmers
feel about adopted names?  In the above paragraph, I said I had
"ldap_start_tls_s" working, but my test code calls ldapStartTls,
because that's what ldap-haskell's author has been doing.

Or would he have written ldapStartTlsS?  but Tls looks really weird
to me, one would think it should be TLS ...

It seems to me that this widespread practice of camel-casing every
adopted name comes at some cost and no benefit.  With code like

    ldap_bind_s a b c LDAP_AUTH_SIMPLE

names are exactly what you find in the underlying C API documentation,
the C include files, etc., and every step away from that costs you
some of that transparency.  Is it LDAPAuthSimple, or LdapAuthSimple?
Is it going to be ldapBindS, or ldapBind?

In case it isn't clear, I would like to advocate for a very conservative
approach to FFI, with the very minimum changes to names and function to
make the FFI work correctly in Haskell terms.  That means changing error
handling and memory management semantics, but it does not mean apparently
gratuitous changes to names, or fiddling with things just because one
doesn't fancy them.

For example, it really annoys me that though I know execve(2) well enough,
I don't have access to this POSIX function in System.Posix.Process but
rather have only some wrapper that has helpfully excluded some of its
functionality.  This didn't need to have been a hard problem - I'm asking
for the easy thing!  You don't need to know why execve() needs to support
argv[0..n].  You don't need to know why there's an ldap_bind_s, and an
ldap_bind.  Just give me access to the functions the way they are, please!


	Donn Cave, donn at drizzle.com

More information about the Haskell-Cafe mailing list