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


July 24, 2000 12:10
Message ID:
> While I don't really object to the idea, I don't see that much of a
> benefit either. But I can see the people who are in the PR camp object.
> One of the perceived problems with Perl is that the more than one way
> to do it makes Perl hard and complex. Pluggable lexers/parsers takes
> this to the extreme.

Well, I'm not that hot on the idea of pluggable lexers/parsers; the only 
benefit that I could see is if the pluggability could somehow scale down (or 
scale up) perl. 

Again, I'm going to call on the linux model, because arguably the linux model
is the most successful at extensibility; linux is everywhere from embedded 
chips to supercomputers. Linux has a core and modules that are added/subtracted
from that core. But the main point is that Linux's core is *small*.

So what we have to consider is perl's 'core'. So far, what has been passed 
along as perl's core is far too large, and has become to some extent archaic.

So what makes perl perl?  Well, one could argue strongly that perl's syntax
makes perl perl (as well as a few ubiquitous functions).   If we take away 
perl's syntax then, I think we take away perl's core, the adhesiveness that 
binds perl together.

However, that doesn't mean that perl's syntax can survive in its current form.
There has to be a tradeoff between the syntax and the embeddability and 
portability of perl. The best way to make something embedded is by making it
regular, clean, and clear; I believe that LALR is the best way to achieve this..

And who knows? If perl is designed correctly/regularly, perhaps pluggable 
lexers/parsers may come as a side effect...

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