Re: Wishlist questions

[Michael Livshin <mlivshin at bigfoot dot com>]

Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

> >> First I must ask you why you think I'm talking about types and in what
> >> sense, since I can't remember talking about it in the letter you reply
> >> to.  
> 
> I've asked because I don't want to separate the module's interface
> from the module implementation.  Eiffel is a very old language and has
> been used to build huge software systems.  Until now it doesn't
> support signatures.  In fact, a signature is just the poor man's
> version of a class.  Signature inheritance is less powerful than class
> inheritance.

the above is rather meaningless out of context.  you could have a
module (or "unit" in PLT-speak) system where the signatures would be
just GOOPS classes, and modules whould be instances of them (or would
behave like ones, the exact equity doesn't matter - that's CLOS power
for you).  i.e. you could have environments whose bindings would be
object slot values.

> > For a large program, it's not the code but the interfaces between
> > modules which is the central and most important part of the design.
> 
> I disagree.  You can mix the module's meta information (extends what,
> imports from, exports what, ...) with the module code.  The compiler
> is responsible for extracting the meta-information.

and this is downright bad idea.  I don't *want* to mix module
meta-stuff with code.  note that this doesn't contradict the desire to
have modules be first-class and in Scheme, and not in some language
above Scheme.  it's just that the current mixing of the meta-code with
actual code in the same lexical context is downright messy and should
go away as far as possible, IMHO.

> > For example, we might design a database interface consisting of a
> > number of variable and procedure names, and possibly type
> > declarations.  Then different people might come up with different
> > database implementations, but they all support the same interface.
> 
> You create a prototype class from which the concrete classes (designed
> by different people) can interit.  Because they derive from a common
> super-class they have not only the same interface but also a common
> structure.
> 
> > This basics of this idea is the same as that behind ADT:s
> 
> Got me. :)  What are ADT's?

abstract data types.  oh, and read some introductory material on CORBA 
if you don't see what Mikael is getting at above.

> > The reason why we want to be able to specify types is that compilers
> > can use them to do static analysis of a module in order to generate
> > maximally efficient code.  
> 
> Types yes, signatures no.   I don't think it is a good idea to abuse
> a programmer as some kind of pre-processor for the compiler. :)
> 
> While compiling P the compiler can get all the meta-information for
> module Q just by looking at the interface file of a Q.  -- This
> interface file has been created by the compiler itself.
> 
>  P.scm ----- compiler ----> P.obj
>                       \---> P.interface 
>                                         |
>  Q.scm ----- compiler ----> Q.obj        |  (references Q)
>                       \---> Q.interface <

how does this sort of thing play with separate compilation?

> > > > * support re-use of code (the same implementation can be presented to
> > > >   the world through several interfaces)
> > Let's take the database situation again: Let's say that there are two
> > branches of development of applications with databases out there.
> > Neither branch knows about eachother until time T.  Then people from
> > the extraordinary application A discover the excellent database used
> > from application B.  Team A might then persuade team B to implement
> > and publish an A family interface in their database code.  This works
> > as an adapter so that code from both the A and B family can use the B
> > database.
> 
> Hmm.
> 
>            Common
>            /    \
>           A     B  (inherit from Common)
>            \    |
>              \  B' (inherit from A and B)
> 
> Customers can use B' which implements both A and B functionality.
> This is called "repeated inheritance", not "multiple inheritance"
> btw.  Repeated inheritance means that all slots inherited from
> Common will be merged in B'.

and Common is the "fragile base class", right?

> > Another example concerns backward compatibility: One might want to be
> > able to publish different revisions of the same interface in
> > developing code so that both old and new users can be supported
> > simultaneously.
> 
> Should the new and old version be available simultanously or
> should the old version only be available to "old" customers?

you should be able to use two modules with identical interface at the
same time.  it's not an interface issue, it's a linking issue.  it's
useful not to confuse the two things.

> Jost

--mike

-- 
For those who like this sort of thing, this is the sort of thing they like.
                                                                 -- fortune