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

On Thu, Mar 13, 2003 at 09:59:31AM -0800, Sigbjorn Finne wrote:

"Ross Paterson" 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.