[MLton-user] Extended Basis Library: Partial order concept

Vesa Karvonen vesa.a.j.k at gmail.com
Thu May 3 13:47:17 PDT 2007


On 5/3/07, Geoffrey Alan Washburn <geoffw at cis.upenn.edu> wrote:
>      I just spent a couple minutes fiddling with a revision to the ORDERED
> concept to introduce partial orders.  I do not really care for the names I
> am using here, but I was not sure whether it would be desirable to have
> types and signatures with names as long as »partially_ordered« or
> »TOTALLY_ORDERED_EX«.
[...]

Ok.  Looks basically good.  PARTIALLY_ORDERED would indeed be a bit
long.  To be honest, abbreviations always leave me a bit uneasy (and this
includes all the abbreviations that I've already introduced into the
extended basis).  Abbreviations never seem short enough unless they are
cryptic.  I find it very difficult to choose abbreviations.  But I think
that PORDERED is fine.  One of the nice things about ML (vs almost every
other language) is that one can safely rename (simply rebind or wrap)
almost everything after the fact.

A few things that come to mind.

I think that TORDERED_EX should be ORDERED_EX for consistency.  IOW,
the two concepts are ORDERED and PORDERED.

ORDERED can be defined more concisely by including PORDERED, ORDERED_CORE,
and ORDERED_EX.  (Just like ORDERED is currently defined in terms of
EQUALITY.)

I'm not sure whether one should use < or <= in PORDERED_CORE.  I would go
for <.  This is probably mostly because that is what I got used to when
working with the C++ STL.  I don't know if there is any technical reason
to prefer one over the other.  In particular, it takes on average the same
number of operations to synthesize other relational operators from either
< or <=:

  a < b              a < b                 not (b <= a)
  a > b              b < a                 not (a <= b)
  a <= b        not (b < a)                     a <= b
  a >= b        not (a < b)                     b <= a
  a == b        not (a < b or b < a)            a <= b and b <= a
  a != b             a < b or b < a        not (a <= b and b <= a)

A semi-technical reason would be that < is one character shorter than <=
and definitions using < therefore lead to a few characters shorter code.
All other things being equal, shorter is better.

-Vesa Karvonen


More information about the MLton-user mailing list