At 01:47 PM 8/30/00 -0400, Karl Glazebrook wrote:
If you do a plain
my int @foo;
it'll end up with a contiguous block of memory anyway. :compact seems to
me more an attribute for sparse arrays than anything else.
Uhm do you mean a contiguous block of 4 byte integers or a
Karl Glazebrook writes:
Yes. And for the record I also think the current approach of lets generate
ten million RFCs and Uncle Larry knows best is nuts. There are already
too many RFCs on this topic alone to grasp coherently.
Do you have a better suggestion?
Nat
Nathan Torkington wrote:
Karl Glazebrook writes:
Yes. And for the record I also think the current approach of lets generate
ten million RFCs and Uncle Larry knows best is nuts. There are already
too many RFCs on this topic alone to grasp coherently.
Do you have a better suggestion?
Karl Glazebrook wrote:
There is a difference between a List of Lists and a multi-dimensional
array - the
latter is rectangular, e.g. the rows are all the same size so you don't
have to
store the sizes of individual ones. So the latter needs much less storage
overhead.
How would you be
Buddha Buck wrote:
RFC 169 says it would be nice if:
@a[^i;^j] = @b[^j;^i];
did a transpose operation.
Should the syntax also allow:
# fill a 10x10 array with 0-99
my @table: bounds(10,10);
@table[^i;^j] = ^i*10 + ^j;
I think it should--it seems a natural extension.
On Tue, Aug 29, 2000 at 05:51:44PM -0500, David L. Nicol wrote:
I'd like to see a last-container-key attribute included as
a possibilty; and that attribute called ":n" to match the
argument of integer functions in introductory algebra. This
approach gives us
for $a @some_list {
John McNamara [EMAIL PROTECTED] writes:
As far as I can see the current consensus is as follows:
1. Implicit variable: nice but not really worth the trouble.
2. Explicit variable between foreach and the array: might conflict
with other proposals.
3. Explicit counter
This is making the index variable into an a wrapper object.
Since the underlying value can't (or shouldn't) know which of the n
containers it is in.
chaim
"JSD" == Jonathan Scott Duff [EMAIL PROTECTED] writes:
JSD Interesting. I must have missed this. I'm not wild about the syntax,
JSD but
On Tue, Aug 29, 2000 at 12:57:07PM -0700, Matt Youell wrote:
So perhaps sometimes in Perl we could say:
my Dog $spot = undef;# Automagically knows to be a Dog ref instead
of a Dog object because of the undef.
if ($age 12) {
$spot = new Doberman();
} else {
Perl6 RFC Librarian [EMAIL PROTECTED] writes:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
my Dog $spot should call a constructor implicitly
Eeeeww. Most of the time I use 'my Dog $spot' is along the lines
of:
package Dog;
sub
Jonathan Scott Duff wrote:
On Tue, Aug 29, 2000 at 11:04:26PM -0400, Michael Maraist wrote:
First greatly stylistic compatibilty. An inexperienced programmer would
see:
my Dog $spot = "Spot";
And become confused. It's totally unintuitive (at least so far as other
mainstream OO
What, then, happens to the following code:
my Dog $spot;
if ($age 12) {
$spot = new Doberman();
} else {
$spot = new Corgi();
}
This is a tricky case that deserves a lot of attention, but not exactly
as written. Imagine this code block:
my int ($x, $y, $z) = (4, 5, 6);
Right now, the default behavior of perl is that un-initialized variables
are automatically undef. It would be weird to have to do explicit
assignment of an variable to say so.
You're right. And as another post mentioned, it's too much "magic". But It's
hard to come up with a comfortable
Uri Guttman wrote:
TC ($this = $that) =~ s/foo/bar/;
TC for (@these = @those) { s/foo/bar/ }
TC You can't really do those in one step without it.
RFC 164 v2 has a new syntax that lets you do the above or, if you want:
$this = s/foo/bar/, $that;
@these = s/foo/bar/,
This whole thing is actually a deep and complicated imbroglio--as I know
you, Damian, are aware. I don't know your ideas for untangling it.
Sure you do: indirect objects MUST DIE! ;-)
But I freely admit that's not a satisfactory solution.
Meanwhile, thank-you for the masterly
Tom Christiansen wrote:
But I will *not* relish typing
STDERR-print("darn")
Agreed. The day this is required is the day Perl stops becoming fun and
starts becoming C++.
No matter what, I think that any basic script should be able to be
written without any -'s.
One goal of my RFC was
Damian Conway wrote:
Nor I. That's why I'd advocate mandatory braces on indirect objects.
I'd rather:
print {STDERR} "darn"
any day.
Sorry, I'm way against that. If you're going to force that, then just
enforce:
STDERR-print("darn")
Same amount of typing.
Indirect objects
Perl6 RFC Librarian [EMAIL PROTECTED] writes:
=head1 DESCRIPTION
One of the most common mistakes I make is forgetting a C; after
Cdo BLOCK, probably because I'm thinking ``if'' and an if doesn't
require a C: after it's closing C}. I'll type, for example,
$cond and do {
#
Tom Christiansen [EMAIL PROTECTED] writes:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Eliminate bareword filehandles.
"Eliminate" is such a strong word. You're saying that we can't
use STDIN, STDOUT, STDERR, ARGV, or DATA anymore? Heck,
My worry is that it seems like this would return
an empty list on success, so:
@foo = chmod 755, "bar", "baz", "quux"
or die "Whoops, died on success!";
This seems to me to go contrary to the way perl tends to work... are
there any other functions (beside system) that
Doesn't dropping the requirement for a terminating ';' make life
harder for the parser?
It doesn't seem like that's a criterion people have been applying
to any of this. Unfortunately.
--tom
Now, just to mess with your head a bit ;)
could a case operator be overloadable?
I know the conditional operator currently cannot be overloaded,
but it seems it should be possible. difficulty is another thing though.
Greg London
Wohoo! REBOL-isous
sub foo : doc( EOS )
Function: Foo
In:scalar - int - foo identifier
Out:array - decomposed foo
Effects: Queries Foo DB
Exceptions: DBI, "bad foo id"
EOS
{
And the liste alternatives really seem rather ugly though
How about
sub foo ($$,DOC) {
}
On Wed, Aug 30, 2000 at 02:47:46AM +0200, Bart Lateur wrote:
On Tue, 29 Aug 2000 18:17:46 -0600, Tom Christiansen wrote:
sub getfh {
return open(my $fh, "+ /dev/null") $fh;
}
Aha! You fell for one of my pet pieves. You tried to return a lexical in
the same expression were
Ariel Scolnicov wrote:
Functional languages that do this are usually lazy
Yes, that's what I meant.
That means that when you create
the structure the `foo' field stores a closure which evaluates to the
desired value. If the field is never accessed, the closure is never
evaluated and
Not a huge issue, but I hadn't seen anyone else bring it up.
If in fact:
bareword filehandles are ditched
globs are killed
prototypes are potentially touched.
perlsub
sub myopen (*;$) myopen HANDLE, $name
sub mypipe (**) mypipe
Tom Christiansen wrote:
I don't know what's happening with indirect objects, but the nastiness
whereby you can only use unsubscripted scalars is quite the crock.
You know, where you can say
print $fh "stuff\n";
and
$fh
But are not (well, in the second you can, but it's
Damian Conway wrote:
I intend to extend the parameter lists RFC to cover optional
(non-tailing) arguments. Personally, I would like to see the
indirect object syntax removed in all contexts, inclusing
this one, and filehandles simply passed as a first argument.
Well, "indirect object
- Original Message -
From: "Perl6 RFC Librarian" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, August 29, 2000 8:59 PM
Subject: RFC 2 (v3) Request For New Pragma: Implicit
Request For New Pragma: Implicit
Good idea, but you have it backwards.. If
David L. Nicol wrote:
How about ALLOWING bareword everything-else? Start having
filehandles work the way everyone expects them to at first,
passing as arguments and so forth, without any special treatment?
How about barewords are always interpreted as function names (by default);
and the
Tom Christiansen [EMAIL PROTECTED] writes:
I intend to extend the parameter lists RFC to cover optional
(non-tailing) arguments.
Will this include having typed variadic functions, allowing you, for
example, to say something like
This function takes any number of arrays, all passed
Peter Scott [EMAIL PROTECTED] writes:
I think you can't just leave it at that; the implication of this
requirement is that there should be a prototype for print's optional
filehandle.
I count on Larry's promise to do something about the indirect object
stuff.
-- Johan
John Porter [EMAIL PROTECTED] writes:
Damian Conway wrote:
Well, as I mentioned in another recent parallel thread, if Cfor is to
be properly functionalized,
I deliberately stated "built-in functions", not "keywords".
Please consult Tom's list and my addendum:
Tom Christiansen [EMAIL
Snatch two syntax constructs away from the jaws of illegal syntax and
an unfortunate syntax, and make them useful weapons of the Perl
arsenal. The constructs are:
$ref-[[LIST]]
$ref-{{LIST}}
The proposed respective meanings:
On Wed, Aug 30, 2000 at 11:10:54AM -0400, John Porter wrote:
Snatch two syntax constructs away from the jaws of illegal syntax and
an unfortunate syntax, and make them useful weapons of the Perl
arsenal. The constructs are:
$ref-[[LIST]]
$ref-{{LIST}}
The proposed
At 10:19 AM 8/30/00 -0400, Jerrad Pierce wrote:
Not a huge issue, but I hadn't seen anyone else bring it up.
If in fact:
bareword filehandles are ditched
globs are killed
prototypes are potentially touched.
perlsub
sub myopen (*;$) myopen HANDLE,
At 11:05 AM 8/30/00 -0400, John Porter wrote:
The potential parsing difficulty I came up with was how to tell that
foreach ($a,$b,$c) (@list) ...
was not
foreach $_ ($a, $b, $c) (@list) ...
Graham tells me that the required parentheses and block braces make it
John Porter writes:
Ah, the old "If you want Tcl, you know where to find it" non-argument.
"Closures?""No! This is Perl, not Lisp!"
"Objects?" "No! This is Perl, not Smalltalk!"
"Patterns?""No! This is Perl, not Snobol!"
"Subroutines?" "No! This is Perl, not Basic!"
Al Lipscomb writes:
I was wondering about maybe being able to store these
attributes as
optional parts of the scalar. Something like this (please
don't get hung up
on the details, I am not much of a designer):
my($amt,$hours,$total);
$amt-{TYPE} = "DOLLARS";
$total-{TYPE} =
At 06:40 AM 8/30/00 -0600, Tom Christiansen wrote:
My worry is that it seems like this would return
an empty list on success, so:
@foo = chmod 755, "bar", "baz", "quux"
or die "Whoops, died on success!";
This seems to me to go contrary to the way perl tends to
#File: Foo.pm
sub foo : doc( EOS )
Function: Foo
In:scalar - int - foo identifier
Out:array - decomposed foo
Effects: Queries Foo DB
Exceptions: DBI, "bad foo id"
EOS
{
This is an interesting and powerful idea, but I can't help thinking that it
needs to be
Johan Vromans wrote:
Hi David,
[Quoting David L. Nicol, on August 29 2000, 19:27, in "Re: RFC 132 (v3) Sub"]
With the enhanced Cwant operator, subroutines can dynamically decide
what to return.
With context-based polymorphism, the decision can be made staticly.
Could you give
Fisher Mark wrote:
* Units of measure are optional;
* Units of measure are fast; and
* Implementing units of measure don't appreciably slow down computations
that don't use units of measure.
enforced types without automatic conversions does all this, the matches
are made once at
chomp() is best used for chop()s main raison d'etre, removing $/
from a string. I say we drop chop().
Nat
On Wed, Aug 30, 2000 at 02:31:00PM -0600, Nathan Torkington wrote:
chomp() is best used for chop()s main raison d'etre, removing $/
from a string. I say we drop chop().
I'll second that motion. We already have lots of ways of removing the
last character of a string if that's what we really
Since everyone seems intent on breaking backward compatibility
(Okay, so no one is explicitly setting out to do so, it is merely often
dismissed as a non-issue). How about an RFC be done proposing that
perl6 ship with a module named Perl5. Which one can use to remedy
most breakings between the
could a case operator be overloadable?
Ccase isn't an operator, it's (half of) a control statement.
In a sense, the existing proposal already allows Ccase to be "overloaded".
If your switch value is a subroutine, then the Ccase value is passed
to that subroutine, which can then
On Wed, 30 Aug 2000, Michael Maraist wrote:
Good idea, but you have it backwards.. If anything, there should be an
"explicit" keyword..
Remember, we want
% perl -p -e 's/foo/bar/g' file.txt
Oh, I know. I threw it in because someone mentioned wanting to turn it
off. (There may have been
Doesn't that tend to lead us in the direction of pack madness where we
end up with yet another 'sub language' within perl. We've already got
pack specifiers and regexen and the 'old' prototyping stuff. I'm not
arguing *against* these things you understand, I'm just vaguely
worried.
As you have
At 03:35 PM 8/30/00 -0600, Tom Christiansen wrote:
=head2 Hash Context
When the result is assigned to a hash, the list returned could be the names
of the unsuccessfully modified files and their corresponding C$! errors.
Um, but we don't have hash context. :-(
We will :-)
RFC 21:
=item
On the other hand, I hardly ever use $_ in main-stream programming. I
always perform:
for my $var ( .. ) { .. }
Certainly I seldom *mention* $_, but I sure use it a lot, as in
for (@array) { s/foo/bar/ }
It's not something I'd like made Law, but I do advise my beginning
students that
You don't want do have a postfix { ... } if condition. It's evil to
have
do {
asd;
asdf;
asdf;
asf;
asdf;
asdf;
sad;
fasdfa;
sdf;
asdf;
asdf;
asf;
asdf;
asd;
as;
Peter Scott wrote:
No-one AFAICT has yet brought up formats, and what would happen to them if
bareword filehandles go the way of the dodo.
Here's some thoughts I've been tooling with. If we take advantage of the
indirect object syntax, we can actually make format into a member
function:
(I'm going to RFC these if nobody presents any killer complaints about
them, it's just that writing RFCs is more work than I want to go through
for tiny little changes like these, especially if they turn out to be
dumb).
%hash in scalar context should return what scalar(keys(%hash))
currently
chomp() is best used for chop()s main raison d'etre, removing $/
from a string. I say we drop chop().
So code that says
chop($k,$v)
will need to say
for ($k,$v) { s/.\z//s }
or else something like:
for ($k, $v) { substr($_, length() - 1) = '' }
I'm not sure I find either of
%hash in scalar context should return what scalar(keys(%hash))
currently does.
But %hash-BUCKET_USE() should return what's currently there.
And a simple boolean (read: don't care) use shouldn't waste time
looking for keys, really, but should be internally optimized to do
the current reasonable
I was against the idea of hash context, but I'd love it if:
foreach ($k,$v) (%hash) {
...
}
I'd like for Perl to emit a warning if people try
for (%hash)
or its aliases. That is, if a foreach loops sole content is
a %{...} at compile time, grinch.
--tom
No-one AFAICT has yet brought up formats, and what would happen
to them if bareword filehandles go the way of the dodo.
I'm about to propose that formats be replaced with a mechanism of
Text::Autoformat::form (with some extensions).
Damian
the reason that they're duplicatable with other features, while I want
to drop chop because its main purpose has now been replaced with the
far superior chomp.
Except that chomp() relies upon the ueberglobal $/ variable,
irrespective of the source of the data being chomped.
--tom
Tom Christiansen writes:
So code that says
chop($k,$v)
will need to say
for ($k,$v) { s/.\z//s }
or else something like:
for ($k, $v) { substr($_, length() - 1) = '' }
I don't think chop() is an operation that's done often enough for
either of the things above to be
Tom Christiansen writes:
But %hash-BUCKET_USE() should return what's currently there.
Do you really use this information? Really? I have no objection
to supplying a way to discover it, but this might even be in an
external module rather than built into the language given how rarely
it's used.
At 04:36 PM 8/30/00 -0600, Tom Christiansen wrote:
the reason that they're duplicatable with other features, while I want
to drop chop because its main purpose has now been replaced with the
far superior chomp.
Except that chomp() relies upon the ueberglobal $/ variable,
irrespective of the
Tom Christiansen writes:
But %hash-BUCKET_USE() should return what's currently there.
Do you really use this information? Really? I have no objection
to supplying a way to discover it, but this might even be in an
external module rather than built into the language given how rarely
it's used.
In message [EMAIL PROTECTED]
Nathan Torkington [EMAIL PROTECTED] wrote:
Resetting an each() should be done in some other way than calling
keys() or values(). Perhaps reset(%hash)? I'm subfond of the current
reset() semantics (symbol table crackheadery + single-match regexp
Tom Hughes writes:
I must admit it had never occurred to me that somebody might
deliberately use keys or values to achieve that, but I guess
somebody might be relying on it without realising it.
while (($k,$v) = each %foo) {
last if ...;
}
keys %foo;# reset the iterator
Tom Christiansen wrote:
format $fh EO_FORMAT;
@, @
$stuff, $junk
EO_FORMAT
Actually this is pretty cool, add a = and turn it into a variable
declaration:
my format $FORMAT = '.';
@, @
$stuff, $junk
.
And that looks pretty similar to Perl 5. ;-)
Anyways, I went
On Wed, 30 Aug 2000 16:14:35 -0600, Tom Christiansen wrote:
I say we drop chop().
So code that says
chop($k,$v)
will need to say
for ($k,$v) { s/.\z//s }
or else something like:
for ($k, $v) { substr($_, length() - 1) = '' }
I'm not sure I find either of those more legible.
I would actualy like to see chop expanded to allow a variable number of
characters to be removed and a sister function to cut the head off. Yes I
know you can do this with substr but sometimes when you want the performance
and need to cut up a string into fields. Lets say the new function is
On Wed, Aug 30, 2000 at 02:31:00PM -0600, Nathan Torkington wrote:
chomp() is best used for chop()s main raison d'etre, removing $/
from a string. I say we drop chop().
Works for me. Are you going to RFC it?
K.
--
Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/
Open Source
On Wed, Aug 30, 2000 at 10:31:48AM -0400, Michael Maraist wrote:
Request For New Pragma: Implicit
Good idea, but you have it backwards.. If anything, there should be an
"explicit" keyword..
This resonates well with me. I had a funny feeling about "use Implicit"
and I wasn't sure what it was,
On Wed, Aug 30, 2000 at 04:53:46PM -0400, Bryan C . Warnock wrote:
On Wed, 30 Aug 2000, Michael Maraist wrote:
Good idea, but you have it backwards.. If anything, there should be an
"explicit" keyword..
Remember, we want
% perl -p -e 's/foo/bar/g' file.txt
Oh, I know. I threw it in
On Wed, Aug 30, 2000 at 02:21:19AM -, Perl6 RFC Librarian wrote:
Allow for a list of loop variables in for(each) statements, i.e. e.g.,
foreach my ($x, $y, $z) (@list) { ... }
Hear, hear. I like this one :)
K.
--
Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/
Open
(yes, I'm in an RFC-commenting mood today...)
On Wed, Aug 30, 2000 at 02:22:31AM -, Perl6 RFC Librarian wrote:
Add Clist keyword to force list context (like Cscalar)
Makes sense to me. Does it connect in any way with Damian's generic
want() function?
K.
--
Kirrily Robert -- [EMAIL
Tom Christiansen wrote:
I'll second that motion. We already have lots of ways of removing the
last character of a string if that's what we really need.
But they're slow and hard to read.
I think the word "drop" should be clarified as "dropped from the core
binary".
In a very cool email,
On Wed, Aug 30, 2000 at 02:22:31AM -, Perl6 RFC Librarian wrote:
Add Clist keyword to force list context (like Cscalar)
Makes sense to me. Does it connect in any way with Damian's generic
want() function?
Only in that it would explicitly cause Cwant 'LIST' to return
Dan Sugalski wrote:
I do want to have a set of C/XS/whatever sources as part of the test suite
as well--right now perl's test suite only tests the language, and I think
we should also test the HLL interface we present, as it's just as
important in some ways.
I want to see Perl become a
On Wed, Aug 30, 2000 at 04:43:56PM -0400, Jerrad Pierce wrote:
Since everyone seems intent on breaking backward compatibility
(Okay, so no one is explicitly setting out to do so, it is merely often
dismissed as a non-issue). How about an RFC be done proposing that
perl6 ship with a module named
77 matches
Mail list logo
