In a previous message, I wrote:
| Some folks out there want to use Haskell to write real programs. For
| them, there's Haskell 98.
To which Alex replied:
| 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.
And Tim added:
| 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).
So now I realize that my message could have been taken the wrong way.
I didn't mean to suggest that people writing real world programs
wouldn't (or shouldn't) use any of the various Haskell extensions
floating around. Far from it! Without you, there would be little
practical motivation to continue developing any of these extensions.
But "Haskell", as it is today doesn't yet provide those features, so
when you say that you'd like to use Haskell, what I think you really
mean is that you'd like to use what Haskell has the potential to be,
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 ...
To the specifics of Tim's comments:
| 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.
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?
I ask because most of the examples of polytypic programming that I have
seen are targeted at fancy data structures. And that doesn't have to
mean much in this setting ... almost anything with recursion in it goes
beyond the kinds of things that I remember from the time that I've spent
writing business applications. As I recall, much of the code that I
wrote back then spent its time editing and moving around record values,
which sounds much the same as what you've described.
| 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).
I don't understand why you think this wouldn't be interesting from a
CS point of view! (Or did I just misunderstand the acronyms?) Haskell
folks have known how to do this sort of thing for a long time (i.e.,
I remember discussions on the Haskell list about it, and that must
have been at least seven years ago now (eek!)), but it didn't make
it to the language or libraries, perhaps because nobody thought it
was likely to be used in practice!
| 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.
| 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).
"shows little sign"? How big a sign would you like?! Perhaps you
haven't read the plans for future development of Hugs and GHC, in
which case you won't know that the two systems are well on their
way to merging into one happy, unified bundle, with ghc's compiled
code working side by side with Hugs' interpreted code? Take a look
at http://www.cse.ogi.edu/~mpj/Hugs98/news.html (also accessible
from the Hugs home page) if you want more details. Currently, both
systems have things to offer that the other cannot provide, but folks
on both sides of the gap are working hard to bring them closer together.
All the best,
Mark
