On Jun26, 2011, at 09:18 , Jeff Davis wrote:
> Currently, there is no way to define a generic "length" function over
> range types, which would give you the distance between the boundary
> points.
I actually wouldn't expect there to be one. From what I gathered
during the last discussion, the ideal behind range types is that they
model sets of the form {x in T | a <= x < b} for arbitrary types
T, with the only requirement being that T be ordered. To compute
a length, you additionally need either an algebraic structure on
T which defines an operation "minus", or some metric which defines
distance(a,b). Both are *much* stronger concepts than simply being
ordered. The problems you outline below seem to me to all root in
this discrepancy.
Strings are a nice example of an ordered type on which no "intuitive"
definition of either "s1 - s2" or "distance(s1,s2)" exists.
> I suppose the "right" way to solve these problems would be:
>
> 1. Force users to supply the "minus" function.
>
> 2. Force users to supply the "zero" value as a constant of the same type
> as the minus function's return value.
>
> 3. Check to see if the minus function's return type is different from
> the subtype. If so, automatically create a new entry in the catalog for
> the "length" function.
>
> I suppose it's not out of the question to do all of that work, but it
> seems like a little much just to get the generic length() function.
That sounds like a poor man's version of type interfaces - i.e. of
a general-purpose way of having various algebraic structures defined
on a type. Having real type interface would be cool, but I don't think
that ranges should introduce a simplistic version of them.
> I don't mind leaving it as-is, and I think it's a fairly reasonable
> solution. But I thought I would re-open it for discussion in case
> someone has a better idea.
I suggest to simply provide no length() function at all. It's beyond
the realm of the mental model behind range types, and providing some
ad-hoc definition is IMHO bound to create more confusion than it'll
help. Especially since "upper(range) - lower(range)" isn't that much
longer to write than "length(range)" anyway.
> The length() function is obviously an
> important function to provide.
I'd say it isn't, but maybe I'm missing some use-case that you have
in mind.
best regards,
Florian Pflug
