On to Hydro

[Tyler Close]

Ben Laurie wrote:
> Tyler Close wrote:
> >
> > Ben Laurie wrote:
> > > Tyler Close wrote:
> > > > >  But having partially ordered elements respond to "<=",
> > > > > but not respond
> > > > > to "<", freaks me out.
> > > >
> > > > It actually seems very natural to me. In order to
> search a linear
> > > > container, you need to have either the "<", or the ">",
> > > operator. A
> > > > partial ordering does not let you search a linear
> > > container, and so
> > > > does not provide either the "<", or the ">" operator.
> > > Pretty slick,
> > > > no?
> > >
> > > No - this is, in effect, (a -> b) -> (a' -> b'), which is,
> > > of course,
> > > false.
> >
> > Does formal proof logic apply to software interface design?
> >
> > I do know that a fact of software interface design is that the
> > interface defines the space of possible operations. My
> opinion is that
> > if the operation is not in the space, then the interface
> should not
> > include it.
>
> This is Catch-22 - you redefine "<" and then claim that it
> isn't in the
> space. Fine, but so what? I prefer "<" to behave like I expect it to
> (i.e. to mean "<=" but not "==")

The operation that is not in the space is "searching and sorting of a
linear container". To remove this operation from the space defined by
the interface, I redefined "<" and removed it from the interface. If
you do not remove it from the interface, then programmers will try to
write a linear container sort using a partial order "<". The inventor
of the language himself made this mistake. He would not have made the
mistake if partial orders did not respond to the "<" operator.

"<" does always behave like you expect it to (It does mean "<=" but
not "=="). Just in some cases the operator is not available (partial
orders). In the cases where it is missing, I very much doubt that you
will notice that it is missing. Perhaps you could come up with a
concrete example where you would like to use "<" on a partial order
and not be bothered with writing out "<= but not ==".

> > > Besides, "a < b" can be defined as "a <= b && a != b"
> if you "only"
> > > provide "<=".
> >
> > "a <= b && a != b" does not result in a total ordering.
> The contract
> > for "a < b" would be that it provides a total ordering.
> If you tried
> > to search a linear container using your partial order
> "<", then your
> > search would be broken in the way defined by the "<=" contract.
>
> Naturally if a set can only be partially ordered, then it
> can only be
> partially ordered. I didn't claim to provide a total
> ordering, I merely
> claimed that you can derive "<" from "<=" and "==".

You can derive partial order "<" from partial order "<=" and "==".

> > Note that your partial order "<" would allow you to search a
> > multi-dimensional container like the Xanadu containers. A Xanadu
> > container could be implemented in E using only the "<="
> operator, as
> > Dean has pointed out. So your syntactically plausible
> implementation
> > is valid, so long as you only apply it within the space that it is
> > defined to be valid for. By not providing your implementation by
> > default, the language makes it clear that the
> implementation is only
> > valid within the space defined by the "<=" operator.
>
> It seems to me that this only helps if the programmer
> happens to write
> his code in a way that uses the operator you want him to
> use to show the
> lack of partial ordering. If the code happens to be written
> the other
> way, nothing has been added.

I think you're missing something. The programmer would be unable to
write his code in a way that did not show the lack of a partial
ordering. There is no partial order "<" operator. You have to use a
combination of "<=", "==", or ">=".

Note that this definition of different levels of function for related
operators is not totally without precedent. The C++ STL is entirely
built around layering the definitions of the pointer arithmetic
operators.

For example, in the C++ STL, an iterator that responds to:

	++i

may not respond to:

	i = i + 1

No one is up in arms about this initially strange looking discrepancy
because people who want to increment an iterator always write "++i"
and there is a very good reason for placing greater restrictions on
the "+" operator. I believe there is a parallel truth to "<=" and "<".

> So, to make it obvious that
> you are talking
> about partial ordering you should eschew _all_ the operators and use
> some new ones (e.g. a.partiallyLessThan(b)). Then no-one gets a
> surprise.

The last thing E needs is another 5 operators. As Dean has pointed
out, and I agree with, having operators for partial orders fosters
understanding.

Tyler


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com