On Tue, Sep 11, 2001 at 12:15:37PM -0400, Ken Fox wrote:
> Simon Cozens wrote:
> > On Mon, Sep 10, 2001 at 08:38:43PM -0400, Ken Fox wrote:
> > > Have you guys seen Topaz?
> >
> > I may have heard of it, yes.
>
> That's it? You're rejecting all of that work without
> learning anything from it?
You may also have heard of the British art of ironic understatement.
> In general I think Parrot is missing critical abstractions.
> The string/buffer relation is one.
Who says we don't have one? The memory management hasn't been
finalised, and the string vtables haven't been completed. So the
strings can very well end up allocating from buffers.
If you're willing to provide a patch, that is.
> Others are the use of stacks in the interpreter and the dispatch of opcodes
> in runops(). This code is going to be very difficult to work with because
> assumptions of the data structures are made in lots of different places.
Please be more specific.
> IMHO this is the main reason why Perl 5 is difficult to
> understand -- and Parrot is repeating it.
It looks like all the work I'm putting into documentation is wasted. :(
Perhaps you'd like to help me out with some more?
> My point is that a "void *" API turns off all compiler
> type checking -- it's unsafe as a public API.
If you can get a compiler to type-check a string buffer as being
valid UTF8, I'm all ears.
> I have looked
> at string_make() and it doesn't do any special processing
> based on encoding. It *requires* that the raw bits are
> compatible with the encoding.
That's right!
> > No, that's a really bad way to do it. We can special-case
> > things like UTF16 to UTF32.
>
> Ok. Are you planning on compiling in all the encodings
> or can a module dynamically load one?
Compiling in. It's only 12 functions, max.
Simon
