RE: Unqualified names for -ddump-splices?
Good idea. I've substantially improved this. In HEAD. Thanks for the suggestion. Simon | -Original Message- | From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Daniel Schüssler | Sent: 16 May 2009 16:11 | To: glasgow-haskell-users@haskell.org | Subject: Unqualified names for -ddump-splices? | | Hi! | | is it possible to look at spliced code without fully qualified names? (And | maybe with simple integer indices for newNames). Currently it can be pretty | hard to decipher sometimes :) | | | Greetings, | Daniel | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ 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 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
draft proposal for relative paths in installed package descriptions
All,
This is a draft proposal for a common mechanism for implementing
relative paths in installed package descriptions.
Comments and feedback are welcome. I'm cc'ing this to the cabal and
ghc-users lists but let's keep the discussion on the libraries list.
There has been some discussion of this issue on the cabal and ghc-users
list, but it's a relatively long thread and the idea has evolved
somewhat so this is an attempt to present the proposal clearly.
Proposal
This proposal is an extension to the Cabal spec section 3
http://haskell.org/cabal/proposal/x272.html
Motivation
--
Being able to have relative paths in the installed package description
is useful as it makes it possible to construct relocatable
(prefix-independent) package installations. This is useful when
distributing compilers along with packages and there may be other uses.
This proposal does not require that all paths are relative. It is still
perfectly ok to use absolute paths where appropriate. It just adds an
option to use relative paths.
The aim is for a single simple specification that any compiler can
implement and have the tools work uniformly, rather than ad-hoc
implementations for each compiler.
Details
---
In the installed package description, we will allow paths that begin
with the variables ${pkgroot} or ${pkgrooturl}. For example:
library-dirs: ${pkgroot}/foo-1.0
haddock-html: ${pkgrooturl}/doc/foo-1.0
They may only appear at the beginning of the paths and must be followed
by a directory separator (platform-dependent '/' or '\'). This is
because the vars refer to a directory so it does not make sense to
construct extensions like ${pkgroot}blah. The use of '{}' is required
and is to avoid any ambiguity (especially since the string $pkgrooturl
is otherwise an extension of $pkgroot).
Directly relative file paths like blah or ./blah are not allowed.
Fields containing paths must be absolute or begin with ${pkgroot}. Field
containing urls must be absolute or begin with ${pkgrooturl}.
The var ${pkgroot} is to be interpreted as the directory containing the
installed package description. For ghc this will be the dir containing
the package.conf db, for hugs/nhc for each package there is a specific
installed package description file, and ${pkgroot} is thus the directory
containing that file. The syntax of the string representing this
directory is the usual system-dependent filepath syntax, e.g.
windows: c:\ghc\ghc-6.12.1
unix:/opt/ghc-6.12.1
The var ${pkgrooturl} is to be interpreted as a url representation of
the directory containing the installed package description. For ghc this
will be the dir containing the package.conf db, for hugs/nhc for each
package there is a specific installed package description file, and
${pkgroot} is thus the directory containing that file. The syntax of the
string representing this directory is as a valid file url including the
file:// prefix e.g.
windows: file:///c:/ghc/ghc-6.12.1
unix:file:///opt/ghc-6.12.1
This is similar to how relative paths in .cabal files are interpreted
relative to the directory containing the .cabal file, however in this
case we mark relative paths more explicitly using a variable.
So in the original example
library-dirs: ${pkgroot}/foo-1.0
haddock-html: ${pkgrooturl}/doc/foo-1.0
If we assume this installed package description is at c:\ghc\ghc-6.12.1
\package.conf on windows or /opt/ghc-6.12.1/package.conf on unix then
the compiler and other tools would interpret these as
library-dirs: c:\ghc\ghc-6.12.1/foo-1.0
haddock-html: file:///c:/ghc/ghc-6.12.1/doc/foo-1.0
or on unix:
library-dirs: /opt/ghc-6.12.1/foo-1.0
haddock-html: file:///opt/ghc-6.12.1/doc/foo-1.0
Tools
-
Tools which process the installed package description format will be
expected to interpret these relative paths. This requires that they can
discover the path for the ${pkgroot}. How they discover this is
dependent on the Haskell implementation. Some implementations use
separate files for each installed package description, some embed them
in library package files, some use databases of installed package
descriptions. Haskell implementations should provide a mechanism to
discover the path for an installed package description.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
