Re: Range Types, constructors, and the type system

Jeff Davis wrote:
> On Sun, 2011-06-26 at 00:57 -0700, Darren Duncan wrote:
>> I believe that the best general solution here is for every ordered base type to
>> just have a single total order, which is always used with that type in any
>> generic order-sensitive operation, including any ranges defined over it, or any
>> ORDER BY or any <,>,etc. The built-in generic text type would have exactly 1
>> system-defined collation that can't be changed, and it would be something simple
>> and generic, such as simply sorting on the codepoint as integers.
>
> Well, we're trying to support SQL, and SQL supports collations, so I
> don't think we can just ignore that.

I'm not saying you can't support collations. See also my reply to Tom.

> I also agree with Tom that it's not a good idea. My reasons are:
>
> * Practical considerations, such as having a bunch of cruft from
> duplicated types all over the system. With sufficient changes to the
> type system, maybe that could be overcome. Or perhaps domains could be
> used to make that work for range types (sort of), but the result would
> not be very consistent with the rest of the system.

Yes, duplication can be avoided.

> * It doesn't seem to be based in any mathematical argument. A type is a
> set of values, and there's no reason it can't have several total orders;
> or no total order at all. So it appears to just be piggybacking on the
> type system infrastructure as a place to hold the metadata for a total
> order.

Yes, I agree that a type is a set of values, and a type can have 0..N total
orders. My proposal is just that, for those types that have at least 1 total
order, exactly 1 of those is defined to be used implicitly in contexts where a
total order is desired and no explicit collation is given, such as in ranges.

> * Who's to say that a "compare" function is the only way to specify a
> total order? There might be other interfaces that would support
> something closer to a lexicographic sort. So, from a theoretical
> standpoint, trying to attach a single notion of total order to a type
> seems strange, because there might be multiple interfaces for specifying
> even one total order.

Thank you for bringing this up, the notion of multiple interfaces for specifying
even one total order. My example of a compare function was just an example, and
it is valuable to consider that this may not be the only way to do it.

> * It would require extra explicit type annotations. If you have 12 text
> types, the only way to practically use any text type is to constantly
> specify which more-specific text type it actually is (probably using
> the :: operator). That is not necessarily a bad choice if starting a
> language from scratch and forming the syntax in a way that it's
> reasonable to do. But this is SQL, and lots of type annotations are
> un-SQL-like.

Well sometimes it doesn't hurt to suggest solutions from the point of view that
one can start the language from scratch, because that provides a clean way to
conceptualize and explain a feature. And then people can find some middle
ground that adapts benefits from that idea for the feature without changing SQL
more than needed. Witness the various improvements to Perl 5 that were first
expressed in terms of Perl 6.

-- Darren Duncan