Front page | perl.bootstrap |
Postings from July 2000
The 0.5 Release of Sapphire Is Available
Thread Next
From:
Simon Cozens
Date:
July 28, 2000 06:00
Subject:
The 0.5 Release of Sapphire Is Available
Message ID:
20000728215956.A4762@othersideofthe.earth.li
I said I'd announce what I'd be hacking on on Friday, and this is it.
This is the last I will say on the subject of Glib or other external
libraries.
http://perlhacker.org/~simon/sapphire-0.5.tar.gz
I wasn't able to hack on this as much as I wanted to over the past few days,
with the result that a few features that I wanted in there have not been
implemented yet. But, however, the 0.5 release of Sapphire is available.
OK, but what on earth is Sapphire?
It's important first of all to note what Sapphire is not. Sapphire is
emphatically NOT an attempt at Perl 6. Perl 6 will, hopefully, have a very
different architecture internally. With Sapphire, I have very deliberately
tried not to break any new ground at all. This is purely a proof-of-concept.
Sapphire is an implementation of the Perl 5 API using the Glib
library. I gave myself one week to see how far I could get, and to be
honest I didn't get as far as I liked. The following things are in:
* SVs, including conversion between PV/IV/NV
* AVs are defined in terms of g_pointer_array
* glib version 1.3, if you have it, will give you UTF8 support to
the level of Perl 5.6.0
I wanted to put hashes in there, but did not have the time. The SV/AV
stuff is separated out into libsvar - I sincerely hope that Perl 6
will take an extremely modular approach to internals design in the
same way as I have done here. This has allowed me to create a C test
suite test.c for the scalar/array library, completely distinct from
the rest of the API implementation. Since I've renamed a bunch of
internal functions, test_compat.c tests the compatibility interface to
the real Perl 5 API; this is another area in which I hope Perl 6 will
draw from Sapphire - breaking internal APIs is always avoidable while
wrapper functions and macros exist.
You'll notice that libre is empty. This is because glib 2.0 is aiming
to provide a complete Unicode-aware Perl-compatible regular expression
engine. To implement this, I need do precisely nothing.
In some places, Perl 5.6.0 is ahead of glib 1.3.0's Unicode support.
I'll be fixing that by contributing patches to glib to allow
character-level manipulation.
Another cool design feature to note is inline.pl. It's a very tortuous
piece of code, but what it does is transform inline functions into
macros. The idea is that you may then compile the code as macros
normally, or compile with -DEXPAND and have them expanded into inline
functions. This should give you debugging benefits without eliminating
any performance worries. Also, compiling with -DEXPAND can check for
syntax errors that compilation with macros can't; it means you can't
have lvalue macros, but that's a disgustingly confusing thing anyway,
so who cares?
It should be stressed that Sapphire doesn't do much. It's a proof of
concept, and proud of it. It's proving the usefulness of a modular
design. It's proving the usefulness of using existing libraries
instead of living in a vacuum. It's proving that glib rocks my world.
What am I going to do with Sapphire now? To implement the entire API,
I'd have to have a working Perl interpreter, which is not a small
challenge. Well, I may hack on it some more now for fun, but I'm not
sure what the point would be. It would teach me more about the Perl 5
internals, but they're about to go away. It would teach me more about
glib, which is certainly useful.
But the main point is, it's a proof of concept. It took me one week to
get to somewhere around the point that Topaz was at after two years. And
that's because I didn't try and reinvent every single wheel. There's good
software out there, folks. Let's use it.
--
SM is fun. ADSM is not.
"Safe, Sane, Consensual"... three words that cannot used to describe
ADSM.
- Graham Reed, sdm.
Thread Next
-
The 0.5 Release of Sapphire Is Available
by Simon Cozens