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

Re: Working Group Proposal

July 24, 2000 10:38
Re: Working Group Proposal
Message ID:
> >Sure,
> >it might make _p_erl faster and leaner, 
> Actually it probably would not make that much difference to '_p_erl'.

How about in the designing/creation of a compiler? How about in creation of 
IDEs with syntax coloring && intellisense types of things? Some may not care 
for them, but large groups of people do...

> >but if we have to pay a price in
> >Perl, is that worth it?
> >
> >> I would go even farther, and say that there should be three levels of LALR 
> >> grammars - one for microperl, one for miniperl, and one for perl itself. 
> I don't think so - the grammar just says what constructs are supported.
> i.e. you can call subs - not which subs you can call. 
> I don't think we want microperl to not have 'unless' if perl6 does.

Ok, I guess my concern is being able to embed perl inside of other applications,
and the memory cost of doing so. ( ie: the scalability problem ).

And yet ANOTHER concern is the existence of various holdovers from perl4, stuff
like getservbyname which really has no right to be in the core proper. 
( ie: the legacy problem ).

And, on the other side of the coin, another concern about perl5-porters 
was the inability to add stuff to the core without going through a huge tug of 
war. ( ie: the immutability problem )

And finally, the fact that perl didn't natively support certain protocols 
(http comes to mind) and needed external programs to bootstrap itself (lynx,
ftp, etc inside of CPAN) ( ie: the portability problem ).

I think we need a method to make perl both really small and large at the same 
time.   I'm open to suggestions, but I think that being big and monolithic 
has a lot of drawbacks if perl is to spread.. Linux does it right, I think, by 
allowing modules to be imported/exported from the kernel at will.

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