Re: Loop controls

[Me]

I'm basically sold on Damian's conclusions. On the other
hand the 'otherwise' clause still feels to me like a CAPITALS
block.

So, as a tweak, I suggest:

 while condition() {
 ...
 }
 NONE {
 ...
 }

--
ralph

Re: Loop controls

[Damian Conway]

ralph wrote:

> I'm basically sold on Damian's conclusions. On the other
> hand the 'otherwise' clause still feels to me like a CAPITALS
> block.
> 
> So, as a tweak, I suggest:
> 
>  while condition() {
>  ...
>  }
>  NONE {
>  ...
>  }


Would you also change C to C? I think lowercase is more
appropriate because C would be a control structure, rather
than an event handler.

Making it a CAPITAL block is also a little inconsistent: the other CAPITAL
blocks attach behaviour to the *surrounding* block, not the *preceding* one.

Damian

Re: Loop controls

[Damian Conway]

Luke Palmer wrote:

> I'd rather have an in-betweener block too. Loops like this are very
> common, and I hate doing "prefix" commas, if you know what I mean.  I
> realize NEXT often used for cleanup, so maybe you could introduse Yet
> Another block, BETWEEN (or SQUEEZE).
> 
> Or are we just going to have to deal with this fact?

We may just have to deal with the fact. Because there's a problem with
in-betweener blocks. Consider:

my $filename;
while get_next_filename($filename)  {
FIRST   { print "\n"  }
my $fh = open $_ or die "Can't open $filename";
NEXT{ close $fh }
print extract_id($fh);
BETWEEN { print (-d $filename ?? "/," :: ",") }
LAST{ print "\n" }
}

This looks reasonable, but there's a bug.

The C block can't decide whether to execute until
it knows whether the loop is going to iterate again. And it can't
know *that* until it has evaluated the condition again. At which 
point, the $filename variable has the wrong value. :-(

The example is a little contrived perhaps, but it might be a common 
problem. For example, it happens here too:

loop ($n=$from; $n<$to; $n+=$skip) {
print $page[$n];
BETWEEN { print "Skipping to page $( $n+$skip )\n"; }
}

C<$n> is updated before the conditional test, but the C
block can't execute until after the conditional.

Don't get me wrong: I *like* the idea of a BETWEEN block.
I just think it's harder to get right (and *much* harder to explain)
than most people would expect.

Damian

Re: Loop controls

[Piers Cawley]

Luke Palmer <[EMAIL PROTECTED]> writes:

> On Tue, 30 Apr 2002, Miko O'Sullivan wrote:
>
>> > Damian, now having terrible visions of someone suggesting C ;-)
>> 
>> Then may I also give you nightmares on: elsdo, elsdont, elsgrep, elstry ...
>
> Ooh! Why don't we have a dont command!  With several variants:
>   dont FILE
>   dont BLOCK
>
> dont { print "Boo" }

Hmm... what sort of semantics do you suggest? Just noop the following
block?

sub don't (&) { return }

I really should get 'round to releasing the semi mythical
Acme's::Abbreviations module. Here's a taster. I really hope that it
won't be possible to perpetrate this sort of thing in Perl 6:

package Acme's::Abbreviations;

@ISA = 'Bloody Silly Thing To Do';
our $VERSION = '0.01';

sub can't {
my $target = shift;
if (UNIVERSAL::isa($target, 'UNIVERSAL')) {
return ! $target->can(@_);
} else {
return ! UNIVERSAL::can($target, @_);
}
}

*doesn't = \&can't;

sub isn't {
my $target = shift;
if (UNIVERSAL::isa($target, 'UNIVERSAL')) {
return ! $target->isa(@_);
} else {
return ! UNIVERSAL::isa($target, @_);
}
}

sub won't {
my $target = shift;
my $method = shift;
eval { $target->can't($method) &&
   $target->can't('AUTOLOAD') };
}

sub mightn't {
my $target = shift;
my $method = shift;
eval { $target->can't($method) &&
   $target->can('AUTOLOAD') };
}

sub mustn't {
my $target = shift;
my $method = shift;

no strict 'refs';
my $old_glob = \ $ {"${target}::"}{$method};
delete $ {"${target}::"}{$method};
*{"$target\::$method"} = *{$old_glob}{$_} for (qw/ SCALAR HASH ARRAY IO /);
1;
}


# Preloaded methods go here.

1;

-- 
Piers

   "It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
 -- Jane Austen?

jvm.ops

[Leon Brocard]

Over the weekend I've been thinking about Targeting Parrot. My
thoughts went something like this: Parrot is a register machine. The
Java virtual machine is a stack machine. Parrot is also a stack
machine. Instead of converting Java bytecode to Parrot bytecode, I can
make Parrot into a JVM. And lo, so I did (for a small number of opcodes):

This is Java source code:

public static void spin() {
  int i;
  for(i = 0, i < 12345678; i++);
  System.out.print(i);
}

which turns into the following Java bytecode:

   0 iconst_0
   1 istore_0
   2 goto 8
   5 iinc 0 1
   8 iload_0
   9 sipush 1000
  12 if_icmplt 5
  15 getstatic #3 
  18 iload_0
  19 invokevirtual #4 
  22 return

On a different VM, not so far away:

# This is Parrot assembler:
  iconst_0
  istore_0
  goto  IN
REDO: iinc  0, 1
IN:   iload_0
  sipush12345678
  if_icmplt REDO
  iload_0
  jvm_print
  end

Cute, huh? Of course, Java interpreters are very optimised (and
non-dynamic) and without JITs doing it in Parrot is about 6 times
slower, but it's interesting nevertheless. Is this the kind of thing I
should be doing? I've attached a fledgling jvm.ops. Does my C code
look ok?

Leon
-- 
Leon Brocard.http://www.astray.com/
Nanoware...http://www.nanoware.org/

 (c) The Intergalactic Thought Association


