S. Alexander Jacobson writes:
> > At 03:55 AM 9/9/99 , Mark P Jones wrote:
> > Some folks out there want to use Haskell to write real programs. For
> > them, there's Haskell 98.
>
> To be clear, I am not an academic researcher. I develop real world
> web sites. I would really like to use Haskell for this process, but the
> tools and libraries are not yet there to get this done in an effective
> manner.
My interest in Haskell is also for writing real programs, some of them business
applications. I'm also interested in using it on web sites (and CGI
applications). I have sometimes used Haskell in my professional life, and deeply
wish to renounce lesser languages forever - writing programs in Haskell is
interesting (C++ stopped interesting me about five years ago) and
mind-expanding.
> Much of the substance of our real world web development involves:
> 1. talking to databases
> 2. talking to other web servers (via http)
> 3. processing XML schema and data files
> 4. generating HTML/XML which mixes string constants with values
> derived from databases and xml files
>
> Haskell98 is good at none of these things, but Haskell so clearly could be!
Saying H98 is no good at these things is an overstatement, but I agree that it
is too lame compared with the much more elegant approaches possible given a some
extensions (many of which are already in ghc).
> Putting aside sexy type system innovations, even basic stuff like the File
> and Directory Libraries clearly needs a major overhaul. Absent a working
> FFI standard, development of the File Directories is happening out in
> space. Real world directory APIs, like LDAP, NDS, and Active Directory,
> are emerging, compatibility with which would be really nice.
> Javasoft has defined a reasonably sane JNDI spec which subsumes a lot of
> file and directory functionality. If Lambada goes up, then it would be
> really sane for the standard File and Directory APIs to mirror JNDI more
> closely (and an easy implementation would be a shallow wrapper around the
> underlying JNDI functionality!). I would make similar points about HTTP
> and SQL libs but there is no standard haskell Net or Database module as
> there is in e.g. Java. (however doesn't lambada assume type system
> extentions?)
It is good for Haskell to be inter-operable with proprietary tools, but I don't
want it to depend on them to implement its standard libraries. I prefer Free
Software.
> Of course, it may be worth someone's time to construct collection classes
> to abstract out database semantics, but the fact that MPTC appears
> designed for the task would make any reasonable developer unwilling to
> restrict themselves to H98.
Indeed (except that extensible records are also needed to do a really good job
of database access).
> On the sexy type system front, the reason why I have been campaigning so
> hard for generic programming interfaces (either via Derive, PolyP, or a
> Categorical Prelude), is that they substantially facilitate much of the
> real work associated with talking to databases and XML files. The actual
> application logic encoded into most of these apps is really small. The
> hard part is building the plumbing to connect all the data sources and
> sinks together. Generic programming interfaces mean that you don't spend
> enourmous amounts of time manually translating haskell datatypes into and
> out of SQL and XML schema (a desired blue sky application is automatic
> optimal compression of valid XML data files as an HTTP transfer encoding
> option).
I agree. Computer science and other scientific applications tend to be clever
programs such as compilers, where data is well structured and processing is
complex. But business applications typically have rather shallow processing,
with lots of semi-arbitrary types of data records to be edited, moved around,
and stored; handling these records often accounts for most of the code in a
business application. In these cases polytypic programming techniques can save a
lot of work. At present I'm hopeful that Derive can meet my polytypic needs,
since neither PolyP nor a categorical prelude look likely to be usable soon.
One problem with both PolyP and the categorical prelude is that they do not seem
to support records with more than two fields. Of course, one can build up
multi-field records from nested two-field types (just like a binary tree), but
is this the right way (or just a workable way) ? Also, the categorical prelude
(not sure about PolyP) does not provide a way to get access to type/field
names (this is not interesting from a CS POV, but would be very useful for
automatically generated GUIs for editing records).
> Yes, you can use various extensions that people have around, but the
> plumbing overhead of wrapping them into any individual project typically
> exceeds the overhead of doing the actual work. The economies of scale you
> get from sharing work or just not there yet.
Nonetheless, I have no intention of restricting myself to H98. I would rather
work around the difficulties of the bleeding edge than accept the lack of
important features e.g. MPTC. My reason is that the payoff from most of these
new features is so large that it outweighs issues of changeability etc. . So far
as I'm concerned, for practical purposes, the Haskell language is defined by
what ghc compiles. I'd like to also use Hugs, for a more interactive development
environment, but it shows little sign of ever being sufficiently compatible (it
is becoming increasing compatible in core aspects, but I want to use most of the
features of ghc, and the benefit of having an interpreter is quickly lost in
having to support two different language dialects).
> The value of the generic programming interfaces is so hight that it
> certain that one of them will become standard. The issue here is that the
> cost of adopting the loser will result in a lot of orphaned code.
But I suspect that all the Haskell techniques here are analogous to C++'s kludgey
attempt at a polymorphic type system (templates). It is suggestive that two of
them involve pre-processors. Still we need to use something, and true
categorical languages are probably still a long way from being usable. I would
have been somewhat interested in Charity, but the implementation is not Open
Source (IIRC one of those "free for non-commercial use" ones), which does not
inspire me with confidence.
Tim
