Note! Some of the following is hypothetical, not strictly based on Apocalypses
and such.  Now that your brain is in the right mode:

Uri wrote:
> >>>>> "DAP" == Deborah Ariel Pickett <[EMAIL PROTECTED]> writes:
>   DAP> C<rule> allows us to define both named and anonymous rules, depending on
>   DAP> context.  C<rx> allows us to define only anonymous rules.  C<rule> is
>   DAP> the more general one, and you can use it exclusively if that's what you
>   DAP> feel like.
>   DAP> The only extra piece of syntactic sugar that C<rx> is giving us over
>   DAP> C<rule>[*] is the ability to have arbitrary delimiters.  If I were
>   DAP> satisfied with always using C<{}> as delimiters for C<rx> then a
>   DAP> program would run the same if I did a C<s:each/rx/rule/> on it.
> not in one case. if you had named rules then you couldn't do that
> substition as rx// has no syntax for a name. i assume you could use the
> := op to alias an rx to a name and that should be the same as a named
> rule.
 
That's not what I was talking about.  I'm saying:
  "Anywhere my code says C<rx> I can write C<rule> instead, change the
  delimiters to braces, and the code runs the same."

I'm not talking about using C<rx> instead of C<rule>; I'm talking about
using C<rule> instead of C<rx>.  Thus named rules, which you're talking
about above, aren't involved.
 
>   DAP> Now . . .
>   DAP> Is there some _syntactic_ constraint (i.e., required by the parser)
>   DAP> that requires C<rule> to use braces for delimiters?  That is, shouldn't
>   DAP> the following:
>   DAP>   $config_line = rule ($ident) { <$ident> = \N* }
>   DAP> always be parseable for any given value of C<{> and C<}> (barring
>   DAP> obvious exceptions like colons and parentheses)?
> no, rules are like subs there and only {} are allowed. 

Funny you should mention that.  This brings up something that I was
afraid to mention before, lest it be regarded as too weird.  There isn't
any strong syntactic reason for subs to be delimited with just braces either.[*]
Sure, there's a historical Perl precedent, and I'd probably be forced to
put the C<sub> keyword in there, but imagine a Perl that could handle
this:

  sub foo «
    mumble
  »

I'm imagining a table something like this:

                 Subroutine                 Pattern matching
--------------------------------------------------------------------

Default          { code }                   / pattern /
delimiter 

Declare named    sub foo <delim>            rule foo <delim>
                    code                      pattern
                 <delim>                    <delim>

Declare named    sub foo (args) <delim>     rule foo (args) <delim>
with args           code                      pattern
                 <delim>                    <delim>

Create           $ref = sub <delim>         $ref = rule <delim>
anonymous          code                       pattern
                 <delim>                    <delim>

Create           $ref = sub (args) <delim>  $ref = rule (args) <delim>
anonymous with     code                       pattern          
args             <delim>                    <delim>            


(By "default delimiter" I mean the delimiter that allows you to create
an anonymous thingy without using "sub" or "rule".)

Now, Perl6 doesn't currently do everything exactly as above, but it
could; there's no syntactic reason why it can't.  The only hurdles are
psychological ones in Perl programmers' heads.  The subroutine/pattern
duality could go so much further than it currently does.

>   DAP> Or, to put it more succinctly: do there exist two pieces of
>   DAP> *syntactically correct* code like
>   DAP>   ... rule ... 
>   DAP> and
>   DAP>   ... rx ...
>   DAP> (where the ... are identical in both) which each produce *valid* and
>   DAP> *different* semantics?
> not that i can see. they are just syntactic variants with some slight
> differences (naming vs delimiters).

Without syntactic restrictions, it should be possible to have one
keyword do both.  (If you then choose to write it two different ways,
that's up to you.) That's what I'm talking about.

>   DAP> To me, that'd be the only reason for C<rx> and C<rule> to be
>   DAP> different keywords. [**] Especially since we're making such a big
>   DAP> deal about patterns and subroutines having lots of parallels.
>   DAP> The same parallel doesn't exist for subroutines[***]; why should
>   DAP> it for pattern matching?
> 
> rx// is closer to how qr// works and looks in perl 5. so if you just
> want to create a anon regex, then this would look familiar
>       $re = rx/ blah / ;      # whitespace always allowed now
> rule could be used there but it is longer and not similar to perl5
>       $re = rule { blah } ;

I agree.  C<rx//> is a more Perl5y way of doing things.  Whether that
makes it better in a Perl6 world, that's arguable. :)
 
>   DAP> [**] As opposed to C<rx> and C<rule> being two different spellings of
>   DAP> the same keyword, something I don't object to.
> they aren't different spellings. they have different syntax but the same
> semantics.

This footnote was taken out of context, so your response isn't really
relevant to what I was saying (sorry).

[*] All right, some delimiters won't ever work, like C<$> or C<;>, but the
paired ones all will.

-- 
Debbie Pickett http://www.csse.monash.edu.au/~debbiep [EMAIL PROTECTED]
"Education at it's best" - sign outside a school (Great misspellings of the 20th
                                   Century).

Reply via email to