/*
** jvm.ops
*/

VERSION = PARROT_VERSION;

=head1 NAME

jvm.ops

=cut

=head1 DESCRIPTION

Library of ops for Parrot which resemble the JVM ops

=cut

###

=head2 Basic ops

These are the fundamental operations.

=over 4

=cut

=item B()

Pop two integers off the stack, add them together and push the result
on the stack.

=cut

op iadd() {
  INTVAL x, y;
  stack_pop(interpreter, interpreter->user_stack, &y, STACK_ENTRY_INT);
  stack_pop(interpreter, interpreter->user_stack, &x, STACK_ENTRY_INT);
  x = x + y;
  stack_push(interpreter, interpreter->user_stack, &x, STACK_ENTRY_INT, 
STACK_CLEANUP_NULL);
  goto NEXT();
}

op iconst_0() {
  INTVAL x = 0;
  stack_push(interpreter, interpreter->user_stack, &x, STACK_ENTRY_INT, 
STACK_CLEANUP_NULL);
  goto NEXT();
}

op iconst_1() {
  INTVAL x = 1;
  stack_push(interpreter, interpreter->user_stack, &x, STACK_ENTRY_INT, 
STACK_CLEANUP_NULL);
  goto NEXT();
}

op sipush(in INT) {
  INTVAL i = $1;
  stack_push(interpreter, interpreter->user_stack, &i, STACK_ENTRY_INT, 
STACK_CLEANUP_NULL);
  goto NEXT();
}

op iload_0() {
  INTVAL i = interpreter->int_reg.registers[0];
  stack_push(interpreter, interpreter->user_stack, &i, STACK_ENTRY_INT, 
STACK_CLEANUP_NULL);
  goto NEXT();
}

op istore_0() {
  INTVAL i;
  stack_pop(interpreter, interpreter->user_stack, &i, STACK_ENTRY_INT);
  interpreter->int_reg.registers[0] = i;
  goto NEXT();
}

op jvm_print() {
  INTVAL i;
  stack_pop(interpreter, interpreter->user_stack, &i, STACK_ENTRY_INT);
  printf(INTVAL_FMT, (INTVAL)i);
  goto NEXT();
}

op iinc(in INT, in INT) {
  interpreter->int_reg.registers[$1] += $2;
  goto NEXT();
}

op if_icmplt(inconst INT) {
  INTVAL x, y;
  stack_pop(interpreter, interpreter->user_stack, &y, STACK_ENTRY_INT);
  stack_pop(interpreter, interpreter->user_stack, &x, STACK_ENTRY_INT);
  if (x < y) {
goto OFFSET($1);
  }
  goto NEXT();
}

op goto (in INT) {
  goto OFFSET($1);
}

Re: Loop controls

[Miko O'Sullivan]

Damian said:
> 6. C would seem to fit the bill rather nicely.


To me, "otherwise" is a synonym for "else", and that makes it too
confusingly similar.  I foresee forever explaining to people the difference
between C and C.  I'm not sure if C is popular
because it is similar to C, but I think the similarity is a reason
*not* to use it.

How about C?  It's absolutely clear what it means and won't be
confused with "else".


> I now confidently await Larry's coming up with an entirely different
solution ;-)

I keep picturing Larry tugging thoughtfully on his mustache while reading
this thread, a smile on his face, his finger hovering over the "reveal"
button.

-Miko

Re: Loop controls

[Jim Cromie]

Damian Conway wrote:

>Luke Palmer wrote:
>
>>Ooh! Why don't we have a dont command!  With several variants:
>>dont FILE
>>dont BLOCK
>>
>>dont { print "Boo" }
>>
>>Would print:
>>
>>
>
>You really *should* be more careful what you wish for Luke.
>The following was just uploaded to the CPAN...
>
>Damian
>
>
>-cut--cut--cut--cut--cut--cut-
>
>NAME
>Acme::Don't - The opposite of `do'
>
>VERSION
>This document describes version 1.00 of Acme::Don't, released May 1,
>2002.
>
>SYNOPSIS
>use Acme::Don't;
>
>don't { print "This won't be printed\n" };# NO-OP
>
>DESCRIPTION
>The Acme::Don't module provides a `don't' command, which is the opposite
>of Perl's built-in `do'.
>
>
>AUTHOR
>Damian Conway ([EMAIL PROTECTED])
>
>BLAME
>Luke Palmer really should be *far* more careful what he idly wishes for.
>
>BUGS
>Unlikely, since it doesn't actually do anything. However, bug reports
>and other feedback are most welcome.
>
>

feature request :

Acme::Dont::Obstruct


We need a dont that will prevent *bad things*,  to wit:

dont ( 'let MS get away with it');
dont ( 'rape the planet');
dont ( 'sack ANWAR');
dont ( 'accept Bushs Energy Plan');
dont ('pass CBTBPTA*%#$');

in this light, your *impressive* module has the shortcoming that it cant 
stop stuff when its not used.

Ex: W was able to hold secret energy meetings with the oil industry, w/o 
the participation of *any*
environmental groups.  Shades of Hillarys health plan that was 
pilloried.  Wheres the uproar now ?

Now the real trick will be getting this module to insert itself into 
code w/o explicit 'use'

stuff it into universal ??


can you make a module that can do that ? huh ? huh ?

Re: Loop controls

[Miko O'Sullivan]

Damian posted:
> NAME
> Acme::Don't - The opposite of `do'

Wonderful job, Damian!  I'll get to work on the complementary Acme::TryNotTo
module.

:-)

-Miko

Re: Loop controls

[Jonathan Scott Duff]

On Wed, May 01, 2002 at 08:27:41AM -0400, Miko O'Sullivan wrote:
> Damian said:
> > 6. C would seem to fit the bill rather nicely.
> 
> To me, "otherwise" is a synonym for "else", and that makes it too
> confusingly similar.  I foresee forever explaining to people the difference
> between C and C.  I'm not sure if C is popular
> because it is similar to C, but I think the similarity is a reason
> *not* to use it.

