I'd have to agree with Andrew. With only 32 registers of each type in
Parrot (the last time I checked) using most of them for function arguments
would cause much needless register copying within each function.
Surely 8 registers of each type would be more than sufficient for
function
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) should
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'
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 already
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
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
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
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
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 violates
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. And why?
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 gonna
fly.
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 for ... elsif
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++ {
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 well for me as
Dan Sugalski
[EMAIL
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 get
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 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 user
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
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
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.
Since
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 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 would
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_collect. You're
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
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
machines to
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 PMC
On Sat, 2002-04-27 at 01:14, Luke Palmer wrote:
On Fri, 26 Apr 2002, Allison Randal wrote:
Besides, I would expect an Celsfor 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 Celsunless then? Just because it's
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 intuitive
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 something?
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++) {
...
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 like
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 false for
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 point.
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 ELSE
On Mon, Apr 29, 2002 at 02:55:09PM -0500, Allison Randal wrote:
I still don't like the idea of Celsifs on loops. I already do an
instant double take with Celse 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
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, 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, but as we're
I still don't like the idea of Celsifs on loops. I already do an
instant double take with Celse 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 value
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. If we were
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 Celsif is different. You use it all the time. The frequency with
which you'd need a loop that leads into
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
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 realize
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 Cwhile nor Cuntil is being
dropped from Perl 6.
Incidently, even
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 Perl 6
The only reasonable way of doing loops is to use highly verbose syntax:
#!/usr/bin/perl
# sample while loop
As_Long_As[0] __(*%$ boolean expression $%*)__
begin_statement_of_syntax
# 7 (spaces required)
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 this array.
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 GC rip
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} = shift;
}
[ 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 Celsifs on loops. I already do an
instant double take with Celse of Where's the if? (with visions of
old Wendy's commercials dancing in my head). It seems that a long string
of Celsifs (possibly separated by other long intervening sections of
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 conditional
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 Celsif anyway; I always preferred Celse if. I really
don't understand what
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 Celsif is different. You use it all the time. The
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 2002
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:
Piers Cawley
[EMAIL
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 that
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 one.
I
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 the Cwhile's
block, it
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 rules.
Allison wrote:
The answer is the same, in any case: When the condition in the
Cwhile has a false value, when the list/array in the Cfor is empty,
or when the condition (2nd expression) in the Cloop is met on the first
^
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 major
and C$cond is defined *outside* the block. So if Larry were to allow
Celse
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
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 $cond;
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 Cwhile and
Celse,
it's scoped to that block. So you can use it inside the Cwhile's block,
inside the Celse's block (assuming Larry allows such a construct), and
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
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
Cwhile has a false value, when the list/array in the Cfor is empty,
or when the condition (2nd expression) in the Cloop is met on the first
68 matches
Mail list logo
