vote no - Re: Unicode operators [Was: Re: UTF-8 and Unicode FAQ, demos]

[David Dyck]

The first message had many of the following characters viewable in my
telnet window, but the repost introduced a 0xC2 prefix to the 0xA7 character.

I have this feeling that many people would vote against posting all these
funny characters, as is does make reading the perl6 mailing lists difficult
in some contexts.  Ever since introducing these UTF-8  > 127 characters
into this mailing list, I can never be sure of what the posting author
intended to send.  I'm all for supporting UTF-8 characters in strings,
and perhaps even in variable names but to we really have to have
perl6 programs with core operators in UTF-8.  I'd like to see all
the perl6 code that had UTF-8 operators start with  use non_portable_utf8_operators.

As it stands now, I'm going to have to find new tools for my linux platform
that has been performing fine since 1995 (perl5.9 still supports libc5!),
and I don't yet know how I am
going to be able to telnet in from win98, and I'll bet that the dos kermit that I
use when I dial up won't support UTF-8 characters either.

 David

ps.

I just read how many people will need to upgrade their operating systems
if the want to upgrade to MS Word11.

Do we want to require operating system and/or many support tools to
be upgraded before we can share perl6 scripts via email?


On Tue, 5 Nov 2002 at 09:56 -0800, Michael Lazzaro <[EMAIL PROTECTED]:

> > CodeSymbol  Comment
> > 167 §  Could be used
> > 169 ©  Could be used
> > 171 «  May well be used
> > 172 ¬  "Not"?
> > 174 ®  Could be used
> > 176 °  Could be used
> > 177 ±  Introduces an interesting level of uncertainty?  Useable
> > 181 µ  Could be used
> > 182 ¶  Could be used
> > 186 º  Could be used (but I dislike it as it is alphabetic)
> > 187 »  May well be used
> > 191 ¿  Could be used

[CVS ci] string_set is back for a faster live - not only

[Leopold Toetsch]

As suggested by Brent, string_set gives us a big improvement, where 
strings are heavily used. One examples is life.pasm, where the generate 
loop does:

	substr S0, S15, I3, 1

~10^6 times. Till now, S0 (the result of substr) was constructed every 
time, now it get's just reused.
This improves life generations from 400/370 to both 587 for GC/malloc 
allocators.

string_set is currently only used in string_substr, but, when people are 
ok with this, can be used everywhere in core.ops, where a string 
register is globbered.

set S0, S1  { $1 = $2 }

would become string_set(interpreter, $1, $2)

leo

