[E-Lang] Hydro & E operator expansions

[Tyler Close]

Ping wrote:
> On Wed, 21 Mar 2001, Tyler Close wrote:
> >
> > I can also easily add and remove methods in Acid. I
> therefore rescind
> > my suggested operator expansion names in favour of the "op__plus"
> > style syntax.
>
> No, don't do this, please.  "+" means "add".  It's not just a couple
> of line segments.

Who said it doesn't mean "add"? The only issue is what "addition"
means for any specific type of object. I just had a look at "addition"
in a couple of dictionaries and the general sense is that "addition"
is putting two things together to make something bigger. Only one of
the listed definitions refered to addition in terms of numbers.

> > I still think the operator message semantics that I proposed are
> > correct. I've got no problem with "+" being asymmetric for maps.
>
> "+" should be symmetric with respect to type.  The left side
> dominates for the purpose of coercion, but otherwise, the types
> of the arguments and the result should be the same.

You're claiming that mathematical addition of numbers is the only type
of addition and that all other types should be coerced into this
definition. This is both a narrow definition and a dangerous one for a
programming language. Remember that the central issue here is not
faithfulness to mathematical principles, but faithfulness to the
message passing architecture of the language runtime. In general,
automatically coercing a parameter to a type that has different
semantics is a dangerous thing.

Consider the company "ABC Attorneys at Law Inc.". The partners in this
firm are Adams, Babcock and Cunningham. Every time a new lawyer is
made a partner, she gets to add her initial to the company's
letterhead. This is done by giving the new partner a "once-only"
object for adding a single character to the sequence of initials in
the company letterhead.

	to addInitial(initial) {
		...	# Destroy this object.
		initials += initial
		...
	}

Your coercion would let the new partner add as many initials to the
letterhead as she chose to. Moreover, with your syntax, it is
impossible to protect against this threat without using guard
statements (:char), or similar fuss. Your message protocol, on its
own, has an unplugable security hole.

This example is somewhat contrived, but it is definitely valid. It's
also a very dangerous place for this design flaw to exist. Beginning
programmers start to design objects by copying what they see around
them. That the string class has such a bad security design flaw is
surely starting off on the wrong foot. Setting the precedent that it
is OK to do automatic coercions between very different types is a
really bad idea.

Automatically coercing a component to a composite also goes a little
outside the semantics of the message passing architecture. If "+" is
string concatenation, then the string implementation of the "+"
operator should expect a single string type parameter. The automatic
coercion smacks of intervention by the language runtime, a la C++.
That this coercion is actually done inside the string's "+"
implementation doesn't take away from this impression.

The automatic coercion is also pretty sucky for performance. The
operation that the progammer wanted to do was adding a single element
to a collection. Forcing the temporary construction of a single
element collection just to satisfy your mathematical sense of purity
is nuts.

> > The resulting syntax is clean, easily understood and requires no
> > modification of the E language.
>
> I strongly disagree.  To take away this principle deprives the
> E programmer from having any reasonable guess as to the meaning of
>
>     [1, 2] + 3

? [ 1, 2 ] + 3
# [ 1, 2, 3 ]

>     [1, 2] + [3, 4]

? [ 1, 2 ] + [ 3, 4 ]
# [ 1, 2, [ 3, 4 ] ]

To concatenate two queues, you use the concatenation operator.

? [ 1, 2 ] | [ 3, 4 ]
# [ 1, 2, 3, 4 ]

Try using E's "|" operator with an EMap. "|" is concatenation.

Somewhere in the depths of my mind, I have a memory of using a
language that did use "|" for string concatenation. Does anyone here
know where this memory came from?

I'm not going to push too hard on using "|" for string concatenation,
since so many Java programmers are used to using "+" and it looks like
I am going to have tough enough going just getting the collection
syntax. Mostly, I just want people to realize that in generalizing
from "a string is a collection of characters" to a collection model,
addition means:

	composite := composite + component

and

	component := component + component

is just a special case that is true for numbers, where a composite
automatically collapses to a component.

> > I will also note that E already has an
> > asymmetric "+" operator with the String class "+".
>
> The only asymmetry is with regard to type dominance.  There is
> no ambiguity about what operation will take place.
>
> > The following is valid:
> >
> > 	def five := "" + 5
>
> ...because 5 can be successfully coerced to a string.
>
> > The following is not valid:
> >
> > 	def five := 5 + ""
>
> ...because "" cannot be coerced to an integer.

And in what way does this make the String "+" operator a "symmetric"
operator? My only point is that you can't argue against using "+" for
with() on the grounds of symmetry. You've already abandoned your
symmetry. You can only be a virgin once.

Tyler