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
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
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)
Given this notation, you could have hashes of compact
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
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
At 10:13 AM 8/25/00 +0200, Bart Lateur wrote:
You're citing my objection for merging in $@ with the rest of the error
variables. $@ currently is the "eval failed" flag, irrespective of what
else failed. We *must* have such a flag. If $@ and $! would be merged,
$! will have to be cleared if the
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: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
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
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 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
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
counting loop round a m//g. But this all seams rather messy.
It's
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 the
Michael Maraist writes:
Compatibility is going to have to be maintained somehow. And we can either
have some sort of perl6 designator (such as the pragma) to designate
incompatible (and otherwise ambiguous) code, or we're going to have to
continue tacking on syntactic sugar to legacy code.
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
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
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 out the syntax but may be
Lightning flashed, thunder crashed and "Ed Mills" [EMAIL PROTECTED] whispe
red:
| So we establish a var $something=n where n is the array origin.
You mean something like $[, which we've had for many, many years. And
which for many, many years we've discouraged the use of?
$[ The
Hey Raptor et al:
Wow you did some homework! Nice ideas, but the consensus seems to be "roll
your own". I've noted that opertors working on arrays are generally
discouraged in favor of scalar ops in these discussions, so for example your
(min,max) (ceiling, floor) are coded thousands of times
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.
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
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
Richard Proctor proposed:
All of these should work:
print EOL;
EOL
print EOL;
EOL
print EOL ;
EOL # this is the end of the here doc
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,
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:
Next you'll propose that
print EOL;
blah
EOL; print "OK!\n";
should work too, and print "OK!\n" as well.
Why not?! This seems like a good thing. ;, #, or \n are all valid
end-of-lines for here string delimiters. Sounds easy enough, and
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
On Mon 28 Aug, Eric Roode wrote:
Richard Proctor proposed:
All of these should work:
print EOL;
EOL
print EOL;
EOL
print EOL ;
EOL # this is the end of the here doc
People may throw rocks at me for this, but I'd like to suggest that
not only
On Mon 28 Aug, Bart Lateur wrote:
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
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
I'd like to see eq and it's brethen retained, as dammit there are times
I want to know (-w) if numbers are turning up when there should be
words and vice-versa. However, spinning off of something Randal wrote:
Yes, but what about:
$a = '3.14'; # from reading a file
$b =
Graham Barr once allowed as how he thought it would be neat if you could say
for my($x, $y, $z) (@list) { ... }
i.e., more than one loop variable, assigned successively from the list. He
didn't have time to RFC it, but when I looked at it, a problem arose: if
the loop variables
Steve Simmons wrote:
In all the straining at gnats over whitespace, filtering, etc, I have yet
to see a single proposal that isn't accomplished by just using variables
and manipulating them appropriately. And it avoids all the problems with
whitespace on the HERE word.
In many cases, I agree
At 07:32 PM 8/27/00 +, Perl6 RFC Librarian wrote:
=head2 Prototypes
Currently, several built-ins do not provide prototype information.
prototype("CORE::abs") == ;$
prototype("CORE::shift") == undef
This must be fixed. One might even call this a bug, although the
current
Object-oriented features were added to Perl with version 5, and in many
ways still appear somewhat "tacked on", with perhaps undue respect
for the Old Ways of Perl 4.
[NB: This is not a serious missive.]
Hey, that Perl uses packages for classes, subroutines for methods, and
references for
My apologies for being too succinct. "lost" is a bit of an emotive word
which is somewhat inaccuracte.
I still believe in RFC 109 and I think I made a good case based on my
own reasons. However the overwhelming majority of responses were negative,
for their own very good albeit different
On 8/28/00 2:35 PM, Tom Christiansen wrote:
Object-oriented features were added to Perl with version 5, and in many
ways still appear somewhat "tacked on", with perhaps undue respect
for the Old Ways of Perl 4.
[NB: This is not a serious missive.]
Hey, that Perl uses packages for
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:
@hash{grep /^[^_]/}
gives you the public values of %hash.
And the advantage of that over
@hash{ grep /^[^_]/,
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
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
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
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
Well, as I mentioned in another recent parallel thread, if Cfor is to
be properly functionalized,
Whoa -- why? Syntax keywords (eg if, unless) certainly need not be
expressible as functions.This isn't tcl!
--tom
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
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
"Randy J. Ray" wrote:
# These are pretty cool...
foreach (@old) { @new = subst /hello/X/gi, @old;
s/hello/X/gi;
push @new, $_;
}
This implies that the subst keyword would *both* modify LIST in-place and
return a complete copy of the list as a
On Mon, Aug 28, 2000 at 04:10:01PM -0400, Eric Roode wrote:
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
54 matches
Mail list logo
