Re: Curious: - vs .
Buddha Buck [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] writes: Buddha Buck [EMAIL PROTECTED] writes: Bart Lateur [EMAIL PROTECTED] writes: On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote: So why not $object!method(foo, bar); In my opinion, because it doesn't provide sufficient visual distinction between $object and method(). At a glance, especially on a crowded page, it's similar in appearance to $objectImethod, for instance. $object.method() has a visual separator (although I'd prefer $object-method()). How about borrowing from Objective C? [$object method(foo, bar)]; How do you create an anonymous list now then? Not that I object to borrowing from Objective C you realise. I thought ($one, $two, $three) was an anonymous list. Oops, meant anonymous array. Seriously, I hadn't considered that their may be a problem with the syntax I gave. How would you, under Perl5, interpret the expression I used. To me, it looks like a syntax error. '$object method(foo,bar)' isn't a valid method call, so it can't be a ref to an anonymous list of one value. Hmm... I plead posting late at night. Other than severe dependence on the comma, is there any reason why we couldn't have the following? $foo = [$one]; # array ref $baz = [$obj,funcall() ]; # array ref $quux = [$one,$two,$three]; # array ref $bar = [$obj method() ]; # method call $bat = [$one $two $three]; # syntax error Apart from the fact that we're adding one more meaning to [], one which has no mnemonic relationship with arrays, no reason at all. -- Piers Cawley www.iterative-software.com
Re: Curious: - vs .
On 26 Apr 2001 23:19:49 -0400, Buddha Buck wrote: $bar = [$obj method() ]; # method call $bar = method $obj() would be more consistent with perl's current $object = new Class() syntax. -- Bart.
Re: a modest proposal Re: s/./~/g
On Thu, Apr 26, 2001 at 04:46:48PM -0700, Larry Wall wrote: And I'm tired of hearing the argument that Perl programmers can't get used to a different operator for concatenation. I know better--after all, Perl is probably what got them used to . in the first place. If you can teach dogs to salivate at a bell, you can probably teach them to salivate at a dog biscuit. :-) I think many of us are resigned to losing . for concatination; I know I can live with that. I just don't want to have this result in ~, ^, or any other C-style punctuation operator getting renamed. I like the fact that Perl follows the same operator conventions as C, C++, Java and others in this area; breaking with tradition here for the sake of aligning . feels inelegant. Renaming . to cc wouldn't bother me half so much. - Damien
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: Curious: - vs .
Bart Lateur [EMAIL PROTECTED] writes: On 26 Apr 2001 23:19:49 -0400, Buddha Buck wrote: $bar = [$obj method() ]; # method call $bar = method $obj() would be more consistent with perl's current $object = new Class() syntax. Yes, well, some people want to get rid of the indirect object syntax, not require it. I don't use it myself, but my understanding is that $bar = method $obj() is legal right now, and that your second example isn't a special-case but just one example of the general case. -- Bart.
Re: Curious: - vs .
Piers Cawley [EMAIL PROTECTED] writes: Buddha Buck [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] writes: Buddha Buck [EMAIL PROTECTED] writes: How about borrowing from Objective C? [$object method(foo, bar)]; How do you create an anonymous list now then? Not that I object to borrowing from Objective C you realise. I thought ($one, $two, $three) was an anonymous list. Oops, meant anonymous array. To be overly pedantic I thought [$one, 2, 3] was a ref to an anonymous array... Other than severe dependence on the comma, is there any reason why we couldn't have the following? [snip] Apart from the fact that we're adding one more meaning to [], one which has no mnemonic relationship with arrays, no reason at all. Since it looks like we are going to be getting $object.method() anyway, it doesn't matter much. It was more of a facetious suggestion to begin with -- although that doesn't mean that it wouldn't work, it's just not going to happen, and I know it. Piers Cawley www.iterative-software.com
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: a modest proposal Re: s/./~/g
On Fri, Apr 27, 2001 at 01:45:02AM -0700, Damien Neil wrote: I think many of us are resigned to losing . for concatination; I know I can live with that. I just don't want to have this result in ~, ^, or any other C-style punctuation operator getting renamed. That's my position. I'd rather live without a concatenation operator than use ~ or ^ for it. But if we must have a concatenation operator, I'd rather it be cc or _ (I didn't like the underscore at first, but it's grown on me a little) or some other punctuation that doesn't already have some well-established-across-multiple-languages meaning. anyway, my two cents ... -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
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: a modest proposal Re: s/./~/g
Jonathan Scott Duff wrote: I'd rather it be cc or _ (I didn't like the underscore at first, but it's grown on me a little) Comparing ~ and _ to available editors markup marks, _ is closer to the sideways () that an editor might use to indicate that two words should be joined together. Tilde looks like it might mean switch the order of the token ahead and the token behind me Will there be confusion with the _ that means the file statted by the last -X test? I doubt it: file tests need to bind tighter than the concat op and the problem is over. I can't create a situation where it would be confusing anyway -- what would the LHS of the _ be in a test situation? There wouldn't be one. For that matter, indirect object syntax is always bareword $object|bareword argument[, ...] which would collide with relatively few concat accretions, even without any semantic information. If it starts with a bareword, it's not a concat. A stronger argument against white-space-juxtapositions IMO would be the possible confusion generated by arguments getting accretted when a comma gets left out, instead of a syntax exception getting thrown: function(this,that the other); the second argument is now the intended second and third args and there is no third arg, instead of a syntax error. -- David Nicol 816.235.1187 [EMAIL PROTECTED] and they all say yodelahihu
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
