Christian Soeller wrote:
No, at least 18. One more piece of semantics that would be appreciated
is optional omission of trailing dimensions in slices, e.g. for a 3-dim
@a:
@a[0:1] == @a[0:1;] == @a[0:1;;]
Christian
this would be the * in my proposal made in mail w/ subject
"a
Nathan Wiger wrote:
"David L. Nicol" wrote:
@a["$i $j $k","$a $y $z"] # two points in DN n-dim syntax
One problem that immediately jumps out at me is how to do this:
@a[[@x], [@y]];
That is, dynamically get your indices. The above seems ok when you know
them in
Christian Soeller wrote:
No, at least 18. One more piece of semantics that would be appreciated
is optional omission of trailing dimensions in slices, e.g. for a 3-dim
@a:
@a[0:1] == @a[0:1;] == @a[0:1;;]
I'd rather see the ';' be required, but the '(0..)' not be required, so you
could
At 05:35 PM 8/31/00 +, David L. Nicol wrote:
Buddha Buck wrote:
The array
syntax would also be useful in multi-dimensional arrays.
That is if multi-dimensional arrays are implemented as lists-of-lists,
which they might not be.
Even if they aren't implemented as lol, they may
Christian Soeller wrote:
There might still be a need for something for those people who need FFTs
and work on really large blocks of data. The hope would be that a perl6
PDL would fill such a gap and be more perlish than it is now. But again
concrete syntax ideas are needed along with a clear
Likely this should be an RFC. I'm too lazy to write it in that format
right now, but I want to send this thing out before it slips my mind
again. Somebody else may pick it up, if he or she wants it. If not, I'll
eventually may have to do it myself.
The articial distinction between
do
At 11:38 AM 8/31/00 +0200, Bart Lateur wrote:
The articial distinction between
do BLOCK while condition;
and
EXPR while condition;
should go, because the former is nothing but a subcase of the latter.
Currently, the former executes the do BLOCK at least once, while the
I want last, next, etc. to magically work where I want them to:
do {
last if /booger/;
...
} while ( ... );
Nat
I want last, next, etc. to magically work where I want them to:
do {
last if /booger/;
...
} while ( ... );
Special cased for postfix modifiers, or generalized? If so,
what's the return value?
$x = TERM OP do { BLOCK } OP TERM;
Actually, these are all pretty similar in
On Thu, 31 Aug 2000 11:21:26 -0600, Tom Christiansen wrote:
One could argue that do{} should take return so it might have a value,
but this will definitely annoy the C programmers.
So what.
"Annoying" would be to have a situation that is *less* powerful in Perl
than in C, not *more*.
Oh, and
Tom Christiansen writes:
One could argue that do{} should take return so it might have a value,
but this will definitely annoy the C programmers.
So what.
So what is that it *already* annoys us, which is *why* we would like to
last out of a do. Perhaps you should be able to last
On Thu, Aug 31, 2000 at 01:26:26PM -0500, Christopher J. Madsen wrote:
I too would like to see last, next, redo work with do loops.
*Only* do loops or do blocks in general? And what should they do?
do { ... last; ... }; # exit the block immediately
do { ... next;
At 11:21 AM 8/31/00 -0600, Tom Christiansen wrote:
I want last, next, etc. to magically work where I want them to:
I too want last to work in do loops.
do {
last if /booger/;
...
} while ( ... );
Special cased for postfix modifiers, or generalized? If so,
what's the return
Peter Scott writes:
I dunno, maybe a last in a do block whose value is used by
something should be a syntax error. We're talking about code like
$x += do { $y = get_num; last if $y == 99; $y } while defined $y;
right? *Shudder*
Yes, but we're also talking about code like
The more interesting case is this:
#!/my/path/to/perl
sub foo_generator { my $a = shift; sub { print $a++ } }
my $foo = foo_generator(1);
$foo-();
Thread-new($foo);
Is $a shared between threads or not?
$a is shared between threads.
The anonymous subroutine is a
Tom Christiansen writes:
However, I really don't want to see 'return' become a kind of 'last'
for do{}. How would I return from a subroutine from within a do loop?
You already can't do that (as it were) from within an eval.
Yes, but 'eval' has the semantics "run this code but don't let
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Thread Programming Model
=head1 VERSION
Maintainer: Steven McDougall [EMAIL PROTECTED]
Date: 31 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 185
Status: Developing
=head1
use Thread;
$thread = new Thread \func , @args;
$thread = new Thread sub { ... }, @args;
async { ... };
$result = join $thread;
$thread = this Thread;
@threads = all Thread;
$thread1 == $thread2 and ...
yield();
critical { ... }; # one thread at
$thread = new Thread \func , @args;
$thread = new Thread sub { ... }, @args;
async { ... };
$result = join $thread;
critical { ... }; # one thread at a time in this block
=item Casync BLOCK
Executes BLOCK in a separate thread. Syntactically, Casync BLOCK
works
Chaim Frenkel wrote:
This is making the index variable into an a wrapper object.
No it isn't. Or at least it doesn't have to.
Often there is a need to find the key an object was found in a container.
More often in hashes than in arrays.
And I think this discussion belongs in -data.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Formats out of core / New format syntax
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 30 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 181
Status:
Perl supplies an operator for line input - angle brackets. This is no
analogous operator for output. I propose "inverse angle brackets":
"Print this line.\n";
Perl already *has* a print operator: "print". :-)
The problem with what you have there is that it hides the act of
output within
On 31 Aug 2000, Perl6 RFC Librarian wrote:
my format $FILE_FORMAT =
@: @
$name, $ssn
.
Then this is even less different and scary. Get rid of that Cmy and
it's Perl 5.
s/that Cmy/that Cmy and the dollar sign/;
Cheers,
Philip
--
Philip Newton [EMAIL PROTECTED]
(mystery: how
can filling in $ be a lot slower than filling in $1?)
It isn't. It's the same. $1 might even be more expensive than $.
It appears that many people don't understand the problem with $. I
will try to explain.
Maintaining the information required by $1 or $ slows down the
Jonathan Scott Duff wrote:
How about something like this?
$re = qr/(\d\d)-(\d\d)-(\d\d)/g;
$re-onmatch_callback(push @list, makedate(^0,^1,^2));
$string =~ $re;
It's not bad, but it loses one thing that I was trying to keep from the
SNOBOL model. If you have (again,
From: "Peter Heslin" [EMAIL PROTECTED]
Sent: Thursday, August 31, 2000 10:51 PM
I would propose that your version of the syntax might also function in
the middle of a regexp: /GHI(?`=DEF)JKL(?`=^ABC)MNO/ would match the
start of the alphabet (fixed-length example used for simplicity).
That's
Johan Vromans wrote:
You can do that easily:
sub param {
my ($self, @rest) = @_;
$self-{aval} = @rest if @rest; # See note
lreturn $self-{aval};
}
I've been thinking about this for a couple days. The only problem I see
is that this doesn't allow me to do this:
I've been thinking about this for a couple days. The only problem I see
is that this doesn't allow me to do this:
$oldpath = $tree-path('L','R') = 'R';
@document = ($title, $junk, $r-xml_extract) = STDIN;
I would still have to use some yeechy combination with
You don't want do have a postfix { ... } if condition. It's evil
I don't see how this is any worse than a postfix while()
do {
asd;
asdf;
asdf;
asf;
asdf;
asdf;
sad;
fasdfa;
sdf;
asdf;
asdf;
You don't want do have a postfix { ... } if condition. It's evil
I don't see how this is any worse than a postfix while()
Look closer: do { ... } while does not require the reader to
scan down to find out the condition *BEFORE* the loop is
entered. With an if, it does.
Because it hides
Which kind of "difference"?
"David L. Nicol" wrote:
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.
Tom Christiansen writes:
Look closer: do { ... } while does not require the reader to
scan down to find out the condition *BEFORE* the loop is
entered. With an if, it does.
I believe what he's saying is that do { ... } requires the reader to
scan down far enough to see if there is a while
Since everyone seems intent on breaking backward compatibility
I don't think this is at all true, but I also don't think the overall
you seem to have ignored the paranthetical clause
idea of a Perl5 module is necessarily a bad one.
However, my hope would be that we do Perl 6 smoothly enough and
We already have a trailing if statement, so this argument is edgy, at
best.
Your brain/eye can look one statement. It's evil and wrong to make
it look infinite statements forward. How can you pretend those are
the same?
Well, I think trailing statements already have only limited
Jerrad Pierce wrote:
That would be my hope too, but as I mentioned, it is seeming somewhat unlikely.
I don't think so. There's lots of proposals out there right now, but
only a very few actually break backwards compatibility. Plus, Larry's
not going to make Perl 6 look like, as Tom would say,
More functions from set theory to manipulate arrays
I'd like to use these functions in this way :
@c = union (@a, @b);
# wich is different from @c = (@a, @b) because union do not duplicate
same elements
@c = intersection (@a, @b);
@c = diff(@a, @b);
Elements of this are found in
John Porter wrote:
Not familiar with indirect object notation?
Insulting non-argument. I'm not replying to it.
Who was it that suggested changing the m// operator to the match()
function, and the s/// operator to the subst() function?
That would be me.
I suppose I could have proposed
On Thu, 31 Aug 2000, David L. Nicol wrote:
Perl looks, and AFAIK has always looked, like "C plus lune noise" to
many people.
I think Perl looks like "C plus moon noise" to former C programmers. I
imagine some people see it and think "Csh plus Awk noise". Perl is a lot
more than
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A Perl frontend to GCC would make my life wonderful. Who would I talk
to about that? I'm not about to pretend that I have any idea how to
do that.
- --Dave
- - -Original Message-
- - From: Sam Tregar [mailto:[EMAIL PROTECTED]]
- - Sent:
Eric Roode writes:
Useful functions all, no doubt. But I would lobby heavily for a new
set of names -- ones that can be remembered! Quick -- which trims
leading spaces, champ, chump, or chimp?
My favourite: chafe().
Nat
[redirected to perl6-language]
Tom Christiansen wrote:
Note the difference between
my $var = func();
and
my($var) = func();
Those are completely different in that they call func() in scalar
and list contexts. Why? Because of hte presence or absence of (),
of course.
On Thu, 31 Aug 2000 19:59:31 +0200, you wrotc:
tr/\w//dlt # Trim all leading trailing whitespace from $_
Eh, scratch that. Too much caffeine i guess.
tr/\n\r\t //dlt; # Trim some whitespace.
-DZ
--
Tell me your dreams and I will crush them.
On Thu, Aug 31, 2000 at 07:59:31PM +0200, Dan Zetterstrom wrote:
Why not use the "function" we already got, tr? Something like:
tr///l # Translate only _l_eading characters matching.
tr///t # Translate only _t_railing characters matching.
With "Only leading" I mean translate
tr///l # Translate only _l_eading characters matching.
tr///t # Translate only _t_railing characters matching.
With "Only leading" I mean translate from start/end until you find a
character not matching. Then you can do nifty things such as:
tr/\w//dlt # Trim all leading trailing
How would you do:
# Writer insists on blank line between paragraphs, first line indented.
# Publisher insists on one paragraph/line, first word ALL CAPS.
Step 1: Fire the lame publisher. I'm serious. It's amazing
what people tolerate. Some things aren't worth the pane.
{
local $/ = "";
TomC wrote:
In general, getting folks to write
s/^\s+//s;
s/\s+$//s; # XXX: \z
is a *good* think.
Why?
Removing leading/trailing whitespace is a tremendously frequently-
performed task. Perl gives you -l on the command line to strip
newlines on input and add them on output, simply
Dan Sugalski wrote:
I expect we'd want to have some sort of heavy-duty regex optimizer, then,
to detect common prefixes and subexpressions and suchlike things, otherwise
we end up with a rather monstrous alternation sequence...
We need a regex merge function too -- then we could write macros
Nathan Wiger wrote:
Well, it just stacks arguments on the end, even with open-ended
prototypes:
@a =~ my_user_sub($arg); # @a = my_user_sub($arg, @a)
What it means is, you can't prototype the thingy that could be
expected on the LHS of the =~, when function is open-ended,
because in
On Fri, 1 Sep 2000 07:27:24 +1100 (EST), Damian Conway wrote:
And has anyone pointed out that Clist is just:
sub list {@_}
Um no. I would expect it to be
sub list { @_[0..$#_] }
It's too early in the morning.
The subtlety here escapes me.
It's the
On Thu, 31 Aug 2000 13:36:10 -0600, Tom Christiansen wrote:
I'm not arguing in favor of the tr/// hack specifically, but
gosh, wouldn't it be nice if there were a thwack() builtin that
stripped leading and trailing spaces?
No. People should learn intrinsic mechanisms with which they can
At 11:46 PM 8/31/00 +0200, Bart Lateur wrote:
On Fri, 1 Sep 2000 07:27:24 +1100 (EST), Damian Conway wrote:
And has anyone pointed out that Clist is just:
sub list {@_}
Um no. I would expect it to be
sub list { @_[0..$#_] }
It's too early in the morning.
Sam Tregar wrote:
On Thu, 31 Aug 2000, David L. Nicol wrote:
run-time efficiency
C doesn't get run-time efficiency from its syntax, so we can't really
expect to get anything here. It gets it from its compilation
architecture. If you want to build a Perl frontend for GCC I think
"David L. Nicol" wrote:
my dog $spot;
to
dog spot;
If we only allow this where enough info is available to allocate dog-sized
pieces of memory directly, Perl can blaze through the code that deals with
dogs.
I don't see what barewords gain us here. Who says that
my
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl should support an interactive mode.
=head1 VERSION
Maintainer: Ariel Scolnicov [EMAIL PROTECTED]
Date: 31 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 184
Status: Developing
On Thu, 31 Aug 2000, David L. Nicol wrote:
We're talking about making a faster Perl. C's syntax requires enough
clarity to compile to something quick. it is a very short hop from
my dog $spot;
to
dog spot;
What about the second version would result in faster execution? Do
This is the kind of thing that keeps Perl instructors in business...
And Perl out of businesses :-(
More than anything I think the inability to write Csub list DWIMishly
argues that we need it built-in. But we also need a *very* careful design
of the semantics.
Damian
I'll be brief because windows just crashed on me.
First, the current debugger allows multi-lines if you use "\" at the end of
the line ( a la C ).
Second, lexically scoped variables will dissapear on subsequent debugger
lines since their scope is wrapped in an eval. For the most part, the
This is the kind of thing that keeps Perl instructors in business...
And Perl out of businesses :-(
More than anything I think the inability to write Csub list DWIMishly
argues that we need it built-in. But we also need a *very* careful design
of the semantics.
I'd like to see from this
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
More functions from set theory to manipulate arrays
=head1 VERSION
Maintainer: Gael Pegliasco [EMAIL PROTECTED]
Date: 30 August 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 179
=head1
Perl6 RFC Librarian wrote:
arsenal. The constructs are:
$ref-[[LIST]]
$ref-{{LIST}}
The proposed respective meanings:
$ref-[$elem[0]]-[$elem[1]}-[...]-[$elem[-1]]
$ref-{$elem[0]}-{$elem[1]}-{...}-{$elem[-1]}
why not just use single braces for
At 05:35 PM 8/31/00 +, David L. Nicol wrote:
Buddha Buck wrote:
The array
syntax would also be useful in multi-dimensional arrays.
That is if multi-dimensional arrays are implemented as lists-of-lists,
which they might not be.
Even if they aren't implemented as lol, they may
Peter Scott wrote:
Having the
indices in one place saves a lot of characters. Compare
$r-{{qw(a b c d e f g h)}}
versus
$r-{a}-{b}-{c}-{d}-{e}-{f}-{g}-{h}
But I would compare it to
$r-{a}{b}{c}{d}{e}{f}{g}{h}
which is only one character longer than
Buddha Buck wrote:
At 05:35 PM 8/31/00 +, David L. Nicol wrote:
Buddha Buck wrote:
The array
syntax would also be useful in multi-dimensional arrays.
That is if multi-dimensional arrays are implemented as lists-of-lists,
which they might not be.
Even if they aren't
64 matches
Mail list logo
