At 01:35 PM 9/11/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > 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)
>
>I think of buffers as more primitive than strings.
That's OK, I don't. :)
>They are segments of
>bits. They can be copied, extended, garbage collected, etc. They don't
>have character encodings. A string is just a buffer with a few more
>semantics.
Strings and buffers are mildly different or the same, depending on how you
look at them. They ought not be conflated, really.
And, honestly, there's nothing to stop you from adding a buffer type if you
don't like what we've got. :)
>Perhaps you intend to make parrot_string.bufstart hold a buffer structure.
No, I don't. It points to a chunk of memory. The encoding library
associated with the string type knows what sort of data's there and its format.
> > >Others are the use of
> > >stacks in the interpreter and the dispatch of opcodes in
> > >runops().
> >
> > So what's wrong with this?
>
>Lots of duplicated code in register.h. We really need a stack template.
Oh, good grief. This is version *0.01*! Sheesh, not everything is going to
look like Hemmingway writing C.
>The interpreter knows the internals of the stack structure and is
>responsible for managing it.
No, it doesn't. The opcode functions do. The interpreter knows nothing to
speak of about the format of the stack, and even if it does so what? It
*should*. The stack is part of the interpreter.
>To change the stack implementation, we'll
>have to carefully examine all the interpreter code.
No, we won't. We change some opcode functions. So?
And deep carnal knowledge of the interpreter guts is just fine for other
parts of the interpreter. Putting walls in at this level gets in the way in
performance far more than the abstraction would help people writing code.
>The semantics of
>the stack aren't real clear either. For example, when changing the
>stack code what invariants must be preserved? If the stack had an API
>the interpreter used I think this would be much clearer.
It might, the code's still young. It might not, too. That's fine as well.
>runops() is hard-wired with assumptions on the ops. What if we want
>to generate a switch-based runops()? How much code is going to make
>the same assumption that runops() does now? runops() should be generated
>similarly to the opcode table.
You must have missed that part of the discussion. This has always been part
of the plan, with the actual core being platform dependent for performance
reasons. (Switch isn't faster everywhere)
>There should be an API for calling ops
>so we don't have to jump through the same hoops required for perl 5.
There will *always* be hoops non-interpreter-core code needs to jump
through to call ops. In fact, no non-interpreter-core code should *ever*
call an op. Ever.
> > Compiler type checking isn't going to work for us at this level--we'd need
> > runtime checking for it to work properly.
>
>I'm talking about the interface between Parrot and user code -- the
>XS layer in Perl 5.
You're looking in the wrong place. We haven't written *any* code or
documentation on how extensions should interface to the core. This is all
interpreter-guts-level stuff, and no extension should *ever* call it. I may
well randomly generate structure offsets and such at build time to make
sure nothing does.
> > 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)
>
>Simon just said the opposite. Does this mean that the C and Unicode
>encodings will be built-in and everything else dynamically loadable?
No, it means Simon and I haven't talked this out yet. All string libraries
will be potentially dynamically loaded. You'll probably get one or two
built in.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
