On Mon, Apr 04, 2005 at 06:50:11PM +0200, Thomas Sandlaß wrote:
: Juerd wrote:
: >And will Perl 6 reference values rather than their containers, that is:
: >will \$foo differ when $foo gets a new value, just as in Python id(foo)
: >changes after foo += 1?
:
: Depends on the definition of the semantics of 'Ref of Scalar of Any'
: versus 'Scalar of Any' versus 'Ref of Any' versus 'Scalar of Ref of Any'.
: My question was actually about the language level definition of *chains
: of references*!
:
: 1) Is the referene creation done with \, := and implicit in scalar context?
: Or do \ and := differ? And what's different with ::=?
Taking the questions in reverse order, ::= differs from := only in
forcing immediate evaluation and binding at compile time. I don't
think \ and := differ very much--in fact, at one time aliasing was
going to be done with:
\$foo = \$bar;
But as in many other areas, we've chosen to differentiate operators
rather than overload existing ones. That's why we have =:= as well.
I don't quite understand your first question. The left side of :=
implies reference context, but the right side only implies scalar context,
so @foo and %bar automatically assume \, while $foo does not, but is
assumed to already contain a reference. At least that's how I'm thinking
of it this week.
: 2) Is derefencing still done with $ chains where you have to know how far
: to go?
I think the common case with chains of references is that you either want
the beginning of the chain or the end. So I think we'll probably go
with ref coalescing behavior.
: Is $$$$$$$foo still valid Perl 6 syntax?
Sure, it's just the extra $'s are no-ops. :-)
Basically, we have
$$ref follow the ref list to the actual object.
$ref ignore the fact that this is a ref unless context forces it.
Ordinary scalar and list context never force a deref. Numeric and
string contexts do force a deref, unlike in Perl 5. Also, boolean
context! That's why we say that refs are no longer guaranteed to be
true in Perl 6.
: 3) How are Refs dispatched in comparison to Scalars, Arrays and Hashes?
$ref.foo() is one of those contexts that forces a deref. The only way
to call methods on the Ref itself is through var($ref), or whatever
it's called today.
: Here is another attempt to pose my question with -> depicting an
: indirection.
: After the declarations with my we have two chains:
:
: $four -> $three -> $two -> $one -> 1
: $five -> 5
:
: Now what does $four = 4 mean? Dump the chain from $three downwards
: and end up with
:
: $four -> 4
: $five -> 5
Yes.
: or go all the way down and just rebind $one and dumping the value 1
:
: $four -> $three -> $two -> $one -> 4
: $five -> 5
No.
: The next question was about how far down $$four goes and how rebinding
: at that level works. If it goes one down and rebinds there we get:
:
: $two -> $one -> 4
: $four -> $three -> $five -> 5
$$four goes all the way down to something that is not a ref.
: BTW, Parrot could collapse chains of reference in a GC run
: or as side effect of identity checks.
That would be convenient.
: >I certainly hope we still have mutable values by design and
:
: In my head "mutable value" and "constant variable" sound funny.
:
:
: >Is your view of the world like Python or like Perl 5?
:
: More like an any-junction of all languages supported by Parrot :)
My view is that the current lexical scope is allowed to impose any
view on reality that it chooses. If you want a lexical scope that
always forces != to coerce both sides with +, that's fine. It's just
probably not the default, since we'll rely on MMD to choose standard
Perl semantics where appropriate.
: >Values have no identity in Perl 5. Containers (variables, named or
: >anonymous) do. That also means that even though $foo = 5 and $bar = 5,
: >\$foo != \$bar. In Python, with foo = 5 and bar = 5, that means id(foo)
: >== id(bar), but I don't like that at all.
:
: Once again \$foo != \$bar just means a dispatch to &infix:«!=»<Ref,Ref>
: which might need to be different for PerlRef and PythonRef if the latter
: exists at all. The difficult thing for the Parrot folks is the mixed case!
: The homogenous cases are up to the languages. But for the mixed case some
: meta language level has to define semantics or the languages have to adapt
: from the inside out by explicit foreign knowlegde.
Doubtless there is room to do both, as long as the language gets the
override over global policy. I know Perl probably wants to break
ties by coercing other language's scalars with implicit +, ~, and ?
where the naive Perl programmer would expect it. $a + $b is not going
to do string concatenation in Perl unless *both* strings are foreign,
and then it's probably up to the global policy. And a pretty good
argument can be made for *never* doing string concatenation with +
in Perl. If the global policy is specific enough about semantics, then
it will distinguish concatenation from addition independently of any
language's particular confusions of the operator names, so there ought
to be some circumlocutional way of saying what you really mean that
gets translated to the appropriate method name in the target language
without you having to know what the target language is. If you really
want to dispatch through another language's dispatcher, there's probably
a way to do that explicitly.
Larry
