Pointer-comparison considered harmful

[Dale Schumacher]

A question posed in today's Friam (paraphrased):

Was it a mistake for languages to provide "pointer-equality" as a primitive?

I believe it was mostly a mistake. For immutable "values" (so-called "value objects") it is clearly wrong to distinguish between "instances" of the same value. For references to mutable objects, it's probably too strong, because I can say if the references are not equal, the objects have distinct futures (barring the possibility of aliasing).

For remote references (to actors), the question I would like to be able to ask is: do two references designate objects/actors with the same future? But the only answers are "yes", and "maybe", but not "no". In other words, there may always be a proxy (not equal) in between, even if the same state is eventually affected. But, if the references are equal, the future states cannot diverge.

[Tony Arcieri]

See also: referential transparency, a common property of functional languages, where values compare equally regardless of if references point to two copies of identical data

https://en.wikipedia.org/wiki/Referential_transparency

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAPeSZfBsqfite5-NjYS0izS53G_vdnz%2BzT7KZ%2B3a5A7BE_%3DZxA%40mail.gmail.com.

--

Tony Arcieri

[Dale Schumacher]

Yes. And in that vein, the Henry Baker paper I mentioned was "Equal rights for functional objects or, the more things change, the more they are the same" https://dl.acm.org/doi/abs/10.1145/165593.165596

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAHOTMVJGu4iZ_VRA9PXZ%3DTS_MnGH2v_MOEygwYdhCzyjrs%2BiEg%40mail.gmail.com.

[Matt Rice]

I've always felt that pointer equality was the right 'least authority'
that could be ascribed to a pointer, and convienent for building
capability systems (although I don't tend to work on actors/futures
etc),
I sort of feel that implicit dereference without a proof of
inhabitance was more problematic. I tend to like where pointer_eq is
`Ref<S> -> Ref<T> -> bool` so you can compare pointers to different
types.
and `deref: Inhabited<T> -> Ref<T> -> T`. (or perhaps just
`InhabitedRef<T> -> T`) Allowing one to have instances of `Ref<⊥>` the
reference type inhabited which cannot be dereferenced without type
conversion + aforementioned proof.

I tend to view it as a useful primitive, (then again I don't tend to
work with futures/actors), ocaml has it, rust has it, sml as far as I
know does not. Perhaps it has been discussed in Successor ML though
I'd be surprised if it was accepted due to referential transparency as
mentioned by Tony. But at the same time I recognize that this may well
be an unpopular opinion. At the same time I view it as a right since
as Dale says above being able to differentiate references is a right
where the inability to differentiate references should be equivalent
to a unitary value.

I'd imagine I would argue faced with Dale's situation with 'yes', and
'maybe', that similar to the way I perceive the ability to have
references which are not dereferencable. I'd rather also have
references which are dereferencable but not equatable.
I.e. treat set/deref/eq each as their own facet. I don't see how it
could be harmful if the rights associated with references are fine
grained and not imposed. The larger hurdle I imagine would be
convincing someone such a system would be worthwhile!

[Dale Schumacher]

I can't say I followed all of your explanation, Matt. However, I think I can be a little more specific.

There is no Ref<T>, Ref<S> distinction, at least if Ref is meant to be a Capability, since there's no Type associated with the target. A Capability is an opaque designation conferring the ability to deliver an asynchronous message to the target (which the target is free to ignore).

In addition, I'm proposing that Cap = Cap' is defined as asserting that two Capabilities designate the same Identity, meaning that changes which occur as a result of messages received through either will never cause observably different behavior. If the equality relation does not hold, then the behavior observable via each Capability may or may not differ over time (the "maybe" case), because either or both could be proxies for a common state-holder to which we may not have direct reference.

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CACTLOFqBht1a%2BsSj_4VGq_kDsL3N%3DO6dN_WnSfO1ttXyMDHtaQ%40mail.gmail.com.

[Matt Rice]

Sorry if i'm below my typically subpar coherence level today, I think
the most important point I was trying to get across is if we consider
pointer comparison to be a right.
That right can be either granted or withheld, and if it is withheld
everywhere it would be unreachable and may as well not exist, thus
cannot be harmful. However this isn't how we typically see
pointer comparison implemented as an ambiently available operator.

> To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAPeSZfAxeOtLdyMiaxz8z4d6DRuzy%3D%2BpqnFL0t99o9UfZPsJKw%40mail.gmail.com.

[Bill Frantz]

For what it’s worth, KeyKOS had the DISCRIM key:

DISCRIM(2;K,L==>c;) "Compare keys"


Returns in c, 0 if K and L are the same key, 1 otherwise.

This comparison required that K and L be identical in the privileges they granted as well as the object they designated. i.e. A R/O page key would not compare equal to a R/W page key to the same page.

Cheers - Bill

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CACTLOFpb%3D%2BHgk1Z0rVU6tmjYZ5WKO32B6nk_cAnHkb-zrxNaOQ%40mail.gmail.com.

[Douglas Crockford]

Bill,

Was DISCRIM an important feature? Was it much used?

[Matt Rice]

On Sun, Feb 26, 2023 at 1:15 PM Douglas Crockford <dou...@crockford.com> wrote:
>
> Bill,
>
> Was DISCRIM an important feature? Was it much used?
>

Not Bill, but my first inclination would be to use it to see if some
cap is a Null cap, and if so reclaim a spacebank,
I also believe I see ways in which you could run into the situation
which Dale described, such as a simple dead man's switch capability.
I'd be curious if Bill knows whether Dale's issue arose under KeyKOS?

[Mark S. Miller]

Please let's remember

http://erights.org/elib/equality/grant-matcher/index.html

--
You received this message because you are subscribed to the Google Groups "friam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to friam+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CACTLOFrHHbwkrwwyBT_sBrGKb_H6o58cOHYQmjTf8Wn2Yj0J7g%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Dale Schumacher]

Absolutely, MarkM. I mentioned Grant Matcher as a use-case for capability equality testing. Also, noted that "eq" isn't strictly required, since the same can be accomplished with "seal/unseal". However, I still believe that "eq" is an easier way to express this idea.

To view this discussion on the web visit https://groups.google.com/d/msgid/friam/CAK5yZYiTdN980W3gtBGMTcybY6ocyX2b4vfcX9JWzmRWXcsYmQ%40mail.gmail.com.

[Bill Frantz]

It had more functions than just comparison. The factory used DICSRIM(1… to determine if a key was sensory. Comparing keys for equality was sometimes a useful debugging function and could be useful for a membrane. It was considered a non-privileged basic function.

Cheers - Bill

Here’s the complete functionality:

Discriminate Key Type

DISCRIM(0;K==>c;) “Discrim type"

returns in c a code depending on the type of key K:

c type of K

1 data key

2 resume key

3 page, segment, node or sense key (memory keys)

4 meter key

5 all others

Fetch keys once produced code 3. It might have to again since fetch keys with lss>0 may be used as segmode keys.

DISCRIM is mainly for debugging. Normally you will know what a key is by knowing how you got it.

Programming Note: The ability to discriminate resume keys is useful to avoid making the alleged key type call on an resume key!

Design note: This call on DISCRIM was designed to give you only information that you could have gotten by other means {albeit destructively and/or statistically}. This statement is valid at every level of description that excludes the domain tool and sense keys {and the extended kernel keys}.

{arcane}Design note: Data keys are not synthesizable; synthetic data keys don't work in segment nodes.

DISCRIM(1;K==>c;) “Is key discrete"

Returns in c, 0 if K is a read-only page key or a read-only no-call segment key or a sense key, 1 otherwise. Such keys are discreet.

DISCRIM(2;K,L==>c;) "Compare keys"

Returns in c, 0 if K and L are the same key, 1 otherwise.

DISCRIM(kt;==>c) returns x'0409' in c.