I actually think exactly the opposite.  In my mind "otherwise" would
just be a synonym for "else" so that 

loop { ... } else { ... }
loop { ... } otherwise { ... }

would both be syntactically valid.  We would just encourage people to
use the "otherwise" version for understandability.  Since there's no
difference between them, there's nothing to explain there, thus no
confusion.

Hmm.  I wonder why the python community (apparently) have no problems
with elses on loops:

7.2 The while statement

The while statement is used for repeated execution as long as an
expression is true: 

while_stmt ::= "while" expression ":" suite
["else" ":" suite]

That's straight from http://www.python.org/doc/current/ref/while.html.
If you read the page though, you'll see that their meaning isn't
dwimmery at all. The else block is executed whenever the expression
evaluates to false which could be if there's nothing to iterate over
or just after the last iteration.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Loop controls

[Jonathan Scott Duff]

On Wed, May 01, 2002 at 04:58:27PM +1000, Damian Conway wrote:
> 6. C would seem to fit the bill rather nicely.

I agree, but I'll also toss out a few alternates anyway:

instead
inlieu  
orelse  loop { ... } orelse { ... } reads nicely to me :-)

Of course if we make for, while, and loop raise an exception when they
don't iterate, there's always exception-based non-looping:

{ loop { ... } CATCH when NoIter { ... } }  # ;-)

or maybe Larry will figure a way for us to write

loop { ... } when NoIter { ... }

Hmm.  Maybe we've got the empty loop code on the wrong end ...

noiter { ... } loop { ... }

or heck, who needs a keyword anyway?  Just define for, while, and loop
to take an optional second coderef:

loop { ... } { ... nothing to see here ... }

tongue mostly in cheek,

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: gcc backend

[Jeff]

Nick Glencross wrote:
> 
> Has anyone given any thought to a gcc backend for generating parrot
> assembler?
> 
> Even with a partial implementation in place, it would be presumably be
> possible to use much of core C, with the benefits of register
> allocation, optimiser etc.
> 
> Obviously it wouldn't be able to use much of parrot's powerful string
> handling or PMCs though, as C cannot convey these concepts. Of course,
> these could probably be hacked in as pseudo-function calls.
> 
> Any thoughts? Anyone tried?
> 
> Cheers,
> 
> Nick

Hi, Nick. I think that question is covered in the Parrot FAQs. Try
 for more information.
--
Jeff <[EMAIL PROTECTED]>

Re: Loop controls

[Miko O'Sullivan]

Jonathan said:
> I actually think exactly the opposite.  In my mind "otherwise" would
> just be a synonym for "else" so that
>
> loop { ... } else { ... }
> loop { ... } otherwise { ... }
>
> would both be syntactically valid.

I believe that the intention is that they *aren't* synonyms, i.e. they look
similar but are different, leading to confusion.  I imagine people who date
twins sometimes kiss the wrong twin and *that* probably throws an exception.
Same concept.

-Miko

Re: Loop controls

[Jonathan E. Paton]

Jonathan Scott Duff <[EMAIL PROTECTED]> wrote:
> Miko O'Sullivan wrote:
> > Damian said:
> > > 6. C would seem to fit the bill rather nicely.
> > 
> > To me, "otherwise" is a synonym for "else", and that makes it too
> > confusingly similar.  I foresee forever explaining to people the difference
> > between C and C.  I'm not sure if C is popular
> > because it is similar to C, but I think the similarity is a reason
> > *not* to use it.

I don't care about the similarity in meaning, the visual distinction would be
nice though.

> I actually think exactly the opposite.  In my mind "otherwise" would
> just be a synonym for "else" so that 
> 
>   loop { ... } else { ... }
>   loop { ... } otherwise { ... }
> 
> would both be syntactically valid.  We would just encourage people to
> use the "otherwise" version for understandability.  Since there's no
> difference between them, there's nothing to explain there, thus no
> confusion.

This now becomes confusing (to me):

if ($foo = 'bar') {
loop {
...
}
else {
...
}

}

and this insane:

loop {
   ...
}
else {
   ...
} if ...;

Where if you intent say the normal 1-3 times then it might be VERY confusing to see 
mixed
conditionals and loops.  I think the fall through (currently mumbled as 'otherwise') 
should be a
different keyword to make it visually distinct.  I suspect Larry has the solution.

Anyone who hasn't seen virtually impossible to avoid intents to the 6th (or 
thereabouts) level
should email me for a sample.  The Games::Golf, _unix_capture() method has them 
because it's
combining signals (requiring double eval), IPC::Open3 and limits (on output length, 
time etc).  I
should make this a plea for a bugfix team, it's riddled with them. ;-)

However, the currect interface for IO::Select and this loop/otherwise type construct 
would be
great fun.  Whenever it's included, can someone please travel back in time and put in 
into Perl 5,
please?

> Hmm.  I wonder why the python community (apparently) have no problems
> with elses on loops:

I hazard a guess that facist whitespace rules have something to do with it.

Jonatha Paton

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: Loop controls

[Dave Mitchell]

In the true sprirt of perverseness, why not make loops into functions that
return the number of iterations taken. Then you can have

loop {

}
or die "loop not taken\n";

;-)


-- 
A walk of a thousand miles begins with a single step...
then continues for another 1,999,999 or so.

Re: gcc backend

[Tim Bunce]

On Wed, May 01, 2002 at 10:09:11AM -0400, Jeff wrote:
> Nick Glencross wrote:
> > 
> > Has anyone given any thought to a gcc backend for generating parrot
> > assembler?
> > 
> > Even with a partial implementation in place, it would be presumably be
> > possible to use much of core C, with the benefits of register
> > allocation, optimiser etc.
> > 
> > Obviously it wouldn't be able to use much of parrot's powerful string
> > handling or PMCs though, as C cannot convey these concepts. Of course,
> > these could probably be hacked in as pseudo-function calls.
> > 
> > Any thoughts? Anyone tried?
> 
> Hi, Nick. I think that question is covered in the Parrot FAQs. Try
>  library x> for more information.

