[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pragmas [Was: Re: another take on hackers and painters]
At 5:04 PM -0400 5/23/03, Scott McKay wrote:
>At 1:10 PM -0700 5/23/03, Michael Vanier wrote:
>>Good to know ;-)
>>I think much of the prejudice against perl has to do with people (like me)
>>who only used it way back when there weren't a lot of the current options.
>>Perl seems to win the prize as the language with the most pragmas, by which
>>I mean language-altering special statements (maybe there is a better word
>>for this). You got yer "use strict", "use warnings", etc. etc.
>>How do people feel about this feature in general? I personally
>>like the idea of pragmas if there is no other way to get the same
>>flexibility, although I would probably have set the defaults differently
>>than perl's are set ;-)
>I don't like directives that alter the semantics of
>the thing being compiled. It's hidden global state
>that makes it harder to understand the program. You
>can't just look at part of the program to ascertain
>that something somewhere else changed the rules.
That's generally not a problem, as has been pointed out already, as
the language-altering pragmas are lexically scoped, and if the
lexical scope is so large that you've long-since lost track of what
you've declared as different, well, you have other problems. :)
With that aside, though, disallowing changes to syntax and semantics
means you can't play with the language, at least not in the language.
(A point that doesn't apply to self-hosting languages, at least
mostly) While this does prevent people from abusing the language in a
way that makes maintenance difficult, it also prevents people from
experimenting with changes to the language.
Case in point--perl. Perl 5 has no switch statement. It was left out
on purpose, not because Larry didn't like it, but because he wasn't
sure how to best do it. (C's switch, while it works OK, has some
issues and a lot of limitations) He never did sort that one out, but,
because of the mutability of the syntax, someone else did. Was the
changed version perfect? No, of course not, but it was darned good,
and after some thumping a modified version got rolled into the design
of perl 6. People, however, can still go grab this module and have a
very nice switch statement now.
Another case in point--perl 6 has a different set of variable sigil
rules than perl 5. (And no, we're not going to argue that one,
thanks) But because of a number of modules, you can warp perl 5's
parsing to use the new sigil rules in perl 5. Would you do this in
production? I hope not. But you can still experiment with it.
Forbidding syntactic or semantic shifts in code (which you can't ever
truly forbid, as long as someone can preprocess the source, and
that's something you can't stop) is, in effect, saying "I do not
trust you to alter the base syntax and semantics. Ever." Forbidding
changes is, in *some* circumstances, appropriate, and I'd not argue
against that one. Forbidding them in *all* circumstances, though, is
I should also note that in the years that this has been possible in
perl, very few people have actually done it, and never (to my
knowledge) in a way that was problematic. (Putting aside things like
the 'perl in latin' type modules, which are demonstrative toys, and
nobody uses them in any sort of production code)
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
email@example.com have teddy bears and even
teddy bears get drunk