Jonathan King writes:
> 1) Haskell code uses white-space as a delimiter by default, presumably
> because it's clean and intuitive.
>
> However: it seems like once a month (or even more often), it gets
> pointed out that the "offsides" rule that Haskell
> compilers/interpreters have to use is, uh, pretty hideous. And
> a slew of Haskell bugs often boil down to finding a misindented
> "where" clause 200-and-something lines up the file.
>
> Also however: Every idea I've seen so far about (re)doing literate
> programming in Haskell seem to recognize the fact that ending
> delimiters are a reasonable price to pay for a lot of reasons. So
> Haskell could end up being a language where you could have a program
> whose documentation is exquisitely and verifiably well-formed despite
> the fact the code itself has been ruined by incorrect indentation.
>
> 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. There is a simpler notion
of the layout which doesn't depend on error-trapping and is preferable, at
least in my mind.
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. And the beauty of referential
transparency is that you can usually do it, too. So I have no problems with
layout...
> 3) People in the Haskell programming community seem to appreciate
> the benefits of abstraction. Wow, what a surprise. Nonetheless,
> I've seen documentation for Haskell projects presented in formats
> that range from plain text to LaTex to HTML to postscript generated
> by a word processor that shall remain nameless...all over the place,
> with the one commonality apparently being that, as far as formats go,
> the statement "You can't get there from here" is true for many if not
> values of "You", "there", and "here". As far as I can tell, the best
> stab so far seems to be LaTeX, just because you probably could get
> to some other format from there on almost any machine.
>
> However: this is not just a problem for Haskell, *and it's a very
> hard problem if you want it to be*. There are maybe a thousand
> computer languages out there and fifty thousand systems
> for semi-literate programming. As far as I can tell, the one that
> is used by the widest variety of people who don't share the same
> lab or office is the "pod" format used by Perl. Now, nobody is going
> to hold that one out as a model of the ideal anything, but, weirdly
> enough, it works well enough, because it doesn't try to over-reach,
> but *does* provide translators and converters *to* the formats that
> people really need. Number one being html, number two being text,
> and number three being man. Everything else seems to be window
> dressing these days.
>
> 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.
[Was there a #2?]
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.
--
Frank Atanassow, Dept. of Computer Science, Utrecht University
Padualaan 14, PO Box 80.089, 3508 TB Utrecht, Netherlands
Tel +31 (030) 253-1012, Fax +31 (030) 251-3791
