[mercury-users] Inaccuracy in language definition ?

[Peter Schachte]

On Mon, Jul 16, 2001 at 07:42:21PM +1000, Fergus Henderson wrote:
> The check is done at link-time, not at compile time.
> 
> In our current implementation we do this by generating symbols
> that will result in duplicate symbol errors from the system linker
> if there are overlapping instance declarations.
[snip]
> I agree that there are significant drawbacks to our current approach,
> but all the other approaches also seem to have even worse drawbacks.

Just to stir thing a little ...

Unless I'm missing something, the problem is worse than your saying.  If I
bought one module from one vendor that declared a libarary type to be an
instance of a library class, I can never link that module with another
module I may have bought from another vendor that declares the same type to
be an instance of the same class, even if it uses different methods.  And
the only way to tell is to try (since this sort of thing may well be a minor
implementation detail in both modules, it's unlikely to be documented).
This seems pretty bad.  The only defence I see is for every library type to
be declared a member of every vaguely plausible library class in either the
module defining the class or the module defining the type.

Couldn't this problem be solved (and a bit more generality provided) if
users named their instances?  That is, when specifying that, say, strings
are comparable, I would give a name to the instance, maybe sortable_string.
Sortable_string then would be an instance of the comparable class, but
string would not.  But since instances are named, you could treat them a
living in a module (and could export or hide them).  This means there's no
such thing as overlapping instance declarations (they would just be defining
similar types with different names).  So I could easily define a
case_insensitive_sortable_string type making string an instance of
comparable using a case-insensitive comparison without a conflict with
sortable_string.  I could even define them in the same module.

The downside of this is that you'd have to explicitly specify which instance
type a particular term is intended to be.  This would only happen where a
term of a particular type is passed where a class instance is needed.  For
example, a function taking a list of strings as argument and passing it
along to a sorting function would have to specify whether to treat it as a
list of sortable_string or case_insensitive_sortable_string.  But this seems
like a good idea anyway.


-- 
Peter Schachte <schachte at cs.mu.OZ.AU>  When the leaders speak of peace / The
http://www.cs.mu.oz.au/~schachte/      common folk know / That war is coming
Phone:  +61 3 8344 9166                    -- Bertolt Brecht 
Fax:    +61 3 9348 1184                
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------