Re: haddock-2.3.0 literate comments discarded from .lhs input
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 sense
when ghc is installed in a prefix-independent way.
Though it also allows for the possibility of relocatable sets of
packages that are not installed relative to the compiler. But more
importantly it's more general and simpler than the current '$topdir'
that ghc uses.
'it' now being the new system evolving in this thread, or have I missed
anything?
The new system I've been proposing.
(a) making ghc-pkg (optionally) instantiate any variables in its
database in (all of) its command-line output and
Yes, though I'm only asking for two vars (previously one), not an ad-hoc
set of vars.
(b) allowing non-core packages to be relocated without having to
update ghc-pkg's database.
In my suggested system this is possible if that set of packages use
their own package db (containing relative paths).
That is news to me - was that specified before this thread moved
to ghc-users?
It was in the first email that was cc'ed to ghc-users:
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. That makes sense beyond just ghc and
even with would allow other sets of relocatable packages, not
just those installed with ghc.
In your system it's possible by updating some var in a central registry
and having that set of packages use paths relative to that var.
So, essentially, your system would have to keep a file listing the
various package.conf locations (currently, GHC only knows about
two: system/user, everything else would have to be passed on the
commandline..). While my system would have to keep a file listing
the variable bindings, so that tools processing the package db can
instantiate the variables.
If you want multiple relocatable sets of packages that are immediately
available in the environment.
I could see both approaches being useful, even together.
So ghc's current system uses two vars, $topdir and $httptopdir.
This is GHC's view of its database. It should be useable independently,
via ghc-pkg and ghc api clients (such as GHC, GHCi, Haddock, ..) -
all of which should be able to resolve the variable bindings, in the
same way.
It's not usable independently, ghc does not always have a topdir. This
makes life hard for tools. It's also not clear what topdir would mean in
the context of other compilers.
Btw, it would really be nice if the package handling code
was shared rather than duplicated.
It would be nice, yes.
I'm proposing to replace those with a standardised ${pkgroot} and
${pkgrooturl} vars which are usable by all compilers and in more
situations.
Now you are talking about Cabal's view of its database.
Cabal does not own the package databases, however it does expect that
they are in the format describe by the Cabal spec, which places
obligations on Haskell implementations to be somewhat package-aware.
It doesn't have to expose the underlying implementation's view,
especially since the other implementations organise their package
handling differently.
All compilers use the same information (it's in the Cabal spec). They do
store it differently but they all identify the location of the
information using a file path. That seems pretty universal, compared to
$topdir.
And why just two variables? Is $pkgroot about .hi files, .a/.so./.dll
files, or about include files, or haddock indices, or ..?
You only need one variable to identify the location of the installed
package description. All relative paths can be constructed from that.
The second variable is to allow for two representations of the same
location, one as a native system path, the other as a URL. We do not
need different variables for different kinds of files (except in as much
as some fields use paths and some urls).
In windows, these tend to end in a common sub-hierarchy, but you're
aiming for something general, right?
If you're making a relocatable package then these files will be in a
common sub-hierarchy and you would use relative paths. If you're not
making a relocatable package (eg following the Linux FSH) then you would
not use relative paths.
So that should be general. It does not remove any existing capability
and it adds the ability to have relative paths for relocatable packages.
Perhaps what you're saying is that we should be able to take any package
whether it lives in a common sub-hierarchy or not and relocate it. In
general this is problematic since packages can embed paths and if those
paths are not relative to a common root then you have to specify them
all (Cabal enables this by setting environment variables). Assuming
Re: haddock-2.3.0 literate comments discarded from .lhs input
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 allow for references to haskell.org when no local docs are installed, but it doesn't seem to work that way). 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. I don't follow this. Which two? package db + package path: in the current system, you only have to update the package db if you move a package that isn't installed under the GHC tree; in your suggestion, you also have to update it if you move the package db/GHC itself while having non-core packages installed outside the GHC tree. Before the HP, windows GHCs could be relocated without needing to update the ghc-pkg database, even if some packages were installed outside GHCs $topdir. I don't see how this is related to what the Windows installer for the HP is doing. Sure, since it's installing packages relative to ghc and we'd like the whole thing to be relocatable then it should use relative paths. I don't think anyone disputes that, the question is how to implement relative paths. I was just disambiguating which GHC installers I was referring to, since there are now two possibilities, with different properties. With your variant, just about any change would need updating. I must be missing something. If you move package.conf and the packages in one go, then nothing needs changing as far as I can see. You seem to be assuming that everything is under a common root? That isn't the case for most unixes (different locations for bin/ doc/ lib/ .., docs installed or not), and even on windows, it stopped being the case with cabal insisting on 'Program Files/Haskell/...' as the default install. Since ghc traditionally installs into 'c:/ghc/ghc-version' (on my system, at least, but I think that no-spaces-location was suggested by one of the GHC installers originally, and spaces in tool paths still confuse the GHC build system), I have two locations. If I move GHC, nothing needs changing. If I move packages that didn't come with GHC, package.db needs updating. If the packages had been registered wrt to a $cabaltopdir, no changes would be needed in either case. In your suggestion, if I move GHC but not the packages, package.db needs updating, if I move the packages but not GHC, package.dg needs updating, only if I move both, and by the same relative path, no update is needed. Assuming that the parts are independently located by whatever the OS packaging conventions say, and can be independently relocated otherwise, it seems simpler to continue with the variable scheme, but with improved support and documentation for it. My suggestion seems very simple! I'm clearly missing some problem which you can see. To be clear, here's what I'm imagining: blah/package.conf blah/lib/foo-1.0/libfoo-1.0.a That is everything under one tree, right? And since package.conf is GHC's register, GHC would have to be in that tree as well. and package.conf would contain foo-1.0 with paths looking like $dbdir/lib/foo-1.0. That is, we interpret $dbdir (or whatever var name we agree on) as being blah/ because that's the dir containing the db. So crucially, it doesn't really matter where ghc.exe is. Assuming ghc can find the package conf then it can find all the files. So it'd let you create multiple relocatable package collections. If the primary package db is kept relative to ghc (eg in ghc's topdir) then the whole ghc installation including libs is relocatable That is what GHC did on windows before cabal changed the package locations away to a path that neither GHC nor its build tools can use. Is that even possible on unix systems, with their various packaging and location traditions? And if Simon ever makes that breakthrough of binary compatibility at least between minor GHC versions, we can't have the libraries in the GHC directories, as they'd be shared between several GHCs. Claus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: haddock-2.3.0 literate comments discarded from .lhs input
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. I don't follow this. Which two? package db + package path: in the current system, you only have to update the package db if you move a package that isn't installed under the GHC tree; in your suggestion, you also have to update it if you move the package db/GHC itself while having non-core packages installed outside the GHC tree. 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. With your variant, just about any change would need updating. I must be missing something. If you move package.conf and the packages in one go, then nothing needs changing as far as I can see. You seem to be assuming that everything is under a common root? Well it is on Windows which is the main case where people want relocatable installations. If we wanted relocatable installations on Unix then it'd all have to be under one root too, eg /opt/whatever. That isn't the case for most unixes (different locations for bin/ doc/ lib/ .., docs installed or not), and even on windows, it stopped being the case with cabal insisting on 'Program Files/Haskell/...' as the default install. Sure, extra packages should not be installed in the ghc tree and so those should not use paths relative to the ghc location. Since ghc traditionally installs into 'c:/ghc/ghc-version' (on my system, at least, but I think that no-spaces-location was suggested by one of the GHC installers originally, and spaces in tool paths still confuse the GHC build system), I have two locations. If I move GHC, nothing needs changing. If I move packages that didn't come with GHC, package.db needs updating. If the packages had been registered wrt to a $cabaltopdir, no changes would be needed in either case. For some reason I really dislike the idea that we make up specific vars like $cabaltopdir for specific purposes. Perhaps that's just me. I want a general solution, not something that forces everyone to adopt conventions like installing everything in ~/.cabal/. That's just a sensible default, but the user rightly has full control over --prefix, --libdir etc etc. In your suggestion, if I move GHC but not the packages, package.db needs updating, No it does not. That would only be the case if you always registered things relative to ghc, but that'd be silly for things not actually installed in the ghc install tree. if I move the packages but not GHC, package.dg needs updating, only if I move both, and by the same relative path, no update is needed. Are you suggesting that we need to be able to move core libs that are distributed with ghc, independently of where the ghc binary is? Assuming that the parts are independently located by whatever the OS packaging conventions say, and can be independently relocated otherwise, it seems simpler to continue with the variable scheme, but with improved support and documentation for it. My suggestion seems very simple! I'm clearly missing some problem which you can see. To be clear, here's what I'm imagining: blah/package.conf blah/lib/foo-1.0/libfoo-1.0.a That is everything under one tree, right? Not necessarily. For the things in the same tree it'd be sensible to use relative paths. For things not in the same tree it'd be sensible to use absolute paths. This scheme also allows other sets of relocatable packages, so long as ghc gets told where to find the package.conf. And since package.conf is GHC's register, GHC would have to be in that tree as well. For core packages shipped with ghc/hp, yes. and package.conf would contain foo-1.0 with paths looking like $dbdir/lib/foo-1.0. That is, we interpret $dbdir (or whatever var name we agree on) as being blah/ because that's the dir containing the db. So crucially, it doesn't really matter where ghc.exe is. Assuming ghc can find the package conf then it can find all the files. So it'd let you create multiple relocatable package collections. If the primary package db is kept relative to ghc (eg in ghc's topdir) then the whole ghc installation including libs is relocatable That is what GHC did on windows before cabal changed the package locations away to a path that neither GHC nor its build tools can use. Do you mean installing binaries in C:\Program Files\Haskell\bin by default? That decision was made by the Windows users. It's true that the GHC build system cannot work in a directory containing spaces, and that's probably too hard to fix. However using tools (eg happy, alex) that are in a dir containing spaces should not be nearly so hard to
Re: haddock-2.3.0 literate comments discarded from .lhs input
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 paths for non-core packages, the current system should just work, right? I thought we were talking about (a) making ghc-pkg (optionally) instantiate any variables in its database in (all of) its command-line output and (b) allowing non-core packages to be relocated without having to update ghc-pkg's database. For some reason I really dislike the idea that we make up specific vars like $cabaltopdir for specific purposes. Perhaps that's just me. I want a general solution, not something that forces everyone to adopt conventions like installing everything in ~/.cabal/. That's just a sensible default, but the user rightly has full control over --prefix, --libdir etc etc. Personally, I only dislike the idea of hardcoding specific variable names in ghc-pkg, which is why I suggested a name-independent approach (I also dislike the current duplication of code in ghc-pkg/ghc api/..). $cabaltopdir would just improve the handling of the default cabal install locations, without dictating where users say those default locations should be - and if users move specific packages/package parts to different absolute locations, those absolute locations would still have to appear in the package database, but I'd expect that to be an exception. If common prefixes are abstracted out via variables, it would simply be easier to see that the majority of package parts are not randomly distributed over the available file systems, but related to the chosen default settings of the tool that installed them (that might involve communication between GHC and Cabal: GHC knows about its own dir, but would have to ask Cabal about its locations - or, better, Cabal could tell GHC about its locations once, when the user changes them). I'm mostly seeing the windows perspective at the moment, btw, but even on unix, one might want to abstract out common prefixes, in case one decides to move packages from $HOME/ to system-wide prefixes, or from one system-wide prefix to another. Perhaps the difference doesn't matter much, apart from readability: Let's say I wanted to move a GHC/Cabal/HP installation to a USB drive: moving GHC/corelibs is straightforward (it doesn't care under what drive name the USB drive gets mounted on the lecture theatre computer), but how would I move Cabal-installed non-core packages (not to mention Cabal itself?)? Is that use case documented in some faq? If the extra package paths are absolute, it would involve something like searchreplace on the concrete representation of the supposedly abstract package database, but as long as that representation is a simple text file, that might not be too troublesome; if the extra package paths are relative to a $cabaltopdir, it would involve telling GHC about the new location prefix whenever calling it directly (or telling Cabal about its new location, and Cabal passing that on when calling GHC). That is what GHC did on windows before cabal changed the package locations away to a path that neither GHC nor its build tools can use. Do you mean installing binaries in C:\Program Files\Haskell\bin by default? That decision was made by the Windows users. s/the/some/ ;-) It is a reasonable default to expect, but if Cabal had ever asked me before starting to install things there, I'd have changed that default immediately. I was thinking more about things that would appear in package.conf: C:\Program Files\Haskell\package\ghc-version C:\Program Files\Haskell\doc\package but it is the same difference: there are now two locations to consider even on windows (GHC/corelibs + Cabal/other packages), and that is probably how it should be. It's true that the GHC build system cannot work in a directory containing spaces, and that's probably too hard to fix. However using tools (eg happy, alex) that are in a dir containing spaces should not be nearly so hard to fix. Maybe so, but last time (end of January) I asked about the GHC build (in a space-free path) using tools where cabal installs them by default (with spaces in path), Simon M answered: It's not practical in general to cope with spaces in paths in the build system. IIRC we tried to get this right once and gave up.. So if there is a tool path specific subset of the problem that could be solved more easily, it doesn't seem to help. Is that even possible on unix systems, with their various packaging and location traditions? I'm not sure what you're referring to. Some unix branches seem to distinguish themselves merely by different package management/location. But apart from Mac frameworks, I'm not aware of any unix that would not expect libraries/binaries/docs to be installed in different locations
Re: haddock-2.3.0 literate comments discarded from .lhs input
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 fighting them!-)
If you don't want to move from absolute paths for non-core packages,
the current system should just work, right?
Yes.
Though it also allows for the possibility of relocatable sets of
packages that are not installed relative to the compiler. But more
importantly it's more general and simpler than the current '$topdir'
that ghc uses.
I thought we were talking about
(a) making ghc-pkg (optionally) instantiate any variables in its
database in (all of) its command-line output and
Yes, though I'm only asking for two vars (previously one), not an ad-hoc
set of vars.
(b) allowing non-core packages to be relocated without having to
update ghc-pkg's database.
In my suggested system this is possible if that set of packages use
their own package db (containing relative paths).
In your system it's possible by updating some var in a central registry
and having that set of packages use paths relative to that var.
For some reason I really dislike the idea that we make up specific vars
like $cabaltopdir for specific purposes. Perhaps that's just me. I want
a general solution, not something that forces everyone to adopt
conventions like installing everything in ~/.cabal/. That's just a
sensible default, but the user rightly has full control over --prefix,
--libdir etc etc.
Personally, I only dislike the idea of hardcoding specific variable names
in ghc-pkg, which is why I suggested a name-independent approach
(I also dislike the current duplication of code in ghc-pkg/ghc api/..).
$cabaltopdir would just improve the handling of the default cabal
install locations, without dictating where users say those default locations
should be - and if users move specific packages/package parts to
different absolute locations, those absolute locations would still have
to appear in the package database, but I'd expect that to be an
exception.
So ghc's current system uses two vars, $topdir and $httptopdir.
I'm proposing to replace those with a standardised ${pkgroot} and
${pkgrooturl} vars which are usable by all compilers and in more
situations.
You're proposing a central registry of vars and to have ghc-pkg
(optionally) expand these vars which could be used anywhere in the
installed package descriptions. Presumably you're also suggesting some
mechanism to query and update this registry of variables.
Is that a fair summary?
Let's say I wanted to move a GHC/Cabal/HP installation to a
USB drive: moving GHC/corelibs is straightforward (it doesn't
care under what drive name the USB drive gets mounted on the
lecture theatre computer), but how would I move Cabal-installed
non-core packages (not to mention Cabal itself?)? Is that use case
documented in some faq?
Ok, so you want to construct a set of relocatable packages. This needs
to be decided from the beginning when you compile said packages because
otherwise packages can have paths baked into them. There are some
restrictions on making relocatable packages, eg you can't set --libdir
to an absolute path, it has to be relative to the --prefix.
In addition to making the package relocatable, we would have to register
the package into a package db that lives relative to the packages in
question. This db would contain relative paths (using ${pkgroot}).
Once this is done then the whole lot would be relocatable onto a USB
drive or whatever. To use this set of packages you would need to specify
--package-conf= to ghc, or --package-db= to cabal.
If the extra package paths are absolute, it would involve something
like searchreplace on the concrete representation of the supposedly
abstract package database, but as long as that representation is a
simple text file, that might not be too troublesome;
Aye, so if you want to be able to move then then it's better if they're
relative.
if the extra package paths are relative to a $cabaltopdir, it would
involve telling GHC about the new location prefix whenever calling
it directly (or telling Cabal about its new location, and Cabal passing
that on when calling GHC).
So that's the bit in your suggestion that corresponds to using
--package-conf= in my suggestion. And it assumes that you don't need to
set $cabaltopdir to two values simultaniously, eg if the machine you've
moved it to on the USB stick also has cabal packages that it needs to
use.
It's true that the GHC build system cannot work in a directory
containing spaces, and that's probably too hard to fix. However using
tools (eg happy, alex) that are in a dir containing spaces should not be
nearly so hard to fix.
Maybe so, but last time (end of January) I asked about the GHC build
(in a space-free path)
Re: haddock-2.3.0 literate comments discarded from .lhs input
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
importantly it's more general and simpler than the current '$topdir'
that ghc uses.
'it' now being the new system evolving in this thread, or have I missed
anything?
(a) making ghc-pkg (optionally) instantiate any variables in its
database in (all of) its command-line output and
Yes, though I'm only asking for two vars (previously one), not an ad-hoc
set of vars.
(b) allowing non-core packages to be relocated without having to
update ghc-pkg's database.
In my suggested system this is possible if that set of packages use
their own package db (containing relative paths).
That is news to me - was that specified before this thread moved
to ghc-users?
In your system it's possible by updating some var in a central registry
and having that set of packages use paths relative to that var.
So, essentially, your system would have to keep a file listing the
various package.conf locations (currently, GHC only knows about
two: system/user, everything else would have to be passed on the
commandline..). While my system would have to keep a file listing
the variable bindings, so that tools processing the package db can
instantiate the variables.
I could see both approaches being useful, even together.
So ghc's current system uses two vars, $topdir and $httptopdir.
This is GHC's view of its database. It should be useable independently,
via ghc-pkg and ghc api clients (such as GHC, GHCi, Haddock, ..) -
all of which should be able to resolve the variable bindings, in the
same way. Btw, it would really be nice if the package handling code
was shared rather than duplicated.
I'm proposing to replace those with a standardised ${pkgroot} and
${pkgrooturl} vars which are usable by all compilers and in more
situations.
Now you are talking about Cabal's view of its database. It doesn't
have to expose the underlying implementation's view, especially since
the other implementations organise their package handling differently.
And why just two variables? Is $pkgroot about .hi files, .a/.so./.dll
files, or about include files, or haddock indices, or ..? In windows,
these tend to end in a common sub-hierarchy, but you're aiming for
something general, right?
You're proposing a central registry of vars and to have ghc-pkg
(optionally) expand these vars which could be used anywhere in the
installed package descriptions. Presumably you're also suggesting some
mechanism to query and update this registry of variables.
Is that a fair summary?
I think so. And you're proposing several separate registries (hasn't
that been a Cabal problem in the past, even with just user and system
to choose from?). Presumably you're also suggesting some mechanism
to query and update the meta-registry of package database locations.
Claus
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: haddock-2.3.0 literate comments discarded from .lhs input
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 been overlooked. I'd be tempted to say that it's ghc-pkg dump/describe responsibility to expand those vars instead, like it does for ghc-pkg field. Do you (or anyone else) intend to work on this? If not, I'd like to fix it, but I'll need some guidance. Like, is Distribution.Simple.GHC.getInstalledPackages where the variable expansion code should go, or should it be somewhere else? I don't think we should be hacking around this in Cabal without any discussion with the ghc folks on what is supposed to be there, what variables are allowed. We need a clear spec on what variables tools are expected to handle and how they are to be interpreted. The output of ghc-pkg describe/dump is not just for ghc to define and play around with. It's supposed to be defined by the Cabal spec. Supporting relocatable sets of packages is a good idea. We should aim to have something that is usable by each compiler, not just ghc, so interpreting paths relative to ghc's libdir doesn't seem ideal. 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. That makes sense beyond just ghc and even with would allow other sets of relocatable packages, not just those installed with ghc. Then perhaps as a compat hack we should get Cabal to handle older ghc versions that do use these funny vars. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: haddock-2.3.0 literate comments discarded from .lhs input
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, like it does for ghc-pkg field. Agreed on ghc-pkg doing the translation. Via commandline options, or via environment vars (one might be tempted to manage the bindings in ghc-pkg's database itself, even). The lack of support for this hampers the useability of ghc-pkg and the database it is responsible for. We need a clear spec on what variables tools are expected to handle and how they are to be interpreted. Currently, there seem to be $topdir and $httptopdir. Given the split between GHC and HP, it might be useful to have an additional $hptopdir, or just a general mechanism for variables in ghc-pkg's database (I recall being disappointed when what looked like environment variables were unaffected by environment settings..). The info is somewhat distributed: http://darcs.haskell.org/ghc/utils/ghc-pkg/Main.hs http://darcs.haskell.org/ghc/compiler/main/Packages.lhs http://darcs.haskell.org/ghc/compiler/main/SysTools.lhs [Note topdir] Supporting relocatable sets of packages is a good idea. We should aim to have something that is usable by each compiler, not just ghc, so interpreting paths relative to ghc's libdir doesn't seem ideal. GHC makes no reference to libdir, it simply talks about a $topdir (where it would like to store things it needs) and $httptopdir (where haddocks might be found). 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. Before the HP, windows GHCs could be relocated without needing to update the ghc-pkg database, even if some packages were installed outside GHCs $topdir. With your variant, just about any change would need updating. Assuming that the parts are independently located by whatever the OS packaging conventions say, and can be independently relocated otherwise, it seems simpler to continue with the variable scheme, but with improved support and documentation for it. Claus ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] Re: haddock-2.3.0 literate comments discarded from .lhs input
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. Aside from this, should we also do the unliting and cpp from Cabal on the sources passed to HsColour? On Fri, Feb 6, 2009 at 11:27 PM, Duncan Coutts duncan.cou...@worc.ox.ac.uk wrote: On Fri, 2009-02-06 at 11:48 +0100, David Waern wrote: 2009/2/6 Alistair Bayley alist...@abayley.org: [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 but it is called Test.Fail in reality? Have you stripped out a deriving statement from the example above? I'm very confused by this message :) Sorry, my mistake. I pasted the error message from a different problem. This is the error I get from 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 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 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 unliting mode that Cabal provides is not usable with haddock-2.x. The solution is to do the pre-processing the same for haddock-0.x and 2.x. Generally the haddock code in Cabal is a horrible inconsistent mess. I believe Andrea Vezzosi has been looking at rewriting it, which is good news. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haddock-2.3.0 literate comments discarded from .lhs input
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 cpp from Cabal on the sources passed to HsColour? Hmm. I thought it did already :-) Well, I know it runs happy, hsc2hs etc. Someone was complaining the other day that the hscolour output run on the result of happy is not really readable, but then it's not clear if running it on the happy input would be any better. For the particular case of .lhs and cpp, I hope we'd get better hscolour output by not running unlit or cpp first. Malcolm says it'll at least do something. So it seems worth checking which ends up looking more useful. Duncan On Fri, Feb 6, 2009 at 11:27 PM, Duncan Coutts 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 unliting mode that Cabal provides is not usable with haddock-2.x. The solution is to do the pre-processing the same for haddock-0.x and 2.x. Generally the haddock code in Cabal is a horrible inconsistent mess. I believe Andrea Vezzosi has been looking at rewriting it, which is good news. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haddock-2.3.0 literate comments discarded from .lhs input
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 unliting mode that Cabal provides is not usable with haddock-2.x. The solution is to do the pre-processing the same for haddock-0.x and 2.x. Generally the haddock code in Cabal is a horrible inconsistent mess. I believe Andrea Vezzosi has been looking at rewriting it, which is good news. In Distribution.Simple.Haddock, in the haddock function we have: withLib pkg_descr () $ \lib - do let bi = libBuildInfo lib modules = PD.exposedModules lib ++ otherModules bi inFiles - getLibSourceFiles lbi lib unless isVersion2 $ mockAll bi inFiles So I guess the easiest thing to do right now is remove the unless isVersion2 $ . I'm testing this at the moment, so when I get it working (or not) I'll let you know, and maybe send a patch. Alistair ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] haddock-2.3.0 literate comments discarded from .lhs input
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 : stable Portability : portable Test case for Haddock. module Test.Haddock ( -- $named_block Fail(..) ) where data Fail = Fail | Succeed $named_block This is some hadock documentation. -- This fails with: [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' If I manually unlit, then Haddock is happy: -- -- | -- Module : Test.Haddock2 -- Copyright : (c) 2009 Alistair Bayley -- License : BSD-style -- Maintainer : alist...@abayley.org -- Stability : stable -- Portability : portable -- -- Test case for Haddock. module Test.Haddock2 ( -- $named_block Fail(..) ) where data Fail = Fail | Succeed -- $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 related note, we have a nice unlitter in cabal that would preserve these comments before invoking haddock. Is this still used with haddock2, or does it now assume haddock2 will do the right thing? Alistair ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haddock-2.3.0 literate comments discarded from .lhs input
2009/2/6 Alistair Bayley alist...@abayley.org: [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 but it is called Test.Fail in reality? Have you stripped out a deriving statement from the example above? I'm very confused by this message :) Sorry, my mistake. I pasted the error message from a different problem. This is the error I get from 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 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. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haddock-2.3.0 literate comments discarded from .lhs input
[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 but it is called Test.Fail in reality? Have you stripped out a deriving statement from the example above? I'm very confused by this message :) Sorry, my mistake. I pasted the error message from a different problem. This is the error I get from haddock: C:\bayleya\eclipse\workspace\takusen\srchaddock -h --odir=doc Test/Haddock.lhs Cannot find documentation for: $named_block Alistair ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haddock-2.3.0 literate comments discarded from .lhs input
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 : stable Portability : portable Test case for Haddock. module Test.Haddock ( -- $named_block Fail(..) ) where data Fail = Fail | Succeed $named_block This is some hadock documentation. -- This fails with: [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 but it is called Test.Fail in reality? Have you stripped out a deriving statement from the example above? I'm very confused by this message :) David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: haddock-2.3.0 literate comments discarded from .lhs input
On Fri, 2009-02-06 at 11:48 +0100, David Waern wrote: 2009/2/6 Alistair Bayley alist...@abayley.org: [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 but it is called Test.Fail in reality? Have you stripped out a deriving statement from the example above? I'm very confused by this message :) Sorry, my mistake. I pasted the error message from a different problem. This is the error I get from 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 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 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 unliting mode that Cabal provides is not usable with haddock-2.x. The solution is to do the pre-processing the same for haddock-0.x and 2.x. Generally the haddock code in Cabal is a horrible inconsistent mess. I believe Andrea Vezzosi has been looking at rewriting it, which is good news. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: literate comments
You could make a utility that just strips code out of XML, using the XML nesting as indentation for the Haskell code. Run it as a preprocessor. It's hard to get stuff like that standardized though. I imagine any kind of development environment is free to pretty up or package the source however it wants, so long as the compiler gets what it needs. The easiest way to make a standard is to make a tool that uses it. Personally I would prefer the kind of all-in-one package of code editor and XML packager/unpackager. That way it all gets done transparently, behind the scenes, and I never have 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 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 in XML, but a uniform representation has its advantages nevertheless (cf. openmath [1]): * approved tools for further processing * separation of the presentation layer, pretty printing * interoperability * cross-linking (e.g., generating library summaries or in the manner of funnelweb [2], but xml-style) * objects are often serializable as xml, too The following questions are still open for me: * would the literate programming facilities really be improved? for now, Haskell plays nice with LaTeX, but not at all with XML * possible advantages of xml schema? What do you think about this? Do you see even more advantages of this approach or would it be senseless work? Regards, Steffen Mazanek ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: literate comments
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 in XML, but a uniform representation has its advantages nevertheless (cf. openmath [1]): * approved tools for further processing * separation of the presentation layer, pretty printing * interoperability * cross-linking (e.g., generating library summaries or in the manner of funnelweb [2], but xml-style) * objects are often serializable as xml, too The following questions are still open for me: * would the literate programming facilities really be improved? for now, Haskell plays nice with LaTeX, but not at all with XML * possible advantages of xml schema? What do you think about this? Do you see even more advantages of this approach or would it be senseless work? Regards, Steffen Mazanek [1] http://www.openmath.org/ [2] http://www.ross.net/funnelweb/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: literate comments
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 and paste valid Haskell inside a code.../code wrapper and expect it to work without some additional markup. You could use a CDATA section: code[CDATA[ ...haskell code goes here... ]]/code This way the only character sequence you have to avoid in the code is ]], which isn't really a restriction. Udo. pgp0.pgp Description: PGP signature ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
literate comments
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 PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: literate comments
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 inside a code.../code wrapper and expect it to work without some additional markup. You may be able to get away with putting your code in PIs like this: ?code main = putStrLn Hello world! ? That, of course, is assuming that you want the XML processor to treat your code as a PI and not as CDATA. Was there something specific you wanted to do? Cheers, Andrew Bromage ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Literate comments
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 of how to format the Prelude in Joe's lap. I'll go ahead and draft the required page. Cheers, -- P
Literate comments
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 that the Prelude is presented with this convention in the report. I volunteer to draft the page. Paul, as syntax honcho you should rule on this. Cheers, -- P OK, here's a counter proposal: add a subsection 1.6 (1.5 is on layout) which describes the suggested convention on literate programming, one page max. But, DON'T re-do the Prelude; I don't believe it will improve the presentation much (in this case, anyway), and I would really rather that we leave this as a suggested convention rather than committing to using it in any substantive way. -Paul
Re: literate comments
I have been following the recent discussions on "literate style" of programming and I fail to see the purpose of making this part of the language. As Mr. Dalton suggested, a preprocessor to separate code lines from literate lines can easily be written. But I think this should be a agreed upon convention and not part of the language. As for literate programming (and I admit these remarks come only from my experience with Web programs) it's a good idea but I'm afraid it has a few problems. 1. Not everyone uses the same typesetter as you. Therefore to 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 run thought the proper typesetting program (try reading a raw, unprocessed man page sometime). And unless you have more than a dumb terminal on your desk, it is unreadable until printed. Assuming of course you have more than a impact print easily available that can handle all the different fronts people love to use. I was taught that comments should be used often, but "by the same token" should contain only relative and useful information. The current comment system of Haskell is fine for these requirements. It has been less than 2 years since Version 1.0 of Haskell was released, with Version 1.2 coming soon. In my opinion, people are wanting to "put the cart before the horse". Literate comments and other "bells and whistles" should wait a few years until the semantic quirks (the module system for example) have been worked out of Haskell and it becomes a stable, well defined language. Brad
Re: Literate comments
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 that it is NOT part | of Haskell but is supported by existing implementations, and mentions | that the Prelude is presented with this convention in the report. I | volunteer to draft the page. This sounds like a good idea to me (although I think it should be an appendix rather than a chapter). And while we're at it, why not include a Haskell program to implement the filter? This would help in several ways: - it's a pretty simple program, and would be another useful example to readers of the report. - the convention for literate scripts would then be as well defined as the semantics of the language itself. - anybody that wants to use literate scripts with an implementation which doesn't already support them wouldn't have to go to the trouble of writing their own filter. It would still probably fit onto just one page! Mark
Literate comments
Despite Paul having ruled on the matter, the debate still rages, with about half saying that is wonderful, and half saying it is awful. Under these circumstances, Paul's ruling seems right: it is pointless to legislate as part of the language. On the other hand, the current circumstance is that the main implementations do all use the convention. It seems reasonable to say this in the report -- we should at least tell other implementors what the current implementors have settled upon. This would also let Joe use the convention in presenting the standard prelude, as he says he would 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 that the Prelude is presented with this convention in the report. I volunteer to draft the page. Paul, as syntax honcho you should rule on this. Cheers, -- P PS: Wadler's Law: The emotional intensity of debate on a language feature increases as one moves down the following scale: Semantics, Syntax, Lexical syntax, Comments.
Re: literate comments
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 having to look at their context. This can be done either by placing a symbol at the start of each comment line, or placing a symbol at the start of each code line. When there are more comments than code, the latter approach produces less "noise". I have no trouble distinguishing most comment lines from most code lines without the annoying "". In the cases where a comment looks very much like code, I don't think the usual LaTeX approach of \begin and \end commands is very hard to understand. For this reason I think that a literate style should be part of the language. In any case, you can write a program to process the "" lines rather than having it be part of the language. Of course, there may be _other_ reasons for making them part of the language.
Re: literate comments
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
Re: literate comments
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 to look at their context. This can be done either by placing a symbol at the start of each comment line, or placing a symbol at the start of each code line. When there are more comments than code, the latter approach produces less "noise". For this reason I think that a literate style should be part of the language. Rick.
Re: literate comments
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 useful when I applied Latex to the source
code... so from experience I would opt for 'literate' Haskell.
Why is it useful? LaTeX doesn't understand that notation, does it?
I know it's silly to spend much time on trivial issues, but I really
am puzzled by this one. Why do people think it's reasonable to have
"" in from of lines of code? \begin{program} and \end{program}
would be more like LaTeX. Is it that hard to use literate programming
without support in the language?
-- jd
Re: literate comments
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 when I applied Latex to the source code... so from experience I would opt for 'literate' Haskell. eniko
Re: literate comments
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. Tony
Re: literate comments
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 comment, or not??? Or is there a lexical error?
The rule is clear. Only lines beginning with are in the program,
so indeed one is still at the comment at the place asked. Further
complication seems unwarranted.
Paul, oh syntax honcho: Are we going ahead with this or not? Cheers, -- P
Literate comments
| 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 Haskell system" document -- just | as we will eventually need a "Haskell std library" document. | ... Finally: all implementations support Bird tracks anyway, so | divergence is not a problem needing to be stamped out. -- Will The reason for putting this in now is so that the examples in the Sigplan Notices version can be done in literate style. This was Joe's request, which I support. (Speak up, Joe!) Will's last point suggests to me that we do have enough experience not to run into serious problems, which answers Tony's concern. Let's not spend too much time on this! Cheers, -- P
Re: literate comments
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 are good ones? Maybe I'm just thick, but I don't get it. I agree that the principle of literate programming is more important than the particular notation used. The great advantages of fixing the notation within the language are readability (I don't have to master someone else's notation to read their program) and portability (I can compile someone else's program without having to have a copy of their editor or their clever filter program). The former advantage is minor - the conventions are easy to understand. However, I would argue strongly for the latter - it seems self-defeating to design a common language like Haskell, and then have people write programs whose source text is non-portable. Nick PS Kevin Hammond has pursuaded me that my request for program lines to begin " " was wrong - I withdraw it in favour of Phil Wadler's original suggestion.
Re: literate comments
| 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 that everyone adopts the same convention, and so that we may use that convention in the Haskell report. Whether is a good convention is a matter of taste, but many people like it. Rex Page at Amoco reports that when they adopted this convention, the length of their comments doubled and the amount of code halved! -- P
Re: literate comments
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 reader. Nick North
Re: literate comments
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 thick, but I don't get it.
Re: literate comments
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
Re: literate comments
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
