Mark P Jones writes:
> | 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.
I didn't mean to imply that business applications involve any sophisticated data
structures. I had in mind just the kind of boring record values you mention,
with no recursion required. Nonetheless, these record values need to be stored,
edited and moved around (and there are *many* different record types). In order
to do this we have to either write code for each type (error-prone, boring, and
a lot of work because there are so many) or write polytypic code e.g. a
polytypic editor (this is discussed briefly by the fudgets authors), polytypic
code to flatten/unflatten records for storage or transport (there isn't much
flattening needed for non-recursive records, but we do need to squash all the
fields together into a blob of bytes, and probably convert to network byte
order; and occasionally we will have a container full of records to deal with),
and similar code for getting records in and out of relational databases.
One might think these operations are trivial, so using polytypic techniques is a
sledgehammer to crack a nut. To some extent this is true - most of the above
could be done by Derive (which is less sophisticated than PolyP). But cracking
the nut is important, because there are many nuts to crack - most business
applications consist of little other than the above manipulation of records. In
other words, if the need to write code for each record type were eliminated, it
would substantially reduce the work needed to write business applications.
I once spent a lot of effort to write a generic editing framework in C++. It
used a family of macros to specify the record fields and their types; then they
could be displayed and edited in a GUI without any code being written. The
effort was justified because I was developing an application that needed to
handle dozens of different record types, with more to come.
> | 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!
I thought it would be uninteresting because the field names are arbitrary (from
a CS point of view); they are irrelevant to the data-structure itself. For
example, I think categorical programming techniques completely avoid naming
fields - they are concerned only with the categorical structure of the data.
But for editing a record, one wishes to prompt the user appropriately for each
field - if the fields are well named, the name should be suitable. Otherwise
someone has to manually specify prompts e.g. the prompt for the 'age' field will
be "age".
> | 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.
Sorry - that phrase was unsuitable. I know work is afoot to merge the two
systems - maybe I should have said there are signs that a seamless merger is
still a long way off. I hadn't read the plans recently, but I have now. See my
other post for some of the incompatibilities that were bothering me.
Maybe things will be better when STG hugs arrives. Then it will be possible to
compile troublesome modules with ghc, and let hugs call them; whereas at the
moment using hugs is an all-or-nothing venture.
I'm actually very interested in the ability of hugs to call ghc compiled code. I
once put a lot of effort into writing a sophisticated (and expensive)
user-interface to a C++ signal-processing library, in order to prototype
signal-processing techniques, because a compile-link-run cycle was too slow and
clumsy. In that kind of situation, the lower-level signal-processing functions
would all be compiled by ghc (to avoid interpreting inner loops), while hugs
would dictate in what way they were used.
Tim
