Re: Flexible parsing (was Tying Overloading)
On Sat, Apr 28, 2001 at 03:44:25PM -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. FYI, the module list has said this for several years: : If developing modules for private internal or project specific use, : that will never be released to the public, then you should ensure that : their names will not clash with any future public module. You can do : this either by using the reserved Local::* category or by using an : underscore in the top level name like Foo_Corp::*. Tim.
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: 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: 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
Re: Flexible parsing (was Tying Overloading)
I think we have to be careful here. We should ask people to name site policy files after their site, and not use a generic name like site_policy, since we'd be likely to end up with 20 different standard site_policy files wandering around the net. So something like use OReilly::Policy; or use Mongolian::Navy::ProcurementOffice::Policy; might be more in order. You Americans and your non-ISO penchant for putting the specific before the general. Surely that should be: use Policy::O::Reilly; # really gonna miss that ' package separator ;-) or use Policy::Mongolian::Navy::Office::Procurement; Next you'll be putting the month and day before the year in dates! Damian
Re: Flexible parsing (was Tying Overloading)
[EMAIL PROTECTED] writes: : use OReilly::Policy; : : or : : use Mongolian::Navy::ProcurementOffice::Policy; : : might be more in order. : : You Americans and your non-ISO penchant for putting the specific before : the general. Surely that should be: : : use Policy::O::Reilly;# really gonna miss that ' package separator :;-) : : or : : use Policy::Mongolian::Navy::Office::Procurement; Well, I did say more in order. I didn't say how much more. : Next you'll be putting the month and day before the year in dates! No, that isn't next, that was previous. Perhaps, being hemispherically challenged, you're looking at it upside down. (-:, er, that is, :-) Larry
Re: Flexible parsing (was Tying Overloading)
At 01:51 PM 4/27/2001 -0700, Larry Wall wrote: Dan Sugalski writes: : Besides, having the site administrator forbid the installation of parser : tweaks might not be what is wanted. If we get PPython in there, a site may : well have a Python.pm module handy, and source might start: : :use site_policy qw(Python); : : for modules that were all-Python, or : :use site_policy qw(Perl); : : for ones that were all-perl. The site-policy file would, amongst other : things, perhaps lock down the parser so you couldn't switch languages in : mid-file. I think we have to be careful here. We should ask people to name site policy files after their site, and not use a generic name like site_policy, since we'd be likely to end up with 20 different standard site_policy files wandering around the net. Well, I was thinking that generally the site policy would be expressed in a single file, and might look something like: Perl: set parser Perl (global); set warnings on (global, fixed); set strict on (global, fixed); Python: set parser Python (global); EasyPerl: set parser Perl (global); set warnings on (global); set strict off; Basically a simple config file that can be protected as the site administrator might see fit, with a simple syntax rather than perl code. (Though if the perl code's straightforward for this stuff, then it doesn't much matter either way) I hadn't really considered having a separate module for each type of site policy decision. 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)
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. Larry
Re: Flexible parsing (was Tying Overloading)
On Thu, Apr 26, 2001 at 11:04:33PM -0500, Jarkko Hietaniemi wrote: On Fri, Apr 27, 2001 at 02:28:58AM +0100, Simon Cozens wrote: On Thu, Apr 26, 2001 at 06:25:03PM -0500, Jarkko Hietaniemi wrote: In a sick way I kinda liked how compilers were able to give out error messages not unlike: foo.ada: line 231: Violation of sections 7.8.3, 9.11.5b and 10.0.16: see the LRM. Ever used the Mac C compiler? Yes...? No. But can we make Configure spit out section numbers in C89 every time it finds a non-conformant feature on the platform? [hmm. for things that C99 doesn't break in C89] Nicholas Clark
Re: Flexible parsing (was Tying Overloading)
Larry Wall wrote: [wrt multiple syntaxes for Perl 6] In any event, I'm not worried about it, as long as people predeclare exactly which variant they're using. And I'm also not worried that we'll have any lack of style police trying to enforce Standard Perl 6. Larry As a member of a consulting group, I am very often called in to enhance or maintain (or just plain fix) existing code for clients. My concern is that it will not be enough simply to know Perl; that I will have to be able to decipher many user-defined variants of Perl. Bad Perl code is easy enough to write and difficult to read, let alone change. And bad Perl code is terribly common. I'm worried that poorly-designed Perl syntaxes will start popping up, further obfuscating poor code, and that will be one more burden for those of us who need to fix it. Sure it's job security, but A badly-written C program is not nearly as hard to maintain as a badly-written PostScript program, partly because PostScript is so redefinable. Maybe reading code written in a bad Perl syntax will be no worse than reading a badly-designed and badly-written class module. I hope that's the case. No, you shouldn't hold back the development of the language simply because people will abuse your efforts and write bad code. Just please keep in mind potential abuses as you're doing your design. A language with arbitrarily flexible syntax can be infinitely difficult to decipher. Thanks. -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
Re: Flexible parsing (was Tying Overloading)
At 04:19 PM 4/26/2001 -0700, Larry Wall wrote: Dan Sugalski writes: : And on the other hand you have things like Forth where every program : essentially defines its own variant of the language, and that works out : reasonably well. (Granted it's more of a niche language, especially today, : but that's probably more due to its RPN syntax) Perhaps. I would also attribute Forth's lack of success in part to its lack of standardization, but only in conjunction with its lack of standardization, if you take my meaning. The core distribution was too small to establish a common culture. It was also the age it was developed in, and the area it came from. It never really hit critical mass, as much because critical mass was really hard to hit at the time as anything else. That seems like a strange thing to say, given how many versions were all over the place, not to mention the forth chips that were designed, but it was really true. There were small clumps of forth folks, but not in places where it ultimately mattered to make the language widespread. Still, I'd guess that the RPNishess was the big reason. It really hurt to get into Forth mode at times since you had to think so differently. I would also argue that Forth's diversity was driven in part by its lack of support for other programming paradigms. I don't see Perl falling into that trap any time soon either... Well, it was the Second Age of computing, and that age has passed. There's also limit to what you can do with 32K of RAM handy. (if you were lucky) 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)
At 09:16 AM 4/27/2001 -0400, Eric Roode wrote: Larry Wall wrote: [wrt multiple syntaxes for Perl 6] In any event, I'm not worried about it, as long as people predeclare exactly which variant they're using. And I'm also not worried that we'll have any lack of style police trying to enforce Standard Perl 6. As a member of a consulting group, I am very often called in to enhance or maintain (or just plain fix) existing code for clients. My concern is that it will not be enough simply to know Perl; that I will have to be able to decipher many user-defined variants of Perl. Bad Perl code is easy enough to write and difficult to read, let alone change. And bad Perl code is terribly common. I'm worried that poorly-designed Perl syntaxes will start popping up, further obfuscating poor code, and that will be one more burden for those of us who need to fix it. This is the only thing I worry about with perl 6's redefinable parser. (Well, from a user-level at least) Combined with easy access to CPAN, it will make it terribly simple to have several flavors of perl handy, which can make maintenance rather dicey. It's also the one reason that I really like the idea of policy files of some sort, to allow sites that don't want this sort of thing to forbid it. I'm not talking things like perl automagically loading policy files in. Rather having use site_policy; set limits that can't be undone at all easily, or something like that. Site management can mandate its use and wield the appropriate baseball bat if it isn't followed. 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)
Dan Sugalski writes: : It's also the one reason that I really like the idea of policy files of : some sort, to allow sites that don't want this sort of thing to forbid it. : I'm not talking things like perl automagically loading policy files in. : Rather having use site_policy; set limits that can't be undone at all : easily, or something like that. Site management can mandate its use and : wield the appropriate baseball bat if it isn't followed. If the site refuses to install the module that tweaks the syntax, that will enforce site policy quite effectively. It's possible that we could take an administrative approach to make sure all such modules go into Tweaks:: or some such, so they can be easily detected. I'm reminded that you couldn't get Ada to do dangerous things without saying with UNCHECKED_TYPE_CONVERSION; or some such glaring declaration at the top. On the other hand, people don't generally declare which dialect they're going to speak in before they start speaking. So there's some balance point in there somewhere, or maybe a set of balance points to be balanced. The trick is to give Perl a wide dynamic range of easily enforced balance points, not to enforce any particular one. Larry
Re: Flexible parsing (was Tying Overloading)
Larry Wall wrote: On the other hand, people don't generally declare which dialect they're going to speak in before they start speaking. On the other other hand, perl already embraces the philosophy of pre-declaring things that change the language. That's what a pragma is. Even my could be construed this way. -- John Porter It's a sky-blue sky The satellites are out tonight let x = x
Re: Flexible parsing (was Tying Overloading)
John Porter writes: : Larry Wall wrote: : On the other hand, people don't generally declare which dialect they're : going to speak in before they start speaking. : : On the other other hand, perl already embraces the philosophy : of pre-declaring things that change the language. That's what : a pragma is. Even my could be construed this way. Certainly, sorry I wasn't clear. I wasn't suggesting that Perl try to intuit the dialect--I was just pointing that out as the opposite end of the continuum from the bureaucratic red tape of trying to ask the government permission to use non-French words in a legal document. :-) For good or ill, a computer program is more like a legal document than a bedtime story. Larry
Re: Flexible parsing (was Tying Overloading)
At 01:16 PM 4/27/2001 -0700, Larry Wall wrote: Dan Sugalski writes: : It's also the one reason that I really like the idea of policy files of : some sort, to allow sites that don't want this sort of thing to forbid it. : I'm not talking things like perl automagically loading policy files in. : Rather having use site_policy; set limits that can't be undone at all : easily, or something like that. Site management can mandate its use and : wield the appropriate baseball bat if it isn't followed. If the site refuses to install the module that tweaks the syntax, that will enforce site policy quite effectively. It's possible that we could take an administrative approach to make sure all such modules go into Tweaks:: or some such, so they can be easily detected. I'm reminded that you couldn't get Ada to do dangerous things without saying with UNCHECKED_TYPE_CONVERSION; or some such glaring declaration at the top. Well, I'm reminded of a place I worked at for quite a while. Almost all our code was in BASIC-PLUS on RSTS/E machines. Production source modules all had a boilerplate header at the top that, amongst other things, brought in some code that forced variable declarations and suchlihe things. Every significant piece of source that went out to customer sites had it at the top. Quick hack code, on the other hand, didn't have to have it (though often as not we did it anyway) and for ten or twenty line toss-off programs we probably didn't bother with it, and the rules were looser. The compiler itself wasn't locked into the strict mode. That's what I'm thinking of here. One perl install would be on a system with the capability of policy enforcement if the programmer so chooses. (The choice being dictated by non-computer means) Two or three line hacks wouldn't have it, while larger source modules might. Besides, having the site administrator forbid the installation of parser tweaks might not be what is wanted. If we get PPython in there, a site may well have a Python.pm module handy, and source might start: use site_policy qw(Python); for modules that were all-Python, or use site_policy qw(Perl); for ones that were all-perl. The site-policy file would, amongst other things, perhaps lock down the parser so you couldn't switch languages in mid-file. 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)
Dan Sugalski writes: : Besides, having the site administrator forbid the installation of parser : tweaks might not be what is wanted. If we get PPython in there, a site may : well have a Python.pm module handy, and source might start: : :use site_policy qw(Python); : : for modules that were all-Python, or : :use site_policy qw(Perl); : : for ones that were all-perl. The site-policy file would, amongst other : things, perhaps lock down the parser so you couldn't switch languages in : mid-file. I think we have to be careful here. We should ask people to name site policy files after their site, and not use a generic name like site_policy, since we'd be likely to end up with 20 different standard site_policy files wandering around the net. So something like use OReilly::Policy; or use Mongolian::Navy::ProcurementOffice::Policy; might be more in order. Larry
Re: Flexible parsing (was Tying Overloading)
Eric Roode writes: : John Porter wrote: : IIUC, this ability is precisely what Larry was saying Perl6 would have. : : I may have my history wrong here, but didn't Ada try that? Not at all. The syntax of Ada was nailed down tighter that almost any language that ever existed. : Super-flexible, redefinable syntax? And wasn't the result that nobody could : read anybody else's code, so Standards Committees were set up to : define Legal Styles that basically reduced the syntaxes that you could : use to just the One Standard Style? Gee, you must be thinking of KR C. :-) In any event, I'm not worried about it, as long as people predeclare exactly which variant they're using. And I'm also not worried that we'll have any lack of style police trying to enforce Standard Perl 6. Larry
Re: Flexible parsing (was Tying Overloading)
Dan Sugalski writes: : And on the other hand you have things like Forth where every program : essentially defines its own variant of the language, and that works out : reasonably well. (Granted it's more of a niche language, especially today, : but that's probably more due to its RPN syntax) Perhaps. I would also attribute Forth's lack of success in part to its lack of standardization, but only in conjunction with its lack of standardization, if you take my meaning. The core distribution was too small to establish a common culture. Despite the fact that we're trying to pare down the actual core core of Perl, I don't think the standard distribution is going to fall into the error of providing too little guidance on cultural matters, if for no other reason than we must minimally provide for translated Perl 5 programs. I would also argue that Forth's diversity was driven in part by its lack of support for other programming paradigms. I don't see Perl falling into that trap any time soon either... Larry
Re: Flexible parsing (was Tying Overloading)
On Thu, Apr 26, 2001 at 04:13:30PM -0700, Larry Wall wrote: Eric Roode writes: : John Porter wrote: : IIUC, this ability is precisely what Larry was saying Perl6 would have. : : I may have my history wrong here, but didn't Ada try that? Not at all. The syntax of Ada was nailed down tighter that almost any language that ever existed. In a sick way I kinda liked how compilers were able to give out error messages not unlike: foo.ada: line 231: Violation of sections 7.8.3, 9.11.5b and 10.0.16: see the LRM. (LRM being the Language Reference Manual.) Truly coding by the book. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Flexible parsing (was Tying Overloading)
On Thu, Apr 26, 2001 at 06:25:03PM -0500, Jarkko Hietaniemi wrote: In a sick way I kinda liked how compilers were able to give out error messages not unlike: foo.ada: line 231: Violation of sections 7.8.3, 9.11.5b and 10.0.16: see the LRM. Ever used the Mac C compiler? -- Language shapes the way we think, and determines what we can think about. -- B. L. Whorf
Re: Flexible parsing (was Tying Overloading)
On Fri, Apr 27, 2001 at 02:28:58AM +0100, Simon Cozens wrote: On Thu, Apr 26, 2001 at 06:25:03PM -0500, Jarkko Hietaniemi wrote: In a sick way I kinda liked how compilers were able to give out error messages not unlike: foo.ada: line 231: Violation of sections 7.8.3, 9.11.5b and 10.0.16: see the LRM. Ever used the Mac C compiler? Yes...? -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Flexible parsing (was Tying Overloading)
At 01:36 PM 4/25/2001 -0400, Eric Roode wrote: John Porter wrote: Dan Sugalski wrote: The one downside is that you'd have essentially your own private language. Whether this is a bad thing or not is a separate issue, of course. IIUC, this ability is precisely what Larry was saying Perl6 would have. I may have my history wrong here, but didn't Ada try that? Super- flexible, redefinable syntax? And wasn't the result that nobody could read anybody else's code, so Standards Committees were set up to define Legal Styles that basically reduced the syntaxes that you could use to just the One Standard Style? Sounds about right. And on the other hand you have things like Forth where every program essentially defines its own variant of the language, and that works out reasonably well. (Granted it's more of a niche language, especially today, but that's probably more due to its RPN syntax) A power so great, it can only be used for good or evil! - Firesign Theater :) 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)
John Porter wrote: Dan Sugalski wrote: The one downside is that you'd have essentially your own private language. Whether this is a bad thing or not is a separate issue, of course. IIUC, this ability is precisely what Larry was saying Perl6 would have. I may have my history wrong here, but didn't Ada try that? Super- flexible, redefinable syntax? And wasn't the result that nobody could read anybody else's code, so Standards Committees were set up to define Legal Styles that basically reduced the syntaxes that you could use to just the One Standard Style? -- Eric J. Roode[EMAIL PROTECTED] Senior Software Engineer, Myxa Corporation
