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
> 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 firs
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 im
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 leas
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 prefer
> > - 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
> > > 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
> - 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.
Soun
> 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 Universi
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 sel
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 reasonab
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, most
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
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.
>
> This is an easy change to
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 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 director
16 matches
Mail list logo
