> I lie: the other reason qr{} currently doesn't behave like that is that
> when we interpolate a compiled regexp into a context that requires it be
> recompiled,
Interpolated qr() items shouldn't be recompiled anyway. They should
be treated as subroutine calls. Unfortunately, this requires a
Bart Lateur:
> >If there are no objections, I will freeze this in twenty-four hours.
>
> Oh, I have a small one: I feel that this pseudo-random salt should NOT
> affect the standard random generator. I'll clarify: by default, if you
> feed the pseudo-random generator with a certain number, you'l
> > Joshua N Pritikin writes:
> > : http://www.oreillynet.com/pub/a/python/2000/10/04/stackless-intro.html
> >
> > Perl 5 is already stackless in that sense, though we never implemented
> > continuations. The main impetus for going stackless was to make it
> > possible to implement a Forth-styl
My critique of the Perl 6 RFC process and following discussion is now
available at
http://www.perl.com/pub/2000/11/perl6rfc.html
Mark-Jason Dominus [EMAIL PROTECTED]
I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for
> To strive for balance, I think perl.com's home page should also have the
> links to Larry's ALS talk and slides.
Thanks very much. I have asked the folks at Songline to arrange this.
We were going to carry these, and in fact the ORA were prepared to
complete Nat's transcript, but then Ask po
Frank Tobin has generously given me permission to forward his comments
to this list.
--- Forwarded Message
Date: Thu, 2 Nov 2000 00:31:42 -0600 (CST)
From: Frank Tobin <[EMAIL PROTECTED]>
X-Sender: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Response to Critique of Perl 6 RFC Process
M
> I just figured it was time for a little nudge.
Yes, thank you. It is on www.perl.com now.
> Anyone think others are needed?
"Stick to the subject."
remove the "Garbage collecting"
message which people perceive as slowing Emacs down and tell them
that it had been sped up. It is, somehow, permissible for a
program to take a lot of time doing any other task than
administrative duties like garbage collection.
Mark-Jas
> "The new version must be better because our gazillion dollar marketing
> campaign said so. (We didn't really *fix* anything.)
The part I found interesting was the part about elimination of the message.
Perceived slowness is also important.
> So you can say
>
> use Memoize;
> # ...
> memoize 'f';
> @sorted = sort { my_compare(f($a),f($b)) } @unsorted
>
> to get a lot of the effect of the S word.
Yes, and of course the inline version of this technique is also
common:
@sorted = sort { my $ac = $cache{$a} ||= f($a);
On (03 May 2001 10:23:15 +0300) you wrote:
> Michael Schwern:
> >
> > Would be neat if: my($first) = grep {...} @list; knew to stop itself, yes.
> >
> > It also reminds me of mjd's mention of: my($first) = sort {...} @list;
> > being O(n) if Perl were really Lazy.
>
> But it would need a
Says Dave Mitchell:
> Closures ... can also be dangerous and counter-intuitive, espcially to
> the uninitiated. For example, how many people could say what the
> following should output, with and without $x commented out, and why:
>
> {
> my $x = "bar";
> sub foo {
> # $x # <-
Dan Sugalski <[EMAIL PROTECTED]>:
> At 2:06 PM + 2/19/03, Peter Haworth wrote:
> >On Fri, 14 Feb 2003 15:56:25 -0500, Dan Sugalski wrote:
> >> I got clarification. The sequence is:
> >>
> >> 1) Search for method of the matching name in inheritance tree
> >> 2) if #1 fails, search for an AUTO
I'm writing automated tests for the example code in my book, which
will go into production early next month. I have the harness and test
apparatus all set up; I wrote a complete set of tests for chapter 6,
and I think I know how I want it done. But I need help writing the
tests themselves, becau
g
This warns you that C<"[EMAIL PROTECTED]"> is going to turn into
C if you don't backslash the C<@>.
See L<http://www.plover.com/~mjd/perl/at-error.html> for more details
about the history here.
Mark-Jason Dominus
TAI is an international time standard. It has a number of technical
advantages over UTC. One of these advantages is that it doesn't have
any silly truck with leap seconds.
Dan Bernstein has defined a time format called TAI64 which is based on
TAI. The format is very simple. TAI64 is almost c
ussion of what this would mean for calls
like
localtime(20)
and then I realized that, as usual, I have no idea what the RFC is
actually proposing.
Mark-Jason Dominus [EMAIL PROTECTED]
I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
It seems to me that there are at least two important things missing
from this proposal.
1. There is no substantive rationale presented for why the change
would be desirable.
The only reasons you put forth are:
* The syntax is ugly and unintuitive.
Ugliness is a matter of opinion, and I d
.
135 (v1): Require explicit m on matches, even with ?? and // as delimiters.
C and C are what makes Perl hard to tokenize.
Requiring them to be written C and C would
solve this.
Mark-Jason Dominus [EMAIL PROTECTED]
I am
> I'm not concerned about / being mistaken for division, since that
> ambiguity already exists with bare /pat/ matches.
Yes, but the current ambiguity is resolved from context in a rather
complicated way. Nevertheless it turns out that Perl does the right
thing in most cases. You are proposin
> There's also long been talk/thought about making $& and $1
> and friends magic aliases into the original string, which would
> save that cost.
Please correct me if I'm mistaken, but I believe that that's the way
they are implemented now. A regex match populates the ->startp and
->endp parts
> >I propose that this 'last successful match' behavior be discarded
> >entirely, and that an empty pattern always match the empty string.
>
> I don't see a consideration for simply s/successful// above, which
> has also been talked about.
Thanks, I will add this to the next version. I did c
> >Please correct me if I'm mistaken, but I believe that that's the way
> >they are implemented now. A regex match populates the ->startp and
> >->endp parts of the regex structure, and the elements of these items
> >are byte offsets into the original string.
>
> I haven't looked at it at all
> But maybe the effect of $& is greatly exaggerated or is a relic from
> perl4? Has anyone actually benchmarked this recently?
Matching with $& enabled is about 40% slower.
http://www.plover.com/~mjd/perl/amper.pl
> What exactly is matched by \g and \G is controlled by two new special
> variables, @^g and @^G, which are arrays of strings.
These sorts of global variables have been a problem in the past.
Since they change the meaning of the \g and \G escapes, I think they
should be pragmas or some other de
> Drawing on some of the proposals for extended 'for' syntax:
> for my($mo, $dy, $yr) ($string =~ /(\d\d)-(\d\d)-(\d\d)/g) {
> ...
> }
>
> This still requires that you know how many () matching groups are in
> the RE, of course. I don't think I would consider that onerous.
If ther rege
> > 1. Return the number of matches
> >
> > 2. Iterate over each match in sequence
> >
> > 3. Return list of all matches
> >
> > 4. Return a list of backreferences
>
> Please see RFC 164. It can handle all of 1-3.
You seem to have missed my point. I'm not ask
> > $count = () = $string =~ /pattern/g;
>
> Which I find cute as a demonstration of the Perl's context concept,
> but ugly as hell from usability viewpoint.
I'd really like to see an RFC that looks into making the following
features more orthogonal:
1. Return the number of match
Nat Torkington writes:
> Mark-Jason Dominus writes:
> > RFC should have a section that addresses the feasibility of
> > translating perl5 to perl6 code if the proposed change is adopted.
> > This section should be required.
>
> I agree.
>
> Ziggy, want to
> This is going to need a much better definition...
Yes, that was my point.
I snipped the following discussion, in which you argued against a
suggestion that I advanced only as an example of something that would
not work.
> (?^baz) should behave as (.*)(?{$1 !~ /baz/})
I don't think that's go
OK, I think this discussion should be closed.
Richard should add a section to RFC110 that discusses the
$count = () = m/PAT/g;
locution and its advantages and disadvantages compared to his
proposal, duly taking into account the many valuable comments that
have been made.
Thanks to eve
The IMPLEMENTATION section of the RFC is supposed to be mandatory, but
there have been an awful lot of RFCs posted that have missing or
evasive IMPLEMENTATION sections. I found more than 39% of all RFCs
have a missing or incomplete implementation section.
Here are the results of my survey. O
> > These 13 ( 8%) had very brief IMPLEMENTATION sections that
> > didn't contain any substantive discussion.
> >
> > These 21 (13%) contained remarks about the author's ignorance.
> >
> > These 15 ( 9%) had no IMPLEMENTATION section at all.
>
> The distinct
> Would there be any interest in adding these two ideas to this RFC:
>
> 1) tr is not regex function, so it should be regularized to
>
>tr(SEARCH, REPLACE, MOD, STR)
MOD should be last, because you're frequently going to want to omit MOD.
But I think this is worth discussing further, be
> =head1 IMPLENTATION
>
> No idea, but should be straight forward.
I think the reason this hasn't been done before it because it's *not*
quite straightforward.
The way tr/// works is that a 256-byte table is constructed at compile
time that say for each input character what output character is
> When does the structure get built? That's why eg. tr[a-z][A-Z]
> brooks no variables, for it is solely at compile time that these
> things occur, and why you must resort to delayed compilation via
> eval qq/.../ to prod the compiler into building you a new one.
Certainly. But if there were
> One thing to be careful of there is thread safety. You can't hand
> the data off the syntax node (the one with the tr op on it), because
> tr/$foo/$bar/ wouldn't work for several threads in it at the same
> time then.
Certainly, but that is true for everything else that is in the op
node, whi
> /t is suggested for "counT", as /c is already taken. Using /t
> without /g would be result in only 0 or 1 being returned, which is
> nearly the existing syntax.
It occurs to me that since none of the capital letters are taken, we
could adopt the convention that a capital letter as a regex mod
> On Mon, 28 Aug 2000, Mark-Jason Dominus wrote:
>
> > But there is no convenient way to run the loop once for each date and
> > split the dates into pieces:
> >
> > # WRONG
> > while (($mo, $dy, $yr) =
> On Tue, 29 Aug 2000 08:47:25 -0400, Mark-Jason Dominus wrote:
>
> >m/.../Count,Insensitive (instead of m/.../ti)
> >
> >That would escape the problem that we are running out of letters and
> >also the problem that the current letters are hard to remembe
> Make your suggestions. But I think it is all off-base. None of this is
> addressing some improvement in working conditions, ease of use, problems
> in the language, etc.
1. I don't agree.
2. This mailing list is also for discussing stylistic improvements to
the language.
3. If you thin
Richard Proctor's RFC166 says:
> =head2 Matching Not a pattern
>
> (?^pattern) matches anything that does not match the pattern. On
> its own, one can use !~ etc to negatively match patterns, but to
> match a pattern that has foo(anything but not baz)bar is currently
> difficult. With this sy
foo(?:)bar/ to get what you wanted. This
is almost identical to what Richard proposed anyway.
It is really not clear to me that this problem needs to be solved any
better than it is already.
I suggest that this section be removed from the RFC.
Mark-Jas
> >>solution to execute perl code inside a string, replacing "${\(...)}" and
> >
> >The first one doesn't work, and never did. You want
> >@{[]} and @{[scalar ]} instead.
>
> "Doesn't work"?
I think what Tom means is that (for example)
print "${\(localtime())}\n";
does not p
> On Tue, 29 Aug 2000, Mark-Jason Dominus wrote:
>
> > OK, I think this discussion should be closed.
>
> I think the bit about "having a special array containing all captured
> matches" might well still live on. The "counting" bit _per se_ is probably
&
> Accepting variables in tr// makes no sense. It defeats the purpose of
> tr/// - extremely fast, known transliterations.
The propsal extends tr/// to handle extremely fast transliterations
whose nature is not known at compile time.
>
> tr///e is the same as s///g:
>
> tr/$foo/$bar/e ==
> Note that the 256-byte thing is out the window with Unicode, but that
> I no longer know how it is done.
Thanks. I was going to mention that, but I forgot before I sent the
message. The 256-byte thing is still in place with unicode, but it's
only used on byte strings, not on UTF8 strings. S
should investigate several
solutions in parallel, and should compare them with one another and
contrast the benefits and drawbacks of each one.
Mark-Jason Dominus [EMAIL PROTECTED]
I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.ht
> Mark-Jason Dominus wrote:
> >
> > m/.../Count (instead of m/.../t)
> > m/.../iCount (instead of m/.../it)
> > m/.../Count,i (instead of m/.../ti)
> > m/.../Count,Insensitive (instead of
> Any requirements on how solid an implementation section should be
> should be left to the working group chairs.
Sorry, I don't understand this. What is the WGC's role here?
> On Wed, Aug 30, 2000 at 02:29:33PM -0400, Mark-Jason Dominus wrote:
> >
> > > Any requirements on how solid an implementation section should be
> > > should be left to the working group chairs.
> >
> > Sorry, I don't understand this. What is
> I am unemcumbered by any knowledge of the regex engine implementation,
Yeah.
But I do know something about it, and I have already expressed my
informed opinion. Having you come along to say that you don't know
anything about it at all, but that you nevertheless think I am
mistaken, is bizar
> 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
> 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
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 really think you need to discuss in more detail why
this feature would be usef
> > The way tr/// works is that a 256-byte table is constructed at compile
> > time that say for each input character what output character is
>
> Speaking of which, what's going to happen when there are more than 256
> values to map?
It's already happened, but I forget the details.
> Ok, I can understand that. But, what happens when we get to UTF16? Aren't
> we talking about 256k per tr///, then? That seems like a lot of memory
> that is potentially wasted and could lead to some really large footprints.
I don't understand what this discussion has to do with this mailing
> (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
There was no discussion of this.
RFC 170: Generalize =~ to a special-purpose assignment operator
(Nathan Wiger)
This is probably the most interesting and far-reaching RFC proposed
this week, but there was essentially no discussion.
Mark-Jason Dominus [EMAIL PROTECTED]
I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
> On Thu, Aug 31, 2000 at 12:34:05PM -0400, Mark-Jason Dominus wrote:
> >
> > perl6-language-regex
> >
> > Summary report 2831
> >
> > RFC 72: The regexp engine should go backward as well as
> > forward. (Peter Heslin)
> >
>
> >>>>> "Mark-Jason" == Mark-Jason Dominus <[EMAIL PROTECTED]> writes:
>
> Mark-Jason> I have some ideas about how to do this, and I will try to
> Mark-Jason> write up an RFC this week.
>
> "You want Icon, you know where to find i
> I think what is needed is something along the line of :
Joe McMahon and I are working on something along these lines.
> > 2. Many people - including Larry - have voiced their desire
> > to see =~ die a horrible death
>
> Please provide a look-up-able reference to Larry's saying that he
> wanted to =~ to die horrible death.
Larry said:
# Well, the fact is, I've been thinking about possible ways to get
> >...My point is that I think we're approaching this
> >the wrong way. We're trying to apply more and more parser power into what
> >classically has been the lexer / tokenizer, namely our beloved
> >regular-expression engine.
I've been thinking the same thing. It seems to me that the attempts
perl6-language-regex
Summary report 2911
RFC 72: The regexp engine should go backward as well as
forward. (Peter Heslin)
The author sent revised version of the RFC. There seem to be two ideas
here:
1. The lookbehind assertions should work for variable-length
patterns. (At pre
I have some trouble understanding just what the proposal is, since the
RFC doesn't contain any examples. But I gather that you want to usurp
*both* the (...) and the [...] notation for numeric ranges.
This would change the meaning of any code that happened to contain a
regex like this:
> Simply put, I want variable-length lookbehind.
Why didn't you simply propose that the (?<...) operator be fixed to
support variable-length expressions? Why so much additional machinery?
> As to your contention that "at best" (?r) will defeat many present
> optimizations, can you tell me why this will necessarily be so in the
> new engine?
Let me explain my thinking along these lines. I've made a number of
assumptions, which may not be correct, and certainly aren't obvious.
I
> I propose adding the first para as a note and moving RFC to frozen soon.
You did not address my points about tr///o and related issues.
I suggest that you submit a revised RFC and then freeze it a week
afterwards if there is still no discussion.
> (?@foo) is sort of equivalent to (??{join('|',@foo)}), ie it expands into a
> list of alternatives. One could possible use just @foo, for this.
It just occurs to me that this is already possible. I've written a
module, 'atq', such that if you write
use atq;
then your regexes may co
> > 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.
>
> I think you should remove the parts of your propsal about making $& be
> autolocalized.
If you're not planning to revise your RFC, let me know so that I can
> I propose adding this note. His preference for the working of
> /t and /g seems the most appropriate. Unless I here any further
> discussion I propose moving this RFC to frozen this week.
Please post a complete, revised version of the RFC *before* you freeze it.
> > (The \ is necessary here because (?@foo) already has a meaning under
> > Perl 5, and I think your proposal must address this.)
>
> (?@foo) has no meaning I checked the code
I don't know what you mean, but you're mistaken, because it means to
interpolate @foo as in a double-quoted string.
> Bad reasons
> I do not have time.
> I do not have the tuits.
I think it would be a step in the right direction if the WG chairs
actually required RFC authors to maintain their RFCs.
> I think it would be a step in the right direction if the WG chairs
> actually required RFC authors to maintain their RFCs.
I also think it would be a step in the right direction if the WG
chairs wrote up summaries like they said they would. They obviously
don't.
Frankly, I don't really see w
> On Tue, 12 Sep 2000 19:01:35 -0400, Mark-Jason Dominus wrote:
>
> >I don't know what you mean, but you're mistaken, because it means to
> >interpolate @foo as in a double-quoted string.
>
> Which is precisely the meaning he wants for it, with $" set t
> :Anyway, Snobol has a nice heuristic to prevent infinite recursion in
> :cases like this, but I'm not sure it's applicable to the way the Perl
> :regex engine works. I will think about it.
>
> It is probably worth adding the heuristic above: anytime you recurse
> into the same re at the same
> : it looks worse and dumps core.
>
> That's because the first non-paren forces it to recurse into the
> second branch until you hit REG_INFTY or overflow the stack. Swap
> second and third branches and you have a better chance:
I think something else goes wrong there too.
> $re = qr{...
> In theory, all letters should be reserved to map to future flags for
> the same reason.
My recollection is that Larry specifically mandated this, and that's
why (?p...) was changed to (??...) in 5.6.0.
> This reminds me of a related but rather opposite desire I have had
> more than once: a quotish context that would be otherwise like q() but
> with some minimal extra typing I could mark a scalar or an array to be
> expanded as in qq().
I have wanted that also, although I don't remember why ju
> =head1 TITLE
>
> crypt() default salt
>
> =head1 VERSION
>
> Maintainer: Mark Dominus <[EMAIL PROTECTED]>
> Date: 11 Sep 2000
> Last Modified: 13 Sep 2000
> Mailing List: [EMAIL PROTECTED]
> Number: 208
> Version: 2
> Status: Developing
If there are no objections, I will freez
> You talked about Good Typing at YAPC, but I missed it. There's a
> discussion of typing on perl6-language. Do you have notes or a
> redux of your talk available to inform this debate?
http://www.plover.com/~mjd/perl/yak/typing/TABLE_OF_CONTENTS.html
http://www.plover.com/~mjd/perl/yak/typing
> (?Q$foo) Quotes the contents of the scalar $foo - equivalent to
> (??{ quotemeta $foo }).
How is this different from
\Q$foo\E
?
> eval should stay eval.
Yes, and this is the way to do that.
When you translate a script, the translator should translate things so
that they have the same meanings as they did before. If it doesn't
also translate eval, then your Perl 5 scripts will be using the Perl 6
eval, which isn't wha
> On Mon, Sep 25, 2000 at 08:56:47PM +0000, Mark-Jason Dominus wrote:
> > I think the proposal that Joe McMahon and I are finishing up now will
> > make these obsolete anyway.
>
> Good! The less I have to maintain the better...
Sorry, I meant that it would make (??...)
I think the proposal that Joe McMahon and I are finishing up now will
make these obsolete anyway.
87 matches
Mail list logo
