[Dbix-class] RFC - merits of overloading ops versus not doing so

[Darren Duncan]

Hello,

I'm hoping for some quick feedback that would influence my Muldis D language
design (which can express anything you can express in SQL, but better, and from
which you can generate SQL) in the short term, but it also applies to language
design in general.

Right now, Muldis D has support for the overloading of operators between
disjoint types, such that you can invoke a virtual operator in your code and
then what would actually execute is one of several concrete operators that are
specific to the data types of the primary arguments.  However, I don't yet spec
any use of this feature aside from ordered and ordinal specific operators such
as comparison or sorting operators.

My main question is whether it is better from a usability point of view to have
distinct syntax for an operation per each disjoint data type that has an analogy
for that operation, or whether it is better to have a single syntax shared by
all types.

Keep in mind that even when the virtuals are provided, you can still choose to
invoke the type-specific versions, which would otherwise be your only choice,
but I would prefer to only provide shorthands for one version, so assuming that
one normally uses shorthands, which they would prefer.

My apologies if you find any of this message difficult to follow, but mainly
what I just want to know is your opinion in a programming language if you prefer
to use overloaded syntax or type specific syntax.  Or if you prefer either
depending on context, then what kinds of contexts those are.  Thank you.

Example 1, numerics (or in a more limited sense, also dates and durations):

   If you have disjoint integer and rational numeric types, each with the
standard math ops, is it more user friendly to read and write code with (read
all of these as infix):

   1. single shared syntax: + - * / etc

   2. distinct syntax: i+ i- i* i/ r+ r- r* r/ etc

   If you were writing something more strongly typed such as perhaps you might
in SQL or Perl, the #2 option would tell you that your operands are integers or
rationals, while the #1 option would not; the latter mean you potentially can
have stronger type checking at compile time, while the former would mean more
checking is done at runtime instead.

   So which of these options would your prefer to either read or write code in?

   Keep in mind that even if the #1 option is provided, you can still explicitly
write code to specifically use the type-specific versions, but the code would be
slightly more verbose, such as:

   Integer.sum(), Rational.quotient(), etc

Example 2, strings or arrays:

   If you have disjoint text and blob and array types, each with at least
catenation and replication ops (read all of these as infix):

   1. single shared: ~ x

   2. distinct: t~ t-x b~ b-x a~ a-x

Example 3, set-like collections:

   If you have disjoint set and bag and interval types, each with at least value
membership ops (read all of these as infix):

   1. shared: in has

   2. distinct: in-s s-has in-b b-has in-i i-has

Example 3b:

   In Muldis D, sets, arrays, bags, intervals are proper subtypes of relations,
and it also makes sense to test for membership of a tuple in a relation:

   1. combining this with the above, using plain "in" or "has" could pose a
challenge because the tuple-membership test has different semantics from a
attribute-value-membership test in the case where the relation is also a
set/etc, at least because an attribute value is allowed to be anything,
including a tuple

   2. distinct: in-r r-has

Example 4, tuples vs relations:

   A relation is like a set of tuples, and a tuple is like a Perl hash, and some
operations on relations have analogies for tuples, such as rename, projection,
wrap, and unwrap:

   1. shared: $foo{x<-y,a<-b} $foo{bar,baz} $foo{%new<-old1,old2}
$foo{new1,new2<-%old}

   2. distinct: $r@{x<-y,a<-b} $r@{bar,baz} $r@{%new<-old1,old2}
$r@{new1,new2<-%old} $t%{x<-y,a<-b} $t%{bar,baz} $t%{%new<-old1,old2}
$t%{new1,new2<-%old}

Thank you in advance for any feedback.

-- Darren Duncan