On Tue, 14 Mar 2000, George Russell wrote:
> Frank Atanassow wrote:
> > What do you all think?
> Well I suppose that includes me, but I'm a bit confused. I've looked at some of
> the .lhs files containing the source of GHC, but the so-called literate nature
> of the code doesn't seem to me to make it any better. Specifically,
> it doesn't do anything that comment characters can't do. So could someone
> explain what exactly literate programming for Haskell is intended to achieve?
> The only thing I really miss in .hs files which is done by Knuth's Web
> (in "TeX the program") are indices for each module indicating where the values
> and types it uses come from, and where the values and types it defines are used.
The other big advantage of literate programming for imperative languages
like Pascal & C is related to that because of the difficulties in passing
variables in and out of functions, and creating the equivalent of
lambda's, functions tend to get quite big without a hierarchical
decomposition. By allowing the <code 57> macros it allows a hierarchical
decomposition for exposition/maintenance purposes without the need to do
it via functions in the code and hence write zillions of lines of
`marshalling-type code'. This big advantage seems to be negligible for
Haskell since higher order functions and let/where clauses handle this as
well as macros, and really rearranging the order (like Knuth does at
several points) makes it tricky to preserve the indentation required by
the layout rule.
As much of a fan as I am of literate programming (I even bought a copy of
METAFONT: the program!) I'm not sure anything more advanced than the
Bird-tracks notation really makes much sense for Haskell.
> Is the idea that the library documentation should be identical with the code?
> Because I don't want this - I don't want to look at code, however nattily presented,
> when all I want to know is how to call Posix.select (say). Imagine if the TeXbook
> didn't exist and all we had were "TeX - the program"; I think it is clear that
> people who find the TeXbook hard going would have even more trouble with "TeX - the
> program".
Documentation is a vague term: certainly it'd be undesirable for a
specification to the libraries to just a literate copy of the code
itself. But if you're thinking in terms of an open source project where
people fix bugs in the libraries then libraries that contain some
explanation would be useful (as an additional item to the library spec). I
don't know if this is just my personal experience but the hardest part of
debugging somebody else's code is to figure out what they believed it was
doing when the wrote it (essentially mentally extending the
specification from the external behaviour of the function to it's
implementation strategy). Here even partial commentary might make
sense.
Just some random thoughts,
___cheers,_dave________________________________________________________
www.cs.bris.ac.uk/~tweed/pi.htm|ALERT: you are communicating with an
email: [EMAIL PROTECTED] |unsavoury individual with a copy of gdb
work tel: (0117) 954-5253 |who reverse-engineered a file format.
