<[]> ugly and hard to type

[Juerd]

Am I the only one who thinks <[a-z]> is ugly and hard to type because of
the nested brackets? The same goes for <{...}>. The latter can't easily
be fixed, I think, but the former perhaps can. If there are more who
think it needs to, that is. And <{}> is a bit easier to type because all
four are shifted (US QWERTY and US Dvorak), while with <[]> I really
have to think hard about when to press and when to release the shift
key.

\letter[] could well replace <[]>, and \LETTER[] would then replace
<-[]>. This is consistent with many other \letters.

"c" for character is taken
"r" for range is taken by carriage return
"a" for any is taken by alarm (bell)
"l" for list is taken by lcfirst

"m" is available, but I can't think of a mnemonic :)

\m[a..z] \M[a..z]

And to replace <[a..z]-[aoeui]> (does that construct even exist?),
[ \m[a..z] & \M[aoeui] ]. IMO, that's the only step backwards.

"a" would best communicate its function. Is the beep thing used enough?
(\cG still does that thing if \a is gone.)

Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html

[Patrick R. Michaud]

On Fri, Apr 15, 2005 at 02:58:44PM +0200, Juerd wrote:
> Am I the only one who thinks <[a-z]> is ugly and hard to type because of
> the nested brackets? The same goes for <{...}>. The latter can't easily
> be fixed, I think, but the former perhaps can.

Part of the thinking behind this is that the <[...]> construct
is likely to be less common in p6 rules than [...] was in p5 regular
expressions. For unicode reasons, one typically should be writing
<alpha> instead of <[a-z]> anyway.

But yes, I understand the difficulty of typing <[...]> on non-US
keyboards. :-)

> \letter[] could well replace <[]>, and \LETTER[] would then replace
> <-[]>. This is consistent with many other \letters.
>
> "c" for character is taken
> "r" for range is taken by carriage return
> "a" for any is taken by alarm (bell)
> "l" for list is taken by lcfirst

Actually, \L[...] is gone -- see S05 and A05. I'm not sure if \a
exists, I haven't seen any reference to it in p6 rules. (One could
claim that it's carried over from p5, but rules are so far different
from regexes that I'm hesitant to make that assumption.) We could
certainly declare \a to be something else.

This isn't a vote from me either in favor or against this idea...
I'm just clarifying and making sure the discussion is up-to-date
with the relevant specs.

Pm

[Ashley Winters]

On 4/15/05, Juerd <ju...@convolution.nl> wrote:
> Am I the only one who thinks <[a-z]> is ugly and hard to type because of
> the nested brackets? The same goes for <{...}>. The latter can't easily
> be fixed, I think, but the former perhaps can. If there are more who
> think it needs to, that is. And <{}> is a bit easier to type because all
> four are shifted (US QWERTY and US Dvorak), while with <[]> I really
> have to think hard about when to press and when to release the shift
> key.

I never liked character sets. They introduced yet another exception to
the parsing rules, and it irked me. If it weren't for the need to
optimize character sets, I'd prefer to be Pythonized into using @{'a'
.. 'z'}

If I read the Apocalypses correctly, I'm allowed to use this bizzare construct:

$foo ~~ /@{< [ ] { } < > : ++ $ . ? / +| +& ?| ?& >}/

to match some of my favorite punctuations, right? It allows
multi-character alternatives as well as the single-character ones, so
it seems preferable to me (assuming it could be optimized happily).

Ashley Winters

[Gcomnz]

> I never liked character sets. They introduced yet another exception to
> the parsing rules, and it irked me. If it weren't for the need to
> optimize character sets, I'd prefer to be Pythonized into using @{'a'
> .. 'z'}

Isn't that just a digression into the bad old pre-internationalized
days. Unicode-schmunicode, but I'm all about the internationalization,
even if I am just an English speaker, and Unicode makes it happen, so
I love it. And it's WAY too easy for me as an English speaker to
ignore or badly program so that Internationalization is more work than
it needs to be, so any effort to push me into character classes is
Good and I appreciate the discipline.

[Larry Wall]

On Sat, Apr 16, 2005 at 02:42:25AM -0700, Ashley Winters wrote:
: I never liked character sets. They introduced yet another exception to

: the parsing rules, and it irked me. If it weren't for the need to
: optimize character sets, I'd prefer to be Pythonized into using @{'a'
: .. 'z'}
:
: If I read the Apocalypses correctly, I'm allowed to use this bizzare construct:
:
: $foo ~~ /@{< [ ] { } < > : ++ $ . ? / +| +& ?| ?& >}/
:
: to match some of my favorite punctuations, right?

Not unless you backwhack that internal > there.

: It allows

: multi-character alternatives as well as the single-character ones, so
: it seems preferable to me (assuming it could be optimized happily).

I will happily assume that all sorts of things could be optimized away
if only someone will generate an endless supply of convex tuits.

Assuming someone doesn't invent such a tuit factory, and that the @ matcher
is smart about caching unchanged arrays, you might actually get much better
performance out of:

@myfavoritepunctuations = < [ ] { } < \> : ++ $ . ? / +| +& ?| ?& >;
$foo ~~ /@myfavoritepunctuations/;

It's arguably a lot more readable too.

Larry

[Juerd]

Larry Wall skribis 2005-04-16 11:08 (-0700):

> : $foo ~~ /@{< [ ] { } < > : ++ $ . ? / +| +& ?| ?& >}/

> Not unless you backwhack that internal > there.

> [...]

> @myfavoritepunctuations = < [ ] { } < \> : ++ $ . ? / +| +& ?| ?& >;

Why isn't nesting allowed there? I'd expect it to work a bit like q<
foo < > bar > in Perl 5, which equals "
foo < > bar ".

[Larry Wall]

On Sat, Apr 16, 2005 at 10:01:44PM +0200, Juerd wrote:
: Larry Wall skribis 2005-04-16 11:08 (-0700):

: > : $foo ~~ /@{< [ ] { } < > : ++ $ . ? / +| +& ?| ?& >}/
: > Not unless you backwhack that internal > there.
: > [...]
: > @myfavoritepunctuations = < [ ] { } < \> : ++ $ . ? / +| +& ?| ?& >;
:
: Why isn't nesting allowed there? I'd expect it to work a bit like q<
: foo < > bar > in Perl 5, which equals "
: foo < > bar ".

Forgot about that. I guess we should talk about it. It's pretty obvious
what the benefits of doing it that way are. I only wonder if, in the
age of Unicode, it's going to get a little less clear what are actually
brackets and what aren't, unless you actually look up the properties.
But then, that constraint applies to openers and closers in general, so
maybe it's not an issue with respect to embedded openers and closers.

Okay, let's keep the P5 semantics, unless someone can think up a better
reason not to than I have.

Larry