Hi all, just dropping in with some thoughts I had while reading the
archive of this list. I've tried to search the list but it's difficult
with perl keywords being common english words and google unable to search
for punctuation; if the stuff below has already been fully resolved, I'd
--- Matthijs van Duin [EMAIL PROTECTED] wrote:
Now the real subject.. has the issue of multiple statement modifiers
already been settled? I saw some mention it wasn't going to be
supported, but also mentions of how it would be useful; I can think
of such a situation myself:
.method when
On Mon, Mar 10, 2003 at 08:20:39AM -0800, Paul wrote:
The real nightmare tends to show up when you duplicate a modifier.
What does
.method given $x given $y; # which object's .method is called?
mean? It gets worse below
I made a mistake in my original post, they definitely need to be left-
PROPOSAL
Replace the 'if', 'unless', 'when' statement modifiers by identically
named lowest-precedence left-associative operators that short-circuit
from right to left.
This means 'FOO if BAR' is identical to 'BAR and FOO', except it has a
lower precedence, and 'FOO unless
On Mon, Mar 10, 2003 at 01:14:05PM -0700, Luke Palmer wrote:
It is nice to see someone who puts as much thought into posting as you
do. Unfortunately, your proposal is moot, as we have a definitive
No, still can't chain them from Larry.
Like the fully-laden Australian swallow that heralds the first Apocalypse of
springtime, I'm back.
I hope you're all off reading:
http://www.perl.com/pub/a/2003/03/07/apocalypse6.html
Special thanks to Simon for getting it on-line as quickly as he did.
I'll do my best to answer questions
Oh, goody.
In psiglet, is the 's' silent?
=Austin
--- Damian Conway [EMAIL PROTECTED] wrote:
Like the fully-laden Australian swallow that heralds the first
Apocalypse of
springtime, I'm back.
I hope you're all off reading:
http://www.perl.com/pub/a/2003/03/07/apocalypse6.html
But mad or not, there are some good reasons to do just
that. First, it makes it possible to write interfaces to other
languages in Perl. Second, it gives the optimizer more
information to think about. Third, it allows the SM folks to
inflict strongly typed
On Mon, Mar 10, 2003 at 01:20:24PM -0800, Austin Hastings wrote:
: In psiglet, is the 's' silent?
Of course not. That is Greek, not English.
Larry
--- Uri Guttman [EMAIL PROTECTED] wrote:
But mad or not, there are some good reasons to do just
that. First, it makes it possible to write interfaces to
other
languages in Perl. Second, it gives the optimizer more
information to think about. Third, it allows
Larry says that
sub foo { ... }
is equivalent to
sub foo will do {...}
But then goes on to give the grammar for subroutine definitions as:
rule lexicalsub :w {
lexscope type?
subintro subname psignature?
trait*
block
}
rule packagesub :w {
Having just read through the declaration bits (not the calling bits,
yet):
It is explicitly stated that is rw on a slurpy parameter distributes
across all the components.
Is there some way of differentiating array of const vs. array of rw?
That is, creating a hash or array that can be extended
I see e-accent in te/en we can say, below, plus
dhow is ii\ the named-only zone below that.
It survived a few refreshes, so I wonder if it's a file-transfer
problem?
=Austin
If instead we force new parameters to be in named notation, like this:
multi *push (@array, [EMAIL PROTECTED],
It survived a few refreshes, so I wonder if it's a file-transfer
problem?
No, Larry is just presenting additional proof that we need Unicode
operators in Perl 6 by using them in English, too. :)
Greetings,
Christian
--
[EMAIL PROTECTED] - http://www.web42.com/crenz/ - http://www.web42.com/
The
is constant (default)
Every formal parameter is constant by default, meaning primarily
that the compiler won't feel obligated to construct an lvalue
out the actual argument unless you specifically tell it to. It
also means that you may not modify the
Christian,
[A6, p7]
There will be two new operators, called pipe operators, that allow us
to hook list generators together with list consumers in either order.
So either of these works:
stuff @foo == 1,2,3
1,2,3 == stuff @foo
[/A6, p7]
I don't think that's going to be an issue --
On 2003-03-10 at 18:03:12, Uri Guttman wrote:
this confuses me. sometimes i want a simple pass by value param which i
can modify locally in the sub. is this the same as the constant above?
No, that's the same as is copy.
--
Mark REED| CNN Internet Technology
1 CNN Center
bah, the is copy is pass by value with local modification (my params in
p5).
this works as most params should be constant. the few that are copies
can be declared that or copied to my vars.
i have to wait on posting before i read the whole megilla.
uri
--
Uri Guttman -- [EMAIL
Austin Hastings wrote:
It is explicitly stated that is rw on a slurpy parameter distributes
across all the components.
Is there some way of differentiating array of const vs. array of rw?
That is, creating a hash or array that can be extended without
overwriting?
I'm not sure I follow what
Just in case anyone cares, page 6 is requiring that I scroll
horizontally. I'll live, but if it can be easily fixed, that's a Good
Thing. :)
Haven't read the rest yet -- still working on it.
Paul
--- Damian Conway [EMAIL PROTECTED] wrote:
Like the fully-laden Australian swallow that heralds
On 2003-03-11 at 10:12:17, Damian Conway wrote:
Austin Hastings wrote:
It is explicitly stated that is rw on a slurpy parameter distributes
across all the components.
Is there some way of differentiating array of const vs. array of rw?
That is, creating a hash or array that can be
--- Damian Conway [EMAIL PROTECTED] wrote:
Austin Hastings wrote:
It is explicitly stated that is rw on a slurpy parameter
distributes
across all the components.
Is there some way of differentiating array of const vs. array of
rw?
That is, creating a hash or array that can be
Austin Hastings asked:
How do I specify an array which may be appended/pushed, but whose
values cannot change?
I believe you'd have to create a class for such things, derived from Array:
class AppOnlyArray is Array {
method STORE(int $index, $value) {
Since noone else has said it yet -- This Apoc looks *great*. The sig
stuff is very, very nice. (The wrapper stuff has interesting
possibilities, too, especially with OO.)
Question on pipes: I like very much the concept of relating them only
to the variadic list, that was the piece we were
Michael Lazzaro wrote:
After reading that appendix, I'm still a bit murky on the
final decisions as to which of these edge cases will be allowed:
my @out == (1,2,3);
my @out == (my @in = foo());
my @out == foo();
(1,2,3) == my @out;
(my @in = foo()) == my
In A6, it is confirmed that you can have complex types such as:
my %pet is Hash of Array of Array of Hash of Array of Cat;
It is also confirmed that you can indeed use such types in sub
signatures, e.g.:
sub foo (@a is Array of int) {...}
Confirmations/Questions:
1) Complex types for sub
Michael Lazzaro asked:
1) Complex types for sub parameters: The above would imply that a sub
can tell the difference between an CArray of int vs an CArray of
str, thank goodness. That also implies that you can use arbitrarily
complex types, and still get the same type checking:
sub foo (
On Tue, Mar 11, 2003 at 01:25:41PM +1100, Damian Conway wrote:
: 3) The edge point between explicitly typed and explicitly non-typed
: variables: If you pass an untyped array (or list?) to an explicitly
: typed array parameter, is the untyped array considered a unique case,
: or will it fail?
Larry Wall wrote:
I dunno. I can argue that it should coerce that. It'll certainly be
able to coerce a random scalar to int for you, so it's not a big stretch
to coerce conformant arrays of them. On the other hand, it's likely
to be expensive in some cases, which isn't so much of an issue for
I believe you'd have to create a class for such things, derived from Array:
class AppOnlyArray is Array {
method STORE(int $index, $value) {
fail Can't modify existing element
if 0 = $index .length;
Larry wrote:
: multi foo (@a is Array of int) {...}
:
: my int @a = baz(); # is Array of int
: my @b = baz(); # is Array of Scalar
:
: foo(@a);# @a is typed correctly, so OK
: foo(@b);# @b is not explicitly typed as Cint; OK or FAIL?
:
: Fails.
:
: Because:
:
:
method x ($me: $req, ?$opt, +$namedop, *%named, [EMAIL PROTECTED]) { ... }
Yikes. And I thought we were trying to get *away* from line noise? :^)
Seriously, can't we use something rather prettier, like this?
method x($me: $req, $opt is optional, $namedop is named,
*%named,
Brent Dax wrote:
method x ($me: $req, ?$opt, +$namedop, *%named, [EMAIL PROTECTED]) { ... }
Yikes. And I thought we were trying to get *away* from line noise? :^)
Seriously, can't we use something rather prettier, like this?
method x($me: $req, $opt is optional, $namedop is named,
First of all, I like where Appendix C is going.
My (small in comparison) problem is with Clet's definition of
failure. The exception bit is neat, and provides for pretty much
out-of-the-box exception safety. But failure based on return value
may not be such a hot idea. Consider:
class
34 matches
Mail list logo
