develooper Front page | perl.bootstrap | Postings from July 2000

Re: The 0.5 Release of Sapphire Is Available

Thread Previous | Thread Next
From:
Tim Jenness
Date:
July 28, 2000 11:44
Subject:
Re: The 0.5 Release of Sapphire Is Available
Message ID:
Pine.LNX.4.21.0007280836310.30117-100000@lapaki.jach.hawaii.edu
On Fri, 28 Jul 2000, Simon Cozens wrote:

> 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

This looks  interesting.

>    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 think you've shown such a thing is doable and I agree that use
of external libraries should be seriously considered. It's probably too
early for implementation discussions but it seems that some kind of
"statement of intent" would be useful early on in the internals design to
clarify whether perl6 is to be written entirely self-contained from
scratch or whether external libraries can be used *in prinicpal* (LGPL
seems to be fine, you just have to force people to install it themselves
before installing perl and each library has to be examined in terms 
of portability, upgradability and performance). Once this is agreed the
glib issue will sort itself out.


>    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.

It seems a shame that the glib people are embarking on a rewrite of the
Perl regex engine at the same time as "we" are embarking on a rewrite of
the Perl regex engine. Any chance that we could join forces with them 
and come up with a perl regex library? (assuming, of course, that they
were happy with this particular part having the Artistic licence).

-- 
Tim Jenness
JCMT software engineer/Support scientist
http://www.jach.hawaii.edu/~timj



Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About