[E-Lang] Operator expansion names, Part 1: Intro

[Bill Frantz]

At 5:17 PM -0700 4/6/01, Mark S. Miller wrote:
>For example, we might say the "normal" math notion of "+" is something like:
>
>    For each data type T to which + applies (after coercions), + should
>    be closed over T, such that for any t1 and t2 in T, t1 + t2 should also be
>    in T.  For any such type T, there must also be a zero element of that
>    type t0, such that t1 + t0 -> t1 and t0 + t1 -> t1.  + must also be
>    associative.
>
>This is violated by both
>
>    [1, 2] + [3, 4] -> [1, 2, [3, 4]]
>
>and
>
>    'a' + 3 -> 'd'

I don't know that the definition speaks to the issue where the second
operand isn't of type T, which applies to the second example.

However, consider that T is lower case letters, and the addition is
modular.  (We end up with the strange definition that the additive identity
element is 'z', but heck, that's better then defining pi as being 3.  :-))
We also have a coercion of numbers to letters:

0 -> 'z'
1 -> 'a'
n mod 26 -> ...
etc.

Note that if we follow the C rule that 'c' is a short hand for an integer,
we get the same kind of logical consistency.

Normal addition obeys the rule: a + b equals b + a.  If the goal is to
encourage people building types to model the mathematical concepts of group
and ring, then we want:

If a and b are in T, then a + b is always in T
a + 0 equals a
a + b equals b + a
(a + b) + c equals a + (b + c)

My naive belief is that bags and sets obey these rules.

Cheers - Bill


-------------------------------------------------------------------------
Bill Frantz       | Microsoft Outlook, the     | Periwinkle -- Consulting
(408)356-8506     | hacker's path to your      | 16345 Englewood Ave.
frantz@netcom.com | hard disk.                 | Los Gatos, CA 95032, USA