Side-effect free containers for E

[Tyler Close]

Since the E language might currently be undergoing some revision for
compilation reasons, I am going to take the opportunity to suggest
some other changes I would like.

The E language recognizes the value of side-effect free containers,
using them as the default for the syntactic sugar for constructing
containers. Unfortunately, the current E implementation doesn't keep
up with the goal.

Currently, there is no way to make efficient use of a side-effect free
container in E. Using the ConstList or ConstMap means constantly
flipping between their Flex versions, making numerous unneeded copies
of the container as you go.

Due to the inefficiency of the Const containers, most E programmers
will only use the Flex versions. This introduces a number of potential
security pitfalls.

Object associations are typically stored in containers. Current Java
programmers are used to just passing out this container and trusting
the calling code to not modify the container. For example:

class Person
{
	Person[] friends;

	Person[] getFriends()
	{
		return friends;
	}
}

This is obviously not a good capability design if 'friends' is
modifiable. I believe programmers will commonly make this mistake if E
has modifiable containers.

Using modifiable containers also makes it significantly more difficult
to do a security audit of a program. If the Person example were part
of a real program, then a security audit would have to study not just
the Person class, but also all classes that might get a reference to a
Person object, in order to determine what the permitted content of a
Person's 'friends' association is. This would be 'too much' work, for
fatal values of 'too much'.

One of E's goals is to make it easy and natural for programmers to
write secure code. Modifiable containers work against this goal.

Using only side-effect free containers also has a number of advantages
when you are implementing persistence. For this reason, I have
recently created a set of side-effect free containers for my Droplets
environment. You can access a Beta version of this code at:
http://www.waterken.com/Hydro/2.0/.

I suggest that E scrap its current container classes and adopt the
Hydro library. I believe the only modification to Hydro that would be
needed is the addition of the Printable interface. I will make this
addition, and maintain the library for E, if Markm decides to adopt
it.

Using side-effect free containers also introduces a number of pleasant
symmetries with the other 'primitive' types. These symmetries suggest
some changes to E's expression grammar:

Operator		Current expansion		Hydro expansion
--------		-----------------		----------
+			add				with
-			subtract			without
- (unary)		negate			reversed

I think these names makes sense for both 'primitives' and containers
and others.

I also suggest that E drop its current compareTo paradigm and instead
use:

Operator		Hydro expansion
--------		---------------
>=			includes
<=			within

The rest of the comparison operators can be made by combination of
these two (while preserving the expected message target). This also
gets rid of the unusual '<=>' operator.

E's iteration syntax would also need to be modified.

E with Hydro would have only 5 container types: Queue, Set, Map,
SortedSet, SortedMap. These 5 container types are more powerful, and
less numerous, than E's current containers
(http://www.erights.org/elang/collect/tables.html). I think switching
to Hydro would make E simpler, more secure, more efficient, and better
suited to an efficient persistence mechanism.

So take a look at the Javadoc, download the code and play with it in
an E shell. Let me know what you think.

Tyler


__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com