I don't think licening issues should prevent any particular avenue
being explored by anyone interested in it, so long as they understand
the implications (in terms of what would/wouldn't be accepted into
the Parrot distribution). The FAQ should probably say as much.

I'm not sure what the licening issues would be in this case anyway.

Being able to target any gcc suported language to parrot sure seems
like a good idea to me. In theory at least. If only for random
experimentaion and stress testing of parrot.

Tim.

Re: Loop controls

[Marius Nita]

On Wed, May 01, 2002 at 04:14:49PM +0100, Dave Mitchell wrote:
> In the true sprirt of perverseness, why not make loops into functions that
> return the number of iterations taken. Then you can have
> 
> loop {
>   
> }
> or die "loop not taken\n";
> 
> ;-)

Right. This was my initial idea; the else/otherwise stuff is too confusing as
it hints too strongly to if blocks. So

  loop { ... } or print "Sorry\n";
  
  loop {
  ...
  }
  or {
  print "Sorry\n";
  # do other stuff
  }

  loop { ... } and print "Done\n";

The point is that it gives you the option to easily do something after the
loop with the knowledge of whether the loop failed or succeeded, and it makes
more grammatical sense, too. (loop/else doesn't.)

>:)
marius.

> -- 
> A walk of a thousand miles begins with a single step...
> then continues for another 1,999,999 or so.

Re: Loop controls

[Allison Randal]

On Wed, May 01, 2002 at 09:03:42AM -0500, Jonathan Scott Duff wrote:
> 
> Hmm.  I wonder why the python community (apparently) have no problems
> with elses on loops:
> 
> 7.2 The while statement
> 
>   The while statement is used for repeated execution as long as an
>   expression is true: 
>   
>   while_stmt ::= "while" expression ":" suite
>   ["else" ":" suite]
> 
> That's straight from http://www.python.org/doc/current/ref/while.html.
> If you read the page though, you'll see that their meaning isn't
> dwimmery at all. The else block is executed whenever the expression
> evaluates to false which could be if there's nothing to iterate over
> or just after the last iteration.

If you abstract the meaning of C to "execute when the condition in
the previous block is false" this makes perfect sense. It's just not
very useful. This is actually a good reason for Perl to use a different
keyword than "else" with loops. You avoid that interpretation entirely.
You also avoid totally annoying Pythonists who occasionally use (and
might be converted to) Perl. :)

Allison

Re: Loop controls

[Allison Randal]

On Wed, May 01, 2002 at 04:22:29PM +1000, Damian Conway wrote:
> 
> NAME
> Acme::Don't - The opposite of `do'
> 
> DESCRIPTION
  ...
