Re: Multiline comments in Perl6
On Dec 30, 2007 8:10 AM, Jonathan Lang <[EMAIL PROTECTED]> wrote:
> Let's say that the programmer in question wants to comment out all but
> the third line; so he prefixes everything else with '#':
>
> #if ($test)
> #{
>.say;
> #} else {
> # .doit;
> #}
>
> What the writer _wants_ this to do is the equivalent of:
>
>.say;
>
> What he'd get with embedded comments would be the equivalent of:
>
>else {
>
Isn't this still a problem if you have something like:
if ($test)
{
.say;
#if ($test2)
#{
.dothat;
#} else {
# .dosomethingelse;
#}
} else {
.doit;
}
I know the answer is to comment at the beginning of the line instead of
later, but still, this is a fairly common practice and is likely to be just
as confusing (if not more, because of the whitespace rules), as allowing #()
to come at the beginning of the line. I'm all for DWIM, but this seems like
it will lead to a lot of head scratching.
Most places in the grammar that have strange whitespace rules or require
other methods of disambiguation at least seem to have a good reason for it;
these are comments, should we really create a mess of potential compiler
errors and limit where embedded comments can be (not allowing them to be the
first thing on a line is pretty strange) just to use this particular
syntax? Like someone else mentioned, every other language has multi line
comments without weird problems like this, why can't we just pick a
construct that isn't so prone to ambiguity?
I suggest we use # for single line comments and ##() for multi line comments
(just adding an extra leading # to differentiate). This has the added
benefit of standing out a bit more to anyone skimming the code.
Re: The new wiki
I own p6docs.com if you'd like to use that, just give me some nameservers to point to. On 7/5/06, Michael G Schwern <[EMAIL PROTECTED]> wrote: Thanks to Tyler MacDonald and yi.org we now have a brand spanking new wiki! http://perl-qa.yi.org/ is its location, we'll worry about getting more official domains later. Its a wiki. Go nuts. Err on the side of editing rather than doing nothing. Not sure if something should go on the wiki? Put it there, it can be deleted. This is MediaWiki, the wiki which Wikipedia runs. Its got some features and differences from other wikis, so please read http://perl-qa.yi.org/index.php/MediaWiki_Editing_Tips to learn how to use it most effectively. I've put together a short list of things you can do for the Wiki. http://perl-qa.yi.org/index.php/What_can_I_do%3F Those of you who have proposed TAP extensions, kindly scrape the details off the mailing list, write them up on the wiki and list them here: http://perl-qa.yi.org/index.php/TAP_Proposals Those writing TAP parsers, kindly write them up on the wiki and list them here: http://perl-qa.yi.org/index.php/TAP_Parsers Those writing TAP producers (things which can produce TAP output. ie. Test::Builder, libtap, Test.pm, Selenium?...), write them up on the Wiki and list them here: http://perl-qa.yi.org/index.php/TAP_Producers
Re: Parrot Shootout
On 12/10/05, Roger Browne <[EMAIL PROTECTED]> wrote: > > Does your compiled code use PMC Integers or native ints? (I'm using > PMCs). > > Regards, > Roger Browne My goal is to have the compiled code as simple as possible, so the compiler uses native ints and strings if it can. I also upgraded the generated code for 'if' and 'elseif' statements to optimize to the 'ne', 'eq', 'lt', and 'gt' opcodes if possible (instead of calling a function to compare two values, storing the result, and testing it for trueness). I made a similar change where addition/subtraction is done as well (instead of calling a function to add two values and re-storing the result, it optimizes to the 'inc' and 'dec' opcodes). You can see the generated PIR here: http://theguildforge.com/ack.pir
Re: Parrot Shootout
On 12/9/05, Shane Calimlim <[EMAIL PROTECTED]> wrote: > > > I ran a couple benchmarks with a language/compiler I've been toying with: > > (running on redhat el3, p4 3.2 ghz) > Ack(3,6): 509 2.85374 seconds > Ack(3,9): 4093223.19224 seconds > > Using the following code: > > ack(x, y) > if x == 0 > return y + 1 > if y == 0 > return ack(x - 1, 1) > else > return ack(x - 1, ack(x, y - 1)) > > say "Ack(3, 9): " .. ack(3, 9) > > This is my first compiler, so I'm sure the generated PIR could use a > little optimization. > > With some adjustments to the compiler I've gotten the times down to: Ack(3,6): 509 0.70313 seconds Ack(3,9): 409350.51184 seconds Still not amazing, but I'm sure there's performance to be squeezed out yet.
Re: conditional wrapper blocks
Excuse my noobness, I really have no idea about any of the inner workings,
but am just concerned with a more elegant syntax of doing it.
How about something like:
if ($condition) {
pre;
always { # maybe "uncond" instead of always, or both -- "always" could
# mean 'ignore all conditions' and "uncond" could mean
# 'ignore the current block's condition
mid_section;
}
post;
}
Or maybe:
if ($condition) {
pre;
} is continued;
mid_section;
continue {
post;
}
A flaw I see in the latter though is that you could not use the "is
continued" trait inside of mid_section without confusing the parser.
On 9/20/05, Yuval Kogman <[EMAIL PROTECTED]> wrote:
>
> Today on #perl6 I complained about the fact that this is always
> inelegant:
>
> if ($condition) { pre }
>
> unconditional midsection;
>
> if ($condition) { post }
>
> Either you put the condition in a boolean var and check it twice, or
> you use a higher order function and give it three blocks, and the
> conditional. But no matter how much we try, it always feels too
> "manual".
>
> I asked for some ideas and together with Aankhen we converged on the
> following syntax:
>
> if ($condition) {
> pre;
> } uncond {
> middle;
> } cond {
> post;
> }
>
> s/uncond/<>.pick/e;
> s/cond/<>.pick/e;
>
> Some restrictions:
>
> The block structure must always be ternary - for other cases we
> already have enough control flow.
>
> The if is not the same if that can cuddle with else - it's either
> or.
>
> Does anybody have any comments, or synonyms for the control
> structure naming?
>
> BTW, I expect readability to be optimal with 1-2 lines of pre/post,
> and 1-5 lines of middle. Any observations?
>
> --
> () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
> /\ kung foo master: /me groks YAML like the grasshopper: neeyah!!
>
>
>
>
