[E-Lang] Hydro & E operator expansions

[Ka-Ping Yee]

On Wed, 21 Mar 2001, Mark S. Miller wrote:
> 
> Perhaps we should adopt exactly the Python style expansion names, and even 
> adopt the particular names from Python where they don't conflict with any 
> other E principle.

Here is an interesting little point.  The Python names, as you saw,
all begin and end with double-underscores.

Why so clumsy and strange-looking?  The intent is that these are
"special" -- that is, automatically invoked by the interpreter.
You would never call a double-underscore method directly, and the
private-like appearance of the name reminds you that it's special.

The names also subtly encourage the one-way-to-do-it philosophy of
Python: it's seems silly to write a.__add__(b) when you can write a+b.

What do you think would happen if all such methods were distinguished
by a naming convention in E?  One example i'm particularly
contemplating is "run".  If it were named "__run__", and no one were
to ever call it by name directly but only invoke it by using parens,
would that be a problem?

(But really it should be named "__call__".)

> I fully recognize and appreciate that the aggregate intelligence and design 
> ability of the list vastly exceeds my own.  That's why I'm doing things this 
> way. Not that this is either a democracy or a consensus system.

I didn't mean to make you feel beleaguered, Mark.  Sorry if i did.
The resulting E should be a product of your final decisions, not a
democracy -- a unifying philosophy of design is essential.

Of course, this won't stop me and others from continuing to argue
our opinions, though. :)

> So, on the particular issue, I find a "no coercion" position hard to 
> swallow: What about "3.1 + 4"?

If it's any consolation, the Python developer community is currently
in a bit of an uproar about this.  All kinds of issues are on the table:

    - Whether 1/2 should be 0 (typesafe) or 0.5 (obvious to beginners).

    - Whether 0.5 should denote rational 1/2, decimal floating-point 0.5,
      or binary floating-point 0.5.

    - Whether 1/2 should produce rational 1/2, decimal floating-point 0.5,
      or binary floating-point 0.5.

    - How to stop people from doing a == b if a or b are floating-point.

    - Whether 1 and 1.0 should even be distinguishable at all, or if
      all numeric types should be unified into a single type.

This may seem radical, but i have come around on this one.  I actually
think 1/2 == 0 is not so bad, maybe even preferable.  And i also think
3.1 + 4 causing a type error is also not so bad!  Think about it.  What
type of result do you expect?  What if you wanted to store integers in
the variable?

Consider:

    def uptoten(i) {
        print i
        if (i < 10) {
            uptoten(i + 1)
        }
    }

If i pass a floating-point number into this routine, i think i want
it to raise an error.  I'm using "+ 1" and "< 10" here with the
assumption that i'm working with an integer, and potentially weird
things could happen if i compute something that's supposed to be an
integer using floating-point and then pass it in.

I really wonder how often you need to combine an integer and a
floating-point number (where the integer is not a constant).

Am i out to lunch on this one?


-- ?!ng

Happiness comes more from loving than being loved; and often when our
affection seems wounded it is is only our vanity bleeding. To love, and
to be hurt often, and to love again--this is the brave and happy life.
    -- J. E. Buchrose