At 12:15 PM 9/11/2001 -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? Building strings on buffers
>looked like a really good idea.
If you're speaking of multiple buffers for a string or something like that,
you're looking at too low a level. That's something that should go in the
variables, not in the string bits. (We do *not* want all string ops slow to
support flexibility of this sort. Only the bits that need it)
>In general I think Parrot is missing critical abstractions.
>The string/buffer relation is one.
Well, we are putting an extra layer of abstraction in here. The string
abstraction's something we don't have in perl 5, certainly not to this degree.
>Others are the use of
>stacks in the interpreter and the dispatch of opcodes in
>runops().
So what's wrong with this?
>This code is going to be very difficult to work
>with because assumptions of the data structures are made
>in lots of different places.
>
>IMHO this is the main reason why Perl 5 is difficult to
>understand -- and Parrot is repeating it.
Perl 5 is difficult to understand for a number of reasons. Some of those
are inherent to interpreters, and those folks will just have to deal with.
> > > The other major suggestion I have is to avoid "void *"
> > > interfaces.
> >
> > I'm using void * to avoid char *. :)
> > ...
> > Look at the code for string_make. If you're already
> > passing *in* a UTF32 buffer, why do we need any special
> > processing for UTF32?
>
>My point is that a "void *" API turns off all compiler
>type checking -- it's unsafe as a public API.
Compiler type checking isn't going to work for us at this level--we'd need
runtime checking for it to work properly.
>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.
This is a first cut, and things will change. But requiring internal
consistency isn't unreasonable. You make sure things get checked properly
going in, but once they're in you can assume they stay correct.
>A really nice interface
>would type check the arguments when making strings so
>that a user sees a type mismatch error when compiling.
Right. That's a place for either the assembler or the compiler to complain.
*Not* the interpreter, as a general rule.
>Ok. Are you planning on compiling in all the encodings
>or can a module dynamically load one? You might want a
>slow-but-standard encoding conversion algorithm anyways.
String encodings will be dynamically loadable. I'm going to add
documentation for those ops in soon. (I was hoping today or tomorrow, but
things are kinda screwy here at the moment)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
