Re: Regex query
[EMAIL PROTECTED] (Jonathan Scott Duff) writes: > Why can't perl be smart enough to figure out what we mean? We're talking about lists, the second most fundamental data structure in the language. If we have to resort to much magic to get these right, we're pretty much doomed from the outset. -- There seems no plan because it is all plan. -- C.S. Lewis
Re: Regex query
[EMAIL PROTECTED] (Smylers) writes: > Does that matter? This example is fairly contrived, and anybody > actually concerned about this can always use: > > $num = @massive.length; I'd be in favour of forcing people to say this if they want the length of the array. But then, it might be that what I want is Pythonish and not Perlish. -- This process can check if this value is zero, and if it is, it does something child-like. -- Forbes Burkowski, CS 454, University of Washington
Re: Regex query
Chip Salzenberg <[EMAIL PROTECTED]> writes:
> According to David Whipp:
> > (7,8,9) == 3 # true
> > (7,8) == 2 # true
> > (7) == 1 # false
> > () == 0 # true?
>
> Hell, yes, why didn't I think of that? This is exactly the same
> problem that afflicts Python's tuple syntax!
various 1-uple syntaxes:
a or [a] Ruby
a, Python
tuple([a]) Python
(a)Perl
((a)) merd
{a}Smalltalk
"http://merd.net/pixel/language-study/syntax-across-languages.html#Various Data Types"
<( .... )> vs <{ .... }>
In several forms of courier, and some other text fonts
I view code in, I find it hard to visually distinguish the
pattern element:
<( ... )>
from:
<{ ... }>
What about replacing the former syntax with:
?
--
ralph
Backtracking syntax
Backtracking syntax includes:
:, ::, :::, ,
I like the way the ':' looks in patterns. But I noticed I have
several niggles about a number of other aspects of the
above syntax. All the niggles are minor, individually, but
they added up to enough that I thought I'd see what the
bikeshed might look like in another color.
First, the niggles:
1. It's nice how the ':', '::', and ':::' progression indicates
progressively wider scope. But I would be surprised if
newbies don't say to themselves, "now just how wide a
scope am I backtracking when there's three colons?".
2. Typo-trap: I can imagine it being fairly easy for some
people to miss, during debugging, both the visual and
behavioral distinction between '::' and ':::'.
3. It seemed odd how the and assertions
switch to the general <...> syntax. I felt like it would be better
if they avoided the general syntax, and preferably had some
family resemblance with the first three backtracking controls.
So, how about something like:
: # lock in current atom, ie as now
:] # lock in surrounding group, currently ::
:> # lock in surrounding rule, currently :::
:/ # lock in top level rule, currently
:// # cut
Thus, redoing a couple examples from synopsis 5:
m:w/ [ if :]
| for :]
| loop :] ?
]
rule subname {
([|_] \w*) :/ { fail if %reserved{$1} }
}
m:w/ sub ? /
--
ralph
Re: Backtracking syntax
[EMAIL PROTECTED] (Me) writes: > 1. It's nice how the ':', '::', and ':::' progression indicates > progressively wider scope. But I would be surprised if > newbies don't say to themselves, "now just how wide a > scope am I backtracking when there's three colons?". Why would newbies be writing three-colon regexes? -- even though I know what a 'one time pad' is, it still sounds like a feminine hygiene product.
Re: Backtracking syntax
> [EMAIL PROTECTED] (Me) writes: > > 1. It's nice how the ':', '::', and ':::' progression indicates > > progressively wider scope. But I would be surprised if > > newbies don't say to themselves, "now just how wide a > > scope am I backtracking when there's three colons?". > > Why would newbies be writing three-colon regexes? By "newbie" I meant it in a relative sense, ie. someone who is learning those particular features. The newbie could be an expert in Prolog and Perl 5. And I'm more concerned about when they are reading some existing patterns than when they are writing one. -- ralph
Re: Backtracking syntax
> Backtracking syntax includes: > > :, ::, :::, , > > 1. It's nice how the ':', '::', and ':::' progression indicates > progressively wider scope. But I would be surprised if > newbies don't say to themselves, "now just how wide a > scope am I backtracking when there's three colons?". What problem there is? Scopes are atom/group/rule - I don't see any possible misunderstanding there as these scopes are so natural. > 2. Typo-trap: I can imagine it being fairly easy for some > people to miss, during debugging, both the visual and > behavioral distinction between '::' and ':::'. If that really is big problem, it can be solved easily by using proper editor which supports high-lighting. ::: could be shown with different color or bold while :: uses some other syntax. > 3. It seemed odd how the and assertions > switch to the general <...> syntax. I felt like it would be better if > they avoided the general syntax, and preferably had some family > resemblance with the first three backtracking controls. > > So, how about something like: > > : # lock in current atom, ie as now > :] # lock in surrounding group, currently :: > :> # lock in surrounding rule, currently ::: > :/ # lock in top level rule, currently > :// # cut I find :,::,::: to be a lot easier to remember than :,:],:> - and also easier to type. While and don't follow same syntax, I don't really see any better solutions. Better solution should IMHO keep :,::,::: and offer better alternative only to . doesn't really belong to this serie as it's different backtracking-operation and so it can and should have different syntax. I wonder if might be usefull instead of with proper syntax-highlighting. -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: Backtracking syntax
[EMAIL PROTECTED] (Markus Laire) writes: > While and don't follow same syntax, I don't really see > any better solutions. is sufficiently "hard" that it musn't be confused with the colon series. > I wonder if might be usefull instead of with proper > syntax-highlighting. Yeah. :: should show up in bold, ::: in bold with a red background, and should blink. -- I would imagine most of the readers of this group would support abortion as long as fifty or sixty years after conception for certain individuals - Michael Stevens
Re: Backtracking syntax
On 22 Sep 2002 at 21:06, Simon Cozens wrote: > [EMAIL PROTECTED] (Markus Laire) writes: > > While and don't follow same syntax, I don't really see > > any better solutions. > > is sufficiently "hard" that it musn't be confused with the > colon series. Yes, I didn't think that enough. :,::,::: only affects current rule while goes further to possibly affect other rules also, so it must have different syntax. -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: Regex query
At 10:52 AM -0500 9/21/02, Jonathan Scott Duff wrote: >So, you expect 7.pow(2) to work? I'd expect it to be an error (this >isn't python after all). Sure, why not? I mean, we already use methods on integers all the time--what do you thin 12.5 is anyway, other than calling the 5 method on the constant 12? :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Regex query
And the one best reason I forgot to include: How do you do C< ($a + $b) * $c > if parentheses are forbidden for mathematical expressions? -- Markus Laire 'malaire' <[EMAIL PROTECTED]>
Re: Regex query
[EMAIL PROTECTED] (Markus Laire) writes: > How do you do C< ($a + $b) * $c > if parentheses are forbidden for > mathematical expressions? I thought that , was actually the list constructor, much as => is the pair constructor. (And hence a => 1, b => 2 would be a list of pairs.) Of course, if we're being rigorously regular, this would mean that the parentheses were optional, and @a = 1,2,3,4; would make sense. I quite like that. -- "How should I know if it works? That's what beta testers are for. I only coded it." (Attributed to Linus Torvalds, somewhere in a posting)
Re: Regex query
On Sat, 21 Sep 2002, Jonathan Scott Duff wrote: > > Why can't perl be smart enough to figure out what we mean? Something > along these lines: > > (7) # list context > (3+4) # numeric context (there's a numeric operator in there) > (3+4,5) # list context (comma trumps the numeric op) My understanding of context (which admittedly, may be completely incorrect) is that context is imposed from the outside. So in (3+4), 3 and 4 are in numeric contect because the '+' says so, but we can't tell what context (...) is in, because there is no context. + has higher precendence than comma, so the 3+4 becomes 7 before the comma creates a list: 7,5. A different workaround just occurred to me for perl6. Maybe instead of (7) having list context imposed by the parenthesis, imposing list context on a scalar automatically creates a 1 item list. So: @a = (7); is the same as @a = 7; And actually, that works in perl5 too. So maybe we're arguing about nothing? > (7,) is an abomination. It's one of python's misfeatures that annoys > me the most. Strangely enough, it's one of the features of perl that I really like, although you have to think of it in the context of ( 'a', 'long', 'list', 'of', 'items', 'one', 'per', 'line', # <-- notice the comma! ) Of course, _requiring_ the comma is bad, but as long as we can use [7] or rely on list context creating a single item list out of a single item, it is not required. ~ John Williams
Re: Backtracking syntax
On Sun, Sep 22, 2002 at 01:39:29PM -0500, Me wrote:
> So, how about something like:
>
> : # lock in current atom, ie as now
> :] # lock in surrounding group, currently ::
> :> # lock in surrounding rule, currently :::
> :/ # lock in top level rule, currently
> :// # cut
I kinda like it, since :: and ::: look very similar to me, too. (I
don't buy the syntax highlighting argument, partly because I often
encounter code in b&w printouts, perlmonks, or wherever.) Though I'd
probably prefer stayed . And those mismatched brackets
bother me, too. What about
:-> :
:: -> :[] or [:]
::: -> :<> or <:>
-> :// or /:/
-> : or :cut or <:cut> or just stay
Then again, I've never been convinced of the similarity between : and
::. To me, a single colon is modifying another operation, so it's like
the ? non-greedy modifier. Is that incorrect? Everything else does
something when backtracked over; the only thing : has in common with
them is that it has something to do with backtracking.
Btw, is /:/ ambiguous? I can't remember if there's any way a /pattern/
can be followed by a colon.
Staring at the third column above, I can't help wondering if [:cut],
<:cut>, and /:cut/ would all be useful. But not enough to really think
about it and figure out what they would mean, exactly -- my brain and
are still having some marital difficulties.
> Thus, redoing a couple examples from synopsis 5:
>
> m:w/ [ if :]
> | for :]
> | loop :] ?
> ]
>
> rule subname {
> ([|_] \w*) :/ { fail if %reserved{$1} }
> }
> m:w/ sub ? /
m:w/ [ if :[]
| for :[]
| loop :[] ?
]
rule subname {
([|_] \w*) :// { fail if %reserved{$1} }
}
m:w/ sub ? /
or
m:w/ [ if [:]
| for [:]
| loop [:] ?
]
rule subname {
([|_] \w*) /:/ { fail if %reserved{$1} }
}
m:w/ sub ? /
Re: Regex query
According to John Williams: > On Sat, 21 Sep 2002, Jonathan Scott Duff wrote: > > (7,) is an abomination. It's one of python's misfeatures that annoys > > me the most. > > Of course, _requiring_ the comma is bad [...] Well, I don't know about Jonathan, but requiring the comma is exactly what Python does[1], and I'm sure I don't want that misfeature in Perl. [1] for tuples in (), that is. lists use [] -- Chip Salzenberg - a.k.a. -<[EMAIL PROTECTED]> "It furthers one to have somewhere to go."