Re: [perl #18219] on_exit not portable

[Leopold Toetsch]

Josh Wilmes wrote:



I agree.   However, the point is fairly moot..  If we're going to do a 
Parrot_on_exit, it's just as easy to provide our own Parrot_exit and not 
need atexit() either.. it's not like atexit() is giving us much at that 
point.


 which would mean, that internal_exception needs an Parrot_interp* 
argument - which it will need anyway to do something useful finally.


--Josh



leo

This weeks Perl 6 summary

[Piers Cawley]

The Perl 6 Summary for the week ending 20021103
Welcome to the latest of the ongoing series of Perl 6 summaries, in
which your arrogant moderator does battle with the forces of prolixity
in a Brobdingnagian attempt to tame the tortuously tangled threads of
Perl 6's design and development mailing lists. And if I keep up the
purple prose at that rate it'll *still* be clearer than the tangle that
is this week's perl6-language discussion.

However, because it's customary, and because the language list scares
me, we'll start with the comparatively tame perl6-internals.

  Fun with file formats
Toward the end of last week, Rhys Weatherley had asked about being able
to insert arbitrary chunks of metadata into parrot bytecode files. Dan
ended up producing a `draft sketch' of the bytecode generation
facilities and the ability to add arbitrary chunks of metadata was
conspicuous by its absence. People didn't seem to be happy about this,
lamenting a lack of flexibility, both in the overall file structure and
in what one could stick into the bytecode. Dan mounted a sturdy defence,
pointing out that we want `a file format that does what we need it
to--present executable bytecode data to the interpreter--as fast as
possible. Everything else is secondary to that.'

Kv Org wondered if it would be a good idea to worry about sandbox issues
in the bytecode format, but nothing came of that question. Well, not
this week anyway.

http://makeashorterlink.com/?S1F442C52

http://makeashorterlink.com/?V20551C52

http://makeashorterlink.com/?H21513C52

http://makeashorterlink.com/?H22541C52

  Portable linking issues

Andy Dougherty is having portability problems. He wants to portably
compile and link 3 files and he wondered what was the best to get an
early test compiled properly on all platforms. Help was supplied, the
build was fixed, and the world remained safe for democracy. (Modulo a
few local difficulties.)

http://makeashorterlink.com/?Q23532C52

  Implicit stack direction probe
Meanwhile, Jason Gloudon's patch to move the stack direction probe back
to initialization time rather that compile time was offered. I'm
assuming that Nicholas Clark's suggested speedup trick from last week
was implemented as part of it, but I'm no great understander of C.

http://makeashorterlink.com/?R54532C52

  Of MOPS and Microops
There's been some discussion of granting a small number of Parrot
registered 'most favoured' status. The idea being that a small number of
registers would actually be held in global (possibly real register)
variables, with the rest being accessed through via indirection through
the interpreter. Apparently the JIT core already does some optimization
along these lines, and Dan doesn't seem to be sure that doing it for the
main interpreter would actually be much of win. Discussion continues.

http://makeashorterlink.com/?L55521C52

  Very complete lexical scopes
Jonathan Sillito has submitted a patch which `implements a very complete
set of lexical scope semantics'. It looks pretty cool to my untutored
eye. General response was positive, though Jürgen Bömmels did have a
query about how to create a new scope.

http://makeashorterlink.com/?W26514C52

  miniparrot, a first attempt
If you've been paying attention to the Parrot build process, you'll be
aware that it was always a goal to use a cut down variant of parrot
itself to run the configuration tests. The plan is that this miniparrot
should be buildable with nothing more than an ANSI compliant C compiler.
Josh Wilmes thinks we're about ready to start building said miniparrot,
and offered his first cut to the list. Response was positive, with
quibbles, which is about what one would expect.

http://makeashorterlink.com/?W37512C52

Meanwhile, over in perl6-language (or "The Horror! The Horror!")
The dreaded `Operator Reshuffle' thread continues apace -- of the 450
posts last week I'd say about 400 of 'em were discussing various aspects
of this. Bear in mind too that the path of discussion could be described
as helical (sort of like circular, but getting more and more wound up
with each go 'round). There are at least two factions involved, roughly
caricatured as `Simon Cozens vs. The Rest of the World'. Simon can be
thought of as the voice of conservatism (or Reason, depending on whether
you agree with him or not), generally arguing against stuff he considers
massively ugly or confusing. Simon's allies vary depending on which
issue he's discussing and his worries include:

*   Perl 6 is going to be even harder to parse than Perl 5

*   Unicode operators in the core language are Just Wrong. Lots of
people agree with him on this.

*   Superpositional operators will be too rare to justify giving 

Re: This weeks Perl 6 summary

[Simon Cozens]

[EMAIL PROTECTED] (Piers Cawley) writes:
> *   Superpositional operators will be too rare to justify giving them
> precious one character operators.

I don't think I think that they'd be too rare. (I think) But I do
think that we're overinflating their importance. Changing the way
people think about programming is all well and good, and I can honestly
see the advantages behind
   if ($a == 1|2|3) { 
but I think the problem is that it's going too far out in a familiar context.
Unfamiliar things should be so marked.

-- 
Um. There is no David conspiracy. Definitely not. No Kate conspiracy either.
No. No, there is definitely not any sort of David conspiracy, and we are
definitely *not* in league with the Kate conspiracy. Who doesn't exist. And
nor does the David conspiracy. No. No conspiracies here. - Thorfinn, ASR

Re: [PATCH?] default char type

[Leopold Toetsch]

Dan Sugalski wrote:


At 1:18 PM +0200 10/26/02, Leopold Toetsch wrote:


The default chartype (e.g. for string constants in PBC) is currently 
unicode with utf32 encoding.
Can someone comment on this?
In some debug sessions I saw a lot of string_compare -> 
string_transcode   cased by this default.


We should probe and set the default at configure time. For most folks 
currently, it should be USASCII or (perhaps) Latin1. I don't think we 
need to go full-out Unicode to start with, at least not for now. (Though 
I would like to get Unicode and Shift-JIS transcoding, at the least, 
sorted out reasonably soon)

The default chartype is USASCII now.
leo

Re: This weeks Perl 6 summary

[Richard Proctor]

On Wed 06 Nov, Piers Cawley wrote:
>   miniparrot, a first attempt
> If you've been paying attention to the Parrot build process, you'll be
> aware that it was always a goal to use a cut down variant of parrot
> itself to run the configuration tests. The plan is that this miniparrot
> should be buildable with nothing more than an ANSI compliant C
> compiler.

Should this be called budgie? :-)

-- 
Personal [EMAIL PROTECTED]http://www.waveney.org
Telecoms [EMAIL PROTECTED]  http://www.WaveneyConsulting.com
Web services [EMAIL PROTECTED]http://www.wavwebs.com
Independent Telecomms Specialist, ATM expert, Web Analyst & Services

[FYI] life generations

[Leopold Toetsch]

Here some numbers for examples/assembly/life.pasm (generations/sec) on 
my Athlon 800 i386/linux:

 314  24th Sept 2002 CGoto/no optimization
 374  trace_system_stack, lo_var_ptr
 401  string_substr/_compare
 587  string_set

 755  -O3 (except core_ops_cg w/o opt.)
 910  -O3 -g (fast_core)
 997  -O3 -P Prederef
1288  -O3 -j JIT
1740  -O3 native C


Have fun,
leo

Re: [CVS ci] string_set is back for a faster live - not only

[Leopold Toetsch]

Leopold Toetsch wrote:

[ substr in life.pasm ]



~10^6 times. 


10^7



set S0, S1  { $1 = $2 }

would become string_set(interpreter, $1, $2)



Exactly this example is wrong, because here these 2 registers just point 
to the same string.


leo

Re: [CVS ci] string_set is back for a faster live - not only

[Peter Gibbs]

Leopold Toetsch wrote:
> string_set is currently only used in string_substr, but, when people are 
> ok with this, can be used everywhere in core.ops, where a string 
> register is globbered.

The behaviour of the following program has changed, is this correct?

  set S0, "test"
  set S1, S0
  set S2, "another"
  substr S0, S2, 1, 3
  print S1
  print "\n"
  end

-- 
Peter Gibbs
EmKel Systems

Keyword arguments

[Piers Cawley]

So, I was, thinking about the way Common Lisp handles keyword
arguments. It's possible to declare a Lisp function as follows:

(defun make-para ( content &key alignment font size color ) ...)

The point here is that the first argument is dealt with positionally,
and subsequent, optional args are dealth with as keyword arguments. It
seems to me that similar functionality might sit well with Perl 6, but
I'm not sure I can think of a good declaration syntax. Calling syntax
is easy:

make_para $text, font => 'Helvetica,Arial,Whatever';

Any thoughts?

-- 
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?

Re: [CVS ci] string_set is back for a faster live - not only

[Leopold Toetsch]

Peter Gibbs wrote:


Leopold Toetsch wrote:


string_set is currently only used in string_substr, but, when people are 
ok with this, can be used everywhere in core.ops, where a string 
register is globbered.


The behaviour of the following program has changed, is this correct?

  set S0, "test"
  set S1, S0
  set S2, "another"
  substr S0, S2, 1, 3
  print S1
  print "\n"
  end


Yes you are right.

Before:
test
now:
not

The questions are (and this is IMHO the same problem with PMCs):
- set vs assign
- what should this program do

leo

Superpositions and laziness

[Piers Cawley]

It occurred to me that being able to set up 'pure' functions in such a
way that they are lazily evaluated when passed a superposition might
be a win.

And then I got to thinking about what would be required from the
language to allow me to implement this functionality in a module. I am
assuming (for the purposes of this example) that functions will get
called with 'simple' argument lists, no defaulting etc, and a maximum
of one superposed argument...)

class PureFunction is Sub {

  # I'm assuming here that 'apply' is equivalent to func(...)
  method apply(*@arglist) {
my @curry_list;
my $super_arg;
for @arglist; .param_list -> $arg; $param {
  when Superposition { 
die "Too many superposed args" if defined $super_arg;
$super_arg = $arg;
  }
  otherwise {
push @curry_list, ($param.symbol => $arg);
  }
}
  
return FunctionApplication::Superposed
 .new( superposition => $super_arg,
   func => $self.given(*@curry_list) );
}
  }
}

class FunctionApplication::Superposed is Superposition {
  my $.superposition;
  my $.func;
 
  method force ($self is rw:) {
return $self = ($.func($.superposition)).force;
  }
 
  method eigenstates {
.force.eigenstates;
  }
}

method Superposition::force ($self:) { $self }

The idea being that, when you do 

a_pure_func($val1|$val2|$val3)

instead of Perl going away and doing the calculation right away, you
get back a 'special' superposition which stores an 'invocation
description' and calculation is deferred until you need to get a
superposition's list of possible states.

If that were all there were to it of course then there wouldn't be
much gain from doing this, however, consider:

# Ignore duplicates, it's a proof of concept dammit!
method FunctionApplication::Superposed::choose {
  loop {
$.function($.superposition.choose);
CATCH Exception::SuperPositionExhausted { die $@ }
CATCH Exception::ChooseFailure { redo }
otherwise { throw $@ }
  }
}

method Superposition::choose($self:) {
  for @.states -> $state {
when Superposition {
  loop {
my $val = try { 
  $state.choose;
  CATCH Exception::SuperPositionExhausted { last }
  otherwise { die $@ }
}
yield $val;
  }
}
otherwise { yield $state }
  }
  throw Exception::SuperPositionExhausted: $self;
}

And, ooh, look, we have something that'll Do The Right Thing with the
nondeterministic algorithm I posted last week. 

*Damn* but Perl 6 is going to be a potent programming language...
   
 

  


-- 
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?

Re: Keyword arguments

[Austin Hastings]

I think Damian already covered this: it's the semicolon.

sub mysub(String $content; int $key, int $align)
{
 ...
}

sub callmysub
{
  mysub("Testing .. 1, 2, 3!"; key => 1024, align => Module::RIGHT);
}

Which, upon reflection, apparently introduces an "implicit hashparsing"
context for autoquoting hashkeys.

=Austin

--- Piers Cawley <[EMAIL PROTECTED]> wrote:
> So, I was, thinking about the way Common Lisp handles keyword
> arguments. It's possible to declare a Lisp function as follows:
> 
> (defun make-para ( content &key alignment font size color ) ...)
> 
> The point here is that the first argument is dealt with positionally,
> and subsequent, optional args are dealth with as keyword arguments.
> It
> seems to me that similar functionality might sit well with Perl 6,
> but
> I'm not sure I can think of a good declaration syntax. Calling syntax
> is easy:
> 
> make_para $text, font => 'Helvetica,Arial,Whatever';
> 
> Any thoughts?
> 
> -- 
> 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?


__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

Back from Seattle

[Dan Sugalski]

Okay, I'm back, and over the next few days I'll be digging through 
the week's backlog of mail. I do apologize--I assumed I'd have 
reasonable network access but, alas, that wasn't the case.
--
Dan

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

Re: Draft sketch of bytecode generation

[Dan Sugalski]

At 10:17 PM + 10/30/02, Kv Org wrote:

On Tue, 29 Oct 2002 09:55:23 -0800, Chromatic wrote:


I'd really like to be able to save comments from
source files as metadata. This has at least two
potential benefits.  First, it >makes it much easier
to recreate the whole file from bytecode (especially
refactored bytecode). 
Second, it makes it possible to pull out method
documentation in the Smalltalk or Python sense.

 Maybe metadata's not the place for this, but it
seems rather natural to me.

I always thought metadata in bytecode was the place
for storing security/permission/capability related
information about the compiled chunk. If we want Perl6
and Parrot to handle security and limited code
sandboxes better than Perl5's Safe.pm, this is a basic
requirement.


Unfortunately not. (Though I really, *really* wish this was the case) 
The bytecode data, all of it, must be considered completely 
untrustworthy unless explicitly (and out-of-bandly) marked otherwise. 
The code segment that invokes a stronger security context can be 
considered out of band in this context, as it is for the code running 
in the secure

The interpreter engine is responsible for enforcing security. It 
*must*, when running with security turned on, assume that all 
bytecode has been written by malicious vermin with too much time on 
their hands and the morals (and ethics) of a rabid weasel. It just 
can't be trusted, unfortunately. (Parrot bytecode is inherently 
unverifiable as well, at least in the general case, which exacerbates 
the problem)
--
Dan

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

Re: [perl #18127] [PATCH] Implicit stack direction probe

[Dan Sugalski]

At 9:03 AM +0100 11/5/02, Leopold Toetsch wrote:

Dan Sugalski wrote:


At 9:41 AM +0100 10/30/02, Leopold Toetsch wrote:


Jason Gloudon wrote:


... By default both compilers align stack variables at their natural
alignment, so PMC pointers would normally fall on 4 byte boundaries.



So, this "someone" are we (parrot itself) + language extensions 
(PXS) which have to be compiled with the same compiler options, 
parrot is compiled with.
Using packed structures with PMCs/Buffers inside is a strict 
"don't do that!".


I'm comfortable with this.



Patch went in during changes WRT Parrot_destroy - though I'm not 
sure if I did mention it in the description.

Cool. I've been out of touch for a week, so that mail'd been queued 
up for rather a long time.
--
Dan

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

Re: Keyword arguments

[Luke Palmer]

> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> From: Piers Cawley <[EMAIL PROTECTED]>
> Date: Wed, 06 Nov 2002 12:44:39 +
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
> 
> So, I was, thinking about the way Common Lisp handles keyword
> arguments. It's possible to declare a Lisp function as follows:
> 
> (defun make-para ( content &key alignment font size color ) ...)
> 
> The point here is that the first argument is dealt with positionally,
> and subsequent, optional args are dealth with as keyword arguments. It
> seems to me that similar functionality might sit well with Perl 6, but
> I'm not sure I can think of a good declaration syntax. Calling syntax
> is easy:
> 
> make_para $text, font => 'Helvetica,Arial,Whatever';
> 
> Any thoughts?

Sure.  It already does that.  But only if the caller feels like it.
If you can remember the order of all those arguments, great, but if
you can't, you can use keywords.

sub make_para($text; $alignment, $font, $size, $color) {...}

Can be called in a lot of ways, one of which you wrote above.

I sure hope it doesn't complain that you didn't specify alignment.  I
guess that's what exists() is for.

Luke

Re: Keyword arguments

[Paul Johnson]

Austin Hastings said:

> sub callmysub
> {
>   mysub("Testing .. 1, 2, 3!"; key => 1024, align => Module::RIGHT);
> }
>
> Which, upon reflection, apparently introduces an "implicit hashparsing"
> context for autoquoting hashkeys.

Those are pairs, aren't they?

-- 
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net

list comprehensions

[Jonathan Scott Duff]

Will there be some shorter-hand way to say these?

@a = @grades[grep $_ >= 90, @grades];
@b = @grades[grep 80 <= $_ < 90, @grades];
@c = @grades[grep 70 <= $_ < 80, @grades];

Granted, it's fairly compact as it is but I'm wondering if there's
some way to not have to mention @grades twice per statement.
Something like:

@a = @grades[$^_ >= 90];
@b = @grades[80 <= $^_ < 90];
@c = @grades[70 <= $^_ < 80];

BTW, is there some other name for these things?  I only know to call
them "list comprehensions" from python.  I've used the concept in
other languages as well but never was it named.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: list comprehensions

[Mark J. Reed]

On 2002-11-06 at 11:43:20, Jonathan Scott Duff wrote:
> 
> Will there be some shorter-hand way to say these?
> 
>   @a = @grades[grep $_ >= 90, @grades];
>   @b = @grades[grep 80 <= $_ < 90, @grades];
>   @c = @grades[grep 70 <= $_ < 80, @grades];
I think what you mean here is just

@a = grep $_ >= 90, @grades;

etc.  grep returns the actual elements, not their indices, so it doesn't
make sense to use them as a slice.  

-- 
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G  | [EMAIL PROTECTED]
Atlanta, GA 30348  USA   | +1 404 827 4754

Re: Keyword arguments

[Piers Cawley]

"Paul Johnson" <[EMAIL PROTECTED]> writes:

> Austin Hastings said:
>
>> sub callmysub
>> {
>>   mysub("Testing .. 1, 2, 3!"; key => 1024, align => Module::RIGHT);
>> }
>>
>> Which, upon reflection, apparently introduces an "implicit hashparsing"
>> context for autoquoting hashkeys.
>
> Those are pairs, aren't they?

Yup.

-- 
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?

Re: list comprehensions

[Jonathan Scott Duff]

On Wed, Nov 06, 2002 at 12:54:12PM -0500, Mark J. Reed wrote:
> 
> On 2002-11-06 at 11:43:20, Jonathan Scott Duff wrote:
> > 
> > Will there be some shorter-hand way to say these?
> > 
> > @a = @grades[grep $_ >= 90, @grades];
> > @b = @grades[grep 80 <= $_ < 90, @grades];
> > @c = @grades[grep 70 <= $_ < 80, @grades];
> I think what you mean here is just
> 
> @a = grep $_ >= 90, @grades;
> 
> etc.  grep returns the actual elements, not their indices, so it doesn't
> make sense to use them as a slice.  

Er, yeah.   I must be subcaffienated right now.  :-(

What I was trying to get at was the ability to slice based on the values
instead of the indices. But maybe it's just the python programming that
I've been doing that makes me think it's useful.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: list comprehensions

[Piers Cawley]

Jonathan Scott Duff <[EMAIL PROTECTED]> writes:

> Will there be some shorter-hand way to say these?
>
>   @a = @grades[grep $_ >= 90, @grades];
>   @b = @grades[grep 80 <= $_ < 90, @grades];
>   @c = @grades[grep 70 <= $_ < 80, @grades];
>
> Granted, it's fairly compact as it is but I'm wondering if there's
> some way to not have to mention @grades twice per statement.

What's wrong with 
  
  @a = grep { $_ >= 90 }  @grades;
  @b = grep { 80 <= $_ < 90 } @grades;
  @c = grep { 70 <= $_ < 80 } @grades;

Or am I missing something? The examples you give seem to imply that
you should use the value of the things contained in @grades as indices
into @grades, and return the values thus indexed. There may be a good
reason for doing this, but one escapes me for now.

> Something like:
>
>   @a = @grades[$^_ >= 90];
>   @b = @grades[80 <= $^_ < 90];
>   @c = @grades[70 <= $^_ < 80];
>
> BTW, is there some other name for these things?  I only know to call
> them "list comprehensions" from python.  I've used the concept in
> other languages as well but never was it named.

I confess I never quite understood why the python folks were so proud
of list comprehensions, AFAICT they're just 'grep' and 'map' given
fancy descriptions.

-- 
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?

Re: list comprehensions

[Simon Cozens]

[EMAIL PROTECTED] (Piers Cawley) writes:
> I confess I never quite understood why the python folks were so proud
> of list comprehensions, AFAICT they're just 'grep' and 'map' given
> fancy descriptions.

Well, sort of. They're more like this:
@array[grep { func() } 0..$#array]

-- 
"If you want to travel around the world and be invited to speak at a lot
of different places, just write a Unix operating system."
(By Linus Torvalds)

Re: Should memory be washed?

[Dan Sugalski]

At 10:03 AM +0100 11/5/02, Leopold Toetsch wrote:

Peter Gibbs wrote:


What is the official position with respect to laundry services in the
Parrot memory allocation code?



I would strongly urge for calloc()ed memory as done now.


This is one place where the current copying scheme is a win--we 
allocate zeroed pages from the OS, which often plays games with the 
MMU to do this really cheaply. That's one of the reasons lots of the 
older code assumes freshly allocated memory is zeroed.

I don't have a problem with guaranteeing zeroed memory, but it's not 
free. If we're going with a malloc-style allocator then I explicitly 
do *not* want to give guarantees of zeroed memory.

Arguably any code that assumes zeroed memory is broken, as it ought 
not be using any memory its not actually filled in data for.

Some code assumes that the memory returned by Parrot_allocate
and its cousins will be pre-washed, while other code does its own
laundry.



By just deleting all this x->y = 0 and memsets all over the place we 
would save hundreds of source lines.

Buffers and PMCs should be sanitized when put on the free list. This 
should be done in the DOD sweep. Extended buffer headers should be 
zeroed past the end of the 'known' bits.



Making the allocation routines responsible for providing clean
memory simplifies things for everybody else, but with a potential
performance cost.



Yes to first - but I don't think its a performance penalty. Almost 
all used fields have to be cleaned first (and are explictely 
currently).

There's a big difference between clean memory and clean headers. The 
headers we need to clean up ourselves, and there's a cost there we 
pay regardless. (Though keeping it in one tight part of the DOD code 
minimizes the cost somewhat)

--
Dan

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

Re: [perl #18219] on_exit not portable

[Josh Wilmes]

At 7:58 on 11/06/2002 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:

> Josh Wilmes wrote:
> 
> 
> > I agree.   However, the point is fairly moot..  If we're going to do a 
> > Parrot_on_exit, it's just as easy to provide our own Parrot_exit and not 
> > need atexit() either.. it's not like atexit() is giving us much at that 
> > point.
> 
> 
> ... which would mean, that internal_exception needs an Parrot_interp* 
> argument - which it will need anyway to do something useful finally.
> 

Not necessarily...  I was thinking that Parrot_exit/Parrot_on_exit would 
have the same signatures as their libc equivalents.   There should not be 
a need to introduce an interpreter in Parrot_exit()..  It wouldn't hurt, 
but I don't think it's particularly necessary, if each interpreter has 
registered an on_exit handler..

--Josh

Re: [perl #18219] on_exit not portable

[Dan Sugalski]

At 1:31 PM -0500 11/6/02, Josh Wilmes wrote:

At 7:58 on 11/06/2002 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:


 Josh Wilmes wrote:


 > I agree.   However, the point is fairly moot..  If we're going to do a
 > Parrot_on_exit, it's just as easy to provide our own Parrot_exit and not
 > need atexit() either.. it's not like atexit() is giving us much at that
 > point.


 ... which would mean, that internal_exception needs an Parrot_interp*
 argument - which it will need anyway to do something useful finally.



Not necessarily...  I was thinking that Parrot_exit/Parrot_on_exit would
have the same signatures as their libc equivalents.   There should not be
a need to introduce an interpreter in Parrot_exit()..  It wouldn't hurt,
but I don't think it's particularly necessary, if each interpreter has
registered an on_exit handler..


Well, I got bit this week by the on_exit stuff. I'm still not sure 
why we need this. Could someone please explain, so I don't have to 
yank it out?
--
Dan

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

Re: [perl #18219] on_exit not portable

[Josh Wilmes]

At 13:41 on 11/06/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote:

> Well, I got bit this week by the on_exit stuff. I'm still not sure 
> why we need this. Could someone please explain, so I don't have to 
> yank it out?

Leo said:

> The on_exit/atexit is currently necessary to clean up behind exceptions.
> If you don't mind memory leaks after exceptions, remove the
> 
> #define ATEXIT_DESTROY
> 
> at the beginning of interpreter.c, until we have a config test for on_exit.
> 
> atexit is not an alternative, because we might have multiple
> interpreters to clean up like in t/op/interp_2.

How about we just remove that define for now for now, and let it leak that 
little bit for now?

Presumably leo can add the ATEXIT_DESTROY to his build if he's trying to 
track down leaks.

I'll try to find some time to write a more portable Parrot_on_exit/
Parrot_exit implementation later this week.  

Then we can get this cleanup behavior back on by default.   At the moment, 
the tinderbox is a mess, which isn't cool.

--Josh

Re: [perl #18219] on_exit not portable

[Dan Sugalski]

At 1:47 PM -0500 11/6/02, Josh Wilmes wrote:

At 13:41 on 11/06/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote:


 Well, I got bit this week by the on_exit stuff. I'm still not sure
 why we need this. Could someone please explain, so I don't have to
 yank it out?


Leo said:


 The on_exit/atexit is currently necessary to clean up behind exceptions.
 If you don't mind memory leaks after exceptions, remove the

 #define ATEXIT_DESTROY

 at the beginning of interpreter.c, until we have a config test for on_exit.

 atexit is not an alternative, because we might have multiple
 interpreters to clean up like in t/op/interp_2.


Right, I saw that, I just don't understand why. If it's in as a fix 
for the current busted state of exceptions, then we need to fix 
exceptions, I think.

For now, I think I'd rather leak, as it is definitely killing the tinderbox.

--
Dan

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

Re: [perl #18219] on_exit not portable

[Josh Wilmes]

At 13:55 on 11/06/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote:

> >Leo said:
> >
> >>  The on_exit/atexit is currently necessary to clean up behind exceptions.
> >>  If you don't mind memory leaks after exceptions, remove the
> 
> Right, I saw that, I just don't understand why. If it's in as a fix 
> for the current busted state of exceptions, then we need to fix 
> exceptions, I think.

I was operating on the assumption that some sort of global cleanup was a 
necessity for some reason.   If it's a workaround for a bug in exceptions, 
then I agree.

> For now, I think I'd rather leak, as it is definitely killing the tinderbox.

Agreed.

--Josh

Re: [FYI] life generations

[Dan Sugalski]

At 12:52 PM +0100 11/6/02, Leopold Toetsch wrote:

Here some numbers for examples/assembly/life.pasm (generations/sec) 
on my Athlon 800 i386/linux:

 314  24th Sept 2002 CGoto/no optimization
 374  trace_system_stack, lo_var_ptr
 401  string_substr/_compare
 587  string_set

 755  -O3 (except core_ops_cg w/o opt.)
 910  -O3 -g (fast_core)
 997  -O3 -P Prederef
1288  -O3 -j JIT
1740  -O3 native C

Yep, that looks about right. There's a huge speedup with -O3, but 
it's off for the moment so we can tell the GC-related bugs from the C 
compiler bugs. I'm certainly up for arguments that it should be on by 
default, or with a switch in configure when we want to go run speed 
demos...
--
Dan

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

Re: [CVS ci] string_set is back for a faster live - not only

[Dan Sugalski]

At 2:13 PM +0100 11/6/02, Leopold Toetsch wrote:

Peter Gibbs wrote:


Leopold Toetsch wrote:


string_set is currently only used in string_substr, but, when 
people are ok with this, can be used everywhere in core.ops, where 
a string register is globbered.


The behaviour of the following program has changed, is this correct?

  set S0, "test"
  set S1, S0
  set S2, "another"
  substr S0, S2, 1, 3
  print S1
  print "\n"
  end


Yes you are right.

Before:
test
now:
not

The questions are (and this is IMHO the same problem with PMCs):
- set vs assign
- what should this program do


Substr should generate a new string and stick that into S0.

If we want to build a fast version that reuses a string register, I'm 
fine with that--it's definitely useful in a large number of 
circumstances, large enough to warrant expressing both sets of 
semantics.
--
Dan

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

Re: Draft sketch of bytecode generation

[Gopal V]

If memory serves me right, Dan Sugalski wrote:
>  (Parrot bytecode is inherently  unverifiable as well, at least in 
>  the general case, which exacerbates the problem)

Hmm... Why ? ... Loose typing ? 

Or does it just become an undecidability problem ?...

Gopal
-- 
The difference between insanity and genius is measured by success

Re: [perl #18219] on_exit not portable

[Leopold Toetsch]

Dan Sugalski wrote:


At 1:47 PM -0500 11/6/02, Josh Wilmes wrote:


At 13:41 on 11/06/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote:


 Well, I got bit this week by the on_exit stuff. I'm still not sure
 why we need this. Could someone please explain, so I don't have to
 yank it out?



Leo said:


 The on_exit/atexit is currently necessary to clean up behind 
exceptions.
 If you don't mind memory leaks after exceptions, remove the

 #define ATEXIT_DESTROY

 at the beginning of interpreter.c, until we have a config test for 
on_exit.

 atexit is not an alternative, because we might have multiple
 interpreters to clean up like in t/op/interp_2.



Right, I saw that, I just don't understand why. If it's in as a fix for 
the current busted state of exceptions, then we need to fix exceptions, 
I think.


Summary of changes I did put in WRT this:
- interpreter startup code is reordered so that all PMCs/Buffers are in 
managed memory now.
- Long running programs using e.g. new interpreters on the fly would 
currently leak tons of memory.
- Debugging memory corruptions is a pain, when there is a lot of leaking 
memory
- freeing all used memory is a good measure against corrupted mem, so
- I implemented Parrot_destroy, which cleans up all internal data 
structures of an interpreter and frees all used mem.

This is currently ok for:

Failed Test  Status Wstat Total Fail  Failed  List of failed
---
t/op/hacks.t  21  50,00%  1
t/op/rx.t237  30,43%  8-9, 12-14, 21-22
t/pmc/pmc.t  824   4,88%  60-62, 74
9 subtests skipped.
Failed 3/34 test scripts, 91.18% okay. 12/494 subtests failed, 97.57% okay.

(Above is produced by "testyamd", which includes mem leaks as failures)

Above leaks are known why/where they come from.

Not too few tests use exceptions to show some wanted error message, so I 
used atexit first, to catch these.

on_exit() jumped in, with the problem: how to clean up multiple 
interpreters, where a simple atexit() can't provide the necessary 
interpreter argument. 2 possible solutions are: a chained interpreter 
list structure keeping track of running interpreters, or an extra 
interpreter argument in internal_exceptions.


For now, I think I'd rather leak, as it is definitely killing the 
tinderbox.


This is was I did say above, just put comments around above statement if 
tinderboxen are the concern.

leo

Re: Should memory be washed?

[Leopold Toetsch]

Dan Sugalski wrote:


I don't have a problem with guaranteeing zeroed memory, but it's not 
free. If we're going with a malloc-style allocator then I explicitly do 
*not* want to give guarantees of zeroed memory.


It doesn't make much sense to give Parrot_{re,}alloc different semantics 
 depending on the memory manager and forcing users to memset their 
(maybe already zeroed) allocated memory.

If we want this, then lets have Parrot_{re,}allocate{,zeroed}. 

The allocate_string variants are ok with unzeroed mem already.


Arguably any code that assumes zeroed memory is broken, as it ought not 
be using any memory its not actually filled in data for.


When implementing list.c I looked at _allocate, saw calloc and assumed, 
it's ok to assume, mem is zeroed - so ...

... Extended buffer headers should be 
zeroed past the end of the 'known' bits.


Done already, thanks to Peters hint. PMCs were ok.


leo

Re: list comprehensions

[Buddha Buck]

Jonathan Scott Duff wrote:

On Wed, Nov 06, 2002 at 12:54:12PM -0500, Mark J. Reed wrote:


On 2002-11-06 at 11:43:20, Jonathan Scott Duff wrote:


Will there be some shorter-hand way to say these?

	@a = @grades[grep $_ >= 90, @grades];
	@b = @grades[grep 80 <= $_ < 90, @grades];
	@c = @grades[grep 70 <= $_ < 80, @grades];


I think what you mean here is just

   @a = grep $_ >= 90, @grades;

etc.  grep returns the actual elements, not their indices, so it doesn't
make sense to use them as a slice.  


Er, yeah.   I must be subcaffienated right now.  :-(

What I was trying to get at was the ability to slice based on the values
instead of the indices. But maybe it's just the python programming that
I've been doing that makes me think it's useful.

-Scott


I think that if there were a slice-based form of grep, it would most 
likely look like you are indexing by a subroutine (or method) reference 
that takes no arguments other than an element of the array.  Something like:

  @a = @grades[{$^x > 90}];

or

  @a = @grades[-> x { $x > 90}];

or

  my StudentGrade @grades;

  @a = @grades[.isPassing];

I could see that as being useful.

Of potentially more use would be:

%grades = { Tom => 85, Mary => 95 };
%a_students = %grades{-> $name, $grade { $grade > 90 } };
print keys %a_students;   # 'Mary'

Re: list comprehensions

[Buddha Buck]

Piers Cawley wrote:

Jonathan Scott Duff <[EMAIL PROTECTED]> writes:



Will there be some shorter-hand way to say these?

	@a = @grades[grep $_ >= 90, @grades];
	@b = @grades[grep 80 <= $_ < 90, @grades];
	@c = @grades[grep 70 <= $_ < 80, @grades];

Granted, it's fairly compact as it is but I'm wondering if there's
some way to not have to mention @grades twice per statement.



What's wrong with 
  
  @a = grep { $_ >= 90 }  @grades;
  @b = grep { 80 <= $_ < 90 } @grades;
  @c = grep { 70 <= $_ < 80 } @grades;

Or am I missing something? The examples you give seem to imply that
you should use the value of the things contained in @grades as indices
into @grades, and return the values thus indexed. There may be a good
reason for doing this, but one escapes me for now.

I don't see why I'd want to do it with arrays, but...

%a_students = %grades{grep /^a/i, keys %grades};

Re: Supercomma! (was Re: UTF-8 and Unicode FAQ, demos)

[Larry Wall]

On Mon, Nov 04, 2002 at 07:27:56PM -0800, Brian Ingerson wrote:
: Mutt?
: 
: I'm using mutt and I still haven't had the privledge of correctly viewing one
: of these unicode characters yet. I'm gonna be really mad if you say you're
: also using an OS X terminal. I suspect that it's my horrific OS X termcap
: that's misbehaving here.
: 
: Aargh!

I'm using mutt version 1.4i.  The stock mutt on my RedHat wasn't new enough.

Larry

Re: perl6-lang Project Management

[Michael Lazzaro]

On Tuesday, November 5, 2002, at 11:18  PM, Allison Randal wrote:

Since you're interested in the management of the Perl 6 project, I'll
let you in on some of it. Let's start with a step back into a bit of
history:


OK, let me pause for a second...  pause, pause, pause... OK, I'm better 
now.  Please forgive me, I'm going to be quite forceful in my 
evaluation of the situation here.  To the point of making a Simon C. 
post look mellow.  Get ready for some spectacular virtual 
coffee-mug-throwing here.

This is a good summary, but please note that I'm already painfully 
aware of the RFC process and phase 2, and have followed it religiously 
since the beginning, though I have been purposefully invisible through 
most of it.  Indeed, it was the RFP process which caused me to decide 
that my company could no longer continue to base our commercial 
software on Perl: with a few noteworthy exceptions, the RFCs all 
focused on narrow "feature add-ons" that did precious little to solve 
the core issues that have served to limit Perl5 in the marketplace.

It is the high quality of Parrot that later convinced me to hesitate in 
my decision, but it is Apoc5 that later convinced me to reverse it, and 
to even get directly involved.  Apoc5 convinced me that, indeed, Larry 
and the design team were reworking the base assumptions of the language 
in a truly innovative way, and that the result was going to be what the 
real-world business community was hoping for.

We will and we should. But that isn't the focus. It can't be. If we
spend all our time fleshing out the details of earlier Apocalypses,
we'll never finish. Hmmm... let me rephrase that. If we spend all
Larry's time fleshing out the details of earlier Apocalypses, Larry 
will
never finish.

This, then is my point.  I am not saying that Perl6 does not have a 
management strategy for dealing with this.  I am saying that the 
management strategy for this particular part of the effort is so 
incredibly piss-poor as to be nonexistent.  Parrot Good.  Larry Good.  
Big, Big HOLE in the middle.  _Who_ is fleshing out the mindless, 
trivial details that Larry posts to this list, and _who_ is 
creating/updating the documentation to reflect those changes?  Anyone?  
If someone is, what, is it supposed to be a secret?  Or does it simply 
not exist, and Why The Hell Not?

The project is proceeding in a much more orderly fashion than you might
think if p6-lang is your only exposure.


But what other exposure would I have?  No, seriously -- let me 
summarize Perl6 from the standpoint of someone who isn't in the loop, 
whatever the "loop" is, so the people who _are_ in the loop can tell me 
why I'm completely misinterpreting the obvious public faces of the 
effort:

-- Apocalpyse 2 came out May 3rd, 2001.  That's, what, about 18 months 
ago.  Since then, there has been no edits or revisions: none of the 
obselete references have been purged or annotated, and none of the 
profound new decisions that have been made since then have been 
acknowledged.  Ditto for Apoc 3 (Oct 2001), Apoc 4 (Jan 2002), and Apoc 
5 (June 2002).  Basic, fundamental decisions have been *invalidated*, 
but you will only know this if you have read and perfectly remember 
every post to perl6-lang since inception.  Great, just great.

-- The Apos and Exes continue to be the _ONLY_ meaningful source of 
documentation of previously decided behaviors.  No member of the 
community besides Larry and Damian has contributed in an ongoing way to 
documenting the rudimentary behavior of Perl6.  Questions asked on 
perl6-language continue to be asked, repeatedly.  Explanations are 
given, repeatedly, often contradicting previous explanations.  Aside 
from Piers and his stunt doubles, explanations result in no "findable" 
specifications whatsoever.

-- Basic, fundamental questions like what each of these lines do:

   my int $n = 5;   # OK
   my int $n = 5.005;   # trunc or err?
   my int $n = "5.05ff" # 5, 0, undef, Nan, or exception?
   my int $n = "fdsjfdf"# 0, undef, Nan, or exception?

   ... are being asked repeatedly of _me_, implying that either (1) 
nobody knows, (2) some people know, but they aren't telling, (3) people 
know, and it has been answered, but people can't find the answer 
anymore because it's lost in N other unrelated answers, or (4) people 
no longer trust the answer, because they don't know what other 
decisions the answer was originally predicated on.

-- The "latest news" on the Perl6 section of dev.perl.org was updated 
July 7th, introducing Piers, and other than linking to Piers' summaries 
contains no information pertinent to Perl6 -- only Parrot.

-- It's November, 2002.  We have just been through a hellacious thread 
reworking operators.  (Apoc 3)  The only documentation of those 
decisions has been my continual reposting of the current status, which 
I had to practically _force_ down people's throats.

I don't *WANT* to write damn documentation.  I wrote a first-ch

Re: list comprehensions

[Austin Hastings]

--- Buddha Buck <[EMAIL PROTECTED]> wrote:
> I think that if there were a slice-based form of grep, it would most 
> likely look like you are indexing by a subroutine (or method)
> reference 
> that takes no arguments other than an element of the array. 
> Something like:
> 
>@a = @grades[{$^x > 90}];
> 
> or
> 
>@a = @grades[-> x { $x > 90}];
> 
> or
> 
>my StudentGrade @grades;
> 
>@a = @grades[.isPassing];
> 
> I could see that as being useful.
> 
> Of potentially more use would be:
> 
> %grades = { Tom => 85, Mary => 95 };
> %a_students = %grades{-> $name, $grade { $grade > 90 } };
> print keys %a_students;   # 'Mary'

This is what makes designing an OODB so much fun.

for keys %minima -> $gr
{
  @grades{ $gr } = grep { .getGrade() >= $minima[$gr] }, @class;
}

This kind of searching is too easy in a transparent language like SQL,
"SELECT * FROM class WHERE curr_grade >= %min", but it's miserable when
you have to "honor the objects".

Being able to say something like:

@grades{ $gr } = @class «st» {.getGrade() >= $minima[$gr]};

makes for a decent start. Combining vectorizing with objects can help
us build a more intuitive way to talk about operations over
collections.

Which kind of suggests that that idea of a standardized Collections
interface isn't so unreasonable, after all -- I think there's value in
being able to invoke map or grep or zip, etc., on an arbitrary
collector (array, hash, lol, ) and have it work in a
consistent, predictable manner.

(But this kind of thing can be a module, or be an extension, so long as
the core collection types aren't blatantly incompatible.)

(«st» is, of course, the vectorized "such that" operator (aka grep). I
shan't demand a single-character punctuation operator... :0)

=Austin


__
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/

Re: Supercomma! (was Re: UTF-8 and Unicode FAQ, demos)

[Larry Wall]

On Tue, Nov 05, 2002 at 11:36:45AM -0500, Ken Fox wrote:
: Jonathan Scott Duff wrote:
: 
: >Um ... could we have a zip functor as well?  I think the common case
: >will be to pull N elements from each list rather than N from one, M
: >from another, etc.  So, in the spirit of timtowtdi:
: >
: > for zip(@a,@b,@c) -> $x,$y,$z { ... }
: 
: sub zip (\@:ref repeat{1,}) {
:my $max = max(map { $_.length } @_);
:my $i = 0;
:while ($i < $max) {
:for (@_) {
:yield $_[$i]
:}
:++$i
:}
:return ( )
: }
: 
: That prototype syntax is probably obsolete, but I'm not sure
: what the current proposal is. It might be better to force scalar
: context on the args so that both arrays and array refs can be
: zipped.

You never have to put \ into a signature anymore--that's the default.
You only get list context (and flattening) when you use the splat.
For a recurring scalar context, you want something like:

sub zip (@refs is repeatedly (Array)) {

The exact syntax is subject to change, of course.

: I really like the idea of using generic iterators instead of
: special syntax. Sometimes it seems like we're discussing 6.x
: instead of just 6.0.
: 
: This iterator is nice too:
: 
: sub pairs (\@a, \@b) {
:my $max = max(@a.length, @b.length);
:my $i = 0;
:while ($i < $max) {
:yield @a[$i] => @b[$i];
:++$i
:}
:return ( )
: }
: 
: for pairs (@a, @b) {
:print .x, .y
: }

Neither of these work on arrays which have a finite but unknown length.

Larry

Re: perl6-lang Project Management

[Simon Cozens]

[EMAIL PROTECTED] (Michael Lazzaro) writes:
> Big, Big HOLE in the middle.  _Who_ is fleshing out the mindless,
> trivial details that Larry posts to this list, and _who_ is
> creating/updating the documentation to reflect those changes?  Anyone?

Allison is, but she was too modest to say so. (And I fear, too busy
to check in much in the recent past. :( )

It's all at http://cvs.perl.org/cvsweb/perl6/doc/design/

-- 
Ermine? NO thanks. I take MINE black.
- Henry Braun is Oxford Zippy

Re: Perl6 Operator List (REMAINING ISSUES)

[Peter Haworth]

[Apologies for late reply, but it takes a long time to read this many
messages]

On Wed, 30 Oct 2002 16:37:09 -0800, Michael Lazzaro wrote:
 1) Need a definitive syntax for hypers,
>  ^[op] and «op»
>  have been most seriously proposed -- something that
>  keeps a bracketed syntax, but solves ambiguity issues.
>
> 2) Possible inclusion of unary prefix ^, meaning "complement". (Assuming
>doesn't conflict with (1))

If ^ means xor (and complement), then we can't use it for hypering. Consider
this example:

  @a ^[alpha_op] +3

You can parse this in two ways:
 * "array a", "hyperop alpha_op", "unary plus", "literal 3"
 * "array a", "binary xor", "call alpha_op and put result in arrayref",
   "binary plus", "literal 3"

The operator doing the least at present seems to be ! (my recent attempts to
reclaim it aside). If we keep ^ as the only xor/complement operator, we can
use ! as the hyperoperator indicator without ambiguity:

  @a ![alpha_op] +3

Or (since people seem to like using ^ for hyperness), we could steal ! back
as doing all the xor/complement things that ^ is doing now, and leave ^
doing just hyperstuff. This stops ! being a (mostly) synonym for ^, which I
didn't really like, but does bring back the confusion between !! and ||.

If we want to have a sigil meaning "the next set of brackets surround a
hyperoperator," it pretty much can't be the same as any of the other
operators, since that introduces ambiguity all over the place. This is
unfortunate, since perl seems to use every printable ASCII character for
something. Using French quotes gets around this, since they aren't being
used for anything else. OT3H, I can't find the «» keys on my keyboard, but
I'm sure I'm just not looking hard enough.


-- 
Peter Haworth   [EMAIL PROTECTED]
"Are you the police?"
"No ma'am, we're musicians."

Re: [RFC] Perl Operator List, TAKE 6

[Larry Wall]

On Tue, Nov 05, 2002 at 08:18:18PM +0100, Dennis Haney wrote:
: Michael Lazzaro wrote:
: 
: >  ~ - force to string context
: 
: >  ~ ~=  - string concat
: 
: ARG. When did this get chosen?
: ~ has to be absolutly the most difficult letter to type on the intire 
: keyboard along with ^ and ", because they are also used as a prefix to 
: make û, ü, õ, ã, ñ etc.
: Thus a standalone ~ must be made with a AltGr+^ followed by a space.

Bummer.  Oh well.  You're not supposed to use string concatenation
all that often anyway...

Larry

Re: [RFC] Perl Operator List, TAKE 6

[John Adams]

On Wed, 6 Nov 2002 11:13:36 -0800 Larry Wall <[EMAIL PROTECTED]> wrote:

> You're not supposed to use string concatenation
> all that often anyway...

I'm not supposed (for some value of supposed) to use Perl at my job, but I do,
and I suspect I use string concatenation in about one script in five, so
should I vote Scylla or Charybdis?

Thanks,

  John A
  see me fulminate at http://www.jzip.org/

Re: list comprehensions

[Me]

> Will there be some shorter-hand way to say these?
> [list comprehensions]

(bb clarified that this is about hash slicing.)

>From A2:

RFC 201: Hash Slicing

...Concise list comprehensions will require
some other syntax within the subscript...

And

There are many ways we could reintroduce
a slicing syntax ... but we'll defer the
decision on that till Apocalypse 9

--
ralph

Re: perl6-lang Project Management

[Jonathan Scott Duff]

On Tue, Nov 05, 2002 at 04:26:58PM -0800, Michael Lazzaro wrote:
> So what say you?  Can we migrate perl6-language into a list that 
> finalizes aspects of the design, documents them, and revises them as 
> needed, rather than our usual circular discussions of things already 
> long-since past?

What would be useful would be a big map of all that is or might be
perl 6.  Items that are still in flux could be marked as such and have
pointers to the relevant mail thread(s).  Items that are finalized
could have links to the documentation that describes those items.

As for who updates the map of the onion and its associated
documentation, I don't know. It should be a small group of people
(perhaps only one) though. Right now, I guess it's just Allison.

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: list comprehensions

[Larry Wall]

You know, guys, I already discussed this one in A4 or thereabouts.
It's the use of an explicit boolean operator as a subscript that
triggers selection.

Larry

Re: perl6-lang Project Management

[chromatic]

On Tue, 05 Nov 2002 23:18:01 -0800, Allison Randal wrote:

> If you really want to be involved where the rubber meets the road -- where the
> "abstract" design gets tested and every last detail must be fleshed out -- you
> might contribute to Parrot. It has a good many of the features of the first 5
> Apocalypses implemented already.

One excellent opportunity is to write tests for Perl 6 features.  Testing gives
several benefits:

- exploring the syntax with a working interpreter
- mapping the boundaries of what's expected
- providing good feedback for debugging Perl 6
- exposing what's not yet implemented
- ensuring that regressions only happen once

I'd be thrilled to help anyone learn how to do this.  It's one of the most
important places to contribute, but it's all-too-often overlooked.

-- c

Re: list comprehensions

[Adam D. Lopresto]

> I don't see why I'd want to do it with arrays, but...
> 
> %a_students = %grades{grep /^a/i, keys %grades};

Looks like that's just the same as 

%a_students = grep {.key ~~ :i/^a/}, %grades.kv;

(after adjusting for perl6 syntax for a few things)
-- 
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/

Aleph-null bottles of beer on the wall,
Aleph-null bottles of beer,
You take one down, and pass it around,
Aleph-null bottles of beer on the wall.

Re: perl6-lang Project Management

[Allison Randal]

On Wed, Nov 06, 2002 at 06:58:52PM +, Simon Cozens wrote:
> [EMAIL PROTECTED] (Michael Lazzaro) writes:
> > Big, Big HOLE in the middle.  _Who_ is fleshing out the mindless,
> > trivial details that Larry posts to this list, and _who_ is
> > creating/updating the documentation to reflect those changes?  Anyone?
> 
> Allison is, but she was too modest to say so. (And I fear, too busy
> to check in much in the recent past. :( )
> 
> It's all at http://cvs.perl.org/cvsweb/perl6/doc/design/

The updates to A1 are finished and pending approval. A2's updates are
half finished. The rest of the revisions to the Apocalypses and Exegeses
are in the form of extensive notes.

Feel free to send me documentation patches (follow Parrot's format:
http://www.parrotcode.org/patchfaq). They'll be accepted if they're
clearly written, technically correct and relevant. They'll be subject to
my edits and a review process by the entire design team. And keep in
mind that I've probably gotten 5 other patches for the same bit, so
your patch may not be the one that gets published.

Allison

Re: perl6-lang Project Management

[Michael Lazzaro]

On Wednesday, November 6, 2002, at 10:58  AM, Simon Cozens wrote:

It's all at http://cvs.perl.org/cvsweb/perl6/doc/design/


No, that's the Apocalypses and Exegesiii, though very nicely cleaned 
up.  I'm talking about detailed documentation for the things the A's 
and E's don't cover.

MikeL

Re: list comprehensions

[Jonathan Scott Duff]

On Wed, Nov 06, 2002 at 11:36:50AM -0800, Larry Wall wrote:
> You know, guys, I already discussed this one in A4 or thereabouts.
> It's the use of an explicit boolean operator as a subscript that
> triggers selection.

I thought so, but I couldn't find it.

thanks,

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Perl6 Operator List (REMAINING ISSUES)

[fearcadi]

Peter Haworth writes:
 > 
 >   @a ^[alpha_op] +3
 > 
 > You can parse this in two ways:
 >  * "array a", "hyperop alpha_op", "unary plus", "literal 3"
 >  * "array a", "binary xor", "call alpha_op and put result in arrayref",
 >"binary plus", "literal 3"
 > 

I think this was already discusse dbefore . 
^ - xor and ^[] vectorization can coexist because perl takes longest
known operator sequence ( and the vectorization is ^[] not "^ [ ]") 

so ^[] is vectorization  
and ^ [foo] *cannot* 

just like ~~ is binding 
and ~ ~ is ( string scalar context ( string scalar context (  

so if you mean xor -- write ^ [...] 

arcady

Re: perl6-lang Project Management

[Angel Faus]

> We started off with an intense RFC process. This produced many good
> ideas, not-so-good ideas, and ideas with potential but desperately
> needing polish. If you'd like a recap, you might try MJD's article
> on the subject (http://www.perl.com/lpt/a/2000/11/perl6rfc.html).
> One of the major things that was lacking from the RFC process was
> focus. The advantage of community contribution is that it brings
> out good ideas from many different perspectives. The disadvantage
> is that the ideas form no coherent whole. Larry was the obvious
> choice to provide the needed focus.

The fact that the RFC process did not well as we all expected doesn't 
mean that the community has to remain silent for two years, or that 
the only authorized way to express should be perl6-language.

Coding is not the only useful thing we can do while we wait for the 
design to finish. While Apocalypses are great to show (and justify) 
the changes, they are no substitute for the a language reference, or 
for user-oriented documentation.

So, while we all wait for Larry to wait the design, is there any 
reason not to start working in the documentation?

This would serve for:

- Consolidating Perl5 documentation + Perl6 Apocalypses/Exegesis/.. 
and merging it all into a single reference.

- Finish the details that may be not complete in the Apocalypses 
(there are plenty of them)

- Create tentative references for "boring" things, that may be 
revised/updated with Larry's coments. 

We can avoid the RFC nightmare by:

- Working in a structured way: for example replicating the structure 
of perl5 documentation. 

- Working _independently_ of Larry. There is no need for Larry to 
spend time reading or fixing the documentation generated by the 
Documentation Group. 

Discussion could be done in a separate list (perl6-documentation?) and 
it would be the Documentation Group's responsability to update the 
documentation whenever an Apocalypses invalidates it.

It's like this: Larry writes the Apocalypses, Damian the Exegesis, and 
the community writes the Cathecism (a codified, detallied and 
anonymous explanation of the most boring details of the faith, 
written in a form that plain people can understand).

-angel

Re: perl6-lang Project Management

[Simon Cozens]

[EMAIL PROTECTED] (Michael Lazzaro) writes:
> No, that's the Apocalypses and Exegesiii, though very nicely cleaned
> up.  I'm talking about detailed documentation for the things the A's
> and E's don't cover.

Ah, well, they don't cover that. I thought that was what you were doing,
right? :)

-- 
So what if I have a fertile brain?  Fertilizer happens.
 -- Larry Wall in <[EMAIL PROTECTED]>

Re: perl6-lang Project Management

[Michael Lazzaro]

On Wednesday, November 6, 2002, at 12:10  PM, Simon Cozens wrote:


[EMAIL PROTECTED] (Michael Lazzaro) writes:

No, that's the Apocalypses and Exegesiii, though very nicely cleaned
up.  I'm talking about detailed documentation for the things the A's
and E's don't cover.


Ah, well, they don't cover that. I thought that was what you were 
doing,
right? :)

AAAGHH

MikeL

Re: perl6-lang Project Management

[Nicholas Clark]

On Wed, Nov 06, 2002 at 01:50:10PM -0600, Allison Randal wrote:
> On Wed, Nov 06, 2002 at 06:58:52PM +, Simon Cozens wrote:
> > [EMAIL PROTECTED] (Michael Lazzaro) writes:
> > > Big, Big HOLE in the middle.  _Who_ is fleshing out the mindless,
> > > trivial details that Larry posts to this list, and _who_ is
> > > creating/updating the documentation to reflect those changes?  Anyone?
> > 
> > Allison is, but she was too modest to say so. (And I fear, too busy
> > to check in much in the recent past. :( )
> > 
> > It's all at http://cvs.perl.org/cvsweb/perl6/doc/design/
> 
> The updates to A1 are finished and pending approval. A2's updates are
> half finished. The rest of the revisions to the Apocalypses and Exegeses
> are in the form of extensive notes.

Good.
(I can't find a better way to say that without sounding insincere)

> Feel free to send me documentation patches (follow Parrot's format:
> http://www.parrotcode.org/patchfaq). They'll be accepted if they're
> clearly written, technically correct and relevant. They'll be subject to
> my edits and a review process by the entire design team. And keep in
> mind that I've probably gotten 5 other patches for the same bit, so
  ^^
> your patch may not be the one that gets published.

Not good. 5 patches means that 4 people wasted effort trying to help.
I don't have a solution to this problem (sorry). But I think it's an
important problem to solve.

  What would facilitate the edit/review process so that the time taken to
  apply a patch gets reduced?

Failing that

  Is there a good way to have the apocalypse documents annotated in some way
  with the lines or sections that are subject to a pending review?

If they're being sent as diffs can we automatically mangle the diffs to
replace the substituted in text with s so that anyone who is thinking of
supplying a documentation patch can at least see which parts of the docs are
already pending changes. Is it sensible to make the list of unapproved edits
available for all to read (bluntly marked as such)

Speaking for just myself, until such time as I know that there wasn't the
strong chance of 1+ patches already existing for any part of the documentation,
I won't even consider using finite supply of free time on submitting
documentation patches for perl6.

Hmm. Don't take that as a commitment that I would be supply patches as soon
as the patch pending sections are known - I suspect my finite time is better
spent on code implementing things.

Nicholas Clark
-- 
INTERCAL better than perl?  http://www.perl.org/advocacy/spoofathon/

Re: perl6-lang Project Management

[Nicholas Clark]

I'm going to repeat what chromatic said (even though I've deleted his message)

On Wed, Nov 06, 2002 at 09:57:58PM +0100, Angel Faus wrote:
> - Finish the details that may be not complete in the Apocalypses 
> (there are plenty of them)

write specifications of all the detailed bits as regression tests.
code is usually more tight in its definition of things than English

Also, if I remember The Mythical Man Month correctly, Brookes said that
either the user manual or the spec can be definitive, but not both - the
other must be a derivative.

I see no reason why this doesn't also apply to specs vs regression tests.
So either we have the definitive docs that define all the details of the
language, or we have the regression tests that define all the details.

I know what I'd prefer. Mainly because I type make test and let the computer
check that the implementation is correct (while I make myself a cup of tea
by hand). I prefer this to checking by hand and machine brewed tea.

Nicholas Clark

RE: perl6-lang Project Management

[Garrett Goebel]

Angel Faus wrote:
> 
> So, while we all wait for Larry to wait the design, is there any 
> reason not to start working in the documentation?

Any chance of getting a wiki setup at:
  http://dev.perl.org/perl6/cathecism/

Say using a wiki which uses pod for markup like:
 
http://search.cpan.org/author/MSERGEANT/AxKit-XSP-Wiki-0.04/lib/AxKit/XSP/Wi
ki.pm

So people can start working on the Perl6 Core documentation, etc.?

RE: perl6-lang Project Management

[Dan Sugalski]

At 2:26 PM -0600 11/6/02, Garrett Goebel wrote:

Angel Faus wrote:


 So, while we all wait for Larry to wait the design, is there any
 reason not to start working in the documentation?


Any chance of getting a wiki setup at:
  http://dev.perl.org/perl6/cathecism/


Wikis have serious scaling issues. Which isn't an argument against, 
merely something that must be kept in mind when considering one.
--
Dan

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

Re: perl6-lang Project Management

[Dan Sugalski]

At 9:57 PM +0100 11/6/02, Angel Faus wrote:

It's like this: Larry writes the Apocalypses, Damian the Exegesis, and
the community writes the Cathecism (a codified, detallied and
anonymous explanation of the most boring details of the faith,
written in a form that plain people can understand).


Make these in the form of tests. Tight, small, unambiguous chunks of 
code with expected behavior.

We will, I promise, roll every single correct test that comes in 
patch form into the parrot source distribution.[*]

[*] Barring license issues, of course. Can't do much with tests 
labelled "May not be distributed with Parrot" for example... :)
--
Dan

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

Re: perl6-lang Project Management

[Allison Randal]

On Wed, Nov 06, 2002 at 10:54:23AM -0800, Michael Lazzaro wrote:
> 
> -- The "latest news" on the Perl6 section of dev.perl.org was updated 
> July 7th, introducing Piers, and other than linking to Piers' summaries 
> contains no information pertinent to Perl6 -- only Parrot.

Sounds like a place you might volunteer.

> I don't *WANT* to write damn documentation.  I wrote a first-chapter 
> summary of some basic Apocalypse 2 stuff because, a year and a half 
> after it first came out, NOBODY HAD DAMN WELL DONE IT YET.  Worse, I'm 
> bloody *volunteering* great gobs of time to do it, and it's like 
> pulling teeth to get people to agree to it!

Unfortunately we don't have time to edit and approve every summary that
every individual produces. Again, we could spend all our time on that
task alone to the exclusion of all others. The project has to keep
focus.

And yes, the review is necessary. The only thing worse than no
documentation is inaccurate documentation.

> >...you might contribute to Parrot.
> 
> I would *love* to.  What should I work on first...

Subscribe to p6-internals and find out where they need help.

> Again, my point is that Parrot is doing fine, and Larry is doing fine.  
> But the hole in the middle -- coming up with the details so that the 
> Parroteers can actually implement something, and not have to sit on 
> their @$$es for a few months after they've finished the non-Perl core 
> -- is getting _very_ _wide_.

The obstruction you're imagining doesn't exist. The "Parroteers" ask for
guidance from Dan. When Dan feels the details aren't clear enough yet he
brings the issue to the rest of the design team. When none of us can
give him an immediate answer (because we haven't covered it yet) and it
is an important issue standing in the way of progress in Parrot, we sit
down and hash it out until we have a clear answer.


I'm not rejecting your help. We welcome all the help we can get. I'm
merely asking (wearing my official assistant project manager hat, if it
helps) that you harness your energy to the places where it will have the
maximum benefit. And believe us when we tell you that you haven't found
the right place yet.

Allison

Re: perl6-lang Project Management

[Michael Lazzaro]

On Wednesday, November 6, 2002, at 12:26  PM, Garrett Goebel wrote:

Angel Faus wrote:

So, while we all wait for Larry to wait the design, is there any
reason not to start working in the documentation?


Yes!  Someone gets it!  The Apocalypses and Exegesis are not "formal" 
documentation, they're the initial, informal specs.  The finished 
documentation won't look anything like them, right?

Any chance of getting a wiki setup at:


My problem with a wiki approach is that it tends to lead to lots of 
duplication of effort, with some sections entirely ignored, as well as 
a wide range of writing styles.  I think a better approach is, indeed, 
for the community to help with documentation, but to do so in a more 
structured way.  This is why I prefer a mailing list approach, with 
questions & answers posted, then documented, in a particular, fairly 
rigid order, where everyone is concentrating on the same excruciating 
details at once, then boom, it's done, move on.  Right now we have the 
mailing list, but not the structure.

Two notes:

1) The primary need right now is not documentation in itself, but the 
community process of *writing* the documentation.  It is by 
methodically *finding* the holes in the specification that the 
specification will finally becomes complete enough to implement 
accurately.

2) Anyone involved in a community documentation effort must agree that 
ALL of it is open source or public domain, and _specifically_ that any 
members of the community who will be writing treeware (books) may use 
any of that text in their own efforts.  This is a dealbreaker, for me: 
I have zero desire to squish commercial documentation efforts -- I 
think those people deserve 100% of that income.

On Wednesday, November 6, 2002, at 12:26  PM, Nicholas Clark wrote:
I see no reason why this doesn't also apply to specs vs regression 
tests.
So either we have the definitive docs that define all the details of 
the
language, or we have the regression tests that define all the details.

I confess I have worked that way myself, on some projects, but I fear 
we aren't capable of that yet.  We still need to flesh out the 
"english" explanations of co-routines, superpositions, and other 
advanced features.  I would rather define how it worked, and test to 
that, then test how it worked, and write up the english implications as 
we accidentally discover them.

MikeL

Re: perl6-lang Project Management

[Dan Sugalski]

At 2:44 PM -0600 11/6/02, Allison Randal wrote:

The obstruction you're imagining doesn't exist. The "Parroteers" ask for
guidance from Dan. When Dan feels the details aren't clear enough yet he
brings the issue to the rest of the design team. When none of us can
give him an immediate answer (because we haven't covered it yet) and it
is an important issue standing in the way of progress in Parrot, we sit
down and hash it out until we have a clear answer.


Shhh! Don't tell, but I really just make it up. ;-)

Now, to put on my cranky curmudgeon implementor's hat...

The answer's to Just Do It. (Which I know you've already done a 
number of times) Try for consensus to some extent, and try to get 
word on the bits that are up in the air from Larry so you've a good 
chance of it being correct, but... do it. Do it, send it in to the 
list, and be done with it. Unless you're covering already-well-hashed 
ground, nobody'll get unhappy and if we do, well, we're adults, we 
can deal with it.

In general, coordinating with Allison's a good idea, so we don't have 
a dozen people doing the same thing, and so the results can be mushed 
together, but there's too much to do for a single person, and none of 
us like being choke points for progress.
--
Dan

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

Re: Draft sketch of bytecode generation

[Dan Sugalski]

At 11:51 PM +0530 11/6/02, Gopal V wrote:

If memory serves me right, Dan Sugalski wrote:

  (Parrot bytecode is inherently  unverifiable as well, at least in
  the general case, which exacerbates the problem)


Hmm... Why ? ... Loose typing ?

Or does it just become an undecidability problem ?...


Loose typing is one reason, as is the potential for 
self-modification, by direct code rewriting, sub definition changes, 
and runtime code production. It's one of those halting problem 
issues--we can't tell whether the code is safe without running it.

That's why more effort's been put into thinking about runtime 
security issues, including resource limits and privilege assignment.
--
Dan

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

Re: [perl #18219] on_exit not portable

[Dan Sugalski]

At 9:19 PM +0100 11/6/02, Leopold Toetsch wrote:

Summary of changes I did put in WRT this:
- interpreter startup code is reordered so that all PMCs/Buffers are 
in managed memory now.
- Long running programs using e.g. new interpreters on the fly would 
currently leak tons of memory.
- Debugging memory corruptions is a pain, when there is a lot of 
leaking memory
- freeing all used memory is a good measure against corrupted mem, so
- I implemented Parrot_destroy, which cleans up all internal data 
structures of an interpreter and frees all used mem.

Right, I understand. (And I really appreciate it--this was a hanging 
area that didn't get nearly the proper attention it needed) The bit I 
don't understand is the need for a hook into the process exit. 
Generally having explicit interpreter cleanup is OK, though if you've 
got a reason to not trust that I can be convinced otherwise.

For now, I think I'd rather leak, as it is definitely killing the tinderbox.



This is was I did say above, just put comments around above 
statement if tinderboxen are the concern.

Yeah, I think I'll do that for right now. What I'd like is a probe 
for this in configure. Oh, Brent :)
--
Dan

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

Re: Should memory be washed?

[Dan Sugalski]

At 8:58 PM +0100 11/6/02, Leopold Toetsch wrote:

Dan Sugalski wrote:


I don't have a problem with guaranteeing zeroed memory, but it's 
not free. If we're going with a malloc-style allocator then I 
explicitly do *not* want to give guarantees of zeroed memory.


It doesn't make much sense to give Parrot_{re,}alloc different 
semantics  depending on the memory manager and forcing users to 
memset their (maybe already zeroed) allocated memory.

Nope, you're right.


If we want this, then lets have Parrot_{re,}allocate{,zeroed}.
The allocate_string variants are ok with unzeroed mem already.


Which was my thought here. Things that care can ask for zeroed 
memory, which they may get anyway. (Or we may keep a big pool of 
zeroed memory around as it's cheaper to clean large blocks or 
something)

... Extended buffer headers should be zeroed past the end of the 
'known' bits.


Done already, thanks to Peters hint. PMCs were ok.


Cool, thanks.
--
Dan

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

Re: [FYI] life generations

[Leopold Toetsch]

Dan Sugalski wrote:


At 12:52 PM +0100 11/6/02, Leopold Toetsch wrote:


Here some numbers for examples/assembly/life.pasm (generations/sec) on 



... I'm certainly up for arguments that it should be on by 
default, or with a switch in configure when we want to go run speed 
demos...

No need currently:

$ perl Configure.pl --ask
 blabla until CFLAGS ...   :add{ -O3 }

leo

Re: [CVS ci] string_set is back for a faster live - not only

[Leopold Toetsch]

Dan Sugalski wrote:



Substr should generate a new string and stick that into S0.

If we want to build a fast version that reuses a string register, I'm 
fine with that--it's definitely useful in a large number of 
circumstances, large enough to warrant expressing both sets of semantics.

Fine. But how do we know, which version we could take. Please read again 
Peter's example. It depends on the semantics of Sx register usage all 
over the program IMHO.

My version doesn't break any current test but gives ~30% increase in 
life generations - yes I do know - 1): correctness, 2) speed - but what 
is correct for Peter's example?

The "normal" case would be that substr (or any operation resulting in a 
new Sx) should be able to reuse an existing string header. Peter's 
example is a of course valid but still exception from a normal program 
flow IMHO. If I (HL) want to save a SReg, I would copy (clone in PMC 
terms) it.

I think, we should invest some more thoughts on an optimization with 
that much potential in execution speed. DOD/GC runs aren't free, when 
minimized we can gain ~30% execution speed.

And for RL (or perl6) programs, reusign PMCs would be a similar case.

leo

Re: [perl #18219] on_exit not portable

[Leopold Toetsch]

Dan Sugalski wrote:



- I implemented Parrot_destroy, which cleans up all internal data 
structures of an interpreter and frees all used mem.


Right, I understand. (And I really appreciate it--this was a hanging 
area that didn't get nearly the proper attention it needed) The bit I 
don't understand is the need for a hook into the process exit. 


Then you should have read on ;-)

~8% tests use internal_exception to deliver a test result. Not catching 
the exception may hide memory leaks in such tests.
More detailled:
Testing for memory leaks uses the same tests as are already in t/*. A 
test is passed, when the result is ok, and when it doesn't leak mem. 
This is accomplished by the scipt "testyamd" I checked in. When the 
exceptions just exits and Parrot_destroy isn't reached, the test would fail.


Yeah, I think I'll do that for right now. What I'd like is a probe for 
this in configure. Oh, Brent :)

I did deactivate it some minutes ago. Tinderboxen should be happy again. 
Waiting for the config test - but it's not an urgent one.

leo

Re: perl6-lang Project Management

[Michael Lazzaro]

My apologies for one more post, but I find the assertions various 
people have posted on this topic to be absolutely astounding.

On Wednesday, November 6, 2002, at 12:44  PM, Allison Randal wrote:
I don't *WANT* to write damn documentation.  I wrote a first-chapter
summary of some basic Apocalypse 2 stuff because, a year and a half
after it first came out, NOBODY HAD DAMN WELL DONE IT YET.  Worse, I'm
bloody *volunteering* great gobs of time to do it, and it's like
pulling teeth to get people to agree to it!


Unfortunately we don't have time to edit and approve every summary that
every individual produces. Again, we could spend all our time on that
task alone to the exclusion of all others. The project has to keep
focus.


No time, because there are so many people clamoring to do it?  Where??  
Forgive me, but I have yet to see *any* ground-up Perl6 documentation 
of comprehensive scope, other than the occasional couple-of-page 
postings to the O'Reilly site.  Seriously, are you saying that a 
document similar to this (http://cog.cognitivity.com/perl6/val.html) 
already exists, but that the design team is been unwilling to release 
it for discussion?  Or are you saying that (revised) 
Apocalypses/Exegeses are all we're gonna get for the indefinite future, 
and any community efforts to the contrary are futile?

It has been asserted in this discussion that (1) we don't need accurate 
online docs yet; (2) the programming can occur (efficiently) without 
them; (3) continuing to move forward on the design while the details of 
previous decisions have yet to be specified is in fact the most 
efficient use of everyone's time, including that of the design team; 
and (4) that the community really can't offer any assistance of value 
here.  Those notions truly surprise me.

...you might contribute to Parrot.

I would *love* to.  What should I work on first...

Subscribe to p6-internals and find out where they need help.


Well, as of yesterday the most interesting topics (IMO) currently are 
that Dan is describing bytecode generation (i.e. he's written some 
needed docs), and the original "Need for fingerprinting" thread is 
devolving into a discussion of the JIT and GC approaches & speed, as 
all threads on p6-internals eventually do.  They are (thankfully) 
focusing on Parrot core issues, not Perl6 language-specific issues, as 
they should be, and as they have been.

Seriously, don't patronize me: it won't get you anywhere productive, 
and it just ticks me off.  I am not _unaware_ of the current Perl6 
dynamics and management decisions; on the contrary, I am observing that 
the current approach has resulted in _profoundly_ little progress per 
unit time, given the pool of available labor and talent at our 
disposal, and has resulted in us revisiting decisions *repeatedly* 
whenever previous designs are more fully worked out.

I'm not rejecting your help. We welcome all the help we can get. I'm
merely asking (wearing my official assistant project manager hat, if it
helps) that you harness your energy to the places where it will have 
the
maximum benefit. And believe us when we tell you that you haven't found
the right place yet.

It sounds like you're pretty firmly rejecting it, when it comes to any 
detailed documentation effort.  So be it.

MikeL

String -> Numeric conversion

[Michael Lazzaro]

If anyone knows the answer to these two questions, I'd appreciate it.

1) What do these do?

   my int $n = 5;   # OK
   my int $n = 5.005;   # trunc or err?
   my int $n = "5.05ff" # 5, 0, undef, NaN, or exception?
   my int $n = "fdsjfdf"# 0, undef, NaN, or exception?


2) Do "num" and "int" share a common base "is a number" class, such 
that (in perl5-ish speak) we can say

   if want(numeric) { ... }

to identify both, or is "num" the base class to test for, and "int" a 
subclass?  (I'm pretty much assuming "bit" is a number too, but never 
mind that now.)

I know that this has been covered before, way back, but my memory fails 
me.  Just trying to polish up what I wrote.

MikeL

Re: perl6-lang Project Management

[Allison Randal]

Nicholas Clark wrote:
> 
> Not good. 5 patches means that 4 people wasted effort trying to help.
> I don't have a solution to this problem (sorry). But I think it's an
> important problem to solve.

Wasted effort is a problem. I don't know that a perfect solution exists.
Parrot's solution of making patches public on the list seems like a
pretty good one. Asking if the work has already been done before you
take on the task also helps.

>   What would facilitate the edit/review process so that the time taken to
>   apply a patch gets reduced?

Some things just take time.

> Failing that
> 
>   Is there a good way to have the apocalypse documents annotated in some way
>   with the lines or sections that are subject to a pending review?
> 
> If they're being sent as diffs can we automatically mangle the diffs to
> replace the substituted in text with s so that anyone who is thinking of
> supplying a documentation patch can at least see which parts of the docs are
> already pending changes. Is it sensible to make the list of unapproved edits
> available for all to read (bluntly marked as such)

This could probably be done. But the effort involved is prohibitively
greater than simply pushing them through the review process, while the
end result -- an updated document -- is the same without the extra
effort. I wouldn't stop anyone who volunteered to set up something like
that, but we could use that time and talent elsewhere to greater effect.

> I suspect my finite time is better spent on code implementing things.

I agree. Keep up the good work.

Allison

Re: String -> Numeric conversion

[Luke Palmer]

> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Wed, 6 Nov 2002 14:53:37 -0800
> From: Michael Lazzaro <[EMAIL PROTECTED]>
> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
> 
> 
> If anyone knows the answer to these two questions, I'd appreciate it.
> 
> 1) What do these do?
> 
> my int $n = 5;   # OK
> my int $n = 5.005;   # trunc or err?

Trunc.  Int context, you know :)

> my int $n = "5.05ff" # 5, 0, undef, NaN, or exception?

If it's like Perl5, 5.05.  But there could be reason to make it an
exception.  Dunno on that one.  I would say 5.05 for now, until
someone with authority corrects it.

> my int $n = "fdsjfdf"# 0, undef, NaN, or exception?

Likewise here.  There could also be reason to have this behave
differently from the last one.  Though, I would say 0 for now.

> 
> 2) Do "num" and "int" share a common base "is a number" class, such 
> that (in perl5-ish speak) we can say
> 
> if want(numeric) { ... }
> 
> to identify both, or is "num" the base class to test for, and "int" a 
> subclass?  (I'm pretty much assuming "bit" is a number too, but never 
> mind that now.)

I believe this was the plan.  Remember, there was int context and num
context, so a natural extension would be that conclusion.

As for your documentation plan, I think it's a good idea, though I
concur with Dan on Just Do It.  Document the language for what best
makes sense now.  If there are *big* issues, ask Larry et al. on this
list.  For the little ones, use common sense and they will be hashed
out later.

Luke

Re: perl6-lang Project Management

[Simon Cozens]

This is getting silly.

[EMAIL PROTECTED] (Michael Lazzaro) writes:
> Seriously, don't patronize me: it won't get you anywhere productive,
> and it just ticks me off.  I am not _unaware_ of the current Perl6
> dynamics and management decisions; on the contrary, I am observing
> that the current approach has resulted in _profoundly_ little progress
> per unit time, given the pool of available labor and talent at our
> disposal, and has resulted in us revisiting decisions *repeatedly*
> whenever previous designs are more fully worked out.

I think you're equating a pool of "available" talent and labor with
a pool of willing talent and labour. Everyone is willing to offer
suggestions, but few people - you being one of the few - are willing
to put the time into thrashing these suggestions out into a coherent
set of documentation.

Here is my suggested solution to the problem.

   1) We find a team of volunteers who are willing to "own" the task of
  converting each Apocalypse into a complete design. If nobody wants
  to write the Perl 6 user manual, then we might as well give up and 
  go home now. So far we only need to find four, though, so it Might
  Just Work.
   2) Each Apocalypse gets a mailing list. Questions about a particular
  topic ought to be directed to the appropriate list. (Where possible.)
   3) Each "subdesigner" is responsible both for monitoring p6l and the
  Apo mailing list for discussion of the topics covered, (and pointing 
  people to the archives where necessary) and also raising questions
  when the fleshing-out process gets stuck. Delegation of some of the
  process to other mailing list members is encouraged.
   4) The subdesigner (or his appointed secretary[1]) summarizes the thread,
  ideally in the following manner:

   What does this code output?

   ...

   I think it should output XXX, because ...
   Joe Bloggs thinks it should output YYY, because ...

5) This summary is taken back to p6l, where interaction between Apocalypses
   can be thrashed out. Further points are noted and added to the summary.
   An arbitrary moratorium should be set when the summary is posted to p6l.
6) The summary gets sent to Allison, who circulates it to the rest of the
   design team, and an arbitration is made.
7) The arbitration gets turned into two things: a test case, and a change
   to the user manual.
8) Both are submitted back to Allison for checking.

Does that save any time or make any sense?

[1] You can tell I've been rereading MMM...

-- 
I'm surrounded by electromagnetic radiation all the time. There are radio
stations broadcasting at lots of kW, other people using phones, the police, 
[...] the X-rays coming from my monitor, and God help us, the sun. I figure 
I have better things to worry about than getting cancer from the three or 
four minutes a day I spend on my cell phone. - Dave Brown.

Re: perl6-lang Project Management

[Dan Sugalski]

At 11:15 PM + 11/6/02, Simon Cozens wrote:

I think you're equating a pool of "available" talent and labor with
a pool of willing talent and labour. Everyone is willing to offer
suggestions, but few people - you being one of the few - are willing
to put the time into thrashing these suggestions out into a coherent
set of documentation.


This is an important observation most people miss. You can (and I've 
dealt with quite a few) find people who will spend hours, days, or 
weeks of their lives writing email discussing some damn thing or 
other that doesn't exist, yet never actually make that thing exist 
even if it'd only take an hour or two to do.

Here is my suggested solution to the problem.


And, though, snipped, a fine solution it is, with two caveats:

1) There *must* be someone who will drive the discussion, or it will 
wander off into some bizarre corner and die

2) Under no circumstances can Larry be allowed to subscribe, or even 
read, the lists. :)
--
Dan

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

Re: perl6-lang Project Management

[Simon Cozens]

[EMAIL PROTECTED] (Dan Sugalski) writes:
> 1) There *must* be someone who will drive the discussion, or it will
> wander off into some bizarre corner and die

That's the job of the Apo pumpkin.

> 2) Under no circumstances can Larry be allowed to subscribe, or even
> read, the lists. :)

I thought that was so obvious it wasn't worth mentioning. :)

-- 
Do you associate ST JOHN'S with addiction to ASIA FILE?
- Henry Braun is Oxford Zippy

Re: perl6-lang Project Management

[Michael Lazzaro]

On Wednesday, November 6, 2002, at 03:34  PM, Dan Sugalski wrote:


At 11:15 PM + 11/6/02, Simon Cozens wrote:

Here is my suggested solution to the problem.


And, though, snipped, a fine solution it is, with two caveats:

1) There *must* be someone who will drive the discussion, or it will 
wander off into some bizarre corner and die

2) Under no circumstances can Larry be allowed to subscribe, or even 
read, the lists. :)

I would also add the observation that there really only need be one 
discussion, going through the issues in series...  The higher-numbered 
issues depend pretty extensively on details of the lower-numbered ones; 
plus, I think having the same dedicated voices, ongoing (rather than 
different voices working in parallel) would achieve better results and 
still be sufficiently fast

Plus, one group would not be nearly as distracting to the ongoing 
design efforts as it would be to have N groups all pinging with 
questions simultaneously, which is what we already have.  :-/

MikeL

Re: perl6-lang Project Management

[Dan Sugalski]

At 11:39 PM + 11/6/02, Simon Cozens wrote:

[EMAIL PROTECTED] (Dan Sugalski) writes:
 > 2) Under no circumstances can Larry be allowed to subscribe, or even

 read, the lists. :)


I thought that was so obvious it wasn't worth mentioning. :)


It's the blatantly obvious stuff that gets missed the most. ;)
--
Dan

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

Re: list comprehensions

[Piers Cawley]

"Adam D. Lopresto" <[EMAIL PROTECTED]> writes:

>> I don't see why I'd want to do it with arrays, but...
>> 
>> %a_students = %grades{grep /^a/i, keys %grades};
>
> Looks like that's just the same as 
>
> %a_students = grep {.key ~~ :i/^a/}, %grades.kv;

I think you could probably get away without the .kv there since, in a
list context you're going to get a list of pairs anyway.

-- 
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?

Re: String -> Numeric conversion

[Piers Cawley]

Luke Palmer <[EMAIL PROTECTED]> writes:

>> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
>> Date: Wed, 6 Nov 2002 14:53:37 -0800
>> From: Michael Lazzaro <[EMAIL PROTECTED]>
>> X-SMTPD: qpsmtpd/0.12, http://develooper.com/code/qpsmtpd/
>> 
>> 
>> If anyone knows the answer to these two questions, I'd appreciate it.
>> 
>> 1) What do these do?
>> 
>> my int $n = 5;   # OK
>> my int $n = 5.005;   # trunc or err?
>
> Trunc.  Int context, you know :)
>
>> my int $n = "5.05ff" # 5, 0, undef, NaN, or exception?
>
> If it's like Perl5, 5.05.  But there could be reason to make it an
> exception.  Dunno on that one.  I would say 5.05 for now, until
> someone with authority corrects it.
>
>> my int $n = "fdsjfdf"# 0, undef, NaN, or exception?
>
> Likewise here.  There could also be reason to have this behave
> differently from the last one.  Though, I would say 0 for now.

Well, it's restricted to either 0 or an exception since you can't use
an int to store anything else (like, for instance the PMCs associate
with either undef or NaN).

Hmm, what does

NaN.isa('Number')

return?

-- 
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?

Re: [perl #18219] on_exit not portable

[Josh Wilmes]

At 15:57 on 11/06/2002 EST, Dan Sugalski <[EMAIL PROTECTED]> wrote:

> >This is was I did say above, just put comments around above 
> >statement if tinderboxen are the concern.
> 
> Yeah, I think I'll do that for right now. What I'd like is a probe 
> for this in configure. Oh, Brent :)

If an on-exit cleanup is required for parrot to not leak memory, then 
simply probing for on_exit in configure won't be sufficient;  that's why a 
platform.c implementation of Parrot_[on_]exit would be needed.

--Josh

Primitive Vs Object types

[David Whipp]

Every primitive type has an associated object type, whose name differs only
by capitalized first letter. A few posts back, Larry mentioned that perhaps
similar things should look different: this may be a good case to apply this
principle.

Whenever a value passes through a primitive type, it loses all its run-time
properties; and superpositions will collapse. I worry that this could cause
very obscure bugs: made worse by the invisibility of the difference between
primitive and object types. I would propose that, at the very least, users
should be required to C before using such things.
Furthermore, I can't help feeling that it would be better to use the
lower-case versions for the common-case: the object-types (and rename the
pimitives to something like C<_prim_int32>, or C). I am
hopeful that the optimiser will be sufficiently clever to notice the obvious
cases where a primitive can be used, so why distract the user?


Dave.

--
Dave Whipp, Senior Verification Engineer,
Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086
tel: 408 523 8071; http://www.fast-chip.com
Opinions my own; statements of fact may be in error. 

Re: Primitive Vs Object types

[Dan Sugalski]

At 6:50 PM -0800 11/6/02, David Whipp wrote:

Whenever a value passes through a primitive type, it loses all its run-time
properties; and superpositions will collapse.


What makes you think so, and are you really sure?
--
Dan

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

RE: Primitive Vs Object types

[David Whipp]

Dan Sugalski [mailto:dan@;sidhe.org] wrote:
> At 6:50 PM -0800 11/6/02, David Whipp wrote:
> > Whenever a value passes through a primitive type, it
> > loses all its run-time properties; and superpositions
> > will collapse.
> 
> What makes you think so, and are you really sure?

I was sure up until the time that I read your reply :).

Why? I guess its a case of ass/u/me; plus reading other
people's assumptions (e.g. Michael Lazzaro's initial
"Chapter", at cog.cognitivity.com/perl6/val.html).

If I am wrong, then I am in need of enlightenment. What
is the difference between the primitive types and their
heavyweight partners? And which should I use in a typical
script?


Dave.

RE: Primitive Vs Object types

[Dan Sugalski]

At 8:24 PM -0800 11/6/02, David Whipp wrote:

If I am wrong, then I am in need of enlightenment. What
is the difference between the primitive types and their
heavyweight partners? And which should I use in a typical
script?


The big difference is there's no way you can ever truly get a 
primitive type in perl 6. (At least so primitive that you can't hang 
properties off it)
--
Dan

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

Re: Primitive Vs Object types

[Michael Lazzaro]

David Whipp wrote:
> 
> Dan Sugalski [mailto:dan@;sidhe.org] wrote:
> > At 6:50 PM -0800 11/6/02, David Whipp wrote:
> > > Whenever a value passes through a primitive type, it
> > > loses all its run-time properties; and superpositions
> > > will collapse.
> >
> > What makes you think so, and are you really sure?

 Why? I guess its a case of ass/u/me; plus reading other
> people's assumptions (e.g. Michael Lazzaro's initial
> "Chapter", at cog.cognitivity.com/perl6/val.html).

Oh, no you don't... don't pin this one on me.  :-)

> If I am wrong, then I am in need of enlightenment. What
> is the difference between the primitive types and their
> heavyweight partners? And which should I use in a typical
> script?

It has been stated multiple times that primitive types can't take
runtime properties or other "object-like" features, so that they may be
as lightweight as possible -- flyweight classes, as it were.

Primitive types were originally intended for runtime speed, thus an
"int" or a "bit" is as small as possible, and not a lot of weird runtime
checking has to take place that would slow it down.  It can't even be
undef, because that would take an extra bit, minimum, to store. 
Promoted types, on the other hand, can do all that stuff -- that's the
whole reason there are two separate versions of each "type".  It allows
some credible possibility of optimal runtime efficiency in Perl6, when
it's important to you.

It is not necessarily a given that the behavior will hold true for
superpositions.  In fact, it is hypothetically possible (tho almost
certainly unworkable) that typechecking on primitives wouldn't really
enforce true primitiveness at all, but merely acts as a "suggested"
type, trading optimal efficiency for more moderate efficiency (but
meaning you _could_ store an undef, etc. in a hole meant for a
primitive: it'll just have to assume more runtime checks then it
originally would for a "true" primitive.)  Or it may be that storing in
primitive type does indeed enforce maximal efficiency, and that you
should use the promoted types when you don't want that.  Dunno.

MikeL

RE: Primitive Vs Object types

[David Whipp]

Dan Sugalski [mailto:dan@;sidhe.org] wrote:

> At 8:24 PM -0800 11/6/02, David Whipp wrote:
> >If I am wrong, then I am in need of enlightenment. What
> >is the difference between the primitive types and their
> >heavyweight partners? And which should I use in a typical
> >script?
> 
> The big difference is there's no way you can ever truly get a 
> primitive type in perl 6. (At least so primitive that you can't hang 
> properties off it)

I hope I'm not being stupid here, but isn't that a lack-of difference.
Michael has just confirmed that 'It has been stated multiple times that
primitive types can't take runtime properties or other "object-like"
features', so now I'm confused. Here's a list of things that ints/Ints might
do, and my previous understanding of if they can:

   int  Int
1 store 32-bit number   YY
2 store "larger" number NY
3 store undef   NY
4 have properties   NY
5 be junctions  NY

It appears that you're saying that (4) is incorrect; and if this is wrong,
then (3) is probably wrong too. I wouldn't be surprised if this means that
(5) is wrong also, so this would just leave (2): Ints are bigger than ints.

My original proposal still stands: represent these differences as a
(compile-time) property, not a new type. Failing that, use typenames that
are more distinctive (e.g. BigInt, or int32).


Dave.

Re: Primitive Vs Object types

[John Williams]

I gotta admit that this issue is bugging me too.  Larry mentions (in
)
that all-uppercase is "ugly" and has "boundary conditions".
Maybe it would be helpful to know what conditions are causing problems.

All-lowercase implies that we want them to be used *more* than the object
types.  But it seems like we should encourage the use of the object types.
Maybe that's because we want to discourage undef values, but I've been
programming databases too long, so I like undefs now.

We certainly don't want to discourage using the autopromoting Int -> Long
-> Bignum features of the object types, do we?

Also the typecasting functions have been defined in all lower case, which
would suggest to the naive user that they will typecast to primitive
types, and perhaps even throw an exception when an undef is cast.


On Wed, 6 Nov 2002, Michael Lazzaro wrote:
> David Whipp wrote:
> > Dan Sugalski [mailto:dan@;sidhe.org] wrote:
> > > At 6:50 PM -0800 11/6/02, David Whipp wrote:
> > > > Whenever a value passes through a primitive type, it
> > > > loses all its run-time properties; and superpositions
> > > > will collapse.
> > >
> > > What makes you think so, and are you really sure?
>
> > If I am wrong, then I am in need of enlightenment. What
> > is the difference between the primitive types and their
> > heavyweight partners? And which should I use in a typical
> > script?
>
> It has been stated multiple times that primitive types can't take
> runtime properties or other "object-like" features, so that they may be
> as lightweight as possible -- flyweight classes, as it were.
>
> Primitive types were originally intended for runtime speed, thus an
> "int" or a "bit" is as small as possible, and not a lot of weird runtime
> checking has to take place that would slow it down.

I don't think the point is to store them as "small" as possible, but as
"efficiently"  as possible.  That is, in whatever register size the
hardware works best on.  We don't want to compact unrelated bits into
a single hardware address, because then we are forced to do extra masking
and shifting everytime we want to use the value.

~ John Williams

Re: perl6-lang Project Management

[Allison Randal]

Dan Sugalski wrote:
> Simon Cozens wrote:
> 
> >Here is my suggested solution to the problem.
> And, though, snipped, a fine solution it is, with two caveats:

There's potential here. If we arrange it so Larry can stay focused and
the total productivity of the project increases, we'll have a good
thing. Let's fill in the details as we go.

Michael, why don't you talk to Casey West? He'll have valuable insights
from his experience with the Perl 5 documentation project. 

Allison

Re: [CVS ci] string_set is back for a faster live - not only

[Peter Gibbs]

Leopold Toetsch wrote:
> Fine. But how do we know, which version we could take. Please read again
> Peter's example. It depends on the semantics of Sx register usage all
> over the program IMHO.

In an attempt to clarify the positions here, let us start with a shorter
example:
  set S0, "zero"
  set S1, "one"
  set S0, S1

The first line will create a new string header, which will COW-reference
the constant string data "zero", and store the address of that header
in register S0.
The second line creates another string header, COWing to "one",
and stores its address in register S1.
The third line could do any of the following:
   a) Create a new string header, COW-referencing string "one",
  and store that new address in register S0
   b) Re-use the existing string header created in line 1, changing
  it to point to string "one"; the register does not change
   c) Store the address of the string header created in line 2 into
  string register S0; no headers are affected in any way
The current implementation is (c).
Does anybody believe this should be different?

An extended version of my previous example follows, as it points
out some more inconsistent behaviour.
--
Peter Gibbs
EmKel Systems

  set S0, "test"
  set S1, S0
  set S2, "another"
  substr S0, S2, 1, 3
  print S1
  print "\n"

  set S0, "test"
  new P1, .PerlString
  set P1, S0
  set S2, "another"
  substr S0, S2, 1, 3
  print P1
  print "\n"

  set S0, "test"
  new P1, .PerlArray
  set P1[0], S0
  set S2, "another"
  substr S0, S2, 1, 3
  set S3, P1[0]
  print S3
  print "\n"

  set S0, "test"
  new P1, .PerlHash
  set P1["a"], S0
  set S2, "another"
  substr S0, S2, 1, 3
  set S3, P1["a"]
  print S3
  print "\n"

  end