First of all, I like where Appendix C is going.
My (small in comparison) problem is with C'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 DBHan
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,
*%
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, [EMA
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 C; OK or FAIL?
:
: Fails.
:
: Because:
:
> 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 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
s
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
Michael Lazzaro asked:
1) Complex types for sub parameters: The above would imply that a sub
can tell the difference between an C vs an C, thank goodness. That also implies that you can use arbitrarily
complex types, and still get the same type checking:
sub foo ( %pet is Hash of Array of
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 su
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
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 all
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) {
--- 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
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 t
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
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 you'
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 PROTECTED
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 Cente
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 -- 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 parame
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 h
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], +
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
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 {
?
?
*
}
rule packagesub :w {
?
*
}
rule
--- 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
On Mon, Mar 10, 2003 at 01:20:24PM -0800, Austin Hastings wrote:
: In , is the 's' silent?
Of course not. That is Greek, not English.
Larry
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 S&M folks to
inflict strongly typed
Oh, goody.
In , 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
>
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 abou
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.
http://archive.develooper.com/perl6-language%40perl.org/
> 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 unle
On Mon, Mar 10, 2003 at 11:28:41AM -0800, Paul wrote:
Agreed. But is it worth putting them in if they would make a problem so
easily, and it can be so easily handled with blocks?
I don't think they can make a problem so easily, and I think it's worth
putting them in because afaics it's not very co
> I made a mistake in my original post, they definitely need to be
> left-associative. Your example should obviously be interpreted as:
>
> (.method given $x) given $y; # calls $x.method
ok.
> I think this is similar to how I mentioned that a duplicate 'for' is
> pointless. Just because poi
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-
as
--- 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:
>
> .meth
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
apprecia
36 matches
Mail list logo
