develooper Front page | perl.bootstrap | Postings from July 2000

Re: Working Group Proposal

Thread Previous | Thread Next
Bennett Todd
July 20, 2000 12:29
Re: Working Group Proposal
Message ID:
2000-07-20-15:00:13 John Porter:
> Bennett Todd:
> > Has Python indulged in non-backwards compat more than Perl? 
> No; but it is considerably more recent, [...]

That's an advantage and a disadvantage. The disadvantage was that it
means they are forever playing catch-up, unless they can seriously
expand their working tools base faster than we can grow CPAN --- or
unless we decide to toss CPAN and start over from scratch.

The advantage is of course that they got to take a fresh look at
language design. However, that edge didn't buy 'em that much, since
lwall promptly swiped all the tasty bits and stuffed 'em into

> [...] and was also more carefully designed from the outset.

That I disagree with utterly. It was designed in a different
fashion, by a designer with a very very different style. Perl has
enjoyed the most exquisitely careful and expert design from the very
beginning. It just wasn't design by an academic computer-science
purist, is all. That's where its lovely fluid expressiveness comes

There's actually a language out there that has that edgy
computer-science purity of bodily fluids, while enjoying a
surprising amount of perl's expressiveness (it appeals to me better
than Python that way, at any rate), and that's Ruby.

> The resemblance could be close enough that converting a perl5
> program to a perl6 program could be a trivial, or automatable,
> task. But I believe that this is a good opportunity for things
> that are broken to get fixed -- and if bw-compat is lost
> sometimes, so be it.

If backwards compat is so broken that it makes it a bad choice to
write the first implementations of perl6 in perl5 --- more
precisely, in the dialect and style that lies in the intersection of
the two languages --- then the gap is too big to hope for much
backwards compat, much salvaging of our accumulated work from CPAN.
Lose CPAN and we're just another competitor in a very populous
field. Perl defined that field, it'd be a shame for us to step to
the back of the line.

> > What sucks, that requires completely breaking any hope of
> > backwards compatibility to fix?
> First and foremost, the proverb that "nothing can parse Perl
> except perl" must be rendered null and void.

Why? If you want easy-to-parse, there are a lot of languages out
there for that. The winner and champion has of course to be scheme
or one of the other lispoids, but there are plenty of more
conventional-looking choices as well.

However, as far as I know, the very essential nature of
perl that distinguishes it from all other languages,
its basis in allowing diverse expressions of various
natural-language-inspired idioms, is not compatible with
easy-to-parse-with-table-driven-BNF-defined-parser. Failing to be
a trivial yacc hack doesn't necessarily qualify as a problem that
requires fixing. If it _did_ require fixing, then the next question
would be, why not just jump ship and join the Ruby camp. That's the
cleanest, handsomest effort I've seen to render a language that
works like Perl on a more classical CS foundation.

> This, I presume, would entail changes to the grammar that would
> likely have the effect of breaking bw-compat.

Well, if it made it a better language to program in, then at least
I'd be interesting in hearing more about what you have in mind, but
I've yet to hear someone offer an approach to making a toy parser,
the kind that computer science researchers love, parse a language
that offers the comfortable expressiveness that distinguishes perl.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About