[mercury-users] Library v2 and Typeclasses'n'Stuff

[Michael Day]

> - make extensive use of assertions/promises.

What exactly are assertions/promises? The one assertion I've stumbled
across was in the int module,

:- assertion all [A,B,C] ( C = B * A <=> C = A * B ).

does the compiler take advantage of this somehow when optimising, or is it
waiting for a future optimisation, or does it allow smarter code analysis
or am I missing the point entirely? Would more widespread use of
assertions improve the quality of the code, or the readability of the
code, or both?

> Typeclasses:
> 
> - showable(T) where
> 	func to_string(T) = string

Seems useful, although I can't help wondering about a system that has
readable/writable, and allows reading from and writing to strings just
like any other IO stream. But hey :)

> - ordered(T) where
> 	pred T < T is semidet,
> 	pred T =< T is semidet

What variations on ordered are usually present in a library of this
nature, is it customary to present < and =< rather than < and =, or just
< ? Is it worthwhile providing more than one class of ordering? Must admit
I'm not familiar with the standard conventions here, so just file that one
under "general brainstorming".

> - set(T) where
> 	... the usual suspects ...
> 
> - tree(T) where
> 	...

set(T) would appear to be a very useful type class due to the large number
of possible implementations. Similarly with map(K, V). But is tree a
useful abstraction? If a tree is being used to implement a set or a map
then it is already catered for, and I would have thought that generally
two trees would not be compatible, for instance mixing a binary tree and
red-black tree, or heap. Hmm come to think of it, I'm not so sure. Do you
have any example usages, I think I must be missing the point.

> - IO

This is where I am most interested, particularly in making it as easy for
users to extend as possible. Seems some well designed type classes could
avoid the mess that results from trying to extend a C++ iostream, wonder
if there are any spare operators that could be used for more sickening IO
syntax...

> - Maths

The basic numeric stuff all seems to be done, are there some more advanced
functions or mathematical tools that could be included? I heard someone
earlier discussing type classes for rings, fields, groups and so forth, is
that what you had in mind?

> - Collections (list, array, set, ...)

Is it possible to define several basic type classes relating to
containers, that would allow more generic algorithms to be written,
somewhat in the spirit of the C++ Standard Template Library? Can it be
possible to write a mergesort predicate that works with several different
types of containers, using type classes?

> - Parsing (std. syntax, regex, awk-like stuff, ...)

That would be nice, indeed!


One question I have is where will the line be drawn between what goes into
the standard library and what gets bundled into a contrib/ or extras/
package separate from the compiler? C and C++ are fairly deprived
languages when it comes to this, it would be nice for things like POSIX
socket support to sneak into the standard libraries given their level of
use. But things like OpenGL bindings, gtk+ bindings, they would be more
appropriate distributed separately from the language itself? What level of
functionality is being sought in the standard library, what is the goal?

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