On Tue, Apr 30, 2002 at 12:53:32PM +1000, Damian Conway wrote:
> Allison wrote:
>
> > The answer is the same, in any case: "When the condition in the
> > C has a false value, when the list/array in the C is empty,
> > or when the condition (2nd expression) in the C is met on the first
>
> OK, will at least this statement still work as it does in Perl5?
No.
> Notice addition of parens.
which, as you surmise later, have no effect on scoping issues.
> If that changes, I for one will need to go rewrite virtually every script
> and library I maintain,
or let p52p6 do it
> In Perl 6 a lexical variable is scoped to the block in which it's
declared.
> Since C<$cond> is declared in the block *containing* the C and
C,
> it's scoped to that block. So you can use it inside the C's block,
> inside the C's block (assuming Larry allows such a construct), and
in
> the follo
Miko wrote:
> I don't know if we're talking about the same thing, but I live using loops
> that declare variables in the test, so please exegize me. Which of these
> lines, if any, would cause a compiler error or warning?
>
> while my $cond = blah() {
> ...
> }
> else {
> print
> and C<$cond> is defined *outside* the block. So if Larry were to allow
C
> on loops, you'd be able to write:
> [snip]
> Given how rarely this kind of thing is actually needed (I've *never* used
such
> a construct), I suspect that an explicit variable is adequate.
I don't know if we're talking a
Allison wrote:
> The answer is the same, in any case: "When the condition in the
> C has a false value, when the list/array in the C is empty,
> or when the condition (2nd expression) in the C is met on the first
^
> Two solutions to the problem of accessing 'what' returned false are:
>
> 1) don't allow it.
> 2) Alias the value of the while/loop/if conditional into a special
> variable.
>
> while( blah() ) {
> ..
> } else { print $COND; }
>
> It's ugly, but it works, and doesn't break the holy scoping r
> > > I can also think of some advantages to having the "else" within the
> > > scope of the loop.
> >
> > while alllines("/etc/passwd") -> $_ {
> > ...
> > } else {
> > die "/etc/passwd: $_";
> > }
>
> But the aliased value, $_, is restricted to the scope of th
G'day all.
On Mon, Apr 29, 2002 at 11:59:45PM +0100, Tim Bunce wrote:
> [ I'm playing devils advocate for a while longer as I'm not 100% convinced ]
Understood.
> Isn't compiler convienience a (the?) major issue here?
I wouldn't call it a "major issue". I think of it as a constraint.
The ma
On Mon, Apr 29, 2002 at 04:25:26PM -0700, Peter Scott wrote:
> At 01:55 PM 4/29/02 -0500, Allison Randal wrote:
> >
> >There will have to be a section of the training material devoted to
> >"When is a loop false?" (I like that perspective, it nicely unifies the
> >cases), but it should be a short
G'day all.
On Mon, Apr 29, 2002 at 10:53:40AM -0400, Dan Sugalski wrote:
> Welcome to my world. They're all bad ideas in some way or, rather,
> they're all equally as good.
That's definitely true. :-)
I should also point out that for Perl, all this is moot. Current Perl
semantics require tha
Piers Cawley
<[EMAIL PROTEC
At 04:15 PM 4/29/02 -0500, Allison Randal wrote:
>On Mon, Apr 29, 2002 at 04:14:01PM -0400, Aaron Sherman wrote:
> >
> > Well then, I guess we should dump "elsif" from if too. After all, it
> > could all be done with nested blocks of if/else
>
>But C is different. You use it all the time. The
On 4/29/02 1:41 PM, "Luke Palmer" <[EMAIL PROTECTED]>
claimed:
> My point is that, IMO, this whole "els" thing is completely preposterous.
> I'm the kind of person that likes to keep down on keywords. And I never
> liked Perl5's C anyway; I always preferred C. I really
> don't understand what at
At 01:55 PM 4/29/02 -0500, Allison Randal wrote:
>On Mon, Apr 29, 2002 at 10:10:01AM -0400, Aaron Sherman wrote:
> > Again, it's just first derivative over time. You're not asking "is there
> > a false value", you're asking "is the loop false". Just as we understand
> > that an array in a conditio
> On Mon, 29 Apr 2002 18:58:18 -0400, Jeff <[EMAIL PROTECTED]> said:
J> Ilya Martynov wrote:
>>
>> Index: core.ops
>> [..snip..]
J> Applied, thanks.
I've just found other POD bugs in core.ops
Index: core.ops
===
RCS file: /cv
Ilya Martynov wrote:
>
> Index: core.ops
> ===
> RCS file: /cvs/public/parrot/core.ops,v
> retrieving revision 1.130
> diff -u -d -u -r1.130 core.ops
> --- core.ops24 Apr 2002 20:31:39 - 1.130
> +++ core.ops29 Apr 20
[ I'm playing devils advocate for a while longer as I'm not 100% convinced ]
On Mon, Apr 29, 2002 at 10:53:40AM -0400, Dan Sugalski wrote:
> At 9:50 AM +1000 4/29/02, Andrew J Bromage wrote:
> >G'day all.
> >
> >On Sun, Apr 28, 2002 at 11:44:04AM -0400, Dan Sugalski wrote:
> >
> >> We're going
Allison wrote:
> I still don't like the idea of Cs on loops. I already do an
> instant double take with C of "Where's the if?" (with visions of
> old Wendy's commercials dancing in my head). It seems that a long string
> of Cs (possibly separated by other long intervening sections of
> code) woul
The only reasonable way of doing loops is to use highly verbose syntax:
#!/usr/bin/perl
# sample while loop
As_Long_As[0] __(*&%$ $%&*)__
begin_statement_of_syntax
# 7 (spaces required)
while_percha
Aaron Sherman wrote:
> > while $result.get_next() -> $next {
> > # do something with $next...
> > ELSE {
> ># do something otherwise with $next
> > }
> > }
> > }
> Here's the code, expanded:
Unfortunately, that code isn't even close to the
>>OO code is full of subs which a) are called very often and b) look
>>like this:
>>
>> sub code
>> {
>> my $self = shift;
>> return $self->{CODE};
>> }
>>
>> sub body
>> {
>> my $self = shift;
>> if (@_) {
>> $self->{BODY} =
Aaron Sherman wrote:
> > Er, what?!? Who said we're dropping "until"? Did I miss something?
>
> Well, if there's no while (replaced by generic "loop", per Apoc4) why
> would there be an until?
As Aaron himself has discovered, neither C nor C is being
dropped from Perl 6.
Incidently, even C i
On Mon, Apr 29, 2002 at 09:42:46PM +0100, Piers Cawley wrote:
> Steve Fink <[EMAIL PROTECTED]> writes:
>
> > On Mon, Apr 29, 2002 at 01:41:56PM -0400, Mike Lambert wrote:
> >> - Make an array of buffer data, in order of insertion into the hashtable.
> >> set pmc_pointer and buffer_ptr and let the
Concerning the els(loop|for|while) controversy, I'd like to bring it back to
the point that started it all: loop-else. There seems to be a fair amount
of support for a loop-else contruct. Can we/Larry decide to accept
loop-else, regardless of what other decisions need to be made? It would be
a
On Mon, Apr 29, 2002 at 04:14:01PM -0400, Aaron Sherman wrote:
>
> Well then, I guess we should dump "elsif" from if too. After all, it
> could all be done with nested blocks of if/else
But C is different. You use it all the time. The frequency with
which you'd need a loop that leads into a
On Mon, 2002-04-29 at 16:41, Luke Palmer wrote:
> > So, the answer to your question is: yes, I do propose that there should
> > be an elsif, elsloop and elsfor. That's it. Three words, not an
> > expansive list of ever-more-complex words.
>
> Oh! I have an idea! Why don't we make the lexer just r
Steve Fink <[EMAIL PROTECTED]> writes:
> On Mon, Apr 29, 2002 at 01:41:56PM -0400, Mike Lambert wrote:
>> - Make an array of buffer data, in order of insertion into the hashtable.
>> set pmc_pointer and buffer_ptr and let the GC rip through it.
>> - The hashtable itself just uses indices into thi
> So, the answer to your question is: yes, I do propose that there should
> be an elsif, elsloop and elsfor. That's it. Three words, not an
> expansive list of ever-more-complex words.
Oh! I have an idea! Why don't we make the lexer just realize a prefix
"els" on any operator. Then you could do
Aaron Sherman wrote:
> Of course it brings other less wholesome things to mind like "elsfor"
> and "elsloop" and "if ... elsfor" and "for ... elsif ... elsloop ...
> else", but why not?
Because Perl 6 is already...err...over-endowed with keywords, few of which are
as klunky as these would be. I
> > I still don't like the idea of Cs on loops. I already do an
> > instant double take with C of "Where's the if?" (with visions of
> > old Wendy's commercials dancing in my head).
>
> Me too. That's why the looping "else" should be spelled "otherwise"
> IMHO.
If a loop produced a boolean val
On Mon, 2002-04-29 at 15:54, Jonathan Scott Duff wrote:
> On Mon, Apr 29, 2002 at 03:30:40PM -0400, Aaron Sherman wrote:
> > On Mon, 2002-04-29 at 10:41, Jonathan Scott Duff wrote:
> > > On Mon, Apr 29, 2002 at 10:26:26AM -0400, Aaron Sherman wrote:
> > > > I would expect that to be "elsuntil", bu
What about unless? Since we are giving els to loops, shouldn't we upgrade
unless as well? That would be really weird if it were not upgraded.
Tanton
- Original Message -
From: "Jonathan Scott Duff" <[EMAIL PROTECTED]>
To: "Allison Randal" <[EMAIL PROTECTED]>
Cc: "Aaron Sherman" <[EMAIL
On Mon, Apr 29, 2002 at 02:55:09PM -0500, Allison Randal wrote:
> I still don't like the idea of Cs on loops. I already do an
> instant double take with C of "Where's the if?" (with visions of
> old Wendy's commercials dancing in my head).
Me too. That's why the looping "else" should be spelled
On Mon, 2002-04-29 at 15:46, Miko O'Sullivan wrote:
> > Well, if there's no while (replaced by generic "loop", per Apoc4) why
> > would there be an until?
>
> Whoa. I actually had a moment of panic there. Then I checked for myself.
> I don't see anything in Apoc4 about getting rid of while. It
On Mon, Apr 29, 2002 at 03:30:40PM -0400, Aaron Sherman wrote:
>
> Ok, once more for those in the cheap seats (no offense, it's just a lot
> of people seemed to have ignored the thread until now and jumped in
> without the context), this is how we got here:
>
> 1. Larry says loops will have "ELS
On Mon, Apr 29, 2002 at 03:30:40PM -0400, Aaron Sherman wrote:
> On Mon, 2002-04-29 at 10:41, Jonathan Scott Duff wrote:
> > On Mon, Apr 29, 2002 at 10:26:26AM -0400, Aaron Sherman wrote:
> > > I would expect that to be "elsuntil", but as we're dropping "until" from
> > > the language, it's a moot
On Sat, 2002-04-27 at 08:53, Damian Conway wrote:
> Which I presume was that the proposed usage:
>
> while $result.get_next() -> $next {
> # do something with $next...
> ELSE {
> if $next eq "xyz572" {
> print "We defined this value, $next, as fals
> Well, if there's no while (replaced by generic "loop", per Apoc4) why
> would there be an until?
Whoa. I actually had a moment of panic there. Then I checked for myself.
I don't see anything in Apoc4 about getting rid of while. It may be
excluded from evolution, but it's still there, sorta l
On Mon, Apr 29, 2002 at 10:26:26AM -0400, Aaron Sherman wrote:
> On Fri, 2002-04-26 at 19:30, Miko O'Sullivan wrote:
>
> > 1) Do we have a reality check on why this syntax is needed?
>
> It's because the alternative is:
>
> Perl5:
> $did = 0;
> for($i=0;$i<$max;$i++) {
>
On Mon, 2002-04-29 at 10:41, Jonathan Scott Duff wrote:
> On Mon, Apr 29, 2002 at 10:26:26AM -0400, Aaron Sherman wrote:
> > I would expect that to be "elsuntil", but as we're dropping "until" from
> > the language, it's a moot point.
>
> Er, what?!? Who said we're dropping "until"? Did I miss
On Mon, Apr 29, 2002 at 01:41:56PM -0400, Mike Lambert wrote:
> - Make an array of buffer data, in order of insertion into the hashtable.
> set pmc_pointer and buffer_ptr and let the GC rip through it.
> - The hashtable itself just uses indices into this array. Each
> linked-list node would be a P
On Mon, Apr 29, 2002 at 10:10:01AM -0400, Aaron Sherman wrote:
> On Fri, 2002-04-26 at 19:06, Allison Randal wrote:
>
> Absolutely what I thought. "elsif" would be for "thing else if" where
> "elsfor" would be "thing else for-loop". Since you got this distinction
> right off, it sounds like an in
On Mon, Apr 29, 2002 at 07:34:22PM +0100, Simon Cozens wrote:
> Steve Fink:
> > The assembler needs to be taught about the PMC constants:
>
> I disagree. Once you start adding assembler functions to make it easier
> for humans to use, you won't stop. I consider the assembler a tool for
> machine
Steve Fink:
> The assembler needs to be taught about the PMC constants:
I disagree. Once you start adding assembler functions to make it easier
for humans to use, you won't stop. I consider the assembler a tool for
machines to use. But if you want to do it, here's a patch.
--- newasm~ Mon A
> > > Btw, this is only a weak guess about what's going on, because the
> > > corruption I'm seeing isn't even in the linked list nodes. It only
> > > happens with GC_DEBUG, but it's not an infant mortality bug.
> >
> > GC_DEBUG adds extra calls to do_dod_run (infant mortality), and
> > do_collec
On Mon, Apr 29, 2002 at 01:41:56PM -0400, Mike Lambert wrote:
> > I suspect the "bug" may be in my understanding of the memory
> > management API, though. If I want to maintain a linked-list of my own
> > objects, how do I do it? If I carve out my objects (hash buckets) from
> > a Buffer, then GC
On Sat, 2002-04-27 at 01:14, Luke Palmer wrote:
> On Fri, 26 Apr 2002, Allison Randal wrote:
>
> > Besides, I would expect an C to actually be a loop of it's own,
> > on the principle of "elsif = else + if" so "elsfor = else + for".
>
> So, you're suggesting we add C then? Just because it's
>
> I suspect the "bug" may be in my understanding of the memory
> management API, though. If I want to maintain a linked-list of my own
> objects, how do I do it? If I carve out my objects (hash buckets) from
> a Buffer, then GC would keep moving them around and breaking the
> ->next link pointers.
On Sun, Apr 28, 2002 at 10:08:01PM -0400, Jeff wrote:
> And a long time coming...
>
> An assembler supporting keyed aggregates. Because of the current lack of
> macro support (that will be added in a few days), it's not built by
> default and isn't invoked in the test suite.
Yay! Thank you.
> S
Sounds like this stuff will collide violently with my local changes.
I'm trying to track down a nasty memory corruption bug. It sounds like
it would probably be easier to find with your new version, though.
The only real changes of interest I have so far are to finish the
implementation of new_tr
Dan Sugalski wrote:
> 1) Has the external interface changed, and are you planning on having
> it change?
So far, no. mem_allocate will shortly need to be told what pool to allocate
from; but I hope to remove this function from the external interface
entirely. Other than that, it should just be the
At 11:05 AM -0400 4/29/02, Melvin Smith wrote:
> >Just for chuckles, I went and benchmarked things, as meaningless
>>numbers are useful to have. With my current GCC3/-O3 build of parrot,
>>the cost to do 10,000,000 sets of saves is as follows:
>>
>>save all: 5.3 sec usertime
>>save 1: 2.6 sec
I just started playing with Parrot assembly and it looks like I have
found a bug with entrytype OP.
This test case causes segfault:
save I1
entrytype I2, 0
Another test case
save I1
entrytype I2, -1
This one causes 'Stack Depth wrong' error instead of getting
At 4:44 PM +0200 4/29/02, Peter Gibbs wrote:
>
>Herewith the first set of patches to the memory allocation routines.
>
>There is no new functionality here yet; basically I have been working on
>trying to remove some of the code that is duplicated between the various
>pools, before even more copies
Dan Sugalski
<[EMAIL PROTEC
At 9:50 AM +1000 4/29/02, Andrew J Bromage wrote:
>G'day all.
>
>On Sun, Apr 28, 2002 at 11:44:04AM -0400, Dan Sugalski wrote:
>
>> We're going caller-save. I think I made this declaration before, but
>> now it's backed up with pure PDD goodness. :)
>
>The first thing to realise is that this vi
> See above.
>
> > Two issues spring to mind:
> >
> > 1) Do we have a reality check on why this syntax is needed? I agree it's
> > cool idea, but can anyone name a real-world scenario where it would be
> > useful? Can we do things just bcause they're cool? That approach didn't
> > work too we
Herewith the first set of patches to the memory allocation routines.
There is no new functionality here yet; basically I have been working on
trying to remove some of the code that is duplicated between the various
pools, before even more copies get made for the new stuff.
The result is some fai
On Mon, Apr 29, 2002 at 10:26:26AM -0400, Aaron Sherman wrote:
> I would expect that to be "elsuntil", but as we're dropping "until" from
> the language, it's a moot point.
Er, what?!? Who said we're dropping "until"? Did I miss something?
> Proposed Perl6:
>
> loop $i=0;$i<$max;$i++ {
On Monday, April 29, 2002 3:10 PM, Aaron Sherman wrote:
> On Fri, 2002-04-26 at 19:06, Allison Randal wrote:
> > On Fri, Apr 26, 2002 at 05:24:13PM -0400, Aaron Sherman wrote:
> > > Of course it brings other less wholesome things to mind like "elsfor"
> > > and "elsloop" and "if ... elsfor" and "f
On Fri, 2002-04-26 at 19:30, Miko O'Sullivan wrote:
> > Of course it brings other less wholesome things to mind like "elsfor"
> > and "elsloop" and "if ... elsfor" and "for ... elsif ... elsloop ...
> > else", but why not?
>
> Well, I agree with the concept, but boyoboy those names ain't
On Fri, 2002-04-26 at 19:06, Allison Randal wrote:
> On Fri, Apr 26, 2002 at 05:24:13PM -0400, Aaron Sherman wrote:
> > Of course it brings other less wholesome things to mind like "elsfor"
> > and "elsloop" and "if ... elsfor" and "for ... elsif ... elsloop ...
> > else", but why not?
>
> Urk.
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.130
diff -u -d -u -r1.130 core.ops
--- core.ops24 Apr 2002 20:31:39 - 1.130
+++ core.ops29 Apr 2002 14:00:28 -
@@ -2823,7 +2823,7
Hi, again!
Sorry but I didn't have the time to read all I should about parrot, but
this question can be usefull to know if I should continue looking at it,
or not... is parrot ready (or will be, soon) to use external libraries?
And another simple... can parrot be used as a filter? assembler x.p
G'day all.
On Mon, Apr 29, 2002 at 07:57:08AM +0100, Piers Cawley wrote:
> Remember that the caller only has to save the stuff that is important
> to it, after all, anything that might be of importance to *its*
> callers will already have been saved. If the callee saves then it's
> going to be d
> > Actually, I _was_ saying we shouldn't do caller-save (except
> > possibly for a small number of registers designated for the
> > purpose).
>
> Remember that the caller only has to save the stuff that is important
> to it, after all, anything that might be of importance to *its*
> callers will
So, I was thinking about how symbol tables are going to work, and I
remembered that Dan had said that he wanted hashes to preserve their
insertion order on print out.
Which led me to think that it'd be really nice if there was some way
of addressing hashes with integers to get the 'nth thing'
ins
Andrew J Bromage <[EMAIL PROTECTED]> writes:
> G'day all.
>
> On Sun, Apr 28, 2002 at 09:49:35PM -0400, Melvin Smith wrote:
>
>> I don't think I and Andrew were saying we shouldn't do caller-save,
>> we were just discussing that the calling convention (read
>> activation record of a subroutine) s
69 matches
Mail list logo
