Michael Hanus wrote:
> 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.
Another solution is to use qualified imports everywhere, which
has the additional benefit of making it clear whether you are
using imported entities or not. BTW, some languages (including
Standard ML and Objective Caml) make qualified imports the
default or even the only choice.
Furthermore, name conflicts which arise due to the fact that
the implementor of a library module has decided to extend
its interface indicates that you have implemented the same
functionality yourself. This is a chance to make use of the
new library function instead of duplicating its functionality,
which would actually improve modularization of your program.
So I really can't see why this should be against the idea of
modularization.
>> 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?
Certainly, there is no need to report an error, you could use a warning
as well. Maybe it is simply that I'm used to the fact the most other
languages with a module system report an error in this case, too?
> [...]
>> 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?
Look at Sect. 3.17.3 of the Haskell report.
http://haskell.org/onlinereport/exps.html#sect3.17.3
Figs. 3 and 4 describe the semantics of case expressions in detail
(including some features which I haven't asked for inclusion in
Curry :-).
Regards
Wolfgang
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Fr Feb 03 2006 - 17:31:16 CET