[mercury-users] some [T] ...

[Michael Day]

> > So the typeclass_info would point to a structure that is shared between
> > all values of foo that have the same type T?
> 
> These structures may be constructed at run-time - unlike ML, we don't
> monomorphise a program during compilation.

Question: is this bad if I have several million values of type foo? Will I
end up with several million type class info structures too?

> It was a pragmatic decision.  It allows one do write traditional
> functional programs, largely without having to worry about modes.

That's pretty much what I meant. Applying a bandaid is a pragmatic 
decision when it's all you have :)

> The problem is that workout out a non-cumbersome mode system that
> admits efficient analysis is still something of a research problem.

I'd put up with the much touted six times slower mode analysis; it'll just
give me more time to think during debugging. But the non-cumbersome aspect
is tricky, it sometimes seems like the mode system of Mercury is
simultaneously its greatest asset and its greatest impediment. Still, with
so many bright people working on it, there's bound to be something figured
out round about the time people get sick of working on the .Net back end,
perhaps :)

> I quite like the idea of using a type class to get around awkward mode
> problems.

Yes. Incidentally - every day brings up another reason why type classes
with functional dependencies would be really helpful *cough* Hint, Hint.

Michael

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------