Front page | perl.bootstrap |
Postings from July 2000
> > Horos <horos@earth.he.net> writes: > >> >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... > > Which would all benefit from having a formal grammar - but the question > was how it would affect 'perl' (the program) - and my answer was "not much". > > > > >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 ). > > The grammar constructs that are allowed have little impact on that - it is > the code behind the operators etc. that costs. > > > > >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 ). > > Right - that is what is different about perl6 - Larry has said we can > rationalize those this time where he did not allow himself to do that > with perl5. > > > > >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 ) > > Right again - so this time we try even harder to make modular additions > possible - perl5 made a major jump in this direction but there is scope > for more. > > > > > >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 ). > > Which is the inverse of the above - on the one hand the "core" should > not have getservbyname() let alone HTTP/FTP "built in" - on the other > the "distribution" should be self contained. > > > > >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. > > Which is what all the "in the core" debates were about - do it as a module > not in the core. Then we have debates about which modules are bundled. > > -- > Nick Ing-Simmons >