I have been working on the Perl 5 reference implementation of
RFC 88 functionality (Try.pm, which is currently available at:
http://www.avrasoft.com/perl6/try6-ref5.txt ), and I stumbled
across the following result.
If you are writing some code, and there is a "throw" subroutine
in scope, and
Summary: I think these should all simply break down into a single
Boolification test of some sort, as occurs already with operator
overload.
LOGHIGHAND Called in context
LOGHIGHOR Called in || context
LOGLOWAND Called in and context
LOGLOWOR Called in or context
LOGIFELSE
I've read over 161 again and I'm starting to see areas where I can clarify
things greatly. I apologize for the confusion. I'll make mods to the RFC in
the near future, after I get more feedback from you all.
Here are my goals as they probably should have been stated in the RFC:
- Concentrate
On Sun, 27 Aug 2000 06:14:00 -0700, Matt Youell wrote:
So an int gets stored as two bytes and not
four or eight.
Gee, I thought it was more like 30. The savings in bytes don't look too
impressive in this case. 4 byte addition is as fast as 2 byte addition
on most pmodern platforms -- and you
Nathan Torkington wrote:
Damian Conway writes:
sub foo :lvalue { $foo }
post foo { die if $foo == 5 }
eval {
foo() = 5;
};
Postconditions on lvalue subs are not tested until the end of the complete
expression in which the sub is called.
On Thu, Aug 17, 2000 at 08:46:53PM -, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Implicit counter in for statements, possibly $#.
Having read over the entire discussion, I want to make a few comments
and throw
General comment on all the discussion of HERE docs.
When HERE docs cause you a problem, don't use 'em. There is little win
if any over
print HERE;
Dear Sir:
You owe me bucks. Pay up.
Me.
HERE
and
$msg =
'Dear Sir:
You owe
Dan Sugalski wrote:
If the vtable stuff goes into the core perl engine (and it probably will,
barring performance issues), then what could happen in the
my Foo $bar;
case would be that all the vtable functions for Foo are taken as specially
named subs/methods in the Foo package. So,
Damian Conway wrote:
I wouldn't be averse to Cself as the default and Cuse invocant as a sop to
the Cthiserites and C$MEophiles. But *they* might be!
This is baloney. I agree, we need to *pick something*!!
What should we do, make a "rename" pragma so everyone can be happy?
use rename want
On Sun, Aug 27, 2000 at 07:54:35PM -0700, Nathan Wiger wrote:
And why is passing $self in $_[0] a good thing?
Because it eliminates a butt-load of translation to convert Perl5
programs to Perl6 programs. Rather than tracking down each and every
sub and figuring out if it's used as a method
Damian Conway:
My forthcoming proposal will be that invocants still be passed as $_[0]
by default, but that there be a pragma allowing $_[0] to be automagically
shifted somewhere else during dispatch. For example:
sub method { print "I was called through: $_[0]";
Nathan Torkington wrote:
David L. Nicol writes:
Any subroutine declaration, for instance
sub Cmp:infix($$){
return uc($_[0]) cmp uc($_[1])
};
implicitly sets up a "catch unknown-keyword:Cmp" routine; that is,
it installs the name of the function in a
dLux wrote:
/--- On Thu, Aug 24, 2000 at 12:30:25PM -0400, John Porter wrote:
| Still not good. "trans" is too overloaded word. "transaction"?
| "transactional"? (a bit too long...) "atomic"?
|
| "acid"?
\---
"transactional" and "transaction" are quite long, I don't like that.
Dan Sugalski wrote:
I'm thinking that a n-dim array could just be a list of lists (of lists of
lists of...) with the n-dim notation just being syntactic sugar (and perhaps
helping with optimisation too).
If you want efficiency, n-dimensional arrays really need to be a concrete
data type
Fisher Mark [EMAIL PROTECTED] writes:
Leaping to conculusions based on no tests at all is even worse...
Will anyone bite the bullet and write the "Internals Decisions should
be based on actual tests on multiple platforms" RFC ?
BTW, I have access to Rational Software's Quantify (and
On Mon 28 Aug, Bart Lateur wrote:
On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote:
It only removes whitespace,
and it measures whitespace with tabs=8.
My editor is set to tabs=4. Perl's interpretation wouldn't agree with
the visual appearance in my editor. This doesn't sound
Next you'll propose that
print EOL;
blah
EOL; print "OK!\n";
should work too, and print "OK!\n" as well.
Yes why not, though it might be bad style.
Because it gains you nothing, and loses much.
--tom
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Less line noise - let's get rid of @%
=head1 VERSION
Maintainer: Karl Glazebrook [EMAIL PROTECTED]
Date: 15 August 2000
Last Modified: 28 August 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Alternate Syntax for variable names
=head1 VERSION
Maintainer: David Corbin [EMAIL PROTECTED]
Date: 20 Aug 2000
Last Modified: 28 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 133
On Thu, Aug 24, 2000 at 03:40:00PM -, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Case ignoring eq and cmp operators
IMHO this problem is better solved by using =~ and its brethren,
which already allow you to do
On Mon, 28 Aug 2000 08:46:25 -0700, Nathan Wiger wrote:
OTOH, what about this...
print EOL
blah
EOL;
which makes this a full blown statement (note the missing semicolon in
the first line)...
No it doesn't!
perl -e '
print EOF
Hello world!
EOF;
'
Can't
David Corbin wrote:
raptor wrote:
$hash{/re/} i.e. this is the same like
my @res;
foreach my $k (keys %hash)
{
if ($k =~ /re/) {push $hash{$k},@res}
};
OR
keys %hash{/re/}
values %hash{/re/}
each %hash{/re/}
Way cool. I'd love this.
Well, $hash{/re/} would
Make your suggestions. But I think it is all off-base. None of this is
addressing some improvement in working conditions, ease of use, problems
in the language, etc.
RANT
You are addressing stylistic issues. Issues that effect the way _I_ want
to work with the language. All of you are being
What if every subroutine tagged itself with a list of the globals
it uses, so a calling routine would know to add those to the list
of globals it wants locked?
At 12:11 PM 8/28/00 -0500, David L. Nicol wrote:
What if every subroutine tagged itself with a list of the globals
it uses, so a calling routine would know to add those to the list
of globals it wants locked?
If you're looking for automagic locking of variables, you're treading deep
into
What I meant to say was more along the lines of "if this could be done as a
macro, does it need to be a pragma, or could it be part of a standard macro
package?"
And, secondly, "if this *is* part of a standard macro package, wouldn't it
be cool to let it shove arbitrary
On 8/28/00 3:09 PM, Damian Conway wrote:
(Or, was it already intended that the implementation of 'use
invocant' might be some sort of compile-time macro?)
No. I think a macro facility for Perl should be more general than just
whacking some code in at the start of every subroutine.
The
The use invocant was proposed as a way to maintain backwards
compatibility and yet give everyone the invocant access syntax he
or she personally favours.
...while also giving the compiler enough information to allow such
invocant access to execute in an optimized
I was talking about the hypothetical situation where you're (re)using or
modifying a bunch of code or classes written by different people and you
constantly have to be aware of which self-thingie to use in which file or
package or whatever. Yeah, you can just glance up to the use
At 11:28 AM 8/28/00 -0700, Steve Fink wrote:
Dan Sugalski wrote:
If the vtable stuff goes into the core perl engine (and it probably will,
barring performance issues), then what could happen in the
my Foo $bar;
case would be that all the vtable functions for Foo are taken as
On 8/28/00 3:53 PM, Damian Conway wrote:
Too much BD for a Monday?
No. I *do* have sympathy with the desire for One True Way, but *only* if the
access function is called Cself (my own religion ;-).
And *that's* the problem.
Yeah, there'll never be consensus on this list or in the
Summary: I think these should all simply break down into a single
Boolification test of some sort, as occurs already with operator
overload.
Counter-summary: Although the high and low precedence binary ops could be
rolled together, the current version of operator
(Or, was it already intended that the implementation of 'use
invocant' might be some sort of compile-time macro?)
No. I think a macro facility for Perl should be more general than just
whacking some code in at the start of every subroutine.
The use invocant was proposed as a way to
(Or, was it already intended that the implementation of 'use
invocant' might be some sort of compile-time macro?)
No. I think a macro facility for Perl should be more general than just
whacking some code in at the start of every subroutine.
Yes. I didn't phrase my comments well.
Nick Ing-Simmons [EMAIL PROTECTED] writes:
But if perl6 bytecode does not need to be modified to be used
I'd assume that.
-- Johan
Steve Fink wrote:
"cond" for conditional?
I was thinking along that line, too. But coopting "conditional" in any way
is probably an ungood idea.
Probly "trans" is good; it has multiple useful mnemonic values: transactional,
transfer, transparent...
--
John Porter
We're building
I think the importance of splitting the core functionality into shared
objects is more general than that. There was some discussion a short time
ago about making a pared-down version for embedding, which would seem to
require some sort of functionality reduction. There is also the desire of
On Mon, Aug 28, 2000 at 12:23:48PM -0600, Tom Christiansen wrote:
Have you ever wanted to count the number of matches of a patten? s///g
returns the number of matches it finds. m//g just returns 1 for matching.
Counts can be made using s//$/g but this is wastefull, or by putting some
Which I find cute as a demonstration of the Perl's context concept,
but ugly as hell from usability viewpoint. I how to assign to an
s/how/have/;
$need_more_coffee++;
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is
On Mon, Aug 28, 2000 at 04:04:20PM -0400, John Porter wrote:
Well, I think it's likely that the perl6 parser would be made to
handle this; but even if not, it shouldn't be too hard to get it
to allow a ref to such a list:
for [ $x, $y, $z ] ( @list ) { ...
I'm wondering how we get
On Mon, 28 Aug 2000 14:43:08 -0400 (EDT), Eric Roode wrote:
Damian Conway wrote:
@hash{grep /^[^_]/}
gives you the public values of %hash.
And the advantage of that over
@hash{ grep /^[^_]/, keys %hash }
would be what? Brevity?
What if I want those keys of %hash? Or both
On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote:
It only removes whitespace,
and it measures whitespace with tabs=8.
My editor is set to tabs=4.
So don't do that. :set sw=4 ts=8. I am confident that were Dante
were writing now, he'd reserve a special pit of Hell for those who
alter
On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote:
Further it should ignore any whitespace (and comments) that follow the
terminator.
All of these should work:
print EOL ;
EOL # this is the end of the here doc
But currently, I like using:
print "#EOT#2";
blah
On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote:
It only removes whitespace,
and it measures whitespace with tabs=8.
My editor is set to tabs=4. Perl's interpretation wouldn't agree with
the visual appearance in my editor. This doesn't sound like a neat
solution.
Why not disallow
That could be very nice. I would really prefer changing parameters
through the API, by calling class functions or something, but I don't
see why everyone should agree with me. Keeping source-editable
parameters in a standard place would then be a win, especially
considering your thoughts
Peter Scott wrote:
for my($x, $y, $z) (@list) { ... }
...
IANAPE (I Am Not A Parsing Expert). So I thought I would see if anyone who
was could say whether this construct would really give the parser problems
or whether looking ahead for the block will disambiguate.
Well, I think
On Mon, 28 Aug 2000 14:22:03 +1100 (EST), Damian Conway wrote:
I don't get it. What makes it so hard? If you see a "/" when you're
expecting an operator, or end of statement, then it's division. If you
were expecting an expression, it's a regex. Ain't it?
Yes. And that's what makes
I've just run a nasty hairy script over the RFC repository and sent
email to those people who I think have language RFCs but haven't put
statuses on them yet.
My aim in this is to figure out which RFCs are still actively under
discussion and which aren't. Some people haven't updated their RFCs
Bron Gondwana wrote:
In [EMAIL PROTECTED], you wrote:
count = array; # scalar context because of assignment to
scalar.
alt_array[] = array; # list context
and if array is a subroutine?
count = array();
count = array; # warning - special meaning in p5.
On Mon, 28 Aug 2000 09:11:39 -0400, David Corbin wrote:
Why not make the details of this controlled by a pragma?
TMFP
Too Many Pragma's.
We're trying to write ONE language here, not 150. Depending on what
pragmas you're used to, you can no longer read, er, understand, other
people's
Bart Lateur [EMAIL PROTECTED] writes:
On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote:
Further it should ignore any whitespace (and comments) that follow the
terminator.
All of these should work:
print EOL ;
EOL # this is the end of the here doc
But
By the way, for all you thesis writers and thesis advisors out there -- I
suspect that a separate implementation of the Perl6 lexer and/or Perl6
parser might make a dandy thesis topic...
By the way, this message makes more sense if you s/a separate/an
independent/... :(
On Mon, 28 Aug 2000 10:38:42 -0400 (EDT), Eric Roode wrote:
People may throw rocks at me for this, but I'd like to suggest that
not only is a comment allowed on the terminator line, but a semicolon
also be allowed. Vis:
print EOL;
EOL; # This should work, too
Let me throw the first
Bart Lateur wrote:
On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote:
It only removes whitespace,
and it measures whitespace with tabs=8.
My editor is set to tabs=4. Perl's interpretation wouldn't agree with
the visual appearance in my editor. This doesn't sound like a neat
While I think it is reasonable that all such configuration parameters
be changeable by an API, there is clearly a place for system defaults.
I've run across two such modules that I know. One wanted you to set the
time-zone the system was running in, and the other was to set a default
SMTP
raptor wrote:
Hi,
I have couple of ideas which may or may not worth it, so I didn't
wrote the RFC but will list them here in short.
Here are the nice to have'it.
1. There will be good to have some sort of "match and/or assign" operator
for structures i.e. HASHES. Can't still figure
Damian Conway wrote:
I think it would be a good thing for user prototypes to be able to
handle this case and I wholeheartedly support the RFC; but it opens
a can of worms that should be addressed. Perhaps in another RFC. Do
any other (Damian) RFCs on (Damian) prototyping
Peter Scott wrote:
Graham Barr once allowed as how he thought it would be neat if you could say
for my($x, $y, $z) (@list) { ... }
ObLanguageMinimalist:
Um. Is this so frequently-used that the above syntax is preferable to:
while ( ($x, $y, $z) = splice (@list, 0, 3) ) {...}
?
Damian Conway wrote:
I have a draft RFC that proposes that the LIST argument of a
grep be optional in a hash slice, and default to the key list
of the sliced hash. So:
That's a waste of RFC paper, Damian. But let's generalize it a bit,
and say that Perl6 should have a standard intrinsic
"SF" == Steve Fink [EMAIL PROTECTED] writes:
SF Or what about a variable attribute:
SF my $x : transactional
SF and making the effect completely lexical? Why would other scopes need to
SF see such variables?
You haven't handled the multiple variable variety. You will need to
able to have a
Stephen P Potter [EMAIL PROTECTED] writes:
At this point, should I go ahead and abandon the Math/Trig and/or
Sockets ones?
I'm still in favor of moving the socket functions into Socket if for no
other reason than it may help beat into people's heads that code like:
eval 'require
I'm still in favor of moving the socket functions into Socket if for no
other reason than it may help beat into people's heads that code like:
eval 'require "sys/socket.ph"';
eval 'sub SOCK_DGRAM {-f "/vmunix" ? 2 : 1;}' if $@;
and
$csock = pack('S n a4 x8', 2, 0, $caddr);
Lightning flashed, thunder crashed and Nick Ing-Simmons [EMAIL PROTECTED]
whispered:
| I think this is inappropriate for sin/cos/tan et. al. and possibly even
| sockets (although Win32 sockets are weird enough that it would be worthwhile)
|
| But for getpw* or shm/queue/msg or other
It's been strongly indicated that removing sockets (as well as any
other Perl functions that are little but wrappers around libc calls)
will not meaningfully reduce the size of Perl nor increase its
speed. Various VM issues have been discussed, including risks of
deadly embrace and egregious
At 10:28 AM 8/28/00 +1000, Jeremy Howard wrote:
X-posted to [EMAIL PROTECTED]
David L. Nicol wrote:
If arrays as we know them implement by using a key space restricted to
integers, I think a reasonable way to get matrices would be to open
up their key space to lists of integers.
I've
BTW, I have access to Rational Software's Quantify (and PureCoverage and
Purify) on WinNT and HP-UX 10.20 which I'd be glad to use for such tests.
If you want to get "in the mood" it would be good to fire it up on
(say) perl5.6.0 and see where the hot-spots are.
Planning on it as part of my
Consider
@x[10:20, 20:40:2, 30:50]
This ALMOST works in the current Perl. @x gives array context,
then the , produces a list.
If [] is overloaded on @a then the subroutine sees a list like
"10:20", "20:40:2", "30:50"
The only reason it does NOT work in the current perl is that "10:20"
is a
At 10:48 AM 8/28/00 -0400, Karl Glazebrook wrote:
Using semicolons is an interesting idea. But consider:
@a[10:20; 30:40];
The ":"s and ";" are awfully hard to visually distinguish.
True, but @a[10..20; 30..40]; isn't hard to distinguish.
Even so, you might get such things as:
@a[10..20:2;
Karl, all: I have just been auditing this list so far ;)
But I would like to speak up in support of Baris' idea. I have long
found it
confusing (both to myself and to those I must explain my code to) the
mix of
pdl multi-dimensional lists (lists of refs to lists) and PDLs, which
appear to be
Christian: You are right, it would not be best to confuse normal perl
lists with compact arrays--they both have their purposes and can be
combined usefully.
What I meant to say (but failed, alas) was that I support the idea for a
new perl variable type called compact array:
$foo -- scalar
@foo
Doug Hunt wrote:
What I meant to say (but failed, alas) was that I support the idea for a
new perl variable type called compact array:
$foo -- scalar
@foo -- array
%foo -- hash
^foo -- compact array (or whatever notation)
I seem to remember that ^ was in the process of being
^foo -- compact array (or whatever notation)
I seem to remember that ^ was in the process of being highjacked by some
other RFC already. Was it higher-order functions?
Yes: RFC 23 (v4): Higher order functions
Damian
Using semicolons is an interesting idea. But consider:
@a[10:20; 30:40];
The ":"s and ";" are awfully hard to visually distinguish.
c.f.
@a[10:20, 30:40];
What do people feel about the whole replacing ".." by ":"
issue?
Karl
Drawing on some of the proposals for extended 'for' syntax:
for my($mo, $dy, $yr) ($string =~ /(\d\d)-(\d\d)-(\d\d)/g) {
...
}
This still requires that you know how many () matching groups are in
the RE, of course. I don't think I would consider that onerous.
If ther regex is
1. Return the number of matches
2. Iterate over each match in sequence
3. Return list of all matches
4. Return a list of backreferences
Please see RFC 164. It can handle all of 1-3.
You seem to have missed my point. I'm not asking for a
Simple solution.
If you want to require formats such as m/.../ (which I actually think is
a
good idea), then make it part of -w, -W, -ww, or -WW, which would be a
perl6
enhancement of strictness.
That's like having "use strict" enable mandatory perlstyle compliance
checks, and rejecting
$count = () = $string =~ /pattern/g;
Which I find cute as a demonstration of the Perl's context concept,
but ugly as hell from usability viewpoint.
I'd really like to see an RFC that looks into making the following
features more orthogonal:
1. Return the number of matches
The compatibility path for perl5 to perl6 is via a translator. It
is not expected that perl6 will run perl5 programs unchanged. The
complexity of the translator and the depth of the changes will be
decided by the decisions Larry makes.
This becomes not merely
"It is not expected that perl6
Tom Christiansen writes:
if you truly must--are important things. If the perl6:perl5
relationship is similar in breadth to what we saw in the perl5:perl4
one, then perhaps, maybe even probably, one will get away with it.
However, if the stretch is appreciably further, I don't think one
Jonathan Scott Duff wrote:
I think that Csubst is too syntactically close yet semantically far
from Csubstr that the evil demons of confusion will rear their ugly
heads.
I agree too, any suggestions are welcome. The fact that 'sub' and
'substr' are already taken makes this tough...
Given
On Mon, Aug 28, 2000 at 08:12:22AM -0700, Nathan Wiger wrote:
Jonathan Scott Duff wrote:
I think that Csubst is too syntactically close yet semantically far
from Csubstr that the evil demons of confusion will rear their ugly
heads.
I agree too, any suggestions are welcome. The fact
next if /\s+/ || /\w+/; next if match /\s+/ or match /\w+/;
Gosh this is annoying. I *really* don't want to have to type "match"
all the time. And now I have to use Cor rather than C||, which is
already ingrained in my head (I rarely use "or" or "and")
There are thirteen
Tom Christiansen wrote:
There are thirteen years of precedent, not to mention the millions of users,
who are completely accustomed to writing expressions like
next if /\s+/ || /\w+/;
It's nearly part of Perl's language signature. I wouldn't count
on this going away if you still
Tom Christiansen wrote:
But if *MOST* perl1 .. perl5 programs aren't going to work unchanged,
that means that most people's existing perl knowledge-base will no
longer be valid. That probably means that they aren't going to be
able to just type in the Perl that they already know, either,
On Mon, Aug 28, 2000 at 01:30:41PM -0500, Jarkko Hietaniemi wrote:
$count = () = $string =~ /pattern/g;
Which I find cute as a demonstration of the Perl's context concept,
but ugly as hell from usability viewpoint. I how to assign to an
empty list to get a number of something? Hello?
"DC" == Damian Conway [EMAIL PROTECTED] writes:
DC However, I have given thought to allowing conditions to be grouped,
DC and de-activated by group. This would probably meet your need.
DC pre mymethod : group("safe-coding practice") { @_ 0 }
DC pre mymethod : group("debugging") { print @_,
What you want is a pre-condition on the overridden assignment operator.
What you want to do may involve having the suggested transactional
variables.
chaim
"NT" == Nathan Torkington [EMAIL PROTECTED] writes:
NT Damian Conway writes:
pre mymethod : group("safe-coding practice") { @_ 0 }
Hildo Biersma writes:
Hold on - post conditions are not intended to veto a change, they're
intended to terminate the program if an assertion is invalid. Hence it
should not matter if they run before or after assignment.
Given that the assertion should be "now this and that should be true",
Just to extend this idea, at least for the exercise of it, consider:
match; # all defaults (pattern is /\w+/?)
match /pat/;# match $_
match /pat/, $str; # match $str
match /pat/, @strs; # match any of @strs
subst; # like s///, pretty
At 01:42 AM 8/25/00 -0600, Tony Olekshy wrote:
Peter Scott wrote:
If $@ and $! are merged, then in code like
try {
system_call_that_fails();
more_stuff_that_succeeds();
}
finally {
}
does the finally block
At 12:16 PM 8/27/00 -0400, Bennett Todd wrote:
The ramifications of some of these things are sufficiently
important that drawing attention to them might be a good thing.
In this case, note that Perl 6 will need to spell out which core
exceptions are by default fatal (eg, :arithmetic) and
Removed perl6-announce x-post
Tom Christiansen wrote:
Hm I don't recall C++ ever thinking to overload the control-flow
operators ("", "||", "," (that is, comma), and "?:"). Why not?
Even if their "a b" should produce a more mundane 1 or 0, one
still might wish control.
'', '||', et
Matt Youell wrote:
Originally I was trying to avoid explicit typing through new keywords, like
'int'. So the latter option would have been the case. But after Nathan
Wiger's reply to my RFC, I realized that either syntax would work. Under one
scenario, 'int', as in your example, would simply
Steve Fink wrote:
But then what does my $x = BlueFoo-new(); print
"$x" do, assuming there is a BlueFoo::STRINGIFY? Print
"BlueFoo=HASH(0x0b38134)"?
The current thinking it to preserve the default behavior, which would be
to print out the ref info, UNLESS there is a STRING function. That
I think the better way is to take Buddha's idea (soon to be RFC'ed, by
the sounds of it), and make current arrays a little more flexible. It
sounds like we'll just have to add an extra dimension somehow, and then
"arrays of compact arrays" will simply be "arrays with some compact
elements".
Karl Glazebrook wrote:
Consider
@x[10:20, 20:40:2, 30:50]
This ALMOST works in the current Perl. @x gives array context,
then the , produces a list.
I see a number of problems with the current (scalar) PDL objects being
turned (essentially) into perl arrays in perl6.
1) How do you
First of all, apologies for my lack of input over the last
week--unfortunately I went on holidays pretty much as this list went online,
so I've been pretty quiet. Anyhow, for those who don't know me, I'm the
chair of perl6-language-data. For the remainder of its existance I'll be
more active.
Doug Hunt wrote:
What I meant to say (but failed, alas) was that I support the idea for a
new perl variable type called compact array:
$foo -- scalar
@foo -- array
%foo -- hash
^foo -- compact array (or whatever notation)
Given this notation, you could have hashes of compact
Christian Soeller wrote:
The other problem with arrays is: how do we deal with functions that
take multiple piddle arguments if they are arrays:
@result = integrate @x, @y, @bounds;
Won't those all be clumped into one big input array?
This should be overrideable by prototypes. And
The way people seem to be showing the status of RFCs is by putting
"Status: foo" up near the maintainer info etc. This makes good sense.
Can this be reflected in the sample RFC and the instructions and so on?
K.
- Forwarded message from Peter Scott [EMAIL PROTECTED] -
From: Peter
1 - 100 of 123 matches
Mail list logo
