Jan Brosius writes:
>
>
>
> > Frank Atanassow <[EMAIL PROTECTED]> wrote:
> >
> >
> > Anyway, I don't think the choice of markup is all that crucial, but I
> > think markup for documenting Haskell should also be as functional and
> > elegant as possible. Is Lout a thing to consider?
> >
>
> Yes, I think Lout is the best candidate
No, I didn't write that; Ketil did. As far as Lout goes, if we are going to
pick something exotic, I would prefer a Haskell solution. :)
But just so this message doesn't become a complete waste of bandwidth, let me
include a link that I found today, to Kurt Nørmark's page.
http://www.cs.auc.dk/~normark/
Take a look at his links to LAML and "elucidative programming", especially the
"Small" and "Large Example" links on the latter page.
Also, there is a mildly interesting (if you can penetrate the flames)
discussion on the merits of XML at Advogato, "Markup Abuse: some comments on
the XML panacea":
http://advogato.org/article/47.html
Also, let me briefly respond to Ketil:
Ketil Malde writes:
> Frank Atanassow <[EMAIL PROTECTED]> writes:
>
> I think most of your points against SGML holds for XML as well, am I
> wrong?
No, I agree they do. I only meant that XML is a lesser evil (if you'll excuse
the loaded terminology).
> [The average user]
> > * is likely to be intimidated by the massive infrastructure (programs:
> > Jade, DocBook stylesheets, Haskell-specific stylesheets, probably
> > also PDFlatex; concepts: SGML, DocBook, DSSSL) that is required to
> > handle his literate code;
>
> To some extent, yes. But the end user really only needs to understand
> how to insert the proper tags, and run hs2ps or the like.
He also has to know what the proper tags are, and what their intended
semantics are, and DocBook is quite large. But perhaps that is unavoidable,
and DocBook is becoming more mainstream anyway.
> > as if installing GHC wasn't hard enough? :)
>
> What, you mean "apt-get install ghc4" is too hard?
I guess you have never tried installing GHC on a non-Linux platform---although
admittedly the situation is much better than it used to be.
> To conclude, I think it is important to determine what we want with a
> literate documentation system, aiming for too many targets is bound to
> end in disaster.
Yes, that's actually what I started this discussion for, to get an idea of the
requirements.
> Thinking a bit further from this, I think one of the reasons why Lisp
> (and I suspect Smalltalk) have such nice development environments, is
> that the environment interacts a lot with the compiler or
> interpreter. I.e. the editor can access data structures more or less
> internal to the compiler. Or put another way, the program text (in
> particular for Lisp) is treated as data by the compilation/development
> system. Could this be achieved with Haskell?
It is easier to do this in LISP and Smalltalk because they are dynamically
typed. You could try for some sort of reflection in Haskell, for example by
starting with the public Haskell parser, but I think it would complicate
things enough that it isn't worth it. I don't think a generic documenting
solution for Haskell will be accepted if we innovate too much.
--
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
