On Thu, 2009-05-28 at 23:40 +0100, Claus Reinke wrote:
If you don't want to move from absolute paths for non-core packages,
the current system should just work, right?
Yes.
The current system being the $topdir one.
Yep. It works, it's just not nice, it's ghc-specific and only make
Currently, there seem to be $topdir and $httptopdir.
And I can't see a justification for there being two.
Each variable provides an indirection that decouples the installation
from one source of _independent_ relocations (btw, I've always imagined
that it is called 'http' instead of 'html' to
On Thu, 2009-05-28 at 11:16 +0100, Claus Reinke wrote:
How about this: a way to specify paths in the package registration info
that
are relative to the location of the package db they are in.
ahem. That sounds like a backwards step, being dependent on two
locations instead of one.
But if you're registering global packages that are installed outside of
the GHC tree then you wouldn't register them using relative paths. I'm
not saying everything must use relative paths.
Please don't move your windmills while I'm fighting them!-)
If you don't want to move from absolute
On Thu, 2009-05-28 at 14:12 +0100, Claus Reinke wrote:
But if you're registering global packages that are installed outside of
the GHC tree then you wouldn't register them using relative paths. I'm
not saying everything must use relative paths.
Please don't move your windmills while I'm
If you don't want to move from absolute paths for non-core packages,
the current system should just work, right?
Yes.
The current system being the $topdir one.
Though it also allows for the possibility of relocatable sets of
packages that are not installed relative to the compiler. But more
On Wed, 2009-05-27 at 15:10 +0100, Alistair Bayley wrote:
Andrea,
2009/3/19 Andrea Vezzosi sanzhi...@gmail.com:
It turns out that those variables are there to allow relocation, in
fact $topdir is expanded by
Distribution.Simple.GHC.getInstalledPackages, it seems that
$httptopdir has
It turns out that those variables are there to allow relocation, in
fact $topdir is expanded by
Distribution.Simple.GHC.getInstalledPackages, it seems that
$httptopdir has been overlooked.
I'd be tempted to say that it's ghc-pkg dump/describe responsibility
to expand those vars instead,
is (without looking at ghc code) that ghc just throws the
literate comments away before lexing the file. This means that the
Haddock comments won't be recognized.
As you say, there is also an unlitter in Cabal. I don't remember if it
is invoked when using Haddock 2, but if it is, it would solve
On Sun, 2009-02-08 at 19:18 +0100, Andrea Vezzosi wrote:
I did work on this and i simplified the code a lot fixing
inconsistencies and making more explicit what how each component
contributes to the arguments to haddock.
Much appreciated.
Aside from this, should we also do the unliting and
2009/2/6 Duncan Coutts duncan.cou...@worc.ox.ac.uk:
Yes, against my better judgement the code in Cabal for haddock-2.x does
not run cpp or unliting like it does for haddock-0.x. Instead it assumes
that haddock-2.x will do all the cpp and unliting itself. Obviously this
mean the special
-- $named_block
--
-- This is some hadock documentation.
--
so it looks as though it's discarding the literate comments. Is this
intended? I was under the impression that because it used the ghc
parser, it could now properly handle .lhs input.
Ona
haddock:
C:\bayleya\eclipse\workspace\takusen\srchaddock -h --odir=doc
Test/Haddock.lhs
Cannot find documentation for: $named_block
Okay, then I understand.
My guess is (without looking at ghc code) that ghc just throws the
literate comments away before lexing the file. This means
[1 of 1] Compiling Test.Fail( Test\Fail.hs, Test\Fail.o )
Test\Fail.hs:11:26:
Can't make a derived instance of `Typeable Fail'
(You need -XDeriveDataTypeable to derive an instance for this class)
In the data type declaration for `Fail'
Are you processing the above module
2009/2/6 Alistair Bayley alist...@abayley.org:
I have this test case for Haddock (2.3.0):
--
|
Module : Test.Haddock
Copyright : (c) 2009 Alistair Bayley
License : BSD-style
Maintainer : alist...@abayley.org
Stability :
throws the
literate comments away before lexing the file. This means that the
Haddock comments won't be recognized.
As you say, there is also an unlitter in Cabal. I don't remember if it
is invoked when using Haddock 2, but if it is, it would solve this
problem.
Yes, against my better judgement
to look at the mess.
Personally, not a big fan of LaTeX. I don't understand the bias towards it.
Sean
- Original Message -
From: Steffen Mazanek [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, October 27, 2003 1:08 PM
Subject: Re: literate comments
Hello,
I have thought
Hello,
I have thought again about the relationship of Haskell
and XML. Finally I come up with the following idea. Why
not introduce a Haskell DTD? Not to gain better literate
programming facilities, but to represent _real_ Haskell
code in XML. Of course, no person would like to program
Haskell
begin [EMAIL PROTECTED] quote:
Quoting Steffen Mazanek [EMAIL PROTECTED]:
Would it make sense, to add a xml like code environment
as well, e.g., code.../code?
It's hard to say. The problem is that some Haskell characters are also
important for XML (e.g. , ) and so you can't just cut
Hello,
in the Haskell report the latex code environment is
mentioned:
http://www.haskell.org/onlinereport/literate.html
Would it make sense, to add a xml like code environment
as well, e.g., code.../code?
Ciao,
Steffen
___
Haskell mailing list
[EMAIL
G'day all.
Quoting Steffen Mazanek [EMAIL PROTECTED]:
Would it make sense, to add a xml like code environment
as well, e.g., code.../code?
It's hard to say. The problem is that some Haskell characters are also
important for XML (e.g. , ) and so you can't just cut and paste valid
Haskell
RFC-822-HEADERS:
Original-Via:
==
We seem to be converging here. I prefer Simon's suggestion of
an appendix to Paul's suggestion of a Section 1.6, but am not
too bothered either way. Will also try to work in Simon's note
about file extensions. I am happy to leave the question
To be precise: I propose an additional chapter of the report, labeled
`Literate comments' and no more than one page long, that states a
convention for providing literate comments, notes that it is NOT part
of Haskell but is supported by existing implementations, and mentions
be useful to the greatest number of people, your comments
should be in straight text. Therefore why not just use the
regular comment structure of the language.
2. If your literate comments are in say a Latex format, they are
probably unreadable until r
RFC-822-HEADERS:
Original-Via: uk.ac.ox.prg; Wed, 5 Feb 92 12:22:19 GMT
==
| To be precise: I propose an additional chapter of the report, labeled
| `Literate comments' and no more than one page long, that states a
| convention for providing literate comments, notes
like to do.
To be precise: I propose an additional chapter of the report, labeled
`Literate comments' and no more than one page long, that states a
convention for providing literate comments, notes that it is NOT part
of Haskell but is supported by existing implementations, and mentions
Original-Via: uk.ac.ed.aiai; Tue, 4 Feb 92 17:26:28 GMT
I think people are asking too much of a literate style. In my
opinion it is useful when writing programs with more comments than code.
In such situations, it is important to be able to distinguish comment lines
and code lines without
Original-Via: uk.ac.ed.mrcvax; Tue, 4 Feb 92 18:37:31 GMT
When programming in Miranda, I almost always produce a literate script,
which doubles as a LaTeX document. I think it would be sad if
Haskell did'nt define a literate style.
Ian
Original-Via: uk.ac.durham; Mon, 3 Feb 92 10:37:28 GMT
I think people are asking too much of a literate style. In my
opinion it is useful when writing programs with more comments than code.
In such situations, it is important to be able to distinguish comment lines
and code lines without having
Original-Via: uk.ac.nsf; Sun, 2 Feb 92 00:18:29 GMT
A personal opinion about this 'literate' feature;
I have done my thesis programming part in Miranda,
which has the same 'literate' option ( lines beginning with
are in the program, the other lines are comments ), and
I found it very
Original-Via: uk.ac.nsf; Thu, 30 Jan 92 23:14:16 GMT
A personal opinion about this 'literate' feature;
I have done my thesis programming part in Miranda,
which has the same 'literate' option ( lines beginning with
are in the program, the other lines are comments ), and
I found it very useful
Original-Via: uk.ac.st-and.cs; Wed, 29 Jan 92 12:57:04 GMT
Should we rush into this? Kent's problem, although solved by Phil, convinces
me that there may be more to discuss about this subject. I suggest leaving
out literate comments until 1.3 or 2.0 or whatever the next version will be
called
Kent inquires about the following program:
| This is a 'literate' Haskell comment line.
| {- This is an illiterate (?? :-) Haskell comment line, but where does it end?
| -- This question sounds familiar, but then no
| -- """literate""" programming was involved.
| -}
| Still in a
| Should we rush into this? Kent's problem, although solved by Phil,
| convinces me that there may be more to discuss about this subject. I
| suggest leaving out literate comments until 1.3 or 2.0 or whatever the
| next version will be called. -- Tony
| Maybe we need a "how to be a good Ha
Original-Via: uk.ac.uknet; Tue, 28 Jan 92 14:04:42 GMT
Jeff Dalton writes:
Could someone please explain to me why there needs to be support
for literate comments in the language (rather than in the editor
or some other program) and why conventions involving or
.troff-like-commands
| Could someone please explain to me why there needs to be support
| for literate comments in the langauge (rather than in the editor
| or some other program) and why conventions involving or
| .troff-like-commands are good ones?
The reason for putting literate comments in the language is so
Original-Via: uk.ac.uknet; Mon, 27 Jan 92 09:49:41 GMT
Yes - please include the literate program convention. I never write any
other way.
Small pedantic point: I think program lines should begin with the two
characters " " to prevent people writing lines beginning "=", which
could confuse the
Original-Via: uk.ac.ed.aiai; Mon, 27 Jan 92 17:36:47 GMT
Could someone please explain to me why there needs to be support
for literate comments in the langauge (rather than in the editor
or some other program) and why conventions involving or
.troff-like-commands are good ones? Maybe I'm just
Phil writes:
... (at Glasgow, we use .has for regular and .lhs
for literate).
Make that ".hs" and ".lhs"; ".hs" is standard across all known
implementations; HBC does ".lhs" as well.
Will "We know when Phil last wrote a Haskell pgm :-)" Partain
I'd be happy with a literate style; but time is short, so decision
needed rapidly (Paul) and then (if positive) appropriate changes made
(mainly Joe).
Simon
40 matches
Mail list logo
