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

Re: Transparent / Opaque references = Link / Ref

Thread Previous
From:
Thomas Sandlass
Date:
May 28, 2005 07:36
Subject:
Re: Transparent / Opaque references = Link / Ref
Message ID:
8B2D97A317E8C9479E35FED99ADC3096CCC8BF@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 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, though.
 
 
> 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.
I admit that :\ is not a real beauty but its seldomly used anyway.
 
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


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