> >I admire micro-kernel-type systems. C and Java give you no functions out of
> >the box. Keywords are just that, keywords. I believe python is like this
> >as well. The idea being that everything has to come from a module.. This
> >limits how much a new developer has to learn, and it doesn't pollute the
> >global name-space pool.
Tom Christiansen wrote:
> A very long time ago, when Perl first came out, people would try to make
> Perl "just like C". That today the impetus is toward Java is still really
> the same story. Fortunately, Larry didn't do it then, and I don't see it
> happening now.
I would like to chime in quickly on this thread to note that having lots of
stuff in the global namespace/core is not a problem from the "JVM port
camp". I went down this road when I started working on the JVM port saying
to myself: "Darn it, if the Perl core was just smaller, this would be so
much easier."
I decided then that the JVM port must be done in subsets. (One reason being
that if you want to target a tiny embedded JVM in a wrist-watch, you can't
ever really have all of Perl anyway).
I see the Perl->JVM compiler having a list of well-documented options that
say: "Ok, if you want this set of core features turned off, then use this
option".
To make this possible, the internals simply need a way via an API for a
back-end porter to tell the front-end that certain keywords are forbidden.
That way, the user can get messages like:
"Sorry, you told me on the command line you wouldn't use core socket
support, but you appear to have done so in the program. Thus, your
compile failed."
And, the more we of these we can catch at compile time, the better.
Shouldn't be too hard, I don't think.
Perhaps it would be better to have Perl support all of perlfunc(1) in the
core still, but allow users to turn subsets off?
Or, perhaps the core functions could be syntactic sugar for access to
modules, and have a transformation happen automagically in the parser? (My
gut says "here there be dragons", but they don't seem like dragons that are
unslayable.)
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
