Re: pragmas [Was: Re: another take on hackers and painters]

[Dan Sugalski <address@hidden>]

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 
completely inappropriate.

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)
-- 
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk