cvs commit: hugs98/src input.c script.c

[Sigbjorn Finne]

----- Original Message -----
From: "Ross Paterson" <ross@soi.city.ac.uk>
To: "Sigbjorn Finne" <sof@galois.com>
Cc: <cvs-hugs@haskell.org>
Sent: Thursday, March 13, 2003 15:59
Subject: Re: cvs commit: hugs98/src input.c script.c


> On Thu, Mar 13, 2003 at 09:59:31AM -0800, Sigbjorn Finne wrote:
> >
> > "Ross Paterson" <ross@soi.city.ac.uk> writes:
> >
> > > On Thu, Mar 13, 2003 at 07:38:28AM -0800, Sigbjorn Finne wrote:
> > > > sof         2003/03/13 07:38:28 PST
> > > >
> > > >   Modified files:
> > > >     src                  input.c script.c
> > > >   Log:
> > > >   script.c:addScript() + input.c:parseScript():
> > > >     Delay assignment of 'scriptFile' until new file/module has been
> > > >     located. This is so that if it cannot be found, we want the
error
> > > >     message to refer to file/module that imported it.
> > >
> > > Doesn't this work only if the first import in a module fails?
> > > If the second import fails, the parent module name is gone.
> >
> > That's true, there's potential for the user to be confused by
> > this. I've added a 'parent' field to script stack entries (nice
> > consolidation you did to the representation, btw), which
> > is then made use of.
>
> I think it's cleaner to report an error immediately if you can't map
> a modid into a filename while processing the import list in chase() or
> handling a loaded module in addScriptName().  In chase() the parent is
> still the current script, so it doesn't have to be remembered.  Also,
> the error can be "Unable to find module" rather that "Unable to find
> file", and it doesn't try to read a file with the same name as the module
> (which is an occasional annoyance).  There's no need for any special
> treatment for filenames, which don't have parents.  (Except for the
> `import "filename"' feature -- would anyone miss that?)
>
> This also fits well with the rearranged structure I've implemented locally
> for the replacement for -X discussed on hugs-user.  That involves pushing

> the distinction between modules and filenames back into script.c.

Okay, that sounds all good -- as long as we end up with a solution that
fixes the usability problem here (i.e., the user is clearly told what module
contained an import that couldn't be located). Commit away.

btw, near the top of my Hugs ToDo list is to change the path searching
code a bit: pre-process the search path into a vector of directories that
could then be used to quickly&easily resolve an import. Perhaps your changes
touches upon some of this already?

--sigbjorn