[e-lang] [Caja] Functional auditor for Cajita

[David Wagner]

David-Sarah Hopwood  wrote:
>In fact I'm wrong here, as shown by this example:
>
>  /*@pure*/ function f() { return cajita.deepFreeze({}); }
>
>  const a = f();
>  const b = f();
>
>  /*@pure*/ function g(x) { return x === a; }
>
>  g(a); // true
>  g(b); // false
>
>Since a and b are observably different, either f or g must not
>be referentially transparent.

I'm not sure if I follow this example.  Can you elaborate
what it illustrates?

Here's my understanding of the bit I think you may be getting at:
conceptually, a referentially transparent function should satisfy the
following property: whenever x=y, then f(x)=f(y).  However, to fill out this
definition, we must define what we mean by "=": what form of equality we
have in mind.  The definition of referential transparency is parametrized
by your definition of equality, and to provide a full definition you
must decide what you mean by "=".  See Section 3.2 and follow-on
discussion in the Joe-E purity paper (Finifter et al 2008).

Note that we only get guarantees about the result of the function
in case when the arguments in both arguments are equal according
to "=".  Otherwise, all bets are off.

I posted earlier about this:
  My post (see the "P.P.S.")
  http://www.eros-os.org/pipermail/e-lang/2009-December/013327.html
  Ihab's response:
  http://www.eros-os.org/pipermail/e-lang/2009-December/013335.html
The response was that in this context, equality is given by ===.
So that means that we only get guarantees about two invocations to
g if the arguments in both invocations are equal according to "===";
otherwise, there are no promises.

You give an example of two invocation to g, namely g(a) and g(b),
where the arguments in both arguments are not equal according to
"===", namely, a !== b.  So you shouldn't expect the results of those
two invocations to be related at all; the two results might be
entirely unrelated.

Does this make sense?  Have I missed something?

In Joe-E, pure functions are useful for relating two invocations
when the arguments are value types that can be compared according
to their value (object identity is not visible).  When you talk
about invocations where the arguments have visible object identity,
things get much messier.  Object identity introduces a can of
worms to discussion of purity.