[e-lang] __equalizer and such E operations (was: EQ, MyCap? review)

Jed Donnelley jed at nersc.gov
Tue Feb 12 18:54:29 EST 2008

<e-lang cc added>
On 2/12/2008 2:57 PM, Kevin Reid wrote:
> On Feb 12, 2008, at 17:23, Charles Landau wrote:
>> Do E objects possess the __equalizer object implicitly? I'd assume  
>> so since I've never seen it in explicit code. Can it be optionally  
>> withheld from an object? If not, then in what sense is it an object?
> It is bound in the safeScope(*), a lexical environment object. E code  
> is nearly always evaluated in safeScope or a derivative of it,  
> however, this is not obligatory. Evaluation always takes an explicit  
> environment.
> (*: I believe 'scope' here to be a terminology error.)

It seems from the above that the operation of __equalizer could
not itself be programmed in E.  It provides information that
could not otherwise be obtained about objects.  Can you give us
an idea of how many such objects or other primitives there are
that relate to the base domain protection in E?  If few, might
you be able to provide a list or a pointer to documentation
with such a list?

I was puzzled when you said about __equalizer:
> It does either pointer (or event-of-creation, to put it conceptually)  
> comparison or structural comparison depending on the kind of  
> references it is given; while the latter may invoke the code of the  
> object, it does so only if the code has been audited to behave  
> appropriately (no side-effects, terminating, correct return value).

in particular when you said 'the latter may invoke the code
of the object'.  What sort of object property could induce
__equalizer to invoke "the" object?  By "the" object, I
assume you mean the first of the two objects - or is it
more complex than that?

> In E, any two references which __equalizer considers the same are  
> indistinguishable by all other means. This implies that pointer  
> comparisons on objects which __equalizer compares structurally are  
> prohibited.

Can you tell us:

1.  How E decides whether to compare two objects structurally
or as pointers?  If E chooses to compare two object structurally
then I assume this is because in some circumstances they may
be regarded as EQ even though their pointers aren't the same?
Can you motivate this choice?

2.  When you say that "pointer comparisons on objects which
__equalizer compares structurally are prohibited", how would
a desire to make such a pointer comparison even be expressed?

Thanks for digging a bit into the language for us Kevin!

--Jed  http://www.webstart.com/jed/

More information about the e-lang mailing list