Front page | perl.perl5.porters |
Postings from August 2010
Quoth public@khwilliamson.com (karl williamson):
> Ben Morrow wrote:
>
[This paragraph only quoted to show why I've switched from (?.:) to (?^:)
in examples]
> More than one person has expressed a preference for ^ over dot, so I'm
> thinking that will be what it ends up being.
Presumably we should also add (?^xs), no colon, analogous to (?xs).
> > I've mentioned in passing before, and I think I should say again, that
> > having a /d switch at all is rather confusing. IMHO it would be much
> > better (if we're going to restrict ourselves to one-letter switches with
> > no arguments) to just have /u and /l, with the old behaviour implied by
> > neither of those being present. The new (?.:) syntax would mean that the
> > one place where /d might potentially be used, (?d-xims:foo), is better
> > written (?.:foo).
>
> I mostly agree, except if that is the one flag that is being switched,
> you don't want to have to specify all of them.
I dont understand what you mean here. You can change from /u to
compatible matching within a group without affecting other flags with
(?-u:...).
> I don't understand why
> the /d is confusing. These operate like radio buttons; my 12 year old
> car still has them. don't know about newer cars. The radio is always
> tuned to a station. You press the button of the station you want.
One reason it's confusing is because under normal circumstances /foo/d
is exactly the same as /foo/. Another is because all the other switches
are booleans, with (?x) to turn them on and (?-x) to turn them off. None
of /lud would be valid in (?-d) under your scheme, and the docs would
have to attempt to explain why.
If we're going to insist on squashing a 3-way choice into a set of
boolean flags, it seems easier to me to model it as '2 flags which can't
be on at the same time' than as '3 flags which can't be on at the same
time, and one of which is on by default'.
> > If you're going to introduce pragmata to turn some switches on for some
> > lexical scopes, the question of 'so how do they get turned off again?'
> > needs to be addressed in a more systematic way than just introducing a
> > single special-case switch that turns some other switches off. I would
> > be happy with either of
> >
> > use unicode_strings;
> > /foo/U;
> >
> > or
> >
> > use unicode_strings;
> > /foo/-u;
> >
> > though the latter obviously has more back-compat considerations. I would
> > also be happy, for now, with requiring people write
> >
> > use unicode_strings;
> > /(?-u)foo/;
> >
> > if they want to go back to the old semantics.
>
> I would find this confusing. Either of your examples says what the
> person doesn't want. It doesn't say which of the other (currently two)
> choices they do want.
They want the default, obviously. The behaviour they would have got
before they asked for /u to be added implicitly.
> You can't unpress a radio button to go to another
> station; you must press the button you want. As more possible things
> like /a got added, it would get worse.
No it wouldn't. Turning off a switch that is currently on goes back to
the default; turning off a switch that is currently off does nothing.
The weird case is turning on a switch that is currently off but is
mutually-exclusive with one that is currently on: that will (probably)
implicitly turn something off.
> > While we're discussing this: would you be at all open to the idea of
> > supplying a /a ('ASCII') switch that makes \d\s\w match what everyone
> > thinks they do (that is, [0-9], [ \t\n] and [a-zA-Z0-9_] respectively)?
>
> I think that if we're going to discuss this now, it should go on another
> thread. It has been discussed before, and is a possibility, but I think
> it's part of a larger problem, and I think would be better served by a
> more general 'use script pragma' that allows ASCII as a special
> sub-script of Latin.
Hmm. OK. I see this as more 'giving me back a feature 5.8 stupidly
removed' than as a new feature, and thus a little more urgent than
support for random script-specfic matching, but never mind.
Ben
Thread Previous
|
Thread Next