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
RE: Haskell Wish list: library documentation
S. Alexander Jacobson Tue, 14 Sep 1999 16:02:50 -0400 (Eastern Daylight Time)
- Re: Haskell Wish list: library documentation Bart Demoen
- Re: Haskell Wish list: library documentation Martin Norb{ck
- RE: Haskell Wish list: library documentation S. Alexander Jacobson
- Re: Haskell Wish list: library documentation Richard Watson
- RE: Haskell Wish list: library documentation Simon Peyton-Jones
- RE: Haskell Wish list: library documentation Simon Peyton-Jones
- RE: Haskell Wish list: library documentation trb
- RE: Haskell Wish list: library documentation Johan Jeuring
- RE: Haskell Wish list: library documentation Simon Peyton-Jones
- RE: Haskell Wish list: library documentation Mark P Jones
- RE: Haskell Wish list: library documentation S. Alexander Jacobson
- RE: Haskell Wish list: library documentation trb
- RE: Haskell Wish list: library documentation trb
- RE: Haskell Wish list: library documentation Johan Jeuring
- RE: Haskell Wish list: library documentation Lars Lundgren
- RE: Haskell Wish list: library documentation Lars Lundgren
- Re: Haskell Wish list: library documentation Keith Wansbrough
- RE: Haskell Wish list: library documentation Mark P Jones