develooper Front page | perl.perl6.language | Postings from May 2005

RE: Transparent / Opaque references

Thread Previous | Thread Next
From:
Thomas Sandlass
Date:
May 28, 2005 08:02
Subject:
RE: Transparent / Opaque references
Message ID:
8B2D97A317E8C9479E35FED99ADC3096CCC8BA@br2mex01.orthogon.com
Luke wrote:
> Both transparent dereferencing (infinite $$foo) and
> opaque dereferencing (one-level $$foo) have their uses, but they are
> definitely distinct.
 
Well, they are more like variations on a theme.


> Instead of adding different syntax for each
> kind, I'll propose something different: two types of references:
> Opaque and transparent.
 
Which could be as simple as a boolean property .opaque on the Ref class
or with the reverse meaning .transparent or .autoref which I think
is better self documenting. OTOH for MMD distinct types are better.
Other well known terms for indirection besides reference are pointer
and link. Pointer sounds a bit too low level. So we could choose
 
Ref  = opaque, one-level (this also maintains the Perl 5 meaning)
Link = transparent, chain following
 
Jargon would be that you deref a Ref but you follow a Link. The latter
is actually an intrinsic feature of the language. Links will be hardly
visible on language level. Something like

my Link $x;
sub foo( Link $l ) { ... }
 
would be errors but could also be just superfluous because every
variable basically is a link. I haven't worked that out.

 
> Opaque references always need to be explicitly dereferenced (except
> for binding an array to an array reference, etc.).
 
Which is easily achievable with overloads of &infix:{'='} for Array and
Ref of Array. While Link should be more of a subtype of the value it
links to. Thus links are more intrinsic to the language infra-structure
while Ref is an application level concept.
 
 
> Transparent
> references always automatically dereference.  The decision of what
> type of dereferencing will go on is left up to the reference taker.
> What I can't decide is which one \ will create, and how you will
> create the other kind.  Also, I can't decide how to one-level
> dereference the transparent references so that you can change them.
 
I would make &prefix:<\> a normal operator available for overloading.
Nourishing my idea that none of ::=, := and =:= are overloadable I
would like to invent another colon op like :\ or \: which if given
term precedence might give access to the Link of a variable such that
 
    \:$link.some_link_method()  or  :\$link.some_link_method()
 
mean
 
   (\:$link).some_link_method() or  (:\$link).some_link_method()
 
Hmm, I like the :\ better because it goes with its counterpart :=
the link operator. This nicely mirrors the pair \ and = somewhat.
 
The only question that remains is how then to single step down
the link chain if that isn't contradicting the link concept in
the first place. But I think it doesn't need an operator.
A method might suffice:
 
:\$link.follow.follow
--

TSa (Thomas SandlaƟ)


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About