brian wrote:

> As you know, one of the biggest complaints about Perl is that you have
> to have a lot of special rules knowledge to figure some things out.
> Whether that is true doesn't really matter: people still complain about
> it.
>
> In this case, it will actually be true.

I don't think that's the case. I think the new approach to Pod has
exactly the opposite effect: it *eliminates* the need for a lot of
special rules and contextual understandings.


> This impacts Learning Perl 6 rather early because it's a rule that
> people need to know at the same time that we tell them that whitespace
> is insignificant.

I'm pretty sure "Learning Perl 6" won't say that. Mainly because it's
not true. Whitespace in Perl 6 isn't always insignificant, even in the
simplest examples. Indeed, whitespace is significantly less
insignificant in Perl 6 than it was in Perl 5.


> That's not really true anymore because a newline followed by an =
> followed by begin is this special case, **no matter how it shows up
> in the program**. Now there's this extra footnote to explain this
> situation, and at the level of basic syntax, we have to explain a
> lot more.

I don't think so.

There are two distinct models we're considering in this thread. The
first model is that Pod is a layer entirely syntactically separate from
Perl, and which is preprocessed out of existence before the compiler
ever sees the source of a program. Call this the "Separation model".

The second model is that Pod is an integral syntactic feature of
Perl: effectively a special kind of comment. Call this the
"Integration model".

The rule you have to teach under the Separation model is:

    "Any line that starts with an = is Pod...and not part of your program."

Whereas the rule you have to teach under the Integration model is:

    "Any line that starts with an = is Pod...and not part of your program
         ...UNLESS it's part of an assignment or comparator or inside a string
            in which case it's something else
             ...UNLESS it's also inside a code block inside that string,
                in which case it's a Pod command again
                    ...UNLESS it's part of a nested assignment or comparator
                       or doubly nested inside the nested string
                           ...UNLESS it's in a doubly nested code block
                              inside that nested string
                                  ...etc.
                                      ...etc."


So, for example, consider the following lines:

    $var

    =comment  Is this Pod?qq{

    =comment  Is this Pod?qq{

    =comment  Is this Pod?qq{

    }}}

Which of those are Pod and which are Perl?

Under the Separation model, they're all Pod;
under the Integration model, only one of them is.


> So, if this is the case, how will a new Perl 6 user debug a program
> failure when part of their program mysteriously disappears because
> they just happened to have =begin at the beginning of a line?

The same way they debug it when part of their program mysteriously
disappears because they just happened to have # at the beginning of a
line: by learning to distinguish between code and commentary.

Except, of course, the Pod mysteriously vanishing will be considerably
easier to debug, because ALL lines starting with =begin vanish, whereas
only some lines beginning with # do.


> Also, doesn't this then limit Pod to Perl 6 (which I thought was not
> the goal)? I doubt other languages will want to deal with this
> situation.

As Smylers so ably pointed out, enabling Pod to be parsed independently
of the underlying language syntax actually makes it vastly easier to use
Pod with other languages. All you need to do is insert a Pod-stripping
preprocessor (already written, as it happens) before the language's compiler...as, indeed, the Perl6::Pod does for Perl 5.


The bottom line is that separated Pod conforms to a single simple rule,
which makes it:

    * easy to teach:               "a = in column 1 is Pod"
    * not context-sensitive:       "a = in column 1 is ALWAYS Pod"
    * easy for humans to identify: "is there an = in the first column?"
    * easy for machines to parse:  "is there an = in the first column?"
    * easy to use:                 "put a = in column 1"
    * easy to avoid                "keep the = out of column 1"

I truly think it works better that way :-)

Damian

Reply via email to