[This is a repost, somehow it didn't get through before, sorry.]
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. Alias connotes name to me and namespacing shouldn't be mixed
with referential semantics. 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
(redundant links are eliminated lazyly)
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 =.
I admit that :\ is not a real beauty but it's 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 # two steps down
--
TSa (Thomas Sandlaß)
