Well, I probably should have skipped it, I guess. But just to clarify:
On Mon, 20 Mar 2000, Frank Atanassow wrote:
> Jonathan King writes:
> >
> > [snip about the off-sides rule vs. actual delimiters, etc. jking]
> >
> > Am I the only person who finds that really, really weird?
>
> Most people slam the offside rule because it depends on trapping
> parser errors, not because they hate the notion of layout.
That's true. I don't "hate the notion of layout", but I wanted to
point out that it's possibly not as intuitive as might be expected,
and does complicate the tools side of things. This is particularly true
if you combine layout with a literate programming system that goes against
that grain.
> There is a simpler notion of the layout which doesn't depend on
> error-trapping and is preferable, at least in my mind.
That would be nice. :-)
> As for stray "where" clauses and the like, I think that happens to me
> maybe once or twice a year. Once my definitions get longer than one
> screenful or so, I know it's time to factor some things out.
Yes, but I was more worried about novices than experts. True, they won't
get burned by a "where" clause 200 lines back, but they can get burned by
other things. I'm afraid I'm beginning to subscribe to the idea that if
you can't reliably cut and paste the code from email...
[snip]
Meanwhile:
> [Was there a #2?]
There was, but I edited it out and didn't change the numbering. :-(
[my rant on the state of Haskell documentation and so forth deleted,
except for:]
> > There's probably a lesson there. You can stipulate any old format
> > you like, but if it won't easily produce HTML (like lout), or
> > produces a psychotic approximation to HTML (like W**d), you're hosed.
> > Any browser on the planet can dump HTML to text or postscript, and
> > no, it won't be artsy, but, gosh, it might just be good enough.
>
> What's your point? I think we all want to be able to produce HTML...
> or did I miss something? I also agree that we should not shoot for too
> much; but I think we should agree on what we shoot for, first.
(Well, the person touting lout seemed to ignore the HTML requirement...)
All I was suggesting is that people were concentrating on the part of the
problem that might be academically more interesting, but which doesn't
actually produce something as quickly or easily as people might expect
these days.
Or, which won't reliably be used by people who write code, so that it
won't achieve the goal of universal anything. Again, I'm not sure you can
shoot too low here. I have a hunch that if you have to use anything like
a DTD to use the system, it's all over. If it doesn't look enough like
Haskell to make writing a helpful editor for it easy, that's probably a
problem, too. (I'm trying to imagine a good emacs mode that does both
layout and XML...).
So, while I like XML in many respects, I'm really dubious that it's a good
idea to make that the basis for a human-typable literary programming
documentation system. Now, as an intermediate format for such a system,
that might be another story. Again, I'd like to point out the unsettling
charm of perl's pod format. If you're a computer scientist, reading the
description could bring tears to your eyes, or even cause internal
bleeding. Yet, it is the key to one of the most impressive distributed
software documentation efforts that I know of. Personally, I know I
rarely used to do man pages for small, tool-like things I did in perl. But
now anything I write for perl has a man page, since it's soooo easy, and
fits right into the perl I just wrote.
jking