> 
> Note that the code in the `don't' block must be syntactically valid
> Perl. This is an important feature: you get the accelerated performance
> of not actually executing the code, without sacrificing the security of
> compile-time syntax checking.

Um... I know it's scary, but I can actually imagine using this (or
something like this) in development. I'll occasionally work on a section
of code I'm not ready to integrate yet. It would be nice to be able to
syntax check it without uncommenting and re-commenting the whole thing.
:)

Allison

Re: Loop controls

[Melvin Smith]

At 11:44 AM 5/1/2002 -0500, Allison Randal wrote:
>On Wed, May 01, 2002 at 04:22:29PM +1000, Damian Conway wrote:
> >
> > NAME
> > Acme::Don't - The opposite of `do'
> >
> > DESCRIPTION
>   ...
> >
> > Note that the code in the `don't' block must be syntactically valid
> > Perl. This is an important feature: you get the accelerated performance
> > of not actually executing the code, without sacrificing the security of
> > compile-time syntax checking.
>
>Um... I know it's scary, but I can actually imagine using this (or
>something like this) in development. I'll occasionally work on a section
>of code I'm not ready to integrate yet. It would be nice to be able to
>syntax check it without uncommenting and re-commenting the whole thing.
>:)

Doesn't if(0) do the job? :)

-Melvin

Re: Loop controls

[Allison Randal]

On Wed, May 01, 2002 at 12:53:39PM -0400, Melvin Smith wrote:
> At 11:44 AM 5/1/2002 -0500, Allison Randal wrote:
> >
> >Um... I know it's scary, but I can actually imagine using this (or
> >something like this) in development. I'll occasionally work on a section
> >of code I'm not ready to integrate yet. It would be nice to be able to
> >syntax check it without uncommenting and re-commenting the whole thing.
> >:)
> 
> Doesn't if(0) do the job? :)

Yes, as does C, and I've used them, though usually only when I
eventually plan on putting in a real condition later. They don't stand
out from the regular flow of control very well. C would.

No. I don't think we need C. I'm *not* saying that. I'm just
having fun with the idea. :)

Allison

Re: Loop controls

[Aaron Sherman]

On Wed, 2002-05-01 at 08:27, Miko O'Sullivan wrote:
> Damian said:
> > 6. C would seem to fit the bill rather nicely.
> 
> 
> To me, "otherwise" is a synonym for "else", and that makes it too
> confusingly similar.  I foresee forever explaining to people the difference
> between C and C.  I'm not sure if C is popular
> because it is similar to C, but I think the similarity is a reason
> *not* to use it.
> 
> How about C?  It's absolutely clear what it means and won't be
> confused with "else".

Call it "maxheadroom" for all it will matter.

* people will still see conditional execution associated with loops
* the unless/elsif syntax is still grotesque and asymmetric
* the treatment of conditionals{1} vs conditionals{1,} is asymmetric

If you un-peel this and expose the elegant simplicity of flow control,
you can unify all of these concepts to their basic form:

flowcontrol:
controlblock |
controlblock TOK_else flowcontrol |
controlblock TOK_else block
;
controlblock:
controlword expression closure |
controlword expression block |
TOK_loop block |
TOK_loop expression ';' expression ';' expression block
;
controlword:
TOK_if |
TOK_unless |
TOK_while |
TOK_until |
TOK_for |
TOK_when
;
block: '{' statements '}' ;
closure: mumble... ;
expression: mumble... ;
statements: mumble... ;

I haven't really thought about this representation of the grammar much,
and I'm not grammar constructor by nature, but you can see the idea
here, and the stark simplicity of it.

What is so lovely about "elsif" that we cling to it, and mutate the
admittedly "obvious" choices elsewhere to preserve it?

Re: // in Perl 5.8?

[David Wheeler]

On 4/17/02 10:02 PM, "Brent Dax" <[EMAIL PROTECTED]> claimed:

> I'm working on a preliminary version right now.  So far it's been
> surprisingly easy--touches toke.c, perly.y, opcode.pl, pp.c, and
> pp_hot.c.  (Of course, it's also off an old bleadperl, but I doubt those
> files change that actively.)

I'm not a p5p, so I was wondering how this was going. I expect it won't go
into 5.8.0, eh?

Regards,

David 

-- 
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/  Yahoo!: dew7e
   Jabber: [EMAIL PROTECTED]

Re: Loop controls

[Aaron Sherman]

On Wed, 2002-05-01 at 12:22, Allison Randal wrote:
> On Wed, May 01, 2002 at 09:03:42AM -0500, Jonathan Scott Duff wrote:
[... in python ...]
> > while_stmt ::= "while" expression ":" suite
> > ["else" ":" suite]
> > 
> > That's straight from http://www.python.org/doc/current/ref/while.html.

> If you abstract the meaning of C to "execute when the condition in
> the previous block is false" this makes perfect sense. It's just not
> very useful. This is actually a good reason for Perl to use a different
> keyword than "else" with loops. You avoid that interpretation entirely.
> You also avoid totally annoying Pythonists who occasionally use (and
> might be converted to) Perl. :)

So, the Python while is the Perl6:

loop {
if () {

} else {

last;
}
}

This is not shocking at all, as Python does not dip into the
polymorphism of containers nearly so much as Perl does. To Python,
evaluating the "truth" of a sequence of this type requires there to be a
truth already present. In this case, the truth of the last evaluation of
the expression suffices.

Perl is fundamentally different in its approach and just as a Pythoner
will have to swallow hard and squint to understand other polymorphic and
context-sensitive aspects of Perl containers, so too will they have to
get over this distinction.

I'm not slighting Python here. I'm just saying that there's a learning
curve fraught with dangerous similarities in both directions, and
constructing Perl to accommodate that transition does not seem to be
particularly wise.

RE: // in Perl 5.8?

[Brent Dax]

David Wheeler:
# On 4/17/02 10:02 PM, "Brent Dax" <[EMAIL PROTECTED]> claimed:
# 
# > I'm working on a preliminary version right now.  So far it's been 
# > surprisingly easy--touches toke.c, perly.y, opcode.pl, pp.c, and 
# > pp_hot.c.  (Of course, it's also off an old bleadperl, but I doubt 
# > those files change that actively.)
# 
# I'm not a p5p, so I was wondering how this was going. I 
# expect it won't go into 5.8.0, eh?

It's far too late to make it into 5.8, but it looks like it'll be in
5.10 when that comes out (in a year or two).

--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

blink:  Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification

Re: // in Perl 5.8?

[David Wheeler]

On 5/1/02 12:11 PM, "Brent Dax" <[EMAIL PROTECTED]> claimed:

> It's far too late to make it into 5.8, but it looks like it'll be in
> 5.10 when that comes out (in a year or two).

I figured. Too bad. ;-) A year or two is long time to wait!

Regards,

David
-- 
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/  Yahoo!: dew7e
   Jabber: [EMAIL PROTECTED]

Re: // in Perl 5.8?

[Mark J. Reed]

On Wed, May 01, 2002 at 12:11:58PM -0700, Brent Dax wrote:
> It's far too late to make it into 5.8, but it looks like it'll be in
> 5.10 when that comes out (in a year or two).
.. . . by which time 6.0 will have already been released, right?

Right?


-- 
Mark J. REED<[EMAIL PROTECTED]>

RE: // in Perl 5.8?

[Brent Dax]

Mark J. Reed:
# On Wed, May 01, 2002 at 12:11:58PM -0700, Brent Dax wrote:
# > It's far too late to make it into 5.8, but it looks like 
# it'll be in 
# > 5.10 when that comes out (in a year or two).
# .. . . by which time 6.0 will have already been released, right?
# 
# Right?

*bites back sarcastic comment about the pace of Perl 6's development*

--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

blink:  Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification

Re: // in Perl 5.8?

[Graham Barr]

On Wed, May 01, 2002 at 12:17:52PM -0700, David Wheeler wrote:
> On 5/1/02 12:11 PM, "Brent Dax" <[EMAIL PROTECTED]> claimed:
> 
> > It's far too late to make it into 5.8, but it looks like it'll be in
> > 5.10 when that comes out (in a year or two).
> 
> I figured. Too bad. ;-) A year or two is long time to wait!

Well if the patch maintains binary compatability, I dont
see why it would not go into 5.8.1. But who knows when that will be.

Graham.

Re: Loop controls

[Allison Randal]

On Wed, May 01, 2002 at 02:47:56PM -0400, Aaron Sherman wrote:
> On Wed, 2002-05-01 at 12:22, Allison Randal wrote:
> 
> > You also avoid totally annoying Pythonists who occasionally use (and
> > might be converted to) Perl. :)
> 
> ... 
> 
> Perl is fundamentally different in its approach and just as a Pythoner
> will have to swallow hard and squint to understand other polymorphic
> and context-sensitive aspects of Perl containers, so too will they
> have to get over this distinction.
> 
> I'm not slighting Python here. I'm just saying that there's a learning
> curve fraught with dangerous similarities in both directions, and
> constructing Perl to accommodate that transition does not seem to be
> particularly wise.

Yes, accommodating Pythonies is not a good primary reason for using a
different keyword. But it's a nice side benefit of what seems to be the
best option (so far) for independent reasons (Damian's post summed up
and solidified the discussion quite nicely).

Allison

Re: // in Perl 5.8?

[Allison Randal]

On Wed, May 01, 2002 at 01:04:10PM -0700, Brent Dax wrote:
> 
> *bites back sarcastic comment about the pace of Perl 6's development*

*fails to squelch reply about the survival rate of prematurely birthed
babies*

Some things just take time.

RE: // in Perl 5.8?

[Brent Dax]

Graham Barr:
# On Wed, May 01, 2002 at 12:17:52PM -0700, David Wheeler wrote:
# > On 5/1/02 12:11 PM, "Brent Dax" <[EMAIL PROTECTED]> claimed:
# > 
# > > It's far too late to make it into 5.8, but it looks like 
# it'll be in 
# > > 5.10 when that comes out (in a year or two).
# > 
# > I figured. Too bad. ;-) A year or two is long time to wait!
# 
# Well if the patch maintains binary compatability, I dont
# see why it would not go into 5.8.1. But who knows when that will be.

I thought they don't introduce new features in point releases...

--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

blink:  Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification

RE: // in Perl 5.8?

[Brent Dax]

Allison Randal:
# On Wed, May 01, 2002 at 01:04:10PM -0700, Brent Dax wrote:
# > 
# > *bites back sarcastic comment about the pace of Perl 6's 
# development*
# 
# *fails to squelch reply about the survival rate of prematurely birthed
# babies*
# 
# Some things just take time.

I know, and I'm not complaining.  I'm just saying that that will
probably give Perl 5 at least a year or two more life.

--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)

blink:  Text blinks (alternates between visible and invisible).
Conforming user agents are not required to support this value.
--The W3C CSS-2 Specification

Re: // in Perl 5.8?

[Graham Barr]

On Wed, May 01, 2002 at 01:53:24PM -0700, Brent Dax wrote:
> Graham Barr:
> # On Wed, May 01, 2002 at 12:17:52PM -0700, David Wheeler wrote:
> # > On 5/1/02 12:11 PM, "Brent Dax" <[EMAIL PROTECTED]> claimed:
> # > 
> # > > It's far too late to make it into 5.8, but it looks like 
> # it'll be in 
> # > > 5.10 when that comes out (in a year or two).
> # > 
> # > I figured. Too bad. ;-) A year or two is long time to wait!
> # 
> # Well if the patch maintains binary compatability, I dont
> # see why it would not go into 5.8.1. But who knows when that will be.
> 
> I thought they don't introduce new features in point releases...

Who is they ?

I am sure I did in 5.005_03 and I think 5.6.1 did also.

Graham.

Re: Loop controls

[Miko O'Sullivan]

Damian said:
> The C block can't decide whether to execute until
> it knows whether the loop is going to iterate again. And it can't
> know *that* until it has evaluated the condition again. At which
> point, the $filename variable has the wrong value. :-(
>
> The example is a little contrived perhaps, but it might be a common
> problem.

I don't think your example is contrived at all.  It's just a situation where
a little
education is all that's needed.  The rule could be quite simple: BETWEEN is
run before every iteration except for the first iteration.  Any variables
that you
use in BETWEEN are for the iteration that is about to run, not the iteration
that
just ran.  Once people gt that concept things become clear.

However, it was because of your conundrum that I first proposed that
C (not C) is put after the loop.  To me that makes it
absolutely clear that between isn't part of any one iteration:

  while whatever() {
 ...
  }

  between {
...
  }


I should admit, however, that this thread has made me prefer BETWEEN inside
the block.  It keeps open the possibility of loops becoming part of if-elsif
chains, even if it's not the choice to allow that right now.

-Miko

Re: Loop controls

[Aaron Sherman]

I now realize that my previous message was a little hard to read (plus I
sounded a bit harsh, which I did not mean to be, I was just excited,
thinking about this), because I insisted on being sort of stilted in my
pseudo-BNF. Here's a cleaner shot at what I meant:

flow:
control 'else' flow |
control 'else' block |
control ;
control:
controlkey expr '->' closuredef |
controlkey expr block |
'loop' block |
'loop' expr ';' expr ';' expr block ;
controlkey:
'if' | 'unless' | 'while' | 'until' | 'for' | 'when' ;
block: '{' statements '}'

That should be a bit easier to appreciate. I find myself looking at this
and loving Perl just a little bit more

Again, my example from before:

unless my $fh = $x.open {
die "Cannot open $x: $!";
} else while $fh.getline -> $_ {
print;
} else {
die "No lines to read in $x";
}

That does seem to roll of the tongue, does it not?

Re: jvm.ops

[Dan Sugalski]

At 9:52 AM +0100 5/1/02, Leon Brocard wrote:
>Cute, huh? Of course, Java interpreters are very optimised (and
>non-dynamic) and without JITs doing it in Parrot is about 6 times
>slower, but it's interesting nevertheless. Is this the kind of thing I
>should be doing? I've attached a fledgling jvm.ops. Does my C code
>look ok?

I like it, it looks good, and I'm having very scary thoughts about 
Java and Parrot. Thoughts like: "How about we build Java method call 
shims so Java cna call Parrot and vice versa?" or "How about we 
emulate the JNI interface and use native libs built for Java?" And, 
of course, I'm having similar thoughts about .NET now...

Being able to do this would give us a pretty significant leg up in 
terms of library code, if it works.
-- 
 Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
   teddy bears get drunk

[APPLIED] Re: First patch to memory allocation routines

[Steve Fink]

I've applied this patch, along with fixing the original resources.c's
indentation (re-indenting patches are annoying, but this patch touched
enough of resources.c files that it seemed like a golden opportunity.)

Re: [APPLIED] Re: First patch to memory allocation routines

[Josh Wilmes]

At 15:58 on 05/01/2002 PDT, Steve Fink <[EMAIL PROTECTED]> wrote:

> I've applied this patch, along with fixing the original resources.c's
> indentation (re-indenting patches are annoying, but this patch touched
> enough of resources.c files that it seemed like a golden opportunity.)

Here are some additional formatting fixes on top of what you've already 
done (which cleaned up the majority of the problems)

(These are based on run_indent.pl's suggestions, with some tweaking)

Index: resources.c
===
RCS file: /cvs/public/parrot/resources.c,v
retrieving revision 1.49
diff -u -r1.49 resources.c
--- resources.c 1 May 2002 22:55:21 -   1.49
+++ resources.c 1 May 2002 23:13:17 -
@@ -17,7 +17,7 @@
 /* Create a new free pool */
 static struct free_pool *
 new_free_pool(struct Parrot_Interp *interpreter, size_t entries,
-  void (*replenish)(struct Parrot_Interp *, struct free_pool*))
+  void (*replenish)(struct Parrot_Interp *, struct free_pool *))
 {
 struct free_pool *pool;
 size_t temp_len;
@@ -43,7 +43,7 @@
 void **temp_ptr;
 
 /* First, check and see if there's enough space in the free pool. If
- we're within the size of a pointer, we make it bigger */
+ * we're within the size of a pointer, we make it bigger */
 if (pool->entries_in_pool * sizeof(void *) >=
 pool->pool_buffer.buflen - sizeof(void *)) {
 /* If not, make the free pool bigger. We enlarge it by 20% */
@@ -68,10 +68,9 @@
  * If the pool is still empty, call the replenishment function
  */
 static void *
-get_from_free_pool(struct Parrot_Interp *interpreter,
-   struct free_pool *pool)
+get_from_free_pool(struct Parrot_Interp *interpreter, struct free_pool *pool)
 {
-void ** ptr;
+void **ptr;
 
 if (!pool->entries_in_pool) {
 Parrot_do_dod_run(interpreter);
@@ -132,13 +131,15 @@
 
 /* We have no more headers on the free header pool. Go allocate more
and put them on */
-static void alloc_more_pmc_headers(struct Parrot_Interp *interpreter,
+static void
+alloc_more_pmc_headers(struct Parrot_Interp *interpreter,
struct free_pool *pool)
 {
 Parrot_new_pmc_header_arena(interpreter);
 }
 
-PMC *new_pmc_header(struct Parrot_Interp *interpreter)
+PMC *
+new_pmc_header(struct Parrot_Interp *interpreter)
 {
 PMC *return_me;
 
@@ -164,16 +165,18 @@
 return return_me;
 }
 
-void free_pmc(PMC *pmc)
+void
+free_pmc(PMC *pmc)
 {
 if (pmc) {
 memset(pmc, 0, sizeof(PMC));
 }
 }
 
-Buffer *new_tracked_header(struct Parrot_Interp *interpreter, size_t size)
+Buffer *
+new_tracked_header(struct Parrot_Interp *interpreter, size_t size)
 {
-UNUSED (interpreter);
+UNUSED(interpreter);
 return (Buffer *)mem_sys_allocate(size);
 }
 
@@ -226,7 +229,7 @@
 Buffer *return_me;
 
 /* Icky special case. Grab system memory if there's no interpreter
-   yet */
+ * yet */
 if (interpreter == NULL) {
 return_me = mem_sys_allocate(sizeof(Buffer));
 return_me->flags = BUFFER_live_FLAG;
@@ -246,7 +249,8 @@
 return return_me;
 }
 
-void free_buffer(Buffer *thing)
+void
+free_buffer(Buffer *thing)
 {
 if (thing) {
 if (thing->bufstart && (thing->flags & BUFFER_sysmem_FLAG)) {
@@ -319,8 +323,8 @@
 mark_used(PMC *used_pmc, PMC *current_end_of_list)
 {
 /* If the PMC we've been handed has already been marked as live
-   (ie we put it on the list already) we just return. Otherwise we
-   could get in some nasty loops */
+ * (ie we put it on the list already) we just return. Otherwise we
+ * could get in some nasty loops */
 if (used_pmc->next_for_GC) {
 return current_end_of_list;
 }
@@ -343,14 +347,14 @@
 trace_active_PMCs(struct Parrot_Interp *interpreter)
 {
 PMC *last, *current, *prev; /* Pointers to the last marked PMC, the
-   currently being processed PMC, and in
-   the previously processed PMC in a loop. */
+ * currently being processed PMC, and in
+ * the previously processed PMC in a loop. */
 unsigned int i, j, chunks_traced;
 Stack_chunk *cur_stack, *start_stack;
 struct PRegChunk *cur_chunk;
 
 /* We have to start somewhere, and the global stash is a good
-   place */
+ * place */
 last = current = interpreter->perl_stash->stash_hash;
 
 /* mark it as used and get an updated end of list */
@@ -358,7 +362,7 @@
 
 /* Now, go run through the PMC registers and mark them as live */
 /* First mark the current set. */
-for (i=0; i < NUM_REGISTERS; i++) {
+for (i = 0; i < NUM_REGISTERS; i++) {
 if (interpreter->pmc_reg.registers[i]) {
 last = mark_used(interpreter->pmc_reg.registers[i], last);
 }
@@ -369,40 +373,40 @@
 for (cur_chunk =

Re: Loop controls

[Allison Randal]

On Wed, May 01, 2002 at 05:08:14PM -0400, Miko O'Sullivan wrote:
> Damian said:
> > The C block can't decide whether to execute until
> > it knows whether the loop is going to iterate again. And it can't
> > know *that* until it has evaluated the condition again. At which
> > point, the $filename variable has the wrong value. :-(
> >
> > The example is a little contrived perhaps, but it might be a common
> > problem.
> 
> I don't think your example is contrived at all. It's just a situation
> where a little education is all that's needed. The rule could be quite
> simple: BETWEEN is run before every iteration except for the first
> iteration. Any variables that you use in BETWEEN are for the iteration
> that is about to run, not the iteration that just ran. Once people gt
> that concept things become clear.

You know, I almost made a very similar reply. But I read through
Damian's message a second time and changed my mind. C makes
sense as a C minus C. As a C minus C it's less
appealing. At the very least it begs a different name than "BETWEEN" (a
name that implies it executes "between" each loop, not at the beginning
of some).

Hmmm... would C not have the same problem as C? It also
"can't decide whether to execute until it knows whether the loop is
going to iterate again". 

Allison

need help with entry form?

[frank crowley]

i've made this entry form for the dungeons and dragons
game. it works as far as sending by email, but the
problem is that the stuff that you click on or type in
from the 3rd line of the form does not show up when
you click to send the results by email. please help me
in fixing this entry form to have it all be sent and
not partial. thanks.
 


MONSTER SUBMIT FORM


 






   
 
  
Creature name 
  

 Creature type 
  
aberration 
animal 
beast 
construct 
dragon 
elemental 
fey 
giant 
humanoid 
magical beast

monstrous humanoid 
ooze 
outsider 
plant 
shapechanger 
undead 
vermin 
  
  Creature size 
  
Colossal - 64
ft. or more (Moby Dick) 
Gargantuan -
32-64 ft. (Whale) 
Huge - 16-32 ft.
(Elephant/Giraffe) 
Large - 8-16 ft.
(Gorilla/Horse) 
Medium-size - 4-8 ft. (Human/Pony) 
Small - 2-4 ft.
(Halfling/Coyote) 
Tiny - 1-2 ft. (Cat)

Diminutive - 6
in. to 1 ft. (Toad) 
Fine - 6 in. or less
(Housefly) 
  

  

  
   
 Type of attacks 
  
 
  
  Bite 
  
  Claw 
  
  Slam
 
  
  Gore 
  
  Tail 
  
  Sting
 
  
  
  

Weapons
 
  
  
  

  

  
   
 
  Type of movement
  
 
  
  Landbound 
  
  Burrow 
  
  Climb
 
  
  Fly 
  
  Swim 
  
  Special 
  
   

  
   
 
  
Natural armor class bonus 
  
0 (Human) 
+1 (Chimera) 
+2 (Centaur) 
+3 (Shark) 
+4 (Gargoyle) 
+5 (Displacer Beast) 
+6 (Boar) 
+7 (Umber Hulk) 
+8 (Wyvern) 
+9 (Water Elemental) 
+10 (Earth Elemental) 
+11 (Stone Giant) 
+12 (Cloud Giant) 
+13 (Elder Xorn) 
+14 (Elder Tojanida) 
+15 (Astral Deva) 
+16 (Nightwalker) 
+17 (Hezrou) 
+18 (Stone Golem) 
+19 (Planetar) 
+20 (Balor) 
+22 (Iron Golem) 
+23 (Mature Adult Blue
Dragon) 
+24 (Mature Adult Red
Dragon) 
+25 (Old Green Dragon)

+26 (Old Blue Dragon) 
+27 (Old Red Dragon) 
+28 (Very Old Green
Dragon) 
+29 (Very Old Blue
Dragon) 
+30 (Tarrasque) 
+40 (Great Wrym Gold
Dragon) 
  

 Alignment 
  
Always 
Usually 
Often 
  
  
Lawful Good 
Neutral Good 
Chaotic Good 
Lawful
Neutral 
Neutral 
Chaotic
Neutral 
Lawful Evil 
Neutral Evil 
Chaotic Evil 
  

  

  
   
 
  Climate/Terrain
  
 
  
  Any 
  
  Cold 
  
  Temperate 
  
  Warm
 
  
  Land 
  
  Aquatic 
  
  Desert 
  
  Plains 
  
  Forest
 
  
  Astral 
  
  Hell 
  
  Hills 
  
  Mountain 
  
  Marsh 
  
  Underground 
  
   

  
   
 
  Organizations
  
1 
  
Solitary 
  
  

 2 
  
None 
Pair 
Brace 
  
  

 2-5 
  
None 
Bevy 
Brood 
Bunch 
Cluster 
Company 
Covey 
Crew 
Family 
Gang 
String 
Team 
  
  

 5-20 
  
None 
Colony 
Nest 
Ride 
Knot 
Pack 
Pod 
Pride 
Squad 
Swarm 
Patrol 
  
  

 20-40 
  
None 
Band 
Drove 
Flight 
Flotillia 
Herd 
Mob 
Platoon 
School 
Troop 
  
  

 40-60 
  
None 
Battalion 
 

Re: [APPLIED] Re: First patch to memory allocation routines

[Steve Fink]

On Wed, May 01, 2002 at 07:15:18PM -0400, Josh Wilmes wrote:
> 
> At 15:58 on 05/01/2002 PDT, Steve Fink <[EMAIL PROTECTED]> wrote:
> 
> > I've applied this patch, along with fixing the original resources.c's
> > indentation (re-indenting patches are annoying, but this patch touched
> > enough of resources.c files that it seemed like a golden opportunity.)
> 
> Here are some additional formatting fixes on top of what you've already 
> done (which cleaned up the majority of the problems)
> 
> (These are based on run_indent.pl's suggestions, with some tweaking)

Applied, thanks.

(I've always wanted to say that.)