"Larry Wall" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> : does that mean that this use of yada yada yada is already decided on and
allowed?
>
> Yes, with the proviso that it only works that way where a term is
> expected. (As a postfix operator it's short for C<..Inf>.)
So, C<...> is a syntactically valid term which dies when evaluated at
run-time (or throws an exception, if they're not the same thing). It seems
to me then that the Yada "operator" has to have 2 special properties beyond,
say, a macro which returns the closure C<{ die }>. And it raises two
questions for me. Also, we should get used to calling it the "Yada Yada Yada
term", or perhaps even the "Yada literal", since it is not operating on
anything (outside its postfix unary form).
[Special Property #1]
If the Yada operator is valid anywhere a term is expected, it must
syntactically valid in all these cases:
my $id = ...;
my Int age = ...;
my Str $name = ...;
my DbHandle $db = ...;
my Int of Hash @array = ...;
Therefore, the compile-time type of the term must be assignment-compatible
with any and all lvalues. This will have to be true at least in those
contexts that ask for strict type-checking, even if other scopes don't care.
This reminds me of Java's C<null> literal reference value which can be
validly assigned to any reference type. (Technically, it's not a keyword,
but try giving that answer on an interview at your own peril.)
I don't see any functional problem with this special property as long as it
can be implemented in the core language. Seems like it would have to be a
special rule of type checking. So we'd have generic Scalar as the universal
recipient, and now the Yada literal as the universal donor. (Any association
of strong type-checking with the extraction of blood is purely imaginary.
;-)
[Special Property #2]
As mentioned in A6, redefining a function (subroutine, method, etc.) which
has only been declared with the Yada Yada Yada closure does not generate a
warning. It seems like Perl 6 will have to take some special note, then,
when we declare a function as:
sub foo($bar, $baz) {...}; # pre-declaring sub foo()
as opposed to:
sub foo($bar, $baz) { die }; # defining sub foo() to throw an exception
(mod throwing syntax)
so that the first case can be redefined without a warning, while the second
case would warn on redefinition.
[Question #1]
I'd like to understand how Aaron Sherman's initial example would work:
class Foo {
has $.a;
has $.b;
...;
}
We know that the class will compile fine, but when exactly would it pitch a
fit (or exception)? I'm unsure of the meaning of this idiom, because the
only time the C<...> line gets evaluated is at class compilation time, which
is when we don't want any complaints in this case.
[Question #2]
Does C<...> know when it's being called during compilation and when it's
being used at run-time? I.e., how would it behave in a compile-time block
such as BEGIN:
BEGIN { our IO $server = ...; };
The rhs value is evaluated here at compile-time. Is C<...> smart enough to
know that and keep quiet?
Regards,
-Dov
