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
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
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
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.
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
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
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?
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
I don't much care for m4; it's not so much better than cpp to be
worth the notice.
*Strongly* disagree.
--tom
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
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]
=
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
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:
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
On Thu, Aug 03, 2000 at 11:40:24AM +0900, Simon Cozens wrote:
On Wed, Aug 02, 2000 at 07:34:36PM -0700, Nathan Wiger wrote:
That Perl should stay Perl
Do we need an RFC for this? Seems like this is more of a "guiding
concept" that should be intergrated into everything. Just my opinion.
15 matches
Mail list logo
