[m-rev.] for review: library improvements

Paul Bone pbone at csse.unimelb.edu.au
Fri Aug 6 09:56:33 AEST 2010


On Fri, Aug 06, 2010 at 09:43:07AM +1000, Zoltan Somogyi wrote:
> For review by anyone. Since the diff to cord.m is effectively a total rewrite,
> I am attaching the new version of the implementation section that file,
> and you probably want to review that instead of the diff.
> (There is only the diff for list.m.)
> 
> Zoltan.
> 
> Library improvements.
> 
> library/list.m:
> 	Replace some semidet code with det code. This leads to a speedup
> 	of about 1.2% on tools/speedtest -l.
> 
> library/cord.m:
> 	Replace the type representing cords. The old type had many different
> 	ways of representing the empty list, and had to rely on a convention
> 	to avoid all but one of them. By design, the new type has only one
> 	representation of the empty list.
> 
> 	The basic idea is to represent the empty/nonempty distinction at the
> 	top level, and to use another type to represent nonempty cords.
> 	This other type is like the ord cord type, but without nil.
> 	The existence of two levels rather than one in the representation
> 	can be expected to lead to a slight constant slowdown, but on the other
> 	hand, the existence of only three rather than four function symbols
> 	in the type that all the recursive code handles can be expected to lead
> 	to a slight linear-size speedup. On tools/speedtest -l, the result
> 	is a very slight speedup, though it is so small that it is in the
> 	noise.

A while ago I considered renaming the cord type to cord_inner and creating a
new cord type which had a single function simple.  Then I could define
user-defined equality and comparison code for 'cord' (the type with the single
function symbol) and make it compare the 'cord_inner' structures without using
structural equality.

This would allow us to be sure that CordA = CordB is true even when the two
cords have a different internal structure but the same semantics.

Is this worthwhile trying to implement?  Is it worthwhile to include in this
change?

Thanks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20100806/8a7f8577/attachment.sig>


More information about the reviews mailing list