On Fri, Aug 18, 2000 at 08:46:17PM +0100, Richard Proctor wrote:
>
>There is one significant area of perl that has very little attention here
>(other than one of my RFCs) that is regexs.
Are you volunteering to chair a sublist?
*grin*
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://neti
Peter Scott wrote:
>
> At 08:43 PM 8/19/00 -0600, Tony Olekshy wrote:
> >Peter Scott wrote:
> > >
> > > Dave Rolsky wrote:
> > > >
> > > > Tony Olekshy wrote:
> > > > >
> > > > > die
> > > > > If argument is anything else, raise a run-time
> > > > > exception.
> > > >
> > > > So this pro
Uri Guttman <[EMAIL PROTECTED]> writes:
> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
> PS> At 08:50 PM 8/19/00 -0400, [EMAIL PROTECTED] wrote:
> >> I do believe thbis is one of the reasons sysread is there
> >>
> >> perldoc -f sysread
>
> PS> Au contraire; sysread reads
On Sat, Aug 19, 2000 at 05:45:39PM -0700, Peter Scott wrote:
>At first I thought this was a -io item, but then I realized the -io part is
>easy; it's the -language part I need to get right :-)
Um. The -io sublist is called -language-io for a reason -- it's for
language discussions related to IO.
I think all discussion fo RFC 76 (reduce) should be on the new -data
sublist. Jeremy, am I on track here?
K.
--
Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/
Open Source development, consulting and solutions
Level 10, 500 Collins St, Melbourne VIC 3000
Phone: +61 3 9614 0949
> If you do it as scalar only. You lose a lot of useful possiblities.
This is indisputable.
> Why do you mind having an attribute?
The problem would seem to be that an lvalue subroutine might return
either an array or a scalar, depending on its arguments. That *can't*
be resolved at compi
On Fri, Aug 18, 2000 at 05:22:17PM -0500, David L. Nicol wrote:
>RFC: Perl6 is Final. There will Be No Perl7
>RFC: Everything is Accessible and Mutable
>RFC: The perl6 reference implementation, no matter how slow it is,
>will be written in perl5, in some kind of well defined virtual machine.
>
At 12:01 AM 8/20/00 -0400, Bryan C. Warnock wrote:
>On Sat, 19 Aug 2000, Peter Scott wrote:
> > -io guys, I've been looking through your archives at the line discipline
> > stuff and I don't see this there: what do you think? The proposal is
> for a
> > mode that specifies a maximum number of ch
> I think we agree.
>
> $foo is a tied variable
> $bar is a normal variable
>
>sub zap : lvalue { return $_[0] ? $foo : $bar }
>
>zap(1) = 5; # Goes to tied variable
>zap(0) = 5; # Normal store
And it would also be good to be able to overload oper
At 08:43 PM 8/19/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > Dave Rolsky wrote:
> > >
> > > Tony Olekshy wrote:
> > > >
> > > > die
> > > > If argument is anything else, raise a run-time
> > > > exception.
> > >
> > > So this probably shouldn't be the case.
> >
> > This soun
http://turnbull.sk.tsukuba.ac.jp/Tools/I18N/LJ-I18N.html is a fine paper
on the need for and challenges involved in I18N and L10N support.
--
\let\l\let\l\d\def\l\a\active\l~\catcode~`?\a~`;\a\d;{~`};!\a\d!{?;~}\l?\the;#
!;]!\l]\l;\.!;,!;\%!;=!]=\d],\expandafter;[!][{=%{\message[};\$!=${\uccode`
On Sat, 19 Aug 2000, Randal L. Schwartz wrote:
> I'll have an adjacent cell. I actually like that *better* than $self.
> Let's not stop there though. Perhaps we need "self" and "super" and
> "thisContext". Only half joking... this would solve a lot of the
> hacking issues. self could be a "die
> "BCW" == Bryan C Warnock <[EMAIL PROTECTED]> writes:
>> 3. Subroutines
>>
>> sub foo { print "foo" }
>>
>> Thread1 Thread2
>> foo(); eval 'sub foo { print "bar" }';
>>
>> This prints either "foo" or "bar".
>>
>> Thread2 replaces the coderef for &main::foo. Th
This belongs on -internals. The threading model will probably be
identical for all ports.
And my suspicion is that -internals will use whatever the platform
provides.
I don't think we want to write a portable threading capability.
> "SWM" == Steven W McDougall <[EMAIL PROTECTED]> writes:
Perhaps foo should be lazily evaluated.
Then the want would return the correct usage. Though once the value
is returned, it should stay that way on all subsequent usages until
the call stack is unwound.
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
>> > Besides, context can't always
What about?
sub foo { lreturn ($one, $two, $three); }
foo = (0..10);
or
foo = &bar;
The compiler needs to know what foo is returning. The attribute tells
perl evaluate foo to determine the context (i.e. where to put the
dirty laundry) and the goes ahead and does the re
Or the lack of a %rest?
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
DC> * Label an argument such that there is no corresponding named
DC> parameter.
>>
>> Could this be eased slightly? How about a %rest hash, if supplied
>> in the prototype would absorb the unused named parameters
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
GB> On Fri, Aug 18, 2000 at 12:25:42AM -0400, Chaim Frenkel wrote:
>> As Graham pointed out, is an lvalue sub supposed to act like a tie or
>> like a variable.
GB> Both.
GB> As Damian points out the lvalue sub must return something that can
I missed the original posting. But why wouldn't you?
If lvalue subs worked properly, so should
local lvalue_sub()
The return of an lvalue sub should be something that is lvaluable.
So local should be able to chew on it.
> "JDB" == J David Blackstone <[EMAIL PROTECTED]> writes:
On Sat, 19 Aug 2000, Peter Scott wrote:
> -io guys, I've been looking through your archives at the line discipline
> stuff and I don't see this there: what do you think? The proposal is for a
> mode that specifies a maximum number of characters to be returned by a
> getline (<>) so that parano
Peter Scott wrote:
>
> Dave Rolsky wrote:
> >
> > Tony Olekshy wrote:
> > >
> > > die
> > >
> > > If argument isa "Exception", raise it as the new
> > > exception and die in the fashion that Perl 5 does.
> > >
> > > If argument is a string, wrap it in a new Error
> > > object, set
At 09:22 PM 8/19/00 -0500, Dave Rolsky wrote:
>On Sat, 19 Aug 2000, Tony Olekshy wrote:
>
> > die
> >
> > If argument isa "Exception", raise it as the new exception and
> > die in the fashion that Perl 5 does.
> >
> > If argument is a string, wrap it in a new Error object, setting
> >
There's been quite a lot of discussion on this list in the last week so
it's probably time for a summary. The current RFCs relevant to this list
are:
18Immediate SubroutinesJean-Louis Leroy v1
21Replace wantarray with a generic want function Damian Conwa
On Sat, 19 Aug 2000, Tony Olekshy wrote:
> die
>
> If argument isa "Exception", raise it as the new exception and
> die in the fashion that Perl 5 does.
>
> If argument is a string, wrap it in a new Error object, setting
> the message ivar to the given string, and raise that in
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> No, the point is not that I want truncated lines but that I want to say
PS> "toss/leave back the excess over 100,000 characters when I do a ,
PS> for I am sure that a line longer than that would be an error of some
PS> kind."
In reply to your message from the not too distant future: next Saturday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Sat, 19 Aug 2000 20:59:26 -0400
From: Jerrad Pierce
>Au
In reply to your message from the not too distant future: next Saturday AD
Reply-to: [EMAIL PROTECTED]
Return-receipt-to: [EMAIL PROTECTED]
Organization: a) Discordia b) none c) what's that?
Content-Typo: gibberish, charset=ascii-art
Date: Sat, 19 Aug 2000 20:50:44 -0400
From: Jerrad Pierce
I do
At 06:22 PM 8/19/00 -0700, I wrote:
>No, the point is not that I want truncated lines but that I want to say
>"toss/leave back the excess over 100,000 characters when I do a ,
>for I am sure that a line longer than that would be an error of some kind."
I phrased this badly. I meant to say that
At 08:59 PM 8/19/00 -0400, [EMAIL PROTECTED] wrote:
> >Au contraire; sysread reads exactly the number of characters requested;
> >what I want is a way for programs that do all over the place to be
> >protected if someone throws a gargantuan number of characters at FH without
> >a newline. The $/
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> At 08:50 PM 8/19/00 -0400, [EMAIL PROTECTED] wrote:
>> I do believe thbis is one of the reasons sysread is there
>>
>> perldoc -f sysread
PS> Au contraire; sysread reads exactly the number of characters
PS> requested; what I
I'm of the camp that feels perl should have a fixed epoch rather than the
epoch of the underlining OS. Furthermore, I can understand that the OS
epoch can also be important when looking outside of perl. Thinking this
over for a while it occurred to me that time() currently has no arguments
and th
At 08:50 PM 8/19/00 -0400, [EMAIL PROTECTED] wrote:
>I do believe thbis is one of the reasons sysread is there
>
>perldoc -f sysread
Au contraire; sysread reads exactly the number of characters requested;
what I want is a way for programs that do all over the place to be
protected if someone t
Peter Scott wrote:
>
> At 11:04 PM 8/18/00 -0600, Tony Olekshy wrote:
> >
> > As currently promulgated, catch "Foo" {} will always catch,
> > because "Foo" is true. Will this cause confusion for developers
> > who meant to say catch Foo {}?
>
> This is a good point, but I'm not about to concede
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> > That's not what's proposed. The core and other users would
> > use classes derived from Error to raise errors. Other users
> > could even just Error itself. Exception is reserved for
> > exceptions that don't and shouldn't derive from Error.
>
At first I thought this was a -io item, but then I realized the -io part is
easy; it's the -language part I need to get right :-)
I have often thought that there should be a way to say that a readline()
should limit the length of line it could return, or in circumstances where
the input source
I added another header to the perl6-all mails. X-Mailing-List-Name
will contain the original list name, san -help and whatnot.
So the recommended procmail filter rule would now be:
:0:
* ^Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
* ^X-Mailing-List-Name: \/(.*)
perl/$MATCH
or someth
Damian Conway wrote:
> sub sort (^&comparator, @list) {
> for (1..@list**3) {
> my ($i, $j) = (rand(@list), rand(@list));
> @list[$i,$j] = @list[$j,$i]
> unless $comparator->(a: $list[$i], b: $list[$j]);
>
As currently promulgated, catch "Foo" {} will always catch,
because "Foo" is true. Will this cause confusion for developers
who meant to say catch Foo {}? And what happens when someone
says catch "Foo", "Bar" {}?
We can't just say that catch Foo {} and catch "Foo" {} are the
same thing, or that
"Brust, Corwin" wrote:
>
> Peter Scott wrote:
> >
> > I think it would be best to supply a reference. This is a
> > mammoth RFC already and it will be decided on by people who
> > very well know what exception handling is; their reading time
> > is at a premium.
>
> Decided on, yes, but having th
Nathan Torkington writes:
: The fact that other languages can implement it trivially doesn't mean
: that Perl can. I'd like us to have realized what kind of internals
: support is needed for a language feature (e.g., optree duping for
: partially-evaluated subroutines) *before* speccing out the i
On 8/19/00 4:04 PM, Damian Conway wrote:
> You can have your cake, but not force us to eat it too...
Come, partake of the Loony Cake... :)
> Like $AUTOLOAD, $ME would be dynamically scoped:
>
> package LoonyBin;
>
> sub self {$ME};
>
> sub get_polite_age : method {
> return (self->age >= 40)
There have been several good suggestions. We'll leave the discussion run
for another few days and then I'll try to summarise the main points in a
single post.
John
--
"The Mosaic code has replaced the law of the jungle."
James Joyce - Ulysses
At 11:04 PM 8/18/00 -0600, Tony Olekshy wrote:
>As currently promulgated, catch "Foo" {} will always catch,
>because "Foo" is true. Will this cause confusion for developers
>who meant to say catch Foo {}?
This is a good point, but I'm not about to concede an extra keyword
:-) Let's look at som
> >We write a lot of simple throws, most of which would look
> >like this with the new mechanism as proposed so far:
> >
> > throw Error_DB "ABC.1234: Message about what went wrong.";
> >
> > Without the techniques and hooks I've described in 88v2d2,
> > I'd have to write the following, which has
Peter Scott wrote:
>
> Tony Olekshy wrote:
> >
> > "An exception is not necessarily an error.\n" x 3;
>
> Note that 'error' is a vague term for which you have a specific
> meaning in mind here; be sure to give that definition where it's
> important.
How 'bout something like, "an exception r
I agree with Tim that it's a red herring that unix systems don't
normally have access to a TAI source.
The proposal under discussion is to use one time format for all
platforms. So maybe there's a minor difficulty in converting unix
time to TAI time; probably it's not as large as the difficult
On 8/19/00 11:50 AM, Randal L. Schwartz wrote:
> I actually don't like the literal $ME. It usurps a variable name that
> has been legal for customer use in prior Perls. Why not use something
> more "system-belonging" like %_ or even $_? In fact, "self" in $_ and
> "args" in @_ has a nice symmet
=head1 TITLE
Structured Exception/Error Handling Mechanism
=head1 VERSION
Maintainer: Tony Olekshy <[EMAIL PROTECTED]>
Date: 19 Aug 2000
Version: 2 (Draft 3)
Mailing List: [EMAIL PROTECTED]
Number: 88
=head1 DRAFT STATUS
This redaction has been modified to reflect Pete
> "John" == John Siracusa <[EMAIL PROTECTED]> writes:
John> I don't like $ME either, but my alternative is probably even more
John> blasphemous: use $self. "It usurps a variable name that has been legal for
John> customer use in prior Perls!" you re-exclaim. Not if it only appears in a
John
RFC 88 is discussing making errors into exceptions. I strongly
don't think we should attempt the converse, that is, making
exceptions into errors.
"An exception is not necessarily an error.\n" x 3;
That's why RFC 88 defines both Exception and Error classes, the
latter of which inherits from
Glenn Linderman wrote:
>
> So that was one thing I tried to do in RFC 119: it discusses
> only throwing and handling exceptions. It leaves open what is
> thrown. It allows for simple exceptions in simple programs to
> use simple mechanisms (throw a scalar); it allows for complex
> but non-OO e
> > Now, go home and write it out 100 times:
> >
> > "Array and placeholder indices both start at *zero*!"
> Array and placeholder indices both start at *zero*!
> Array and placeholder indices both start at *zero*!
> Array and placeholder indices both start at *zero*!
> Array
> Well, RFC 23 doesn't mention ^0, and has several examples starting
> at ^1. And it draws the analogy between ^1, ^2, etc and $1, $2,
> etc. I didn't make it up.
My apologies. The examples you refer to are incorrect. They were added by
a helper, but the responsibility is mine -- for not
Damian Conway wrote:
>
> It's an idea that within a method call, the object reference would
> not be passed as the first argument (or maybe, not *just* as the
> first argument), but in a variable named $ME. I was pushing that
> envelope a little.
Is this RFC'ed yet? If not, I'll do it, but not u
"David L. Nicol" wrote:
> > =head1 TITLE
> >
> > Default methods for objects
>
> Title does not match description. How about
>
> Overloadable bracketing
>
> or
>
> Brackets as Methods
>
> or
>
> Syntax as Overloadable Methods
Good point! Will be part of v2.
Christian
Nathan Torkington wrote:
>
> David L. Nicol writes:
> > RFC: Perl6 is Final. There will Be No Perl7
> >
> > We declare that our framework willbe so flexiblke
> > that anything can be done with it and there will be no penalty
> > for something being in-core opposed to out-of-core and so on
Larry Wall wrote:
> Jarkko Hietaniemi writes:
> : > > (Yes, there is a small aesthetic edge in using $a vs $_[0], but I still
> : > > consider the $ and $b to be warts.)
>
> Yes, but has anyone pointed out that
>
>@out = sort ^b cmp ^a, @in;
>
> won't do what people will certainly think it ou
Array and placeholder indices both start at *zero*!
Array and placeholder indices both start at *zero*!
Array and placeholder indices both start at *zero*!
Array and placeholder indices both start at *zero*!
- Original Message -
From: "Damian Conway" <[EMAIL PROTECTED]>
To: "Jarkko Hietani
On Sat, Aug 19, 2000 at 07:57:34AM +1000, Jeremy Howard wrote:
> The choice of algorithms is a great idea, but why do we need a modifier?
> Isn't it a pretty straightforward set of rules that allow us to decide if a
> DFA matcher will work?
Well, that all depends what the meaning of the word work
> So perhaps you should ask people to contribute implementation notes
> sections to your RFCs rather than entire RFCs? And no sense in requiring
> that for the initial version, though a solicitation in the text of the
> RFC itself might hasten their appearance.
I thought that was what
> So that's what I missed, that you expect named actual parameters to
> be legally passable to subs with unnamed formal parameters. I would
> consider that inappropriate, needing at least a warning.
Perhaps under:
use strict 'parameters';
> If people want to use named pa
Simon Cozens wrote:
> Currently, SvPVX(foo) requires one lookup
No lookups at all -- SvPVX(foo) is just a pointer offset, i.e. an add.
> with a vtable, it would necessitate two, (One to find the functino in "foo",
> and then the functino must find the data in "foo")
It would probably work somet
On Fri, 18 Aug 2000, Steven W McDougall wrote:
> Thread1 Thread2
> push @a, (1, 2, 3); push @a, (4, 5, 6);
>
> The interesting question is whether push is atomic.
Array operations should be atomic.
>
> Atomic
> @a is either (1, 2, 3, 4, 5, 6) or (4, 5, 6, 1, 2,
I'm rejigging RFC 88 so that not only does $@ refer to the
current exception, but @@ refers to the exception stack. This
moves all the link handling stuff (such as link and any) out
of the Exception class and into the handling mechanism itself.
So, now you can say:
catch grep { $_->isa
Damian Conway wrote:
>> Well, RFC 23 doesn't mention ^0, and has several examples starting
>> at ^1. And it draws the analogy between ^1, ^2, etc and $1, $2,
>> etc. I didn't make it up.
>
> My apologies. The examples you refer to are incorrect. They were added by
> a helper, but the
> > If there are any RFC's which you have in mind and could send me your
> > notes on, I'd be *more* than happy to help out.
> >
> This is actually an excellent idea, because then Damian can
> concentrate on coming up with the key ideas. However, rather than
> having to shuffle n
Larry Wall wrote:
> Jarkko Hietaniemi writes:
> : > > (Yes, there is a small aesthetic edge in using $a vs $_[0], but I
still
> : > > consider the $ and $b to be warts.)
> : > >
> : > And anyhow, this will work just fine (see RFC 23):
> : >
> : > $sum = reduce ^a + ^b, @numbers;
> :
> : I have b
On the main perl6-language list, Larry Wall wrote:
> The main downside of accessors is that you can't (currently) say
>
> local $obj->attribute = 2;
Oooh. Someone proposed this as a reason why we can't get rid of
dynamic variables, and I've spent all evening being troubled by it.
If that "c
Larry Wall wrote:
> The main downside of accessors is that you can't (currently) say
>
> local $obj->attribute = 2;
Is anyone thinking of this? This comes at a good time when I've
been looking for just such an idea to shore up one of my proposals on
perl6-language-strict.
J. David
Sam Tregar wrote:
>
> On Fri, 18 Aug 2000, Graham Barr wrote:
> > So it is a security issue then as it needs somewhere to cache these
> > object files, and anyone must be able to do it.
>
> The place it stores its objects is configurable, so it's only a security
> problem if you make it one! I'
Well, RFC 23 doesn't mention ^0, and has several examples starting at ^1. And
it draws the analogy between ^1, ^2, etc and $1, $2, etc. I didn't make it up.
So I don't think you're being consistent here. Neither do I consider it an
improvement to add ^0.
While the positional placeholders may w
At 08:01 PM 8/18/00 -0600, Tony Olekshy wrote:
>RFC 88 is discussing making errors into exceptions. I strongly
>don't think we should attempt the converse, that is, making
>exceptions into errors.
>
> "An exception is not necessarily an error.\n" x 3;
Note that 'error' is a vague term for wh
> Since there is a run-time component we could probably write a
> proof-of-concept parser for some of this in perl5 now:
>
> use NamedParameters;
This would certainly be an interesting and useful module. I
encourage someone to create it. Of course, it couldn't (easily)
include all
> > It's an idea that within a method call, the object reference would
> > not be passed as the first argument (or maybe, not *just* as the
> > first argument), but in a variable named $ME. I was pushing that
> > envelope a little.
>
> Is this RFC'ed yet?
It may have been m
Mike Pastore <[EMAIL PROTECTED]> writes:
> I like the proposed syntax! I also think that C would be
> useful, ...
Seconded. It nicely fits in the current way each() is used and no
backward incompatibilties.
Especially when iterating sparse arrays.
while (($index,$value) = each(@sparse_array))
hi all
Can any body tell me how do i learn mod perl and what is mod perl
i am new to perl and got some experence in php
can i get some guide lines
thanks in adv
reg
rajesh mats
--
QuantumLink Communications, Bombay, India
Jarkko Hietaniemi writes:
: > > (Yes, there is a small aesthetic edge in using $a vs $_[0], but I still
: > > consider the $ and $b to be warts.)
: > >
: > And anyhow, this will work just fine (see RFC 23):
: >
: > $sum = reduce ^a + ^b, @numbers;
:
: I have been amply reminded of this, thank
Dave Storrs wrote:
> On Thu, 17 Aug 2000, Jonathan Scott Duff wrote:
> > BTW, if we define C to map keys of a hash to named place holders
> > in a curried expression, this might be a good thing:
> >
> > with %person {
> > print "Howdy, ", ^firstname, " ", ^lastname;
> > }
> >
Nathan Torkington wrote:
>
> Exporter is pure Perl, but
> I'd love to see its functionality moved into the core (or, indeed,
> replaced by a general compile-time interface setup with separate
> runtime execution semantics) for speed reasons.
Anyone RFC'ing this yet?
This time I'm *not* voluntee
On Fri, 18 Aug 2000, Steven W McDougall wrote:
> I've spent the last 3 years programming WindowsNT threads in MSVC++,
> and I *really* like it. I want similar capabilities in Perl6.
>
> 1 The C++ thread model
> Here is the thread model that I have in C++. It is a starting
> point for thinking abo
On Fri, 18 Aug 2000, Graham Barr wrote:
> > No. The documentation states that the compilation is done only when the
> > source file is out of date with the companion object file. As I
> > understand it, Inline has some kind of limited automatic make ability.
>
> So it is a security issue then a
> I think this does the right thing too:
>
> @out = sort ^0 cmp ^a, @in;
>
> Since numbered placeholders have higher priority than named, it
> should create the function
>
> sub ($, $a) { $_[0] cmp $_[1] }
> When the curry is evaluated, the a: parameter is bound t
At 09:40 PM 8/18/00 -0600, Tony Olekshy wrote:
>Peter Scott wrote:
> >
> > Tony Olekshy wrote:
> > >
> > > "An exception is not necessarily an error.\n" x 3;
> >
> > Note that 'error' is a vague term for which you have a specific
> > meaning in mind here; be sure to give that definition where
/--- On Fri, Aug 18, 2000 at 06:19:43PM -0400, Chaim Frenkel wrote:
| I don't think you should even attempt to version/transaction
| protect
| a tied variable. Anything that leaves the memory or could leave
| the
| memory (e.g. socket write) should probably not be versioned.
|
| Unles
> Good distinctions. So, if I'm reading you right, this won't work?
>
>@oldpath = $tree->path('L','R') = ('R');
It means:
@oldpath = $tree->patch('L','R')->OP_=('R');
So it will work fine, if that's what you intended. :-)
> Basically, the lvalue sub by your definition
>From his padded room, Randal suggested:
> > "John" == John Siracusa <[EMAIL PROTECTED]> writes:
>
> John> I don't like $ME either, but my alternative is probably even more
> John> blasphemous: use $self.
>
> John> But wait, it gets worse: I'd even be happy with the bar
> : Text::Balanced has to track in order to parse almost any Perl code.
>
> It's a good thing you said "almost".
Ah, that Jesuit education finally pays off! ;-)
> Does it parse [*]] correctly?
No, but only because C ignores punctuation vars entirely.
It would be a simple fix to
Larry pointed out:
> Yes, but has anyone pointed out that
>
>@out = sort ^b cmp ^a, @in;
>
> won't do what people will certainly think it ought to?
It *will*, if C *names* the two values it passes to the
comparator!
E.g.:
sub sort (^&comparator, @list) {
Nathan Wiger writes:
> Anyone RFC'ing this yet?
I could RFC it in vague terms, but I'm waiting to see how things
like interfaces turn out.
> Which reminds, anyone gonna RFC the rumored death of typeglobs? :-)
I figured that as Larry had used it as an example of things that were
up for grabs in
Clever, and really obscure; wouldn't this then require that _everyone_ that
writes a curried expression for the sort sub use ^a & ^b, and that everyone
writing a non-curried sort sub name their parameters a and b? I guess that
wouldn't necessarily be bad, but it would be restrictive.
Damian Conw
Tim Jenness <[EMAIL PROTECTED]> writes:
> I think this is a bit of a red herring. Presuambly the time on your
> computer depends on where you are synching from (if at all) - if you are
> synching to a TAI time server then you are fine. In the worst case you
> are synching to the sys admins watch
Damian Conway wrote:
>
> The lvalue accessor *shouldn't* be doing the assignment (what if an assignment
> isn't what I want?).
>
> The (overloaded) operator = should do the assignment. To whatever lvalue
> the lvalue subroutine returns.
>
> Or the "assignment" should be done by operator += or o
On Fri, Aug 18, 2000 at 03:15:54PM -0700, Steve Fink wrote:
> There would still be a use of a /f like flag, though -- treat all (...)
> like (?:...). That would make the regex more likely to be DFA-able, and
> is often what I want but I don't want to clutter up my regex with those
> nasty ?:'s eve
Jeremy Howard wrote:
>
> > Steve Fink writes:
> > > And both those examples apply to the underpinnings. Ok, maybe I have an
> > > unusually broad definition of the word "underpinnings". Think "anything
> > > that can't be done with a pure perl module".
> >
> Say "anything that can't be done *fast
"Christopher J. Madsen" wrote:
> foreach $item $index (@array) {
> print $item, " is at index ", $index, "\n";
> }
That's useful syntax, but I'd rather it mean stepping
pair-wise through @array. Then we could scan through a hash
with
foreach $key $value (%hash) { ... }
(Hashes are
[EMAIL PROTECTED] writes:
: Bare C and bare C *are* the main culprits. They require
: the tokenizer to track expression semantics so that when it encounters a
: '/' or '?' it can tell whether a pattern is plausible in this place or
: whether they've reached a division or hook operator, respectivel
Larry Wall wrote:
>
> Yes, but has anyone pointed out that
>
>@out = sort ^b cmp ^a, @in;
>
> won't do what people will certainly think it ought to?
>
> Larry
Well, this will hopefully be moot. I was inspired by discussion here, my
own disdain, and p5p strict issues to write an RFC simply
> "Damian" == Damian Conway <[EMAIL PROTECTED]> writes:
Damian> Don't give alternatives. Give a "these alternatives were considered and
Damian> *rejected*" list. $ME is capitalized (like all "magic" vars), and short.
I actually don't like the literal $ME. It usurps a variable name that
has
On Fri 18 Aug, Damian Conway wrote:
>> All of these can be done today but are not necessarily "easy".
>>
>
> /\A(?s:(?!and).)*\Z/
>
> /pattern returned from ${\some_function} as part of a regex/
>
> /match any of (${\join'|',@list}) here/
>
I am not saying these things can't be done,
> Except that Perl 6 people will know all about numbered parameters, so they
> will write:
>
> @out = sort ^2 cmp ^1, @in;
>
> and it will work just as they expect!
As long as they expect it to fail miserably! :-(
Now, go home and write it out 100 times:
"Array and
1 - 100 of 106 matches
Mail list logo
