In article <[EMAIL PROTECTED]>, Damian Conway <[EMAIL PROTECTED]> wrote:
[ First, I should note that whatever we end up with, that's the party line and that's what I teach, but before we end up there, I know from my years of experience teaching that certain sorts of questions are going to come up. I'm looking at this from the perspective of the student sitting in a class, not from the implementors perspective. ] > 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'm speaking at the programmer level, not the implementor level. For the guy in the trenches, this is a special case. This is more complexity for the guy typing code, even if it's easier syntactically for the guy writing the parser. > > 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. Well, it won't say that if it's not true, but until pretty recently it's been mostly true. > 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." And that's something that now comes up very early in teaching the assignment operator. > 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). > > 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. The start of a Pod comment now affects it's line and the ones following it. > > > 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. 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. I know you think it's easier to teach and explain, but that's because you came up with it. The notion that a special character in a certain column means something was tough to explain to other people in FORTRAN too. 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.
