Re: Flexible parsing (was Tying Overloading)
At 03:44 PM 4/28/2001 -0700, Larry Wall wrote: Dan Sugalski writes: : I hadn't really considered having a separate module for each type of site : policy decision. Er, neither had I. Each site only has one policy file. I just want it named after the actual site, not some generic name like Policy. I think policy files are inherently non-portable, so they should be named that way. Ah. I was thinking that site_policy.pm (or whatever extension perl 6 modules get) would be the code we provide that handles all the policy setting, with it reading off of some config file in some standardized spot. (I can easily see a site having multiple policies, FWIW) From an admin position, I'd much rather have perl use one single file in a known location regardless of where I was, but I don't really care all that much. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Flexible parsing (was Tying Overloading)
On Sat, Apr 28, 2001 at 02:44:17PM -0400, Dan Sugalski wrote: Well, I was thinking that generally the site policy would be expressed in a single file This smells strangely familiar. Alot like the .perlrc discussion that was had back many moons ago. The havoc a general syntax-altering policy file could wreck would be enourmous. To use a Perl 5 example, consider the simple setting of use strict as a general site policy. Basicaly, most of the Perl code in your /usr/bin will explode when you try to run it. Unfortunately, the perl6-language archive doesn't seem to go back far enough to cover the .perlrc discussion. Is the old archive still around? -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One But in the year 2006, the entire world shall be united. Then the God followers will live happily ever after on earth. --Alex Chiu, Immortality Guy
Re: a modest proposal Re: s/./~/g
On Sat, Apr 28, 2001 at 10:39:01AM -0700, Larry Wall wrote: Now we just need to make ... ___ ... mean something exceptional. ___ ... ___ is valid. :) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One BOFH excuse #437: crop circles in the corn shell
Re: Flexible parsing (was Tying Overloading)
At 04:30 PM 4/29/2001 +0100, Michael G Schwern wrote: On Sat, Apr 28, 2001 at 02:44:17PM -0400, Dan Sugalski wrote: Well, I was thinking that generally the site policy would be expressed in a single file This smells strangely familiar. Alot like the .perlrc discussion that was had back many moons ago. The havoc a general syntax-altering policy file could wreck would be enourmous. To use a Perl 5 example, consider the simple setting of use strict as a general site policy. Basicaly, most of the Perl code in your /usr/bin will explode when you try to run it. Right, that's why the policy stuff we're discussing is optional... :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Flexible parsing (was Tying Overloading)
On Sun, Apr 29, 2001 at 11:44:24AM -0400, Dan Sugalski wrote: At 04:30 PM 4/29/2001 +0100, Michael G Schwern wrote: To use a Perl 5 example, consider the simple setting of use strict as a general site policy. Basicaly, most of the Perl code in your /usr/bin will explode when you try to run it. Right, that's why the policy stuff we're discussing is optional... :) Ugg, we're definately rehashing the .perlrc discussion now. :( By optional I take it you mean an admin can choose to define their own site policy or not? I see this as causing more trouble than its worth. Consider the following post Perl6 laments... Oh damn, this won't work under insert naughty OS here because they ship with a messed up policy file! There's no real good solution to this one anymore than there's a good solution to people shipping with dead perls. Grrr, I can't run insert program here because the admin has an odd Perl policy setup This one could be dodged by having $HOME/.perl_policy (oops, I almost typed '.perlrc' :) files which override the site-wide policy. But the idea of programs running differently depending on which user you are makes my brain hurt. It also waters down one of the intents of a site policy which is to keep users from doing naughty/silly things. Of course, the site policy could deny being overriden by the user policy... but then that brings us right back to square one. In general, easy, customizable configurations are for applications, not languages. Go with 'use Policy::...' on each script. A site-wide policy is easily gotten by simply defining /usr/bin/perl as a shell alias: #!/bin/sh /usr/bin/realperl -MPolicy::Company $@ Or something like that. Before anyone brings up but that fork will slow things down! consider the startup search for site policy files that will have to occur when *every* perl program runs if you go that route (then again, we already do that with Config.pm and other libraries). -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Maybe they hooked you up with one of those ass-making magazines. -- brian d. foy as misheard by Michael G Schwern
Re: Flexible parsing (was Tying Overloading)
At 05:37 PM 4/29/2001 +0100, Michael G Schwern wrote: On Sun, Apr 29, 2001 at 11:44:24AM -0400, Dan Sugalski wrote: At 04:30 PM 4/29/2001 +0100, Michael G Schwern wrote: To use a Perl 5 example, consider the simple setting of use strict as a general site policy. Basicaly, most of the Perl code in your /usr/bin will explode when you try to run it. Right, that's why the policy stuff we're discussing is optional... :) Ugg, we're definately rehashing the .perlrc discussion now. :( By optional I take it you mean an admin can choose to define their own site policy or not? No. Optional in that you have to do a use SomePolicyThingWeHaventDecided; to put it in force. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Flexible parsing (was Tying Overloading)
On Sun, Apr 29, 2001 at 12:49:28PM -0400, Dan Sugalski wrote: At 05:37 PM 4/29/2001 +0100, Michael G Schwern wrote: By optional I take it you mean an admin can choose to define their own site policy or not? No. Optional in that you have to do a use SomePolicyThingWeHaventDecided; to put it in force. Ahh, ok. Carry on then. :) -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One OH GOD!! It's LINUX! All you Linux fanboys go wild! It never crashes! It'll wash your underpants! It'll eat your dog for you, if you want your dog to be eaten! It'll make you attractive and smell good and... it'll... uh... uh. Man, I'm so sick of this shit. http://www.goats.com/archive/000602.html
Re: Flexible parsing (was Tying Overloading)
On Sun, Apr 29, 2001 at 12:20:42PM -0700, Ask Bjoern Hansen wrote: don't know which archive you are talking about, but http://archive.develooper.com/perl6-language%40perl.org/ should have all mails sent to perl6-language from it's start to a few days ago when I moved stuff around. I think I need to get my eyes/head examined. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One i gave them some paste do that funky dance, white boy i laughed my ass off -- Fmh
Re: Flexible parsing (was Tying Overloading)
On Sun, 29 Apr 2001, Michael G Schwern wrote: Unfortunately, the perl6-language archive doesn't seem to go back far enough to cover the .perlrc discussion. Is the old archive still around? don't know which archive you are talking about, but http://archive.develooper.com/perl6-language%40perl.org/ should have all mails sent to perl6-language from it's start to a few days ago when I moved stuff around. http://archive.develooper.com/perl6-language%40perl.org/msg2.html - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than 100M impressions per day, http://valueclick.com
Re: Flexible parsing (was Tying Overloading)
Damian Conway wrote: You Americans and your non-ISO penchant for putting the specific before the general. Surely that should be: use Policy::O::Reilly; I knew someone would argue that, but I didn't think it would be someone as illustrious as Damian. Do you think Larry doesn't know what he's talking about? OReilly::Policy is (or might be) still general before specific. OReilly::* might be a whole family of site- specific modules. I think that's safer than supposing a universe of Policy::* policy modules. -- John Porter
Re: a modest proposal Re: s/./~/g
Larry Wall wrote: Now we just need to make ... ___ ... mean something exceptional. Ref: http:[EMAIL PROTECTED]/msg02873.html ) -- John Porter
Re: Flexible parsing (was Tying Overloading)
You Americans and your non-ISO penchant for putting the specific before the general. Surely that should be: use Policy::O::Reilly; I knew someone would argue that, but I didn't think it would be someone as illustrious as Damian. Illustrious??? Do you think Larry doesn't know what he's talking about? I think Larry's as prone to an occasional misstep as any other desparately overworked genius. OReilly::Policy is (or might be) still general before specific. OReilly::* might be a whole family of site- specific modules. I think that's safer than supposing a universe of Policy::* policy modules. CPAN's razor: Thou shalt not multiple top-level namespaces without necessity. If it's an IO mechanism, it goes under IO:: If it's a database driver, it goes under DBD:: If it's a linguistics module, it goes under Lingua:: If it's a policy, it should go under Policy:: Surely you wouldn't condone OReilly::IO::File, OReilly::DBD::TimBase, OReilly::Lingua::EN::Puns, when they ought to be IO::File::OReilly, DBD::TimBase::OReilly, and Lingua::EN::Puns::OReilly??? So by all means let's have the whole family of site-specific modules. But put them under something like a Local::O'Reilly (Local::VALinux, Local::ActiveState, Local::Microsoft, etc.) namespace. Let's not have a Policy policy that spawns 50,000 new top-level packages. Damian
Re: Flexible parsing (was Tying Overloading)
Damian Conway wrote: If it's a policy, it should go under Policy:: If it's an OReilly site module, it should go under OReilly, eh? What's general and what's specific is entirely a matter of perspective, since OReilly and Policy are entirely orthogonal concepts. Surely you wouldn't condone OReilly::IO::File, OReilly::DBD::TimBase, OReilly::Lingua::EN::Puns, when they ought to be IO::File::OReilly, DBD::TimBase::OReilly, and Lingua::EN::Puns::OReilly??? They ought to be? It's the same judgment. I don't find yet another example particularly convincing. So by all means let's have the whole family of site-specific modules. But put them under something like a Local::O'Reilly (Local::VALinux, Local::ActiveState, Local::Microsoft, etc.) namespace. BSD, BE, FreeBSD, HPUX, Mac, MSDOS, OS2, etc. etc. Shouldn't they all go under OS? And don't forget Sun::*, which is (meant to be) a model of vendor-specific namespaces. If I work at OReilly, I don't need a Local:: in front of my OReilly to tell me that it's a local namespace. Let's not have a Policy policy that spawns 50,000 new top-level packages. What's the problem? There will be only one, or a handful, at any given site. -- John Porter
Re: Flexible parsing (was Tying Overloading)
If I work at OReilly, I don't need a Local:: in front of my OReilly to tell me that it's a local namespace. but you need OReilly in front? do you label your clothes Shirt and Pants as well? might be orthagonal but the top level should serve a useful purpose instead of something along the lines of: here's my animal, mammal, canine, dog, border collie -- spot.
Re: Flexible parsing (was Tying Overloading)
On Sun, Apr 29, 2001 at 05:06:03PM -0400, John Porter wrote: OReilly::Policy is (or might be) still general before specific. OReilly::* might be a whole family of site- specific modules. Policy::* is *guaranteed* to be a large family of site-specific modules, hopefully even larger than the number of modules that ORA could possibly cook up. So maybe Policy:: is general before specific. Disclaimer: I come from the UK academic community, the people who brought you [EMAIL PROTECTED] -- I hooked up my accelerator pedal in my car to my brake lights. I hit the gas, people behind me stop, and I'm gone. -- Steven Wright
