[Prev][Next][Index][Thread]

Re: Interfaces

Greg Sullivan (7/2/00) said:
>One shortcoming of Dylan's module system is that you cannot be more
>specific than names -- i.e. you can't specify the type signature of
>methods or generic functions at the module level.  At least Java
>interfaces allow you to specify the names _and_ types of methods that
>must be implemented.

Speaking as one of the designers of the existing module system, I strongly
disagree with you on this.  It was in fact completely intentional that Dylan
module definitions *don't* contain such information.  Dave Moon explained
it well, in a long-ago (3/3/94) email discussion:

   Dylan does not require programmers to make a textual copy of portions
   of the definitions of items exported by a module, like a C header file
   or an  Ada package declaration.  In my opinion Dylan modules still have
   a  well-defined interface; the difference is that we assume there will
   be the  obvious development tools for printing out that interface,
   instead of requiring programmers to pretend to be tools and copy text
   from one file to  another.  (Except of course Dylan still requires
   programmers to copy the -names- of the exports from their definitions
   into the define module statement.  We haven't thought of a good way to
   avoid that.)

As Rob Meyers (7/3/00) noted:

   In Java, you still have to read the sources or the JavaDoc to find out
   about a method. Dylan is no different ...

>Having type signatures as part of the module system would enable
>better cross-module type checking and better optimization.

Having type signatures as part of the module system should do nothing to
improve cross-module type checking and optimization.  The development
environment and delivery model assumed by the existing specification of
module defining forms is that part of a library that one can compile code
wrto and link to is some information provided by the compiler when it
processed that library.  One of the things that should be in that
information is the stuff needed to compile more efficiently references
to the library's bindings.  Type information is only one of many bits that
ought to be placed there, including such things as inlining  information,
sealing, expected code size (might be used for automatic inlining
decisions), expected runtime cost (again useful for inlining), and so on.
Much of that can't reasonably be generated by the programmer, and really
needs to be done by the compiler.  Given the existence of this repository,
it seems pretty silly to make the programmer maintain two independent
copies of the type information when the compiler could just as easily
generate the needed information by processing the definitions instead of
comparing the two copies and complaining about the occasional mismatch.
References: