Wolfgang Lux wrote:
> I admit that it is a bit inconvenient that you have to change the
> local module. However, keep in mind that you only have to add an
> appropriate hiding clause to the import declaration (or specify the
> entities, which you want to import, explicitly).
Hiding clauses might not be enough if the implementor of the imported
modules decide to extend it. Thus, I think the influence of
additional imported entities to the code of the local module
is against the idea modularization. You are right that this
can be avoided by writing correct imports that enumerate
all the required entities, but this is also a tedious task.
> On the other hand, Haskell's policy of reporting an error in case
> of name conflicts between top-level declarations and imported entities
> becomes really a bonus when you want to import a library function, but
> there accidentally happens to exist a definition with the same name
> in the module. If the compiler silently chooses the local definition,
> this may lead either to somewhat confusing error messages from the
> type checker (confusing because you will likely have troubles to match
> the types in the error message with the type of the imported function)
> or, even worse, to very hard to track down runtime bugs. IMHO,
> preventing such errors is really worth the "inconvenience" of having
> to use hiding clauses.
I agree that this is an advantage. However, why is it necessary
to report an error and, thus, forbid the import completely?
I think that the same goal can be less strictly achieved by providing
a warning so that the programmer becomes aware of the potential
problem. Note that a similar situation or conflict can also
occur inside a module between top-level and local declarations.
In this case, a conflict is not considered as an error but
might cause the same problem. Thus, PAKCS delivers warnings
in this case, and I think the same warnings should be also
delivered w.r.t. import shadowings.
> If you have guards in the alternatives of a case expression you
> sooner or
> later want to have local declarations that scope over all guards and
> where
> the pattern's arguments are in scope, e.g.
Ok, I see the point and I'll add it if nobody objects.
However, the translation of case expressions becomes more complex
so that I wish to have a complete specification of translating
complex cases into primitive cases in the report, similar to
the elimination of local declarations (Appendix D.8).
Do you have references to similar works?
> I assume that you refer to syntax aware highlighting as, e.g.,
> performed by the Haskell mode for Emacs. AFAIR, the Haskell mode
> (on which your Curry mode for Emacs is based) uses the case of
> identifiers in order to distinguish variables/functions and
> constructors. In fact, without reading the definitions of module
> A, how would you tell whether A.x is a function or a constructor
> and colorize it correctly?
Of course, such a correct highlighting is not possible with the
simple Emacs mode (which already has it drawbacks). A correct
colorization requires more information. Thus, I am thinking
of a better programming environment like Visual Haskell or,
at least, one can use colorization when generating program
documentation, as with currydoc (but this is not yet done).
Best regards,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Do Feb 02 2006 - 21:27:42 CET