"Michael Maraist" <[EMAIL PROTECTED]> writes:
[...]
> First, the current debugger allows multi-lines if you use "\" at the end of
> the line ( a la C ).
Thanks. TomC also pointed this out. I still don't like it, though.
(But it will be added to the next revision).
Take a look at what sh will
Dan Sugalski wrote:
> > > get_value
> > > set_value
> The get/set value functions are for when something knows what the SV (or
> whatever we call it) really is and can handle the raw data. For example,
> if my code knew a SV held a complex number (which doesn't map well to the
> int/floa
Dan Sugalski wrote:
> At 04:59 PM 8/31/00 -0400, Buddha Buck wrote:
> >At 04:43 PM 8/31/00 -0400, Dan Sugalski wrote:
> >>Okay, here's a list of functions I think should go into variable vtables.
> >>Functions marked with a * will take an optional type offset so we can
> >>handle asking for vari
On Thu, Aug 31, 2000 at 09:45:52PM -0600, Tom Christiansen wrote:
> >Well, remember that BEGIN{} blocks are just subs too, with an optional
> >'sub'.
>
> Not exactly. They are not callable, as they disappear immediately.
> More importantly, they have no @_, and things like pop and shift
> act up
On Wed, Aug 30, 2000 at 04:20:24PM -0600, Tom Christiansen wrote:
> One wonders whether bigna and complices should make the builtin list.
If they were fast and didn't require hoop-jumping or some special
magic and no penalties for those who don't use them, I certainly
wouldn't mind them as builti
On Thu, Aug 31, 2000 at 07:56:24PM -0700, Nathan Wiger wrote:
> > So the object would be left undefined? That means this code:
>
> No, not at all. Remember, everything's going to inherit from CORE, at
> the very least, which would have to provide a CREATE method which just
> instantiates a simp
>Well, remember that BEGIN{} blocks are just subs too, with an optional
>'sub'.
Not exactly. They are not callable, as they disappear immediately.
More importantly, they have no @_, and things like pop and shift
act upon @ARGV from within them.
The compilerish chapter of the Camel calls them bl
> > 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 C 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 measu
Larry Wall wrote:
>
> More generally, for all X, I wouldn't mind
> if Perl became the language of choice for X.
Who wouldn't!
But I think that would probably have to be, "if Perl became the language
of choice for X - 1".
Perl's gotta be written in something, after all... ;-)
-Nate
Of course,
> $thread = new Thread \&func , @args;
> $thread = new Thread sub { ... }, @args;
>async { ... };
> $result = join $thread;
>
> critical { ... }; # one thread at a time in this block
>
> =item C BLOCK
>
> Executes BLOCK in a separate thread. Syntactically, C BLOCK
> works
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
debug
> > Besides, what would be the alternative, BEGIN{} - like blocks?
>
> Such blocks are put forth as an alternative:
Well, remember that BEGIN{} blocks are just subs too, with an optional
'sub'.
But that aside, I don't think a block is what we want to connote. A
block implies "this is evaluated
Adam Turoff wrote:
>
> Look again.
>
> Next request? ;-)
Can you continue to rock? You're kickin' my ass as RFC Librarian. Nice
job.
-Nate :-)
>
> 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 { ... };
> 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 C DWIMishly
argues that we need it built-in. But we also need a *very* careful design
of the semantics.
Damian
On Thu, 31 Aug 2000, Jarkko Hietaniemi wrote:
> How about
>
> to_string *
> from_string *
>
> as generalizations of formatted/pretty input/output and freeze/thaw
> (cf printf/Data::Dumper/Storable)?
Erm, I could see that, but freezing and printing are still different
operations, so I'm not sur
> Steven W McDougall wrote:
> > > 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 o
On Thu, Aug 31, 2000 at 05:15:34PM -0700, Nathan Wiger wrote:
> First off, nice additions to the RFC.
Thanks. :)
> > Listed below are constructor alternatives. If a sub is chosen (as in sub
> > PREPARE {}) it will suffer from the disadvantage of potentially causing
> > problems with current
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).
> 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) = ;
>
> I would still have to use some yeechy combination wit
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> Chaim Frenkel wrote:
>> You are now biting off quite a bit.
KF> What good is half a transaction? If transactions are to be useful,
KF> they should be fully supported -- including rolling back stuff some
KF> third party module did to its inter
How about
to_string *
from_string *
as generalizations of formatted/pretty input/output and freeze/thaw
(cf printf/Data::Dumper/Storable)?
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
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.
> >
> >Ev
Buddha Buck wrote:
> If I'm stepping on toes here, please tell me...
>
See my other message today for the RFCs I'm thinking of writing. Buddha--you
and I should probably sought out offline which of us will write what RFC.
> RFC 169v2: Matrix Indexing
> Cover my $matrix[$x;$y;$z] syntax
>
First off, nice additions to the RFC.
> Listed below are constructor alternatives. If a sub is chosen (as in sub
> PREPARE {}) it will suffer from the disadvantage of potentially causing
> problems with current Perl modules.
I don't really think this is a valid concern. We can have p52p6 warn
On Thu, Aug 31, 2000 at 11:48:51PM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> my Dog $spot should call a constructor implicitly
Look at me, replying to my own RFC, how tacky. :)
> If the multi-argument form of the constructor were to be adopted this would
> have to change. Dog->$M
Jeremy Howard wrote:
> I'd rather see the ';' be required, but the '(0..)' not be required, so you
This is not good! There are a lot of routines where it is very useful to
specify a slice as
@a[0]
that should work regardless how many dimensions @a really has. There are
many instances in PDL
>The most serious obstacle to easy interaction is the impossibility of
>typing multiple line commands to a Perl debugger (see below).
% man perldebug
...
Multiline commands
If you want to enter a multi-line command, such as
a subroutine definition with
arrays-of-scalars
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Standard support for opening i/o handles on scalars and
arrays-of-scalars
=head1 VERSION
Maintainer: Eryq (Erik Dorfman) <[EMAIL PROTECTED]>
Date: 23 Aug 2
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? D
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 ABSTR
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: Developin
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
"=for testing" - Embedded tests
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: Aug 31 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 183
Status: Developing
=he
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
JART - Just Another Regression Test
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: Aug 30 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 182
Status:
"David L. Nicol" wrote:
>
> > One problem that immediately jumps out at me is how to do this:
> >
> >@a[[@x], [@y]];
>
> I think I dealt with that in the next paragraph, suggesting
>
> @a["@x","@y"]
Well, this is not bad, only it's not without its problems. Say you
wanted to get you
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
cou
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
=head1 VERSION
Maintainer: Michael Fowler <[EMAIL PROTECTED]>
Date: 29 August 2000
Last Modified: 31 August 2000
Mailing List: [EMAIL PROTEC
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
> "DLN" == David L Nicol <[EMAIL PROTECTED]> writes:
DLN> Ken Fox wrote:
>> . The real problems of exception handling, closures, dynamic
>> scoping, etc. are just not possible to solve using simple C code.
>>
>> - Ken
DLN> I'm not talking about translating perl to C code, I'm ta
Ken Fox wrote:
> . The real problems of exception handling, closures, dynamic
> scoping, etc. are just not possible to solve using simple C code.
>
> - Ken
I'm not talking about translating perl to C code, I'm talking about
translating perl to machine language.
C is babytalk compared to Perl,
Dan Sugalski wrote:
>
> Okay, here's a list of functions I think should go into variable vtables.
All the math functions are in here. Can the entries that my type does
not use be replaced with other functions that my type does use?
> Functions marked with a * will take an optional type offset
"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
At 03:45 PM 8/31/00 -0600, Nathan Torkington wrote:
>Jarkko Hietaniemi writes:
> > > I'm not too worried about getting the vtbl right at the first because
> > > it will be pretty obvious how it should go once the code starts to form.
> >
> > Some planning isn't that painful :-)
>
>Yes. Especially
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
"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 advance (at least what variables
At 05:30 PM 8/31/00 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > get_value
> > set_value
>
>Wouldn't these go on the SV and not on the inner type? Maybe I'm
>thinking value when you're saying variable?
Nope. The get/set value functions are for when something knows what the SV
(or whate
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
"
At 03:12 PM 8/31/00 -0600, Tom Christiansen wrote:
> >> get_int *
> >> get_float *
>
> >Could you elaborate on these a lot? What's an 'int'? What's a 'float'?
> >Having lately been battling a lot with quad ints and doubles vs long
> doubles
> >I seriously want this interface not to suc
At 04:05 PM 8/31/00 -0500, Jarkko Hietaniemi wrote:
>I'm confused (I might have missed some discussions, being busy in other
>fronts) so please bear with my silly questions.
>
> > type
>
>The basic set-in-stone types are...?
int, float, string, ref, hash, array. All of which have multiple lev
At 04:59 PM 8/31/00 -0400, Buddha Buck wrote:
>At 04:43 PM 8/31/00 -0400, Dan Sugalski wrote:
>>Okay, here's a list of functions I think should go into variable vtables.
>>Functions marked with a * will take an optional type offset so we can
>>handle asking for various permutations of the basic
On Thu, Aug 31, 2000 at 07:08:38PM +1100, iain truskett wrote:
> * Adam Turoff ([EMAIL PROTECTED]) [31 Aug 2000 17:41]:
> > A handful of long overdue updates to http://dev.perl.org/rfc have been made:
> [...]
> > - More detailed summaries of all RFCs are available, organized by
> > RFC numbe
On Thu, Aug 31, 2000 at 08:02:36AM -0400, David Corbin wrote:
> > Comments, criticisms, etc. welcome.
> >
>
> Can you put a legend explaining the color code on the pages where the
> colors are used?
Look again.
Next request? ;-)
Z.
Jeremy Howard wrote:
> That's true. I still think it's confusing to have such similar syntaxes mean
> such different things. I'd also like to be able to say:
>
> @a[[$i,$j,$k], [$x,$y,$z]]
>
> to get two points.
Just in case anyone isn't aware of this:
using a "stuff'em into hash keys" N-d
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 C is just:
> > > >
> > > > sub list {@_}
> > >
> > > Um no. I would expect it to be
> > >
> > > sub list { @_[0..$#_] }
> >
> >It's
=head1 VERSION
Date: 31 Aug 2000
Number: 1
Mailing List: [EMAIL PROTECTED]
Chair: Nathan Wiger <[EMAIL PROTECTED]>
=head1 SUMMARY
The main point which most discussions are currently centering around is
the idea of fundamental embedded objects in Perl 6. With this concept, a
simple s
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 c
"David L. Nicol" wrote:
> No, I'm not, it's the direction that RFC 61 ends up if you let it
> take you there.
You seem to be confusing:
(1) linking C code with Perl
with
(2) compiling Perl to C code
There is a world of difference. Swig does (1) pretty well already.
If you want a first c
On Wed, Aug 30, 2000 at 04:07:51PM -0400, mike mulligan wrote:
> Can this be repackaged in such a way that it is a more natural extension of
> the existing regexp language?
>
> The RFC notes that the look-behind construct (?<= pattern) can almost be
> used. Two issues: 1. as currently implement
On Wed, Aug 30, 2000 at 11:54:29PM -0400, Mark-Jason Dominus wrote:
>
> The big thing I find missing from this RFC is compelling examples.
> You are proposing a major change to the regex engine but you only have
> two examples. Both involve only fixed strings and one of them is
> artificial. I
On Fri, 1 Sep 2000 07:27:24 +1100 (EST), Damian Conway wrote:
> > > And has anyone pointed out that C 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
Jarkko Hietaniemi writes:
> > I'm not too worried about getting the vtbl right at the first because
> > it will be pretty obvious how it should go once the code starts to form.
>
> Some planning isn't that painful :-)
Yes. Especially given that vtables are an unbenchmarked change. It'd
be good
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 i
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 th
> Wouldn't these go on the SV and not on the inner type? Maybe I'm
> thinking value when you're saying variable? The following seem useful
> on variables too:
>
> before_get_value
> after_get_value
> before_set_value
> after_set_value
>
> There ought to be specializations of get_value an
Dan Sugalski wrote:
> get_value
> set_value
Wouldn't these go on the SV and not on the inner type? Maybe I'm
thinking value when you're saying variable? The following seem useful
on variables too:
before_get_value
after_get_value
before_set_value
after_set_value
There ought to b
Buddha Buck wrote:
> Would you go for:
>
> @a[$first;*];
> @a[*;$last];
> @a[$first;*;$last]?
>
> Say yes, and I'll add it tonight!
Nice! I'd go as far as implying a trailing ';*' if omitted.
>
> I'm unsure if @a[*;$middle;*] has any reasonable interpretation.
Probably just croak. Unless so
On Thu 31 Aug, Mark-Jason Dominus wrote:
> Summary report 2831
> RFC 110: counting matches (Richard Proctor)
>
> An extensive side discussion of
>
> $count = () = m/PAT/g;
>
> developed, including an excursion off into context issues. I have
> asked th
Buddha Buck wrote:
> RFC X+2: Retrieving Matrix dimensions
> Present @#matrix as analogous to $#array
> Discuss what $#matrix should return, as well as @#array
> What is @matrix in scaler context? (undef, anyone?)
Number of elements? For sparse matrices number of non-zero elements?
At 08:10 AM 9/1/00 +1200, 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;;]
Would you go for:
@a[$first;*];
@a[*;$last];
@a[$first;
>> get_int *
>> get_float *
>Could you elaborate on these a lot? What's an 'int'? What's a 'float'?
>Having lately been battling a lot with quad ints and doubles vs long doubles
>I seriously want this interface not to suck.
I was a tad concerned there, too. I'm hoping one can painles
Karl Glazebrook wrote:
> This also addresses one pain in current PDL which is the
> difficulty of multi-dim indexing.
I like it, too ;)
> > print $a[[0,0,0]];# literal ref list
> > print $a[0;0;0]; # literal singleton ; list
> > print $a[[$y,$y,$y]]; # variable-based ref list
> > print
I'm confused (I might have missed some discussions, being busy in other
fronts) so please bear with my silly questions.
> type
The basic set-in-stone types are...?
> name
Huh? A name for what? (How does this relate to a 'string'?)
> get_bool
Stored as...? char? int? Boolean or
Ken Fox wrote:
> Trolling?
No, I'm not, it's the direction that RFC 61 ends up if you let it
take you there.
fast perl6 becomes, as well as slicing, dicing and scratching your
back, a drop-in replacement for gcc.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Graham Barr wrote:
> On Thu, Aug 31, 2000 at 03:55:28PM +1100, Damian Conway wrote:
> > And has anyone pointed out that C is just:
> >
> > sub list {@_}
>
> Um no. I would expect it to be
>
> sub list { @_[0..$#_] }
According to my quickie tests, both have the desired effect
(supplying l
At 04:43 PM 8/31/00 -0400, Dan Sugalski wrote:
>Okay, here's a list of functions I think should go into variable vtables.
>Functions marked with a * will take an optional type offset so we can
>handle asking for various permutations of the basic type.
Perhaps I'm missing something... Is this f
Okay, here's a list of functions I think should go into variable vtables.
Functions marked with a * will take an optional type offset so we can
handle asking for various permutations of the basic type.
type
name
get_bool
get_string *
get_int *
get_float *
get_value
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 macro
Tom Christiansen wrote:
>
> >Is some technical reason that this can't be done in perl 5? I hate
> >having to add another pair of braces just to reassure perl that I didn't
> >forget a comma:
>
> >print {$fh{$name}} "data\n";
>
> Indirect objects are very limited in what they can be.
Curre
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
> > And has anyone pointed out that C 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.
Damian
>Is some technical reason that this can't be done in perl 5? I hate
>having to add another pair of braces just to reassure perl that I didn't
>forget a comma:
>print {$fh{$name}} "data\n";
Indirect objects are very limited in what they can be.
--tom
Tom Christiansen wrote:
> >=item Complex filehandle references
>
> >my %filesystem;
> >my $filename = '/etc/shells';
> >open $filesystem{$filename}, $filename
> >or die "can't open $filename: $!";
> >print <$filesystem{$filename}>;
> >__END__
>
> >GLOB{0xa042284}
Fisher Mark wrote:
> The rest of us with our TVs, VCRs, and so on have only compiled
> code in our devices.
I'd buy a microwave that resets to 'JAPH' after a power failure.
Maybe. ;)
- Ken
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
TC> It just kinda irks me here:
TC> $total += 2 * do {
TC> my $count = 0;
TC> for $n (@nums) { $count += $n }
TC> $count;
TC> };
TC> I rather that were:
TC> $total += 2 * do {
TC> my $count = 0;
[perl6-language removed from the follow-up]
"David L. Nicol" wrote:
> I want to see Perl become a full-blown C/C++ JIT. Since Perl is for
> a large part a compatible subset of C I don't see this as unrealistic.
Trolling? First, Perl is more like lisp with a good syntax -- in other
words about a
If I'm stepping on toes here, please tell me...
Here are some suggestions for some upcoming language-data RFC's I'm
thinking of writing:
RFC 169v2: Matrix Indexing
Cover my $matrix[$x;$y;$z] syntax
Add Jeremy's $matrix[$listref] syntax
Discuss why two ways of doing it.
Move inde
> in any case, i think we have a fair agreement on rfc 158 and i will
> freeze it if there is no further comments on it.
In light of this:
$& The string matched by the last successful pattern match (not
counting any matches hidden within a BLOCK or eval() enclosed
by the
>actually it is more like which code refers to $& and which regex that
>caem from. the problem stems from $& being a global and not local like
>$1.
Say what? They scope the same!
sub foo { /./ }
$_ = "stuff";
/.../;
foo();
print $&;
--tom
Tom Christiansen writes:
> >Yes, but 'eval' has the semantics "run this code but don't let it play
> >any funny tricks on me, like dying or anything", where 'do {...} while'
> >has the semantics "a while loop that evaluates its condition at the
> >end". There's no obvious reason why 'return'
> MD> One of Uri's suggestions in RFC 158 was to compute $& only for
> MD> regexes that have a /k modifier. This would solve the $& problem
> MD> because Perl would compute $& only when asked to, and not for
> MD> every other regex in the rest of the program.
>
> the rfc was about makin
[cc'd to internals to check a possible performance problem.]
Steven W McDougall wrote:
> > 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($f
> "MD" == Mark-Jason Dominus <[EMAIL PROTECTED]> writes:
MD> The $& cost is paid by every regex in the entire program, whether they
MD> used it or not. This is because Perl has no way to tell which regexes
MD> use $& and which do not.
actually it is more like which code refers to $&
>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
construct infinitely many beautiful and powerful effects. This
Chaim Frenkel wrote:
> You are now biting off quite a bit.
What good is half a transaction? If transactions are to be useful,
they should be fully supported -- including rolling back stuff some
third party module did to its internal variables. (Maybe that's a
little extreme ;)
> I believe that t
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, sim
>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 bu
>AFAICT we could make it a syntax error iff foo is not used in void context;
>Perl must be able to tell whether or not it is used in order to know what
>context the result is in, right?
Well, that depends. Often you must delay till run-time. When Perl
simply sees something like:
sub fn {
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'
At 02:30 PM 8/31/00 -0500, Christopher J. Madsen wrote:
>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;
> >
>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 $/ =
1 - 100 of 178 matches
Mail list logo
