(We do want to promote units but to be honest, I considered
contracted units a 'warm up' exercise for Stevie :-)
Philippe, do you realize that
F/F units used structural sig matching (they are Matthew's response
to my finding faults with struct/functors)
O/F units use nomimal sig matching?
While I was surprised at first, it started to make sense as Stevie
and I worked through the exercise of adding contracts. Matthew and I
lived in a "free" world where sigs just mentioned names and there was
no meaning attached to them at all. I never figured out whether our
type system was pragmatic. In this day and age, I'd say my
grandmother could have designed it (if she were alive).
The very moment you introduce some amount of meaning (even an epsilon
such as a type) or a lot (such as a contract) -- you seem to get some
of the ML-style problems. BUT nominal matching ensures that you can
say "the same t as over there" with importing appropriately. The name
of the sig determines sameness, no sharing constraints needed. Yet.
The problem with cyclic export/import comes out most when you think
about cyclic datatypes. ML style type systems can't allow that.
Neither can we. So we will have to think hard about this one. For now
I recommend using macros to overcome the problem.
-- Matthias
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
