Re: Curry module system

From: Michael Hanus <>
Date: Mon, 06 Feb 2006 14:50:55 +0100

Wolfgang Lux wrote:
> 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.

...but I think this is not the best choice for a lazy programmer...
(I have bad reminiscences of Modula because of this 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.

Ok, it is difficult to define what modularization means and I have
no exact definition for it. I only had in mind that changes
in another module should not require changes in my own module
if the part of the interface I am using from the other module
does not change.

> > 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?

No, Java does not report an error since in Java local definitions
shadow global as well as imported definitions. In general, I think an
error should be reported for programs which have no semantics
or for which a reasonable semantics is difficult to
provide/understand. In our case, shadowing of imports
is the same as shadowing in local declarations so that it is
fairly easy to understand. However, there may be pitfalls and
thus a warning is reasonable for shadowings.

> > 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.
> Figs. 3 and 4 describe the semantics of case expressions in detail

Thanks, but I looked for a more static translation into
definitional trees or basic case expressions a la FlatCurry.
Nevertheless, I think that the rules of the Haskell report
could be helpful for this task.

Best regards,


curry mailing list
Received on Mo Feb 06 2006 - 15:07:44 CET

This archive was generated by hypermail 2.3.0 : Do Jun 20 2024 - 07:15:07 CEST