Simon Cozens <[EMAIL PROTECTED]> wrote:
> Patches welcome.
Well, this isn't a patch, but if you really meant patches literally and not
figuratively, I can provide one if you let me know. ;)
> Of the suggestions that have been advanced so far, four are worthy of
> more consideration: C, C++, Java and a specially-designed Perl
> Implementation Language. (PIL)
> Java is portable and gives us OO, but it's slow and ugly.
I am probably the biggest proponent of the "use Java to implement Perl"
camp.
And, on this front, I would like to comment. First, "ugly" is a matter of
taste, and I don't think we should let that be a deciding factor. Every
programming language is ugly in one way or another.
As for "slow", this will be helped by GCJ, the new GCC 3.0 front-end for
Java. Java will compile to native code, via GCC.
GCJ is not yet ready for prime time, so I certainly understand reluctance on
building on infrastructure that isn't done yet. However, if we, as a team,
decide that Java is a real contender, I will volunteer to start monitoring
GCJ's progress. It might turn out that GCJ will be ready "just-in-time" for
us to use it to implement Perl. ;)
I know there is great resistance to requiring GCC, and I remember those
threads. I believe this was mostly from the VMS camp. So, is there a
native-code Java compiler for VMS?
> We need to think about the data structures that will replace SVs, HVs and
> AVs. I predict that such structures will be extensively used by the
> internals themselves, so they need to be fast and efficient.
One concern that I have about the data structure design thus far (and I
believe I wrote an RFC about this) is that we should try to resist the
temptation to "talk in C" too soon. Most of the ideas I have seen thrown
around are filled with C-isms. Of course, that's totally reasonable, if it
helps people think about the issues. However, I would like it to be
possible for a programmer of language Foobar to take the specification of
the data structures and implement them directly in Foobar without too much
trouble. The fewer C-isms in the high-level spec, the easier such a task
will be.
As the RFC 125 discussed, I think the interfaces for data structures and
other APIs to be somewhat object-oriented. Basically, something like:
An SV must answer the following methods:
UnicodeString toString() # returns the scalar value as Unicode string
ASCIIString toString() # returns the scalar value as an ASCII string
int32 toInt() # returns the scalar value as a 32-bit int.
or something like that.
> We seem to have settled on a vtable model for SVs, which is cool.
vtables are a strategy for implementing a particular OO-style interface.
I'd like to see higher level documentation developed before we get too far
into the detailed data structure design.
> Again, if we're going to make a Perl a platform for building languages,
> we need to make it easy to replace Perl's parser with a parser for other
> languages, and the way to do this is to have a clearly defined interface
> by which programmers can write their replacement.
I think this is very important. It is also important that the specification
of the Parser itself be clear. If the parser is to be written in a subset
of Perl, that subset must be somewhat clearly defined.
> =head2 Memory Allocation
> Memory allocation's pretty much a solved problem, so this shouldn't need
> to require much thought.
[...]
> =head2 Garbage Collection
I would like to note that GCC has actually switched to using garbage
collection to manage its *internal* data structures rather than a
traditional C memory management system. The GCC team has been pleased with
both the performance and ease of use.
The argument is: "Computers do a better job at memory allocation than humans
do by hand, so let the computer do it!"
I think we should give this idea some serious consideration.
--
Bradley M. Kuhn - http://www.ebb.org/bkuhn
PGP signature
