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

[Ross Paterson]

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.