Re: RFC 165 (v1) Allow Varibles in tr///

On Wed, 30 Aug 2000 00:31:24 -0400, Stephen P. Potter wrote: >For every tr/// in a program, >256 bytes have to be allocated? Even if I only do something like tr/a/A/? >Is this really the optimal solution for this Speedwise, it is. You don't have to do any tests on the bytes. All you have to do

Re: RFC 165: Allow variables in a tr///

"Stephen P. Potter" <[EMAIL PROTECTED]> writes: > Lightning flashed, thunder crashed and Tom Christiansen <[EMAIL PROTECTED] > m> whispered: > | >The // tend to confuse people and make them expect tr to operate as a > | >regular expression. > | > | So what? q/.../ is not a "regex function" eith

Re: RFC 165: Allow variables in a tr///

On Wed, 30 Aug 2000 00:08:46 -0400, Stephen P. Potter wrote: >Personally, I would say that q/.../ and friends were a bad idea. A lot of >non-gurus see /.../ (whatever comes before it) and their first impression >is that it has something to do with regex. I would suggest that anything >that isn'

Re: RFC 110 (v3) counting matches

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 fairly closed, though. Cheers, Philip -- Philip Newton

Re: RFC 170 (v1) Generalize =~ to a special-purpose assignment operator

On 30 Aug 2000 02:07:24 -, Perl6 RFC Librarian wrote: >Generalize =~ to a special-purpose assignment operator Personally, I think of it as the "apply to" operator, as opposed to the "assign to" operator: = assign the RHS to the LHS =~ apply the RHS to the LHS pe

Re: RFC 165 (v1) Allow Varibles in tr///

On Wed, 30 Aug 2000 11:05:41 +0200, Bart Lateur wrote: >Some processors, >like Intel's x86, even have a special machine instruction to do that: >XLAT. In the meantime, I found an x86 instruction set reference on the web. Here is the description for XLAT:

Re: Overlapping RFCs 135 138 164

> TC> ($foo += 3) *= 2; >that is way too many assignment ops. better is the normalized > $foo = ($foo + 3) * 2; > TC> $n = select($rout=$rin, $wout=$win, $eout=$ein, 2.5); >who uses select directly anymore? use a module! :) I see the smiley, but one must be exceedingly careful

Re: RFC 165: Allow variables in a tr///

>Personally, I would say that q/.../ and friends were a bad idea. That's one opinion. As Piers points out, it's hardly universal. Go read what I just wrote Uri. >A lot of >non-gurus So what? see /.../ (whatever comes before it) and their first impression >is that it has something to do wit

Re: RFC 165 (v1) Allow Varibles in tr///

>Lightning flashed, thunder crashed and Mark-Jason Dominus <[EMAIL PROTECTED] >pered: >| > > 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

Re: RFC 165: Allow variables in a tr///

Stephen Potter wrote: >Personally, I would say that q/.../ and friends were a bad idea. A lot of >non-gurus see /.../ (whatever comes before it) and their first impression >is that it has something to do with regex. I would suggest that anything >that isn't a regex should not use /.../. Make q,

Re: RFC 110 (v3) counting matches

> 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 > fairly closed, though. I didn't mean to

Re: RFC 165: Allow variables in a tr///

Lightning flashed, thunder crashed and Tom Christiansen <[EMAIL PROTECTED] m> whispered: | >Personally, I would say that q/.../ and friends were a bad idea. | | That's one opinion. As Piers points out, it's hardly universal. | Go read what I just wrote Uri. "Personally" generally denotes opin

Re: RFC 165 (v1) Allow Varibles in tr///

Lightning flashed, thunder crashed and Tom Christiansen <[EMAIL PROTECTED] m> whispered: | >Even if I only do something like tr/a/A/? | >And, it is going to get worse for UTF8/UTF16? | | Use the Source. If we all always used the source, we wouldn't need books and trainers. Where would you and

Re: RFC 165 (v1) Allow Varibles in tr///

On Wed, Aug 30, 2000 at 12:31:24AM -0400, Stephen P. Potter wrote: > Lightning flashed, thunder crashed and Mark-Jason Dominus <[EMAIL PROTECTED]> whis > pered: > | > > The way tr/// works is that a 256-byte table is constructed at compile > | > > time that say for each input character what output

Re: RFC 165 (v1) Allow Varibles in tr///

Lightning flashed, thunder crashed and Bart Lateur <[EMAIL PROTECTED]> whis pered: | Speedwise, it is. You don't have to do any tests on the bytes. All you | have to do is use the ord of the character (the byte value) as an offset | in a table, and replace what you had with what you find in the ta

copying and s/// (was Re: Overlapping RFCs 135 138 164)

> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: >> who uses select directly anymore? use a module! :) TC> I see the smiley, but one must be exceedingly careful not to TC> enshrine one's own personal preferences and predilections--one's TC> own small choices of style and nuance

Re: RFC 165 (v1) Allow Varibles in tr///

> 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

Re: copying and s/// (was Re: Overlapping RFCs 135 138 164)

Uri Guttman wrote: > > TC> ($this = $that) =~ s/foo/bar/; > TC> for (@these = @those) { s/foo/bar/ } > > TC> You can't really do those in one step without it. RFC 164 v2 has a new syntax that lets you do the above or, if you want: $this = s/foo/bar/, $that; @these = s/foo/b

Re: Overlapping RFCs 135 138 164

