This week's Perl 6 Summary
The Perl 6 Summary for the week ending 20030209 Welcome to the latest Perl 6 summary, your handy cut out and keep guide to the goings on in the crazy world of Perl 6 design and development. It's been a rather quiet week this week; only 75 messages in perl6-internals and a mere 57 in perl6-language. So, at least it's palindromic. We start off, as is traditional, with perl6-internals The 2004 Performance challenge Dan announced that he'd made a bet with Guido van Rossum that Parrot would be faster at executing a pure python benchmark of some sort to be determined. The details of the challenge will be announced at OSCON 2003 and the results at OSCON 2004. Dan stands to lose $10 and a round of beer for the Zope/Pythonlabs folks. (Dunno how many of them there are though...). We don't know what he stands to win yet, but I'd hope 'beers from each of the Zope/Pythonlabs folks' are included. For some reason nobody commented on this. http://makeashorterlink.com/?K2C815C63 More Parrot Objects Jerome Quelin wondered how Parrot objects would handle property inheritance. Dan pointed out that properties don't get inherited and Jerome realised he meant to ask about attribute inheritance. Attributes *are* inherited but are mostly invisible to any methods but the methods of the class that defines the attributes (though they will be accessible (presumably through reflection)). In another subthread, we got confused by multimethods. http://makeashorterlink.com/?O6D816C63 http://makeashorterlink.com/?O4E822C63 -- Multimethods Bytecode Metadata James Michael DuPont wanted to know what had been decided about Bytecode metadata and outlined the things that he'd like to know about a given bytecode. Leo Tötsch reckoned that what James wanted was either in the bytecode right now, or was handleable by the framework that was in place. He pointed James to docs/parrotbyte.pod in the Parrot distribution. Further discussions centred on the *amount* of metadata and whether this would affect loading speed and efficiency, or get in the way of the desired 'mmap and go' principle. Jürgen Bömmels pointed out that we also had to be capable of passing meta data from a compiler 'through' IMCC and on to the final bytecode. There was also a touching reunion between James Michael DuPont and Gopal V. Ah... http://makeashorterlink.com/?E41925C63 Multi programming language questions Phil Hassey has been lurking, fascinated on the internals list for a couple of months. This week he broke the silence by asking a couple of questions about cross language function dispatch, string compatibility and global scopes. For instance, PHP, Common Lisp and others are case insensitive about functions. Which is okay when you're calling such a function from a case sensitive language, but can be tricky if you call out from a case insensitive to a case sensitive language. Dan thought that there wasn't going to be much that could be done about this problem (at least, not transparently) but seems to think that the other issues raised shouldn't be too problematic. http://makeashorterlink.com/?R32931C63 Random questions David popped up and, after remarking on the amount of progress Parrot had made since he last looked at it, had a few questions about various bits and pieces. Leo and Dan provided a bunch of good answers. http://makeashorterlink.com/?X63912C63 A Scheme for extending core.ops Leo Tötsch seems to have got bored of 'just' being the Patch Monster and has been producing some discussion documents proposing all sorts of useful tricks for improving the design/speed/extensibility of Parrot's internals. This week he turned his attention to core.ops. His plan involves a way of reducing the size of core_ops, improving cache locality and generally solving a raft of problems I didn't even know Parrot had. His new scheme allows for a small core.ops, easy extension and no execution speed penalty for non core ops. As is usual with Leo's stuff, the scheme came with code. Gregor had a bunch of observations and suggestions and he and Leo thrashed out a slightly modified scheme for going forward. http://makeashorterlink.com/?P54921C63 Week of the alternative runloops Leo Tö offered a couple of different core runloops this week. First up was the Computed Goto Prederefed (CGP) runloop which, essentially combined a two runloop optimization techniques to provide what can only be described as massive speedups. The -O3 compiled version ran parrot_mops 6 times faster than the basic 'fast_core' and more than 3 times faster than the previous fastest core. People were impressed. A few days later, Leo reached into his bag of tricks and pulled out the CSwitch runloop that did
Re: Arrays vs. Lists
On Monday, February 10, 2003, at 05:56 PM, Luke Palmer wrote:
Indeed, this supports the distinction, which I will reiterate:
- Arrays are variables.
- Lists are values.
My hesitation about the 'arrays are variables' part is that Damian
corrected me on a similar thing when I was writing about scalars. A
variable is more like a name of a container for a value, e.g. there's
three parts to it:
- the name (what it's called in the namespace)
- the container (a specific container implementation)
- the value (what's inside it)
So I don't know that arrays are variables, so much as arrays are
containers, if we want to get pedantic about it (which I don't, but...
documentation... sigh).
Just to clarify... in P6, is this an array reference, or a list
reference?
[1,2,3]
What about this?
\@array
I'd say both of them are array references, but there's no variable
associated with the first one -- it's just an anonymous container. So
I'd rewrite the definition to:
- Lists are an ordered collection of scalar values
- Arrays are containers that store lists
(Coupled with Uri's explanations, of course... it's the 'container'
part that allows read/write, as opposed to simply read.) Yes/no?
Arrays are things that know about lists. They know how to get a
particular element out of a list. They know how to *flatten
themselves, interpolating themselves into the surrounding list. They
know how to map, grep, sort, splice themselves. They know how to turn
themselves into a scalar. Lists don't know how to do these things.
But is it OK for a list to be silently promoted to an array when used
as an array? So that all of the following would work, and not just 50%
of them?
(1..10).map {...}
[1..10].map {...}
(@a,@b,@c).pop
[@a,@b,@c].pop
MikeL
Re: Arrays vs. Lists
On Monday, February 10, 2003, at 06:26 PM, Joseph F. Ryan wrote: Deborah Ariel Pickett wrote: (Just going off on a tangent: Is it true that an array slice such as @array[4..8] is syntactically equivalent to this list (@array[4], @array[5], @array[6], @array[7], @array[8]) ? Are array slices always lists in Perl6?) I think so, unless its possible to do crazy things like reference part of an array. Maybe @array[4..8] is a list, and \@array[4..8] acts like an array. Or maybe \@array[4..8] is actually ( \@array[4], \@array[5], \@array[6], \@array[7], \@array[8]), like it is in perl 5. If it keeps that behaivor, then @array[4..8] is always a list. What is the utility of the perl5 behavior: \($a,$b,$c) meaning (\$a, \$b, \$c) Do people really do that? I must say, given that it looks *so obviously* like it instead means [$a,$b,$c], I wonder if attempting to take a reference to a list should be a compile-time error. Note that this is still OK: \($a) # same as \$a because as previously discussed, it's the commas making the list, not the parens. But \($a,$b,$c) seems like a bug waiting to happen. I don't use it. Can someone give an example of an actual, proper, use? What joy I'll have explaining that one to my students . . . Groan. Yeah. I feel your pain. :-| MikeL
RE: Arrays vs. Lists [x-adr]
From: Michael Lazzaro [mailto:[EMAIL PROTECTED]]
Just to clarify... in P6, is this an array reference, or a list
reference?
[1,2,3]
Exactly. It's still up in the air...
Apoc 2, RFC 175:
So it works out that the explicit list composer:
[1,2,3]
is syntactic sugar for something like:
scalar(list(1,2,3));
Depending on whether we continue to make a big
deal of the list/array distinction, that might
actually be spelled:
scalar(array(1,2,3));
What about this?
\@array
hmm. As perl Apoc2, Lists, RFC 175... arrays and hashes return a reference
to themselves in scalar context... I'm not sure what context '\' puts them
in.
I'd guess \@array is a reference to an array reference.
I'd say both of them are array references, but there's no variable
associated with the first one -- it's just an anonymous
container. So
I'd rewrite the definition to:
- Lists are an ordered collection of scalar values
- Arrays are containers that store lists
(Coupled with Uri's explanations, of course... it's the 'container'
part that allows read/write, as opposed to simply read.) Yes/no?
I'd just stick with Uri's explanation. Arrays are allocated. Lists are on
the stack...
It doesn't need improving... The only question is whether it is still
accurate in the _context_ of Perl6 ;)
But is it OK for a list to be silently promoted to an array when used
as an array? So that all of the following would work, and
not just 50% of them?
(1..10).map {...}
[1..10].map {...}
(@a,@b,@c).pop
[@a,@b,@c].pop
There's only one person who can answer that... and he's not reading ;)
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
Re: Arrays vs. Lists [x-adr]
[Recipients trimmed back to just p6-language; the Cc: list was getting a bit large.] On 2003-02-11 at 12:56:45, Garrett Goebel wrote: I'd just stick with Uri's explanation. Arrays are allocated. Lists are on the stack... Nuh-uh. Those are implementation details, not part of the language definition. From the standpoint of the Perl6 language, in the magical world where that language is executed directly with no need of interpreters, compilers, etc., what (if anything) is the distinction between an array and a list? I like the arrays are containers that hold lists explanation, assuming it's valid. Also, I would be very surprised if \@array returned a reference to a reference. I would assume that the \ forces scalar context and therefore interpretation as a reference. So these two statements would be equivalent: $ref = @array; $ref = \@array; As would these: print \@array; print scalar(@array); -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists [x-adr]
On Tuesday, February 11, 2003, at 10:56 AM, Garrett Goebel wrote: What about this? \@array hmm. As perl Apoc2, Lists, RFC 175... arrays and hashes return a reference to themselves in scalar context... I'm not sure what context '\' puts them in. I'd guess \@array is a reference to an array reference. I understand the logic, but: my $r = @a; # ref to @a my $r = \@a; # ref to ref to @a ??? my @array = (\@a,\@b,\@c); # array of three arrayrefs Boy howdy, I think that would freak people. But making '\' put them in list context would of course be far worse: @array = (\@a); # means @a = ( \@a[0], \@a[1], ... ) ??? So I think '\' just puts things in CRef context, which solves the problem and always does The Right Thing, I think. So the context rules for arrays are: - in scalar numeric context, returns num of elements - in scalar string context, returns join of elements - in scalar ref context, returns a ref - in generic scalar context, returns a ref IMO. MikeL
Re: Arrays vs. Lists
Michael Lazzaro wrote:
On Monday, February 10, 2003, at 05:56 PM, Luke Palmer wrote:
Indeed, this supports the distinction, which I will reiterate:
- Arrays are variables.
- Lists are values.
My hesitation about the 'arrays are variables' part is that Damian
corrected me on a similar thing when I was writing about scalars. A
variable is more like a name of a container for a value, e.g.
there's three parts to it:
- the name (what it's called in the namespace)
- the container (a specific container implementation)
- the value (what's inside it)
So I don't know that arrays are variables, so much as arrays are
containers, if we want to get pedantic about it (which I don't, but...
documentation... sigh).
They're definately variables. The container is a PerlArray,
which is a distinctly different object compared to a
PerlUndef.
Just to clarify... in P6, is this an array reference, or a list
reference?
[1,2,3]
I'd say it is an array reference.
What about this?
\@array
I'd say both of them are array references, but there's no variable
associated with the first one -- it's just an anonymous container
There should be a variable attached, but just no name
attached to the variable.
So I'd rewrite the definition to:
- Lists are an ordered collection of scalar values
- Arrays are containers that store lists
(Coupled with Uri's explanations, of course... it's the 'container'
part that allows read/write, as opposed to simply read.) Yes/no?
Maybe :-)
Arrays are things that know about lists. They know how to get a
particular element out of a list. They know how to *flatten
themselves, interpolating themselves into the surrounding list. They
know how to map, grep, sort, splice themselves. They know how to turn
themselves into a scalar. Lists don't know how to do these things.
But is it OK for a list to be silently promoted to an array when used
as an array
But this would mean that an implicit anonymous array would need
to be created, which isn't always possible in the middle of a
statement. So, that would mean the compiler would need to be
smart enough to figure out when this will happen, and then
create the anonymous array beforehand, and then somehow
alias the list contents to the array. Thats a heck of a lot
of magic going on there.
So that all of the following would work, and not just 50% of them?
(1..10).map {...}
I think this should be an error. What object is the method
getting called on?
Is forcing the functional syntax on lists really that horrible?
[1..10].map {...
I think this *should* work, although I'm not sure *how*.
(@a,@b,@c).pop
This doesn't make any sense, since pop modifies the pop-ee.
What do you expect should happen here?
[@a,@b,@c].pop
Same as above.
Joseph F. Ryan
[EMAIL PROTECTED]
Re: Arrays vs. Lists
On 2003-02-11 at 17:12:52, Joseph F. Ryan wrote:
(@a,@b,@c).pop
This doesn't make any sense, since pop modifies the pop-ee.
What do you expect should happen here?
[@a,@b,@c].pop
Same as above.
Except that the Perl5 equivalent, ugly as the syntax may be, works fine:
pop @{[@a,@b,@c]}
It creates an anonymous array, then removes the last element, leaving two
elements in the array - which is irrelevant since the array is
then discarded completely.
I don't see any reason to change this behavior for Perl6.
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists
On 2003-02-11 at 17:44:08, Mark J. Reed wrote:
pop @{[@a,@b,@c]}
It creates an anonymous array, then removes the last element, leaving two
elements in the array - which is irrelevant since the array is
then discarded completely.
Minor correction: we don't know how many elements are left in the
array - it depends on how many elements were in @a, @b, and @c to
start with. One less than that. :)
--
Mark REED| CNN Internet Technology
1 CNN Center Rm SW0831G | [EMAIL PROTECTED]
Atlanta, GA 30348 USA | +1 404 827 4754
Re: Arrays vs. Lists
JFR == Joseph F Ryan [EMAIL PROTECTED] writes:
(@a,@b,@c).pop
JFR This doesn't make any sense, since pop modifies the pop-ee.
JFR What do you expect should happen here?
[@a,@b,@c].pop
JFR Same as above.
there is a subtle distinction in those two. the first should be a syntax
error. the second isn't an error but isn't needed. you could just
as easily do ( @a, @b, @c )[-1].
and the equivilent works in perl5. dumb, but it works.
perl -le 'print pop( @{[qw(a b c)]} )'
c
and i haven't seen anything in perl6 that drastically changes the
semantics of lists and arrays from perl5. so the current definitions we
have been tossing about should suffice.
minor variation:
an array (anon or named) is a container that holds a list. the
array container itself can be modified. containers can stay
alive as long as you want.
a list is a ordered bag of values. it is alive
only where it is created in the current expression. the list
cannot be modified.
uri
--
Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com
- Stem and Perl Development, Systems Architecture, Design and Coding
Search or Offer Perl Jobs http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class
Re: Arrays vs. Lists
Michael Lazzaro [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... What is the utility of the perl5 behavior: \($a,$b,$c) meaning (\$a, \$b, \$c) Do people really do that? I must say, given that it looks *so obviously* like it instead means [$a,$b,$c], I wonder if attempting to take a reference to a list should be a compile-time error. If you make the ListRef an error, can we hyper- the reference operator to achieve the Perl5 behavior?
RE: Arrays vs. Lists
Dave Whipp:
# Minor correction: we don't know how many elements are left in the
# array - it depends on how many elements were in @a, @b, and @c to
# start with. One less than that. :)
#
# These days you need the splat operator to flatten lists: so
My understanding was that arrays would flatten implicity in list
context, and the splat was only to be used in cases like subroutine
calls, when an array would normally ref-ify.
--Brent Dax [EMAIL PROTECTED]
@roles=map {Parrot $_} qw(embedding regexen Configure)
How do you test this 'God' to prove it is who it says it is?
If you're God, you know exactly what it would take to convince me. Do
that.
--Marc Fleury on alt.atheism
Arrays, lists, referencing (was Re: Arrays vs. Lists)
But is it OK for a list to be silently promoted to an array when used
as an array? So that all of the following would work, and not just 50%
of them?
(1..10).map {...}
[1..10].map {...}
And somehow related to all this . . .
Let's assume for the moment that there's still a functional version of
the Cmap operator (I think Larry indicated that it probably wouldn't
be going away, despite ~ and friends). I'm also going to use $_ in the
code block, even though things like $^a exist. Lowest common
denominator and all that.
Let's also assume:
@count = (1, 2, 3, 4, 5);
@smallcount = (2, 3, 4);
$#array works like in Perl5 (if not, you can mentally change my
notation below)
What's the result of these statements in Perl6?
@a = map { $_ + 1 } @count; # my guess: @a = (2, 3, 4, 5, 6)
@a = map { $_ + 1 } @count[0..$#count]; # my guess: @a = (2, 3, 4, 5, 6)
@a = map { $_ + 1 } (1, 2, 3, 4, 5); # my guess: @a = (2, 3, 4, 5, 6)
All fair enough. Now how about these?
@a = map { $_ + 1 } (1, @smallcount, 5); # Three or five elements?
@a = map { $_ + 1 } (1, @smallcount[0..$#smallcount], 5); # Array slices appear to
be lists
@a = map { $_ + 1 } \@count; # Map the array or its reference?
@a = map { $_ + 1 } [1, 2, 3, 4, 5]; # one-element list or five-element array?
$ref = @count;
@a = map { $_ + 1 } $ref; # Map the scalar or the array it refers to?
@a = map { $_ + 1 } @count;# Am I sure about this one any more, given the one
above?
There's a slippery slope here that needs propping up.
It's things like this that make me worry a great deal about implicit
dereferencing, something which is going to be happening a lot more in
Perl6 than in Perl5.
Where's the list of rules that state:
- when implicit referencing happens
- when implicit dereferencing happens
- when arrays are flattened into lists, and
- how to stop this from being the default, and
- how to make it happen when it isn't the default
- how arrays of pairs, lists of pairs (i.e., hash literals)
and hashes are related, and when one can be substituted for
another (and when one is implicitly converted to another)
?
I think some of this is in A2, but not all of it.
I'm prepared to summarize the outcome of this discussion if we actually
arrive at anything definite.
--
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
Oh, she's got it bad. What? What has she got? Isn't it obvious, Daddy?
Ariel's in *love*. - _The Little Mermaid_
Re: Arrays vs. Lists
Michael == Michael Lazzaro [EMAIL PROTECTED] writes: Michael Do people really do that? I must say, given that it looks *so Michael obviously* like it instead means [$a,$b,$c], I wonder if attempting to Michael take a reference to a list should be a compile-time error. Michael Note that this is still OK: Michael \($a) # same as \$a Michael because as previously discussed, it's the commas making the list, not Michael the parens. But \($a,$b,$c) seems like a bug waiting to happen. I Michael don't use it. Can someone give an example of an actual, proper, use? It was to make pass by reference easier, before prototypes if I recall: myfunc \($a, @b, %c); which means the same as if we had said: sub myfunc (\$ \@ \%); myfunc($a, @b, %c); Except that the prototyped version mandates the specific types. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
regex matching from a position ?
Hello everybody,
I've sometimes the task to analyse a string
starting from a given position, where this position
changes after each iteration. (like index() does)
As this is perl there are MTOWTDIIP but I'd like
to know the fastest.
So I used Benchmark.pm to find that out. (script attached)
Excerpt from script:
from_start = sub { m/\S*\s+(\S+)/; },
re_dyn = sub { m/^[\x00-\xff]{$pos}\S*\s+(\S+)/; },
re_once = sub { m/^[\x00-\xff]{$pos}\S*\s+(\S+)/o; },
substr = sub { substr($_,$pos) =~ m/\S*\s+(\S+)/; },
substr_set = sub { $tmp=substr($_,$pos); $tmp =~ m/\S*\s+(\S+)/; },
from_start is for comparision only as it should be.
re_once is for comparision too as the index can't be adjusted.
(and dynamically recompiling via eval() for changing indexes can't be fast enough)
Results:
2505792 bytes to do ...
Benchmark: timing 100 iterations of from_start, re_dyn, re_once, substr,
substr_set...
from_start: 1 wallclock secs ( 1.26 usr + -0.01 sys = 1.25 CPU) @ 80.00/s
(n=100)
re_dyn: 9 wallclock secs ( 6.52 usr + 0.00 sys = 6.52 CPU) @ 153374.23/s
(n=100)
re_once: 1 wallclock secs ( 1.26 usr + 0.01 sys = 1.27 CPU) @ 787401.57/s
(n=100)
substr: 4 wallclock secs ( 2.36 usr + 0.02 sys = 2.38 CPU) @ 420168.07/s
(n=100)
substr_set: 5 wallclock secs ( 3.23 usr + 0.00 sys = 3.23 CPU) @ 309597.52/s
(n=100)
Rate re_dyn substr_set substrre_once from_start
re_dyn 153374/s -- -50% -63% -81% -81%
substr_set 309598/s 102% -- -26% -61% -61%
substr 420168/s 174%36% -- -47% -47%
re_once787402/s 413% 154%87% ---2%
from_start 80/s 422% 158%90% 2% --
So: every possibility is *much* slower than necessary!
So I propose (I know that I'm a bit late, but who cares ... :-)
a new option for regexes (like each, case-insensitive,
and match- multiple-times) which allows to specify a
position to start matching. That should be *no* overhead!
eg:
$text.m:from500:i /\s*(\S+)/;
Currently the substr() is the fastest available option - unless somebody
has more imagination than me (which I take as given).
So, is there a faster possibility, is that no problem for perl6,
or will something like this be implemented?
Regards,
Phil
#!/usr/bin/perl
use Benchmark qw(cmpthese);
$pos=500;
$runs=100;
$_=`cat /etc/* 2 /dev/null`;
study $_;
print length($_), bytes to do ...\n;
cmpthese($runs,
{
from_start = sub { m/\S*\s+(\S+)/; },
re_dyn = sub { m/^[\x00-\xff]{$pos}\S*\s+(\S+)/; },
re_once = sub { m/^[\x00-\xff]{$pos}\S*\s+(\S+)/o; },
substr = sub { substr($_,$pos) =~ m/\S*\s+(\S+)/; },
substr_set = sub { $tmp=substr($_,$pos); $tmp =~ m/\S*\s+(\S+)/; },
}
);
Re: regex matching from a position ?
From: Ph. Marek [EMAIL PROTECTED]
Date: Wed, 12 Feb 2003 08:42:57 +0100
--Boundary-00=_BsfS+fOE40iabfr
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hello everybody,
I've sometimes the task to analyse a string
starting from a given position, where this position
changes after each iteration. (like index() does)
As this is perl there are MTOWTDIIP but I'd like
to know the fastest.
So I used Benchmark.pm to find that out. (script attached)
Excerpt from script:
from_start = sub { m/\S*\s+(\S+)/; },
re_dyn = sub { m/^[\x00-\xff]{$pos}\S*\s+(\S+)/; },
re_once = sub { m/^[\x00-\xff]{$pos}\S*\s+(\S+)/o; },
substr = sub { substr($_,$pos) =~ m/\S*\s+(\S+)/; },
substr_set = sub { $tmp=substr($_,$pos); $tmp =~ m/\S*\s+(\S+)/; },
from_start is for comparision only as it should be.
re_once is for comparision too as the index can't be adjusted.
(and dynamically recompiling via eval() for changing indexes can't
be fast enough)
Phil, please see the perlfunc entry for pos and the perlre section
on \G. This is what you need.
Luke
