On Fri, 23 May 2003, Nicolas Cannasse wrote:
> > Which means we're probably stuck with something like:
> > let Int.compare x y = if (x < y) then -1 else if (x > y) then 1 else 0
> Uh !
> This time Brian you're using up to TWO times polymorphic comparison !
You're right. Need a typecast:
let Int.compare (x: int) (y: int) = if (x < y) then -1 else if (x > y)
then 1 else 0
> I think the most easy solution is really to use the substraction, but that
> will cause the problems you showed with max_int / min_int , and doing some
> previous boundary tests before return x - y will increase the cost of it. So
> my conclusion is this is an user-specific problem (some might need max_int
> while some might not ) which should be addressed by not adding the module
> Int to the ExtLib, although it was a good idea.
Actually, handling the corner cases is a good argument, IMHO, *FOR* adding
class Int. This strikes me as being a common error.
> About the partial_map, this can be done using a fold_left, which is more
> appropriate since you don't allocate None/Some blocks . But I think perhaps
> fold_left/right are not so easy to use in the first place, so maybe having a
> partial_map would be nice , but I would rename it to filter_map since this
> can be done using one map + one filter.
Allocating the option blocks doesn't worry me much. I assumed that we
wanted to a) avoid allocating an unnecessary interim list, and b) wanted
to construct the list forwards, as opposed to doing a List.rev. If either
of these are relaxed, then yes, the function can be fairly easily
implemented given existing functions.
> BTW, I would prefer a more simple version of the Brian one, which does not
> need two loops :
> let filter_map f l =
> let rec loop dst = function
> |  -> ()
> | h :: t ->
> match f t with
> | None -> loop dst t
> | Some x ->
> let r = [ x ] in
> Obj.set_field (Obj.repr dst) 1 (Obj.repr r);
> loop r t
> let dummy = [ Obj.magic () ] in
> loop dummy l;
> List.tl dummy
I forgot about this trick. This is a better implementation.