On Sat, Mar 01, 2003 at 06:09:15PM +0100, Paul Johnson wrote:
: I suspect that a lot would break if the order of
: evaluation changed. And I think it would be sensible for Perl 6 to
: define such an order.
Certainly. The fact that Perl 5 doesn't define it is merely an
oversight, brought on no do
On Wed, Feb 19, 2003 at 12:00:33AM -0500, Stephen McCamant wrote:
> > "DP" == Deborah Ariel Pickett <[EMAIL PROTECTED]>
>writes:
>
> DP> One thing that the C comma operator promises is that its left
> DP> operand (and all side effects) is completely evaluated before work
> DP> starts o
[EMAIL PROTECTED] (Allison Randal) writes:
> In the design meetings early this month we added C for true
> pass-by-value.
Can someone please compile a list of all the "is foo" properties that
have been suggested/accepted as being pre-defined by the language?
I can't keep track of them all.
--
So
Luke wrote:
> If you want to modify a parameter in place, you declare with C.
> If you want to pass by-value, there might be a property for that, but
> I think this was recommended:
>
> sub foo($bar_) {
> my $bar = $bar_; # Copy, not bind
> # ... with $bar
> }
In th
> On Sun, Feb 23, 2003 at 11:12:18AM +1300, Martin D Kealey wrote:
> > I would like to argue in favour of "pass by value" to be the
> > default in the absence of some explicit prototype, because it
> > allows greater type-safety, and because the opposite default
> > interacts badly with out-of-orde
On Sun, Feb 23, 2003 at 11:12:18AM +1300, Martin D Kealey wrote:
> I would like to argue in favour of "pass by value" to be the default in the
> absence of some explicit prototype, because it allows greater type-safety,
> and because the opposite default interacts badly with out-of-order execution
I would like to chip in in favour of the "list is value, array is container"
side of the argument. However I think that needs clarifying.
A reference is a value; the thing it refers to is a container.
An anonymous container is a container with no references from any symbol
table. It can lose it
On Wed, Feb 19, 2003 at 09:51:12AM +1100, Deborah Ariel Pickett wrote:
> That said, I don't know of anything that the C comma operator can do
> that you couldn't equivalently do with a Perl5 C statement:
>
> foo() or (do { warn("blah"); next; }); # Yes, it's ugly.
Well, gee, it's not that ugl
Dave Mitchell wrote:
> On Tue, Feb 18, 2003 at 10:06:29PM -, Smylers wrote:
>
> > More practically, the length of a list is never interesting: a list
> > by definition must be hardcoded into the program so its length is
> > known at compile time.
>
> Err, no. Eg in perl 5:
>
> $value =
> "DP" == Deborah Ariel Pickett <[EMAIL PROTECTED]>
writes:
DP> One thing that the C comma operator promises is that its left
DP> operand (and all side effects) is completely evaluated before work
DP> starts on the right operand. (This may not be strictly true in
DP> the Perl interpret
On Wed, Feb 19, 2003 at 09:51:12AM +1100, Deborah Ariel Pickett wrote:
> That said, I don't know of anything that the C comma operator can do
> that you couldn't equivalently do with a Perl5 C statement:
>
> foo() or (do { warn("blah"); next; }); # Yes, it's ugly.
Or just a Boolean:
foo(
On Tue, Feb 18, 2003 at 10:06:29PM -, Smylers wrote:
> More practically, the length of a list is never interesting: a list by
> definition must be hardcoded into the program so its length is known at
> compile time. Indeed it should be known by whoever typed it in!
Err, no. Eg in perl 5:
> > 2) (4, 1, 2) + 7 returns (9). This is C comma behavior, and I always
> >found it incredibly non-intuitive. I'd really like to get away
> >from this, even if it means that this expression is a fatal error
> >"Can't add scalar to list".
[...]
> Agreed, however, that (2) is icky. My
Michael Lazzaro wrote:
> So, IMO, the only reasonable answer is (3)... that a list in numeric
> context returns the length. Thus we have consistency between lists
> and arrays:
>
> (1,2,3) + 4 # --> (1,2,3).length + 4 --> 7 (list)
> [1,2,3] + 4 # --> [1,2,3].length + 4 --> 7
On Saturday, February 15, 2003, at 08:47 AM, David Storrs wrote:
I can see five possible courses here:
1) We decide that my suggestion is a bad one and do nothing with it.
That's fine; I am not wedded to it, I just thought it was an
interesting idea that I wanted to raise.
2) (4, 1, 2) +
On Fri, Feb 14, 2003 at 10:10:09PM -0700, Luke Palmer wrote:
> > Date: Fri, 14 Feb 2003 12:38:59 -0800
> > From: David Storrs <[EMAIL PROTECTED]>
> >
> > Some random musings, for what they're worth...
> >
> > 1) The fact that we've had this long thread about arrays and shows
> >that they are
I just wrote:
> ... I'm strongly in us limiting new features to those that come about
Um, try "I'm strongly in favour of limiting" etc.
> through a desire for particular functionality rather than a desire to
> use up some 'spare' syntax ...
Sorry about that.
Smylers
Luke Palmer wrote:
> The real question is, if they don't auto-vector, what I this do:
>
> @a = (4, 1, 2) + 7;
>
> @a could be (9) or (10), maybe even (\(4,1,2)+7), but hopefully not.
What about making that a fatal error? If it doesn't do anything
sensible -- and if all the suggested outcom
> Date: Fri, 14 Feb 2003 12:38:59 -0800
> From: David Storrs <[EMAIL PROTECTED]>
>
> Some random musings, for what they're worth...
>
> 1) The fact that we've had this long thread about arrays and shows
>that they are confusing. How could we change the
>functionality/eliminate the differ
Some random musings, for what they're worth...
1) The fact that we've had this long thread about arrays and shows
that they are confusing. How could we change the
functionality/eliminate the differences so as to simplify things?
2) It seems that the functionality of lists is a proper subs
On Wednesday, February 12, 2003, at 05:50 PM, Deborah Ariel Pickett
wrote:
All right, I'm prepared to buy that. Now how would it extend to
hashes?
A %hash in list context returns a list of its pairs (NOTE4)
A %hash in scalar context returns a reference to itself (NOTE1)
A %hash in numeric (sc
> Here are some of the answers from my own notes. These behaviors have
> all been confirmed on-list by the design team:
>
> An @array in list context returns a list of its elements
> An @array in scalar context returns a reference to itself (NOTE1)
> An @array in numeric (scalar) context retur
On Tuesday, February 11, 2003, at 04:56 PM, Deborah Ariel Pickett
wrote:
But is it OK for a list to be silently promoted to an array when used
as an array? So that all of the following would work, and not just
50%
of them?
(1..10).map {...}
[1..10].map {...}
And somehow related to al
> But is it OK for a list to be silently promoted to an array when used
> as an array? So that all of the following would work, and not just 50%
> of them?
> (1..10).map {...}
> [1..10].map {...}
And somehow related to all this . . .
Let's assume for the moment that there's still a fun
24 matches
Mail list logo
