MLC has its own sublist: WAS: Re: Recording what we decided *not* to do, and why
Please post further MLC remarks to the MLC sublist: [EMAIL PROTECTED] I can't guarentee that any MLC comments posted under a different subject, and on a different list will make it into the final Multiline Comments RFC! Not to mention that this specific argument is already addressed in the current RFC posted there. --Michael John Porter said: Glenn Linderman wrote: When using an inline comment, I want to spend my character budget mostly on the comment, and just enough on the delimiters to see it effectively. # magic here # would do quite nicely When reading a script, I'd like to be able to quickly distinguish the comments using my eyeballs and brain, without the need to involve my fingers and editor Bogus arguments both, at least wrt #...# vs qc Same number of characters overhead, same LACK of obviosity to the eyeball.
Re: Recording what we decided *not* to do, and why
John Porter wrote: Glenn Linderman wrote: When using an inline comment, I want to spend my character budget mostly on the comment, and just enough on the delimiters to see it effectively. # magic here # would do quite nicely When reading a script, I'd like to be able to quickly distinguish the comments using my eyeballs and brain, without the need to involve my fingers and editor Bogus arguments both, at least wrt #...# vs qc Same number of characters overhead, same LACK of obviosity to the eyeball. We can agree on the same number of characters overhead. My comment regarding # ... # characters were intended to address comparisons with things like using "#token ... token" in an in-line fashion, not as comparison with "qc...". Regarding obviosity, # end-of-line comments already exist and the eyeball has become trained to consider them as comments... for many years of shell, make, hosts file, etc. usage, long before Perl, the eyeball has learned to pick out # to mean beginning of comment. # (or the like, any bracket character, or, with deference to the multitudes of C and Pascal programmers, even the "*" character, as in "#*...*#") is a simple extension to #, and, by use of a bracket character (or *), implies there will be an end. qc... clearly raises the expectation of bracketing, but builds on absolutely no semantics with respect to commenting. Rather, it builds on the semantics of quoting, so the eyeballs wouldn't detect it as a comment, and the brain would wonder what kind of quoting this should be. Eventually, no doubt, the brain would catch on, but it would always remain confusing to the eyeballs, as the "qc" sequence could so easily be found in other, non-comment situations. While the "#" character is legal to use for other syntactical purposes in Perl (any place that "any character" is permitted, for example, q#...#, the availability of so many other characters to fill that bill causes me to avoid using # in those situations. The only situation in which I use non-comment-introducing "#" characters in my scripts are within quoted strings, where the "#" is required to appear for the purpose of the script. This encourages the eyeballs to retain their "# as comment" scanning ability! -- Glenn = There are two kinds of people, those who finish what they start, and so on... -- Robert Byrne ___ Why pay for something you could get for free? NetZero provides FREE Internet Access and Email http://www.netzero.net/download/index.html
Preprocessing (Was: Re: Recording what we decided *not* to do, and why)
Russ Allbery [EMAIL PROTECTED] writes: However, cpp has the significant advantage that its active syntax is designed to be embedded in a programming language and are Perl comments. This is *not* true of m4, which would be horribly, horribly confused by a Perl script. I fail to see this point. Having a program depend on a preprocessing stage that, if skipped, would still result in valid but erroneous source seems dangerous to me. m4 was not designed with embedding in a programming language in mind, and lots of things like macro invocation syntax and default quoting characters would interact very poorly with Perl. I wouldn't classify the cpp language (#ifdef #define #include) friendly to C either. It looks as if they happily co-exist since invoking the C compiler automatically invokes the preprocessor. But let's not put energy in a cpp versus m4 discussion. External macro processors exist and can be applied by suffienciently skillful people anyway. I think the question we must ask ourselves is: what kind of preprocessing would we like perl to provide automatically. Also, I think that preprocessing only plays a relevant role if we have byte compiling. There a few advantages of a preprocessor if preprocessing/compilation/execution are _always_ done together. -- Johan
Re: Preprocessing (Was: Re: Recording what we decided *not* to do, and why)
Johan Vromans [EMAIL PROTECTED] writes: I fail to see this point. Having a program depend on a preprocessing stage that, if skipped, would still result in valid but erroneous source seems dangerous to me. No, the point is more that normal Perl source is *full* of active m4 characters. Without quoting, all your paired quotes would disappear, comments would be stripped even when they're not actually comments but are really regexes, m4 wouldn't understand things like Perl strings and regexes and do substitutions where it shouldn't, etc. The problem is not that you can skip the preprocessing stage, but rather that as soon as you want to use m4 on a Perl program, you'd have to do a *huge* amount of work on all the parts of the program you *don't* need to preprocess just to be able to do things with the part that you do want to preprocess. cpp, on the other hand, has very few active constructs or characters, just identifiers, function calls, and # at the beginning of a line. It still causes a few problems where it recognizes something it shouldn't, but it's trivial to deal with compared to m4. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: Recording what we decided *not* to do, and why
Michael Mathews [EMAIL PROTECTED] writes: Jonathan Scott Duff said Status: tabled # shelved, put away for now Please avoid 'tabled' - it means near the opposite in the UK. To table something is to put it "on the table" i.e. open for discussion. -- Nick Ing-Simmons
Re: Recording what we decided *not* to do, and why
John Porter [EMAIL PROTECTED] writes: But a standardized macro facility would be nice. Although -- wouldn't it have to parse perl? Or else have a wholly distinct grammar? Several macro processors exist and are easily available. I do not see the need to duplicate (parts of) their functionality in perl. Personally, I'd even trow out -P. -- Johan
Re: Recording what we decided *not* to do, and why
Tom Christiansen [EMAIL PROTECTED] writes: While a function style or quoted form comment might seem clever, and even Perlish due to its syntax, it doesn't help the author of the code/comments readily distinguish them. What good are comments if you can't find them when you need them? Sounds like an argument for :10,20s/^/###/ style comments. Hurray! -- Johan
Re: Recording what we decided *not* to do, and why
Several macro processors exist and are easily available. I do not see the need to duplicate (parts of) their functionality in perl. Personally, I'd even trow out -P. Well, possibly, but especially if a cpp-like source filter module is included standard. --tom
Re: Recording what we decided *not* to do, and why
I don't much care for m4; it's not so much better than cpp to be worth the notice. *Strongly* disagree. --tom
Re: Recording what we decided *not* to do, and why
Tom Christiansen wrote: I don't much care for m4; it's not so much better than cpp to be worth the notice. *Strongly* disagree. O.k., what I really meant was, When they're both incapable of doing the sorts of things I want a macro language to do, does it matter that one is gobs more powerful than the other? -- John Porter
Re: Recording what we decided *not* to do, and why
hi, it will be good if all these RFC are put somewhere on the WEB (we can't follow all those mailing lists if the amout of posts stay the same :") ) also in this way we will get broader picture what is happenning.. = iVAN [EMAIL PROTECTED] =
Re: Recording what we decided *not* to do, and why
While a function style or quoted form comment might seem clever, and even Perlish due to its syntax, it doesn't help the author of the code/comments readily distinguish them. What good are comments if you can't find them when you need them? Sounds like an argument for :10,20s/^/###/ style comments. --tom
Re: Recording what we decided *not* to do, and why
At 01:11 PM 8/3/00 -0500, Jonathan Scott Duff wrote: BTW, I propose that RFCs have a Status: field as part of the VERSION. Here are some possible values that I can see: Status: accepted # we all agree that it should go in Status: rejected # we all agree that it shouldn't go in Status: tabled # shelved, put away for now Since I have been lead to believe that in standard US practice, "to table" means to stop talking about something for now, and in standard UK practice "to table" means to bring up for discussion, I suggest that the last be "Status: postponed" instead of "Status: tabled". But then, I'm so far behind on my perl6 mail that someone else may have suggested that. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Recording what we decided *not* to do, and why
Steve Simmons writes: This idea is both important and more general. If we go thru a huge discussion of, say, multi-line comments and decide *not* to do it, we don't want to have the whole thing repeated with perl 6.1, 7.0, etc, etc. When something reaches RFC stage but is rejected, part of the process should include archiving the gist of the arguements for and against. IMHO the RFC editor should be responsible for this. IMHO someone should write an RFC on why perl6 should NOT have comments. The RFC editor doesn't have time to follow these zillions of discussions and write documents based on them. Nat RFC,PCR,PHB,whatever :-)
