Hi Takeshi -- > I have submitted an issue about internal errors arising > from the use of file names such as "real.chpl" and "list.chpl" > (I'm sorry to have taken time to do this...) > > https://github.com/chapel-lang/chapel/issues/6189
Thanks very much for filing this. I started to look into this yesterday but didn't get very far yet, though you'll see my initial comments on the issue itself. > Though this issue can be easily avoided by just using > different file names, my concern is that this might discourage > a new user to keep learning further, particularly because > there are several "work-in-progress" message both in the PDF > manual and the Chapel web site (so the user might > assume that it may be too early to try the compiler). I definitely agree that this definitely shouldn't cause an internal error and would be discouraging if it was a user's program. > So, to avoid such an unfortunate case, I would appreciate it > if some more explicit error message is printed when a user file > name or module name is problematic (e.g., by interference > with internal routines). I believe this would make the chance > of new users to stumble on such trivial cases in the initial > learning step. I think this would be great, but I'm not sure what set of names we would need to guard against to keep the user safe. If it were just the internal types and symbols that the compiler inserts (like real, int, etc.) guarding against that list wouldn't be too bad, but your example showing that 'list' also results in problems is a bit more worrisome, since that's not part of the language itself. For that reason, I'd like to understand what's going on in that case better and think more about how we implement the built-in types to see if we can come up with a more robust and general solution other than starting to look for certain identifiers, for fear that that list would just grow and grow. > # By the way, I feel it would be even better not to use a file > name implicitly as module names (like Python), but rather > always define a module explicitly in files (like namespace in C++ > or module in Fortran). Because this requires only adding two > lines on the header and footer of the file (with no entire > indent assumed), I guess things may become more explicit and > more robust, e.g., for change of file names. I think that's a reasonable style consideration, but I don't think we're open to making the language require it. Specifically, the ability to just drop some Chapel code into a file and start compiling it has been a big productivity boost in the language, and not something we'd want to give up. Moreover, as you note, this wouldn't actually do anything to guard the user against the surprising error messages that you note if they named their module 'real' or 'int' or 'list'. That said, note that for most of our library modules, we do use the 'module' keyword to introduce the module rather than relying on the filename due to a belief that it represents a better practice. Thanks again for filing the issue, -Brad ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
