David Wagner wrote:
> 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.Yes. But whatever we mean by "=", it's clear that we can't reasonably have true = false. In the above example, we can apply referential transparency once to conclude a = b (since the calls to f() have no arguments -- or they could have been passed the same argument), and again to conclude g(a) = g(b). Therefore either true = false, or one of f or g is not referentially transparent. But both were declared as @pure, therefore @pure does not imply referentially transparent for any definition of = satisfying not(true = false). (Nor can we usefully weaken referential transparency to use different versions of equality on the left and right of the implication, since then it could not be applied compositionally.) Forbidding use of === and !== in a deep-frozen function solves the problem. It's similar to Joe-E restricting on == and != to non-value types, but we can't do that in Cajita because it is untyped. If I'm not mistaken, Joe-E *could* also relax its restriction on == and !=, and possibly its restrictions on calling nondeterministic APIs, by only applying them to (I think) methods of Immutable objects. > 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 ===. Ihab only said that Cajita currently exposes ===. That doesn't imply that = is ===. In my proposal, = is Henry Baker's 'egal'. (I should write out a definition of egal in Cajita to make this clearer.) > 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? I think you missed that referential transparency was being applied twice (probably my fault for not spelling out the argument in more detail). -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
