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.
> http://haskell.org/onlinereport/exps.html#sect3.17.3
> 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,
Michael
_______________________________________________
curry mailing list
curry_at_lists.RWTH-Aachen.DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/curry
Received on Mo Feb 06 2006 - 15:07:44 CET