brian d foy wrote:
> Whereas the rule you have to teach under the Integration model is:
We don't teach any rule under this model, and it's been fine for over a
decade :)
When we do teach the current Pod, the simple rule is that Pod starts:
* when Perl is expecting a new statement
* there is a =something at the beginning of the line
Which is considerably simpler than the long rule list you used to say
the same thing (which seems a bit of FUD, honestly).
Agreed about the parenthetical. From my perspective, the proponents
of the Separation Model are overstating the difficulties inherent to
the Integration model. That said:
By the rule you give above, Pod Sections cannot be embedded in the
middle of statements. For example, given:
if
a = 5
{
say "ouch!"
}
you couldn't insert a Pod Section between the first and second lines,
or between the second and third lines. From a guy-in-the-trenches
perspective, this isn't a problem; interrupting an instruction
mid-stream in order to talk about it is very bad form. Still, it's a
restriction that Damian's Separation model lacks.
> > 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:
> 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.
That's not really the case. The # only affects one line, and a pound in
a literal string doesn't start a comment. People grok single line
comments very well.
With the advent of block comments, this isn't as true as it used to
be. In fact, I expect that some people will have to take a moment to
wrap their heads around the notion that you ignore everything that
follows the closing bracket on the last line of the block quote. That
said, I don't expect there to be much of a learning curve here.
Still, it may be worth it to state that a line that starts with '#'
followed by a closing bracket is _not_ commented out (although said
character sequence should be stripped out of the line). Less
cognitive dissonance that way.
The start of a Pod comment now affects its line and the ones following
it.
...also not much in the way of a learning curve; in fact, I expect
that people will grok Pod Sections more readily than they will grok
block comments as currently written.
Well, easy to use Pod with other languages until they try to use the
assignment operator at the beginning of the line, or a = in a literal
string at the beginning of a line.
...or you're dealing with a language that assigns special meaning to
lines that begin with '='.
You are not going to be able to make Pod completely orthogonal to the
code that it's embedded in. You can come close (and IMHO you come
_very_ close with the Separation model that you're discussing), but
there will always be some sort of constraint placed on the code into
which you're embedding Pod.
There are other things to consider, and to me it looks like this design
decision isn't based on what's easier for the Perl 6 programmer but
what's easier for the implementors. It's not that I don't understand
both sides, I just disagree about where the complexity should be.
Thank you, Brian. That's exactly the sense that I've been getting
from the explanations being given.
Which is not to say that there isn't a time and place when ease of
implementation should trump ease of programming; taking an extreme
example, being able to write a program that consists of the single
line:
attend my every wish
is the ultimate in terms of ease of programming; it's also impossible
to implement, barring the invention of mind-reading hardware and
sapient artificial intelligence software. If a small increase in the
programmer's learning curve is the price that must be paid to achieve
a massive reduction in the implementor's workload, it may very well be
worthwhile to foist some of the complexity onto the programmer.
The question is whether or not this is one of those cases.
--
Jonathan "Dataweaver" Lang
