"Matthew" == Matthew Walton <[EMAIL PROTECTED]> writes:
Matthew> Perl 6 has formal parameters for subs, methods etc. I don't see any Matthew> mention of Perl 5-style prototypes in S6, and I honestly can't see how Matthew> they could possibly fit with formal parameters. Hopefully Larry or Matthew> someone can clarify whether they still exist or not.
As long as you can have a user-defined null-prototyped subroutine (one that doesn't need parens following), you have the problem. See the sin/time examples in the monk article, and then consider user-defined functions that have no args (like time) and those that do (like sin).
Matthew> The Perlmonks article throws up a lot of very nasty cases. Not knowing Matthew> the entire current language definition by heart, I can't say this with Matthew> absolutely certainty, but I retain the belief that Perl 6 is at least Matthew> *easier* to deal with than Perl 5.
I believe you have a false belief. I don't know anything in the new prototypes-which-became-full-formal-arguments that made it any *easier* to recognize the ending of a subroutine argument list without knowing its precise definition.
In Perl6:
sub no_args () { ... } sub list_args ([EMAIL PROTECTED]) { ... }
no_args / # this is a divide list_args / # this is the start of a regex
See, it's still there. :)
I believe I did mention that being able to call functions without parens is a problem.
Matthew> It is also possible that telling the difference between /-as-divide Matthew> and /-as-regex becomes much easier if lookahead is employed in the Matthew> tokeniser.
No, not possible at all. The entire rest of the program may be valid either way. You *must* know by the time you're done with /, or /-and-more. The rest of the code cannot be a hint. Again, see my article.
I read the article. I believe I mentioned that as well.
But I will have to concede that it is impossible to correctly determine the structure of an arbitrary Perl 6 program without having to hand the definitions of all functions used and also any grammars and macros used. Sometimes you will be able to do it, sometimes you won't, but you can't operate on the assumption that you can.
It's quite a disappointment in some ways, but we've lived with it in Perl 5, and I'm sure we can live with it in Perl 6.
And I still think Perl 6 will have fewer cases in which it's completely impossible for not-Perl to parse it. Unfortunately, fewer still implies some, and some is still a problem.
