cvs commit: hugs98/src input.c script.c
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. Revision Changes Path 1.64 +6 -2 hugs98/src/input.c 1.7 +0 -2 hugs98/src/script.c
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. On the subject of scripts (though not new in this change), it's a bit wierd that findPathname() discovers that something is missing, but then returns its argument intact so that fileInput() will report the error. This produces wierdness like a module M matching a file M with no extension, or the inaccurate message 'Unable to open file "M"'. Of course fileInput() has to check even if findPathname() succeeded, in case the file disappears, but earlier on we could give better messages.
"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. --sigbjorn
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.
----- 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
On Thu, Mar 13, 2003 at 06:47:11PM -0800, Sigbjorn Finne wrote:
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.
Thanks -- done.
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?
No, there's no effect on this.
participants (3)
-
Ross Paterson -
Sigbjorn Finne -
Sigbjorn Finne