Front page | perl.bootstrap |
Postings from July 2000
> >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