The suggested changes sound hard to understand and to implement
consistently in all compilers. I lean towards leaving the spec as it
is.
Hmm, I'm not sure why you say these changes are hard to understand.
Which part(s) in particular do you find difficult?
Hugs already implements the first
Simon Marlow wrote:
- We could provide the ability to specify a module prefix
to associate
with a directory in the search path. For example, you could say
that the directory '.' is associated with the module prefix
Graphics.Rendering.OpenGL and avoid having to place
I'm not sure what syntax we'd use for this. Henrik suggested
placing the module prefix in square brackets before
the directory,
eg.
ghc -i '-i[Graphics.Rendering.OpenGL].'
This seems a bit unpredictable to me; it means that you can
have a whole bunch of
- We could provide the ability to specify a module prefix
to associate
with a directory in the search path. For example, you could say
that the directory '.' is associated with the module prefix
Graphics.Rendering.OpenGL and avoid having to place
your sources
in
The suggested changes sound hard to understand and to implement
consistently in all compilers. I lean towards leaving the spec as it
is.
IIRC, the current Hugs semantics is a complex balancing act intended
to achieve backward compatability and implement module paths at the
same time. I'd
Hi Simon,
CC Glasgow-Haskell-Users
I've never quite managed to figure out what VPATH is for; one reason is
that I've never got it to cooperate well with automatically-generated
dependencies.
As long as one uses automatic variables in all commands, it seems to
work fine. Well, I have at least
Hi Alastair!
The suggested changes sound hard to understand and to implement
consistently in all compilers. I lean towards leaving the spec as it
is.
I think they're pretty straightforward, actually.
Coudl you elaborate on why it seems complicated to you?
As to implementation, I can't
Hi Folks,
Henrik Nillson I have been discussing the current behaviour of GHC
when searching for modules, particularly in combination with
hierarchical modules, and have identified two ways in which things might
be made more flexible.
The current situation forces you to put sources in a
On Mon, Dec 09, 2002 at 12:40:18PM -, Simon Marlow wrote:
- The sources for a module A.B.C would be allowed to be placed
in either A.B.C.hs or A/B/C.hs relative to one of the directories
in the search path. Currently only A/B/C.hs is allowed.
Please let us know if either of
Hi,
I'm not sure what syntax we'd use for this. Henrik suggested
placing the module prefix in square brackets before the directory,
eg.
ghc -i '-i[Graphics.Rendering.OpenGL].'
In contrast to the previous suggestion, this would actually save
some trips to the OS
Hi Lauri,
Since the problem is often that your program/library has a managable
depth, but it is _located_ very deep in the hierarchy (eg. User.*
modules if you have a long and complicated domain), then how about
allowing A.B/C.hs for module A.B.C? Then you don't need to have a
long, mostly
Hi Andre,
I like this idea, especially if this is currently the way Hugs
does it. It's great for smaller projects.
Yes, we believe Hugs does allow A.B.C.hs as well as A/B/C.hs.
Ultimately, I think it is actually going to quite important that the
different Haskell tools provoide reasonably
On Mon, Dec 09, 2002 at 12:03:10PM -0500, [EMAIL PROTECTED] wrote:
If, say, a library consists of the top-level module A.B.C and
a bunch of internal components A.B.C.M1, A.B.C.M2, etc.,
I can't see why I should not be allowed to put them all in one
directory.
I think that's the selling
It's all bad once that VPATH word gets mentioned ;).
Granted!
But other work-arounds can be even worse!
And again, if an implementor for some reason thinks he or she could benefit
from using a mechanism like VPATH, it's good if that's not too painful.
/Henrik
--
Henrik Nilsson
Yale
- The sources for a module A.B.C would be allowed to be placed
in either A.B.C.hs or A/B/C.hs relative to one of the directories
in the search path. Currently only A/B/C.hs is allowed.
This is an easy change to make, and I believe Hugs already does
it this way.
Sounds
15 matches
Mail list logo
