Fwd: [perl #40508] [PATCH] Removal of C++ comments in pmc files
What's a "C++ comment"? If you mean //...\n comments, those are legal in ANSI-99 C (and the syntax goes back to BCPL). If the coding standard specifies multiline-style comments only, fine, but please don't use misleading terminology. -- Forwarded message -- From: via RT Paul Cochrane <[EMAIL PROTECTED]> Date: Wed, 11 Oct 2006 01:32:55 -0700 Subject: [perl #40508] [PATCH] Removal of C++ comments in pmc files To: [EMAIL PROTECTED] # New Ticket Created by "Paul Cochrane" # Please include the string: [perl #40508] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=40508 > Hi, This patch changes C++ comments found in pmc files to C comments. Regards, Paul files affected: languages/APL/src/pmc/aplvector.pmc languages/pugs/pmc/pugscapture.pmc -- Mark J. Reed <[EMAIL PROTECTED]> Index: languages/APL/src/pmc/aplvector.pmc === --- languages/APL/src/pmc/aplvector.pmc (revision 14877) +++ languages/APL/src/pmc/aplvector.pmc (working copy) @@ -124,11 +124,15 @@ * we use our own type here. Perhaps a better way to * specify it? */ -//array_t = pmc_type(INTERP, -//string_from_const_cstring(INTERP, "APLVector", 0) -//); +/* +array_t = pmc_type(INTERP, +string_from_const_cstring(INTERP, "APLVector", 0) +); +*/ shape = pmc_new(INTERP,VTABLE_type(INTERP,SELF)); -//#array_t); +/* +#array_t); +*/ VTABLE_set_integer_native(INTERP, shape, 1); VTABLE_set_integer_keyed_int(INTERP,shape,0, VTABLE_get_integer(INTERP, SELF) Index: languages/pugs/pmc/pugscapture.pmc === --- languages/pugs/pmc/pugscapture.pmc (revision 14877) +++ languages/pugs/pmc/pugscapture.pmc (working copy) @@ -35,7 +35,9 @@ } siva; static PMC* intret; -// STRING * parrot_hash_get_idx(Interp *interpreter, Hash *hash, PMC * key); +/* +STRING * parrot_hash_get_idx(Interp *interpreter, Hash *hash, PMC * key); +*/ static PMC* undef_pmc; /*
Re: renaming "grep" to "where"
I still don't think we have a consensus that grep needs to be renamed,
much less what it should be renamed to. To me, "keep" implies throwing
the rest away,I.e., modifying the list. "Select" has the advantage of
lacking that connotation. To avoid dissonance with the two perl5
"select"s, we could go with a synonym like "choose" or, in the 4-char
category, "pick". But my vote is still to keep grep as "grep".
On 9/20/06, Aaron Sherman <[EMAIL PROTECTED]> wrote:
Damian Conway wrote:
> In other words, classify() takes a list of values, examines each in
> turn, and ascribes a "label" value to it. The call returns a list of
> pairs, where each pair key is one of the label values and each pair
> value is an array of all the list values that were ascribed that label.
>
>
> Personally, I don't have a problem with us keeping 'grep'. However, if
> we do decide to change the name, I suspect 'keep' might be readable,
> short, SWIM, and not confused with other operations:
>
> my @evens = keep { $^num % 2 == 0 } @numbers;
OK then. Just so that I can type of the final result in S29, let's see
if everyone agrees to several points that have been made in this thread:
1. "classify" is the real grep
2. convenience function, "keep" is probably a macro
3. "use List :compat" will get you a "grep" just as it will likely get
you "mv" on the OS module, etc.
Is any of this going to break the bank? If not, I'll get it in today.
--
Mark J. Reed <[EMAIL PROTECTED]>
Re: renaming "grep" to "where"
I envision a select, reject, and partition, where
@a.partition($foo)
Returns the logical equivalent of
[EMAIL PROTECTED]($foo), @a.select($foo)]
But only executes $foo once per item. In fact. I'd expect partition
to be the base op and select and reject to be defined as
partition()[1] and partition()[0] respectively...
On 9/19/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
Larry Wall wrote:
> Mark J. Reed wrote:
> : I have no horse in this race. My personal preference would be to
> : leave grep as "grep". My second choice is "select", which to me is
> : more descriptive than "filter"; it also readily suggests an antonym of
> : "reject" to do a "grep -v" (cf. "if !" vs "unless"). But I'd accept
> : "filter", too.
Given a choice between 'grep', 'filter', and 'select/reject', I'd
prefer the third model: it counterbalances the break from tradition
with additional functionality.
> But which *ect do we call the one that returns both?
In short: if 'select/reject' would be analogous to 'if/unless', should
'select' be allowed the equivalent of an 'else' as well as a 'then'?
Personally, I think that this would be an unneccessary complication -
much like 'unless' doesn't get to split code into true and false
branches, and statement modifiers can't be nested.
Meanwhile, your examples seem to be illustrating another possibility:
something analogous to 'grep' that uses the 'given/when' paradigm
instead of the 'if/then' paradigm. This, I think, has promise -
though, as you say, there's already a way to do this using gather.
What I'd be looking for would be a more compact syntax:
(@good, @bad, @ugly) = @stuff.divvy {
when .sheep { @good }
when .goat { @bad }
default { @ugly }
}
...or something of the sort. Regardless, this oughtn't actually be
the replacement for grep, IMHO; it should _supplement_ grep instead.
> Anyway, it's not clear to me that grep always has an exact opposite.
I don't see why it ever wouldn't: you test each item in the list, and
the item either passes or fails. 'select' would filter out the items
that fail the test, while 'reject' would filter out the ones that pass
it.
--
Jonathan "Dataweaver" Lang
--
Mark J. Reed <[EMAIL PROTECTED]>
Re: renaming "grep" to "where"
As a random alternative, I note that Ruby's analog to grep is called "find_all" (though it also has a "grep" that behaves differently from Perl's). Personally, I'm not enamored of "filter" because it has connotations of removal... On 9/19/06, Jonathan Scott Duff <[EMAIL PROTECTED]> wrote: On Tue, Sep 19, 2006 at 04:38:38PM +0200, Thomas Wittek wrote: > Jonathan Lang schrieb: > > IMHO, syntax should be left alone until a compelling reason to change > > it is found. While I think it would be nice to have a more intuitive > > name for grep > What would be the disadvantage of renaming it to a more intuitive name? > I can only see advantages. Lost culture perhaps. There's a long strong tradition of the term "grep" in perl and it would be a shame to toss that away without some serious thought. That said, I'm in favor of the term "filter" because, as Damian mentioned, that term is used in several other languages. > > I don't think that this qualifies as a compelling > > reason to change it - especially since it's so easy to add aliases via > > modules > As Smylers said above: Please, no more aliases. They only create confusion. Sure, but "all's fair if you predeclare". Aliases imposed on us all may cause confusion, but presumably, if an individual has asked for an alias, they are willing to risk the potential confusion. For me personally, I can live with "filter" as an alias for "grep". But that's just me. -Scott -- Jonathan Scott Duff <[EMAIL PROTECTED]> -- Mark J. Reed <[EMAIL PROTECTED]>
Re: Same-named arguments
So what's the rationale behind the latest changes? I thought p6
consistently regarded the sigil as part of the name; seems like that
should go for named parameters, too. In fact, sigils would seem to be
a good way to distinguish named parameters from pairs.
Alternatively, reserve either :k(v) or k=>v for named parameters and
use the other for pairs. I don't see the value of conflating those two
things syntactically - is it just for compatibility with p5 modules
that take their parameters as hashes?
I freely admit to myopia and a lot less time thinking about this
stuff, but using extra parens or autoquoting vs explicit quotes to
distinguish named params from pair arguments feels wrong.
On 8/25/06, Luke Palmer <[EMAIL PROTECTED]> wrote:
On 8/25/06, Michael Snoyman <[EMAIL PROTECTED]> wrote:
> I asked this same question on perl6-users, but no one really seemed to
have
> a definitive answer, so please forgive me for reasking.
>
> I was wondering how named arguments would work when parameters of
different
> types had the same name, ie sub foo($bar, @bar, &bar) {...}.
That's probably an error at compile time, given the new provision that
'@bar' => ... is not a named argument so we have no way to distinguish
between the parameters.
Luke
--
Mark J. Reed <[EMAIL PROTECTED]>
Re: Same-named arguments
So what's the rationale behind the latest changes? I thought p6
consistently regarded the sigil as part of the name; seems like that
should go for named parameters, too. In fact, sigils would seem to be
a good way to distinguish named parameters from pairs.
Alternatively, reserve either :k(v) or k=>v for named parameters and
use the other for pairs. I don't see the value of conflating those two
things syntactically - is it just for compatibility with p5 modules
that take their parameters as hashes?
I freely admit to myopia and a lot less time thinking about this
stuff, but using extra parens or autoquoting vs explicit quotes to
distinguish named params from pair arguments feels wrong.
On 8/25/06, Luke Palmer <[EMAIL PROTECTED]> wrote:
On 8/25/06, Michael Snoyman <[EMAIL PROTECTED]> wrote:
> I asked this same question on perl6-users, but no one really seemed to
have
> a definitive answer, so please forgive me for reasking.
>
> I was wondering how named arguments would work when parameters of
different
> types had the same name, ie sub foo($bar, @bar, &bar) {...}.
That's probably an error at compile time, given the new provision that
'@bar' => ... is not a named argument so we have no way to distinguish
between the parameters.
Luke
--
Mark J. Reed <[EMAIL PROTECTED]>
Re: Same-named arguments
So what's the rationale behind the latest changes? I thought p6
consistently regarded the sigil as part of the name; seems like that
should go for named parameters, too. In fact, sigils would seem to be
a good way to distinguish named parameters from pairs.
Alternatively, reserve either :k(v) or k=>v for named parameters and
use the other for pairs. I don't see the value of conflating those two
things syntactically - is it just for compatibility with p5 modules
that take their parameters as hashes?
I freely admit to myopia and a lot less time thinking about this
stuff, but using extra parens or autoquoting vs explicit quotes to
distinguish named params from pair arguments feels wrong.
On 8/25/06, Luke Palmer <[EMAIL PROTECTED]> wrote:
On 8/25/06, Michael Snoyman <[EMAIL PROTECTED]> wrote:
> I asked this same question on perl6-users, but no one really seemed to
have
> a definitive answer, so please forgive me for reasking.
>
> I was wondering how named arguments would work when parameters of
different
> types had the same name, ie sub foo($bar, @bar, &bar) {...}.
That's probably an error at compile time, given the new provision that
'@bar' => ... is not a named argument so we have no way to distinguish
between the parameters.
Luke
--
Mark J. Reed <[EMAIL PROTECTED]>
Re: multi-line comments, C macros, & Pod abuse
I think this is not even a metaprogramming issue so much as a
programming environment one. I mean, if your editor doesn't make it
easy to stick a # at the beginning of a bunch of lines with one
action, and likewise remove them later, you need to get a new editor.
:)
On 8/21/06, Joshua Hoblitt <[EMAIL PROTECTED]> wrote:
On Mon, Aug 21, 2006 at 12:06:36AM +0100, Andrew Suffield wrote:
> On Sun, Aug 20, 2006 at 03:55:56PM -0600, Luke Palmer wrote:
>
> > Why would you care about introducing a new lexical scope? You would
> > care about that if you used a variable you declared in the commented
> > code in the code below it, which is broken.
>
> Typically because you have several versions that you want to switch
> between, and you'd rather add a few characters of comment rather than
> spend the time rearranging the code to use ifs or subs or
> something. It's something you might do when debugging or experimenting
> (especially under time pressure) - at least, that's how I use '#if 0'
> in C.
The more I think about this issue the more I realize that this is really
a very simple case of metaprogramming. Which got me thinking about more
sophisticated compile time flow control. I imagine that defining
something like a compile time switch switch statement is possible with
the existing macros. Would anyone like to take a shot at defining a
macro to do this? Is it possible to jump to something outside of a
macros input that is also evaluated at compile time?
> Using <<'#END' (or rather, q:to'#END') is actually not that bad an
> idea... it'd work in most places where #{} would give trouble. Unless
> anybody has any better ideas, that could be a useful idiom to
> remember.
Using heredocs for commenting code out is slightly undesirable as it
would create a branch that has to be tested at runtime. One would hope
that the compiler would note the conditional on a constant and throw the
heredoc out as dead code but it certainly feels untidy.
-J
--
--
Mark J. Reed <[EMAIL PROTECTED]>
