Thanks for elaborating what you meant.
But what you said is
> > > > The thing about Perl is that it lets you execute Perl code during the parse.
- a source filter is just preprocessing like in C. (just built-in and using Perl as meta language)
- function declarations without prototypes effect if parens are necessary when parsing or an error is thrown. No idea if this exist in other languages. IIRC you don't need any parens in Ruby
- prototypes in declarations also effect parsing of arguments and parsing errors. That's why they are discouraged if not explicitly meant for syntax extension.
BUT as you already said these are declarations, they don't "let you execute Perl code during the parse" .
You also said contrary to Lisp, which doesn't make much sense since Lisp (or even TCL) let me execute macros at parse time.°
Though I have to admid I'm aware about a bug in the regex syntax which allows the execution of code at parse time by injecting a BEGIN block.
But I still need to be convinced that Perl executes more code during parsetime than other languages.
For instance JS doesn't allow any of the mentioned mechanisms for syntax extensions, with the effect that there are plenty of project with meta languages generating JS.
update
°) and reader macros make static parsing impossible (for the sake of creating a DSL) | [reply] |
Ah, there you go, I didn't know about reader macros in Lisp. And C++ template expansions are Turing-complete (I believe), so that's another exception. C preprocessor macros let you do some of that stuff, but they're very restricted (you can't nest an #if inside a #define, for example).
The reason I bring up prototypes is that Perl code can decide whether or not to install them, like this:
use warnings;
BEGIN {
*foo = rand() < .5
? sub { print "@_\n" }
: sub ($) { print "@_\n" }
}
foo 27, 42; # Parsed as "foo(27,42);" or "foo(27),42;"
In any case, I was just making an observation, not arguing about which language is "better" or "more efficient" or "more flexible." | [reply]
[d/l] |
| [reply] |
