This message is about design matters for "Muldis Rosetta Example Engine" (MREE),
which is to be the self-contained reference implementation of my Muldis D language.
As of last month, my plan was to implement MREE in pure Perl 5 for now, and then
within a year port that to Perl 6, after which point both versions would be
maintained together.
But now, my current intention is to try doing those 2 versions simultaneously
instead, which would be very similar to each other in design.
Part of the reason for this new plan is that the first "Rakudo Star" release is
imminent, now being promised for this July, and not later than July 29th. See
http://use.perl.org/~pmichaud/journal/40407 for details on that.
In short, Rakudo Star is a Perl 6 distribution series intended to be usable
right now by end users; it bundles together recent versions of the Parrot
compiler toolkit / VM and the Rakudo Perl 6 compiler (each of which separately
have their own monthly releases) which are known to work well together, in a
single installation, so it is as simple to install and use as other programming
language implementations that come in one package.
Given that I already intended to delay starting on MREE until around August, the
ducks should be sufficiently in a row by then that it would be possible for me
to start my development simultaneously in Perl 5 and Perl 6 versions, each
targeting a specific sufficiently-polished Perl implementation that is intended
for end users and hence ought to be sufficiently complete to get something
working on.
Another reason for this dual-version approach is that I had already intended for
a large part of Muldis D to be written in Muldis D, that is make the language
partially bootstrapped, same as is the current process for Perl 6 itself.
Muldis D is designed to support this. And so, I could potentially write about
80-90% of Muldis D just once and have that shared by both the Perl 5 and Perl 6
implementations (and by any further implementations in other languages).
Of course, any implementation could implement much more or all of the language
natively, but that would simply gain performance, not to make it run at all, the
latter being more the goal of a reference implementation. Also the partial
self-hosting helps to make the language more self-documenting, and demonstrate
directly how most operators can probably be logically reformulated as different
combinations of others.
Another reason to do the Perl 6 now is that Perl 6 would include a much nicer
parser / grammar engine than is otherwise available, and I could write a Muldis
D parser in it much more easily than otherwise. In fact, the PTMD_STD grammar
in the language spec is 90% the same as what the Perl 6 grammar engine takes
already.
And so, since Muldis D has multiple layers of nested grammar, where outer layers
are just alternate syntax for inner layers, I could use the Perl 6
implementation to help bootstrap the Perl 5 one.
I could write the initial 80-90% using the tersest Muldis D syntax that needs
all of the grammar to parse, and then Parse it in Perl 6 and have the Perl 6
generate the equivalent Muldis D code using just the more verbose inner grammar
layers whose parser is much simpler, and then the Perl 5 version can then use
that initially for its partial bootstrap, so its other parts can be fleshed out
and made working and then I can work to beef up Perl 5's grammar support a bit
later.
Similarly, I could start writing a common test suite in Muldis D code for both
implementations to use in common, and when starting off, the Perl 6 version can
translate the initial terser syntax into the more simple syntax, so to test the
Perl 5 version, until it catches up.
But we'll see; the Perl 5 parser may not take too long to do all the layers.
Also, Perl 6's native distinct scalar types like Int, Rat, Str, Blob, etc
already directly correspond to Muldis D's native unlimited-size values, so I
have less indirection or compromises-for-speed to do there than in Perl 5.
So, in summary, I would initially target MREE to run on Perl 5.8.1+ plus Moose
on the Perl 5 side (though I would develop it on Perl 5.12.1+), and target
whatever the latest Rakudo Star is at the time on the Perl 6 side. For the Perl
5 version, I would skip 5.10.x for minimum versions; it will support 5.8.x for
as long as reasonably possible, and then skip straight to 5.12.x.
Both versions would, of course, use the same database file formats.
Also of course, the Perl 5 version is the more important one in the near term
since that is still by far the most heavily used application language.
So that is my current thought on the matter.
-- Darren Duncan
_______________________________________________
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
