RE: Haskell Wish list: library documentation

[S. Alexander Jacobson]

On Tue, 14 Sep 1999, Mark P Jones wrote:
> given further enhancements.  So perhaps I should have said: "Some
> folks out there want to write programs in a stable language.
> For them, there's Haskell 98."  For the rest, there are choices to be
> made.  One person may decide that programming in "ghc" rather than
> "Haskell" will suit them best.  Another may be more hesitant, but
> hopeful that Haskell will soon become the language they want it to be.
> And so on ...

We all want to program in a stable language because there are a lot of
rewards that come with scale (with enough eyes all bugs are shallow).
The issue is whether H98 as is useful enough to accumulate a large
enough  base of users whose interests match my own.

It is nice to have a definition of some base level compatibility, but we
should all expect rapid evolution of the language a' la HTML/XML/CSS.

Since the language is changing so rapidly (regardless of when the
standards bodies certify the changes), it makes sense to allow
more diversity in the definition of Haskell to allow for more and better
libraries.  Why not do something like "Haskell by Contract(tm :-)" 

* Language implementors should declare which language features they support
* Library writers should specify which language features they require

That way it is easy for both a prospective user as well as a language
implementor to figure out what they are betting on.  

Language implementors know which changes will break which libraries and
which language features are most used/popular.

Library writers know how well supported each language features is and can
measure the liklihood that their code will be orphaned by future lack of
support for the feature.

The key issue here is how library writers should document the language
features which their libraries require.  Ideally Haskell implementations
would come with a tool that looks at a program and automatically
enumerates the language features used.  
(I don't know enough about compiler design to know how easy this is, but
the +H98 feature of Hugs seems to be a step in this direction).

Also nice would be a sense of the size of the userbase for libraries.  So
everyone can have a good sense of how many users depend on a particular
language feature either directly or indirectly.

> | application. In these cases polytypic programming techniques can save
> | a lot of work.
> 
> I'd really like to know more about this, as might others with interests
> in polytypic programming.  Could you provide some examples to illustrate
> this?

Design
A lot of our application development takes the form of designing a
datastructure to describe the content of the site.  The initial Shop.com
site actually used Haskell datastructures for Categories and Merchants.
Now we are using an XML Schema.

Production
Once this datastructure is defined.  It needs to be filled in with
content.  Our content is a taxonomy of shopping sites and the merchants
that have offerings in each category.  We have been maintaining this
content by hand editing a big Haskell source file with the data.  Now we
edit a big XML file using an XML editor.  It would be nicer if we had some
way of directly exporting Haskell datastructures into some editable
interface and then saving them back into some serialized form for later
use.  XML Editors are a form of this generic data structure editor.
Haskell's stronger type system makes it possible to auto-generate better
interfaces for editing particular data structures.
We don't want to work too hard on making a nice editing interface because
our datastructures change too frequently to bother.
We are moving towards a system in which the merchants edit their own data,
but that requires even higher quality interfaces and further constrains
our ability to add features and change representations.

Rendering/Deployment
Once we have all the data in some consistent datastructure, we need to
export it to javascript datastructures and to the server side DBMS.
There is a lot of art to figuring out which data should go on the client
and which on the server for each browser.  The key point here is that
changes to the schema result in substantive changes to the code which
generates the javascript and loads the database.  The conversion from
Haskell to SQL or from XML to SQL or from Haskell/XML to compact
javascript datastructures is work that is both boring and requires a lot
of care (subtle syntactic issues revolving around quotes of quotes).

The key point here is that there is little complex business logic here.
There is a lot of transforming data from format to format for use by
different parties.  I want generic programming libraries:

1. to insert/extract a Haskell/XML structures from a SQL database

2. to compress XML datastructures for use in Javscript
        (rather than doing hand compression to minimize loadtime)

3. to generate web based editors/viewers for these data structures

It would also be nice if Haskell has fewer data structure namespace
conflicts with XML, Java, or SQL datastructures (i.e. if Haskell required
less name mangling). The HaXML people ran into this problem. I think
either the xRec proposal goes a long way towards solving it, but I don't
understand enough about the theory behind xRec and RH generic programming
extensions to know whether they are compatible.

> | So far as I'm concerned, for practical purposes, the Haskell language
> | is defined by what ghc compiles.
> 
> To avoid confusion then, I think you should really say that you are
> programming in "ghc", or the ghc dialect of Haskell.

Again, it would be nice to have some standardized ways of describing the
language features that a particular program uses.  Haskell code that
uses MPTC is still Haskell.  The question then is which language 
implementations support MPTC now and which will soon.
 
-Alex-

___________________________________________________________________
S. Alexander Jacobson                   Shop.Com
1-212-697-0184 voice                    The Easiest Way To Shop