Tom Christiansen wrote: > > >($foo = $bar) =~ s/x/y/; will never make much sense to me. > > What about these, which are much the same thing in that they all > use the lvaluability of assignment: > > chomp($line = ); > ($foo = $bar) += 10; > ($foo += 3) *= 2; > func($diddle_me =

Re: copying and s/// (was Re: Overlapping RFCs 135 138 164)

Nathan Wiger wrote: [...] > RFC 164 v2 has a new syntax that lets you do the above or, if you want: > >$this = s/foo/bar/, $that; >@these = s/foo/bar/, @those; > > Consistent with split, join, splice, etc, etc. I often use the comma operator like this s/foo/bar/, $n++ if $x; If "s"

Re: RFC 165 (v1) Allow Varibles in tr///

Lightning flashed, thunder crashed and Mark-Jason Dominus <[EMAIL PROTECTED]> whis pered: | I don't understand what this discussion has to do with this mailing | list, and I don't understand what your point is. tr/// has already This discussion doesn't have anything to do with this list. They w

Re: copying and s/// (was Re: Overlapping RFCs 135 138 164)

On Wed, 30 Aug 2000, Nathan Wiger wrote: > RFC 164 v2 has a new syntax that lets you do the above or, if you want: > >$this = s/foo/bar/, $that; >@these = s/foo/bar/, @those; > > See RFC 164 v2, all this is supported, as well as this: > >@str =~ s/foo/bar/; > > Which has been a pi

Re: copying and s/// (was Re: Overlapping RFCs 135 138 164)

Mike Lambert wrote: > > or even: > @a = s/a+/a/, @a; This is actually the native syntax from RFC 164. > Basically, the argument is that you could theoretically do @a =~ s/a+/a/ > with QS, along with many other things. So perhaps, imo, it would be best > to just let QS handle it. I'm fine with t

Re: RFC 165 (v1) Allow Varibles in tr///

On Wed, 30 Aug 2000 10:44:55 -0400, Stephen P. Potter wrote: >| Memory usage is irrelevant compared with speed. > >That's interesting. I could swear I've seen people make a tradeoff before, >rather than always just implementing the fastest solution. Nothing is >irrelevant (except resistance, if

Re: RFC 72 (v2) The regexp engine should go backward as well as forward.

I've been lurking a few days now, and RFC 72 piqued my interest. I see the motivation for a backwards-moving regexp engine, but am uncomfortable with the details. First worry is the syntax proposed. I cringe when I see the regexp being expressed such that "(?r)EDCB" matches "BCDE". That and th

Re: RFC 165: Allow variables in a tr///

>| >A lot of >| >non-gurus >| >| So what? >There are far more non-gurus using perl than there are gurus. If all we >cared about was the gurus, we wouldn't need Perl. Wrong. And irrelevant. >| Pick your own quotes is a perl thing. Let them learn this concept. >| If they can't, you made a

Re: RFC 165 (v1) Allow Varibles in tr///

>Lightning flashed, thunder crashed and Tom Christiansen >m> whispered: >| >Even if I only do something like tr/a/A/? >| >And, it is going to get worse for UTF8/UTF16? >| >| Use the Source. >If we all always used the source, we wouldn't need books and trainers. >Where would you and I be then?

Re: copying and s/// (was Re: Overlapping RFCs 135 138 164)

I keep noticing the connection between $foo =~ /whatever/; $foo->whatever; for ($foo) { whatever } They're all topicalizers. --tom

Re: copying and s/// (was Re: Overlapping RFCs 135 138 164)

>RFC 164 v2 has a new syntax that lets you do the above or, if you want: > $this = s/foo/bar/, $that; > @these = s/foo/bar/, @those; >Consistent with split, join, splice, etc, etc. That looks tremendously *IN*consistent, since now you must alter the laws of precedence! :-( % perl -MO=D

Re: copying and s/// (was Re: Overlapping RFCs 135 138 164)

> TC> ($this = $that) =~ s/foo/bar/; > TC> for (@these = @those) { s/foo/bar/ } > TC> You can't really do those in one step without it. >but do they really need to be combined into one step? i sometimes prefer >the separate assignment statement for clarity. other times i feel i am >

Re: Overlapping RFCs 135 138 164

>I was referring to the visual similarity of = and =~, when in fact they >have nothing to do with one another. The expression I picked is just a >frequently encountered idiom that puts the two in close proximity. Your >proposed ~ thing would make it much rarer, but I still think =~ looks >like som

Re: copying and s/// (was Re: Overlapping RFCs 135 138 164)

Uri Guttman wrote: > but we need a better syntax for s/// that doesn't modify its string but > returns a copy which has had the substitution applied to it. possibly a > s/// modifier? > > $new = $old =~ s/foo/bar/n ; > > n for new? if our internal string representation could grow from

Re: RFC 165 (v1) Allow Varibles in tr///

>For the record, the UTF8 version of tr/// does not use a plain 256K >table. It uses a data strcuture called a 'swash'; this is also the >data structure that is used by the UTF8 versions of 'uc' etc., the >\p{...} regex escapes, and the others. The swash is based on a hash, >and the code is in u

Re: copying and s/// (was Re: Overlapping RFCs 135 138 164)

>Uri Guttman wrote: >> >> TC> ($this = $that) =~ s/foo/bar/; >> TC> for (@these = @those) { s/foo/bar/ } >> >> TC> You can't really do those in one step without it. >RFC 164 v2 has a new syntax that lets you do the above or, if you want: > $this = s/foo/bar/, $that; > @these

Re: RFC 72 (v1) The regexp engine should go backward as well as forward.

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