Re: [WIP][PATCH 1/2] pvm: add new pvm value: opaque values

[Jose E. Marchesi]

> Hi Jose.
>
> On Wed, Feb 15, 2023 at 10:26:39AM +0100, Jose E. Marchesi wrote:
>> > +PKL_DEF_INSN(PKL_INSN_OPQGETN,"","opqgetn")
>> > +PKL_DEF_INSN(PKL_INSN_OPQSETN,"","opqsetn")
>> 
>> Hm do we really need an opqsetn instruction?  Isn't the name in #<NAME>
>> something that is up to whatever is providing the opaque value?
>> 
>
> No. I just put it there because of completeness, I can remove it.
>
>
>> > +/* Determine whether two given opaque values are equal.  */
>> > +
>> > +immutable fun _pkl_eq_opaque = (any v1, any v2) int<32>:
>> > +{
>> > +  if (asm string: ("opqgetn; nip" : v1) != asm string: ("opqgetn; nip" : 
>> > v2))
>> > +    return 0;
>> > +  if (asm uint<64>: ("opqgetp; nip" : v1) != asm uint<64>: ("opqgetp; 
>> > nip" : v2))
>> > +    return 0;
>> > +  return 1;
>> > +}
>> 
>> I thought the #<NAME> basically identifies a class of opaque types.  For
>> example, #<regexp>.
>> 
>> Then every regexp is equal to another?
>> Woulnd't it make more sense to introduce an eqopq instruction that
>> compares by payload/pointer?
>> 
>
> The `_pkl_eq_opaque' compares both name and payload/pointer (I'm using both
> `opqgetn' and `opqgetp' instructions).
> And do you mean we only need to compare the payloads and not names?

I am thinking that for the values to be really opaque, we shouldn't have
an opqgetp instruction at all.

For comparing, eqopq can do the right thing without exposing anything.
I can imagine some opaque values that are equal even if they have
different pointers, and vice-versa.

Regarding the name, I think it should only be only used for printing
purposes, and only there.

WDYT?