[plt-dev] compound units and contracted signatures

Carl Eastlund wrote:
>Philippe wrote:
>> Carl Eastlund wrote:
>All of this assumes inferred linking, and that compound units export
>all signatures.

It wouldn't have to explicitly export all signatures, each compound
unit could just have some special attribute somewhere to keep track of
which linking assumptions have been made so far.  Implementation
details :-)

>For explicit linking that may hide some exports, your
>reasoning does not apply.  You can have many different t?'s, and a
>later linking won't see earlier ones.

I'm not saying it's perfect, I'm just saying that in the most common
linking case it's quite obvious where the t? predicate should come
from, and that it would be nice to have a form like
compound-unit-with-contracted-signatures to handle that common case
more smoothly, that's all.

Carl Eastlund wrote:
>Jay McCarthy wrote:
>> Carl Eastlund wrote:
>>> Philippe is only describing problems of units with contracts, which
>>> are very, very new. None of this applies to units without contracts.
>>> Have I missed something?
>>
>> The exporting importing problem is about non-contracted units.
>
>True, but Philippe's need for it was.

Actually, I said that, out of my three units that have to re-export
imports, two do it because of contracted signatures.  The third one is
different: I'm implementing the equivalent of the adapter pattern
using units.  Something like this:

u1 --b,c--> u0 --a,c--> drscheme

where u0 acts as an adapter between u1 and drscheme that transforms
functions like b into functions like a.  The problem is that some
functions like c that are exported by u1 don't really need to be
adapted in u0, they could just be directly re-exported, but that's not
possible.  So I have either to do the re-define/rename dance inside u0
to go around the restriction on re-exporting the import c, or I have
to split the signature of u1 into two parts, one that's imported by u0
to be adapted, and one that bypasses u0 entirely:

u1 --b--> u0 --a--> drscheme
|                    ^
|                    |
+---------c----------+

This works too, but it means I have to tell the person implementing u1
to deal with two separate signatures instead of just one, for no
obvious reason (from their point of view).  So I just do the
re-define/rename thing instead, since then I'm the one dealing with
the small extra complexity, not the other person.

For this problem too I think that the nicest solution would be to
remove the not-re-exporting-imports restriction, but that's just me :-)

All in all, there are fairly simple ways to go around all the various
little problems with units, it's just that none of them are really
nice.

>> But, not having contracts in units was always a detriment to use them
>> for me, now that we have those, I'm observing all sorts of other
>> annoyances when I tried to use them in ways like Philippe mentions.

Yes, my experience so far is that contracted signatures do exacerbate
the not-re-exporting-imports problem.  That being said, contracted
signatures are great, and the unit system is definitely getting better
(scheme/unit makes life quite a bit easier, for example).

Philippe