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. 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. PMCs might implement split strings or some higher abstraction
using several parrot_strings.
Perhaps you intend to make parrot_string.bufstart hold a buffer structure.
That'd be good, except that now parrot_string.buflen is not really owned
by the string anymore -- the buffer structure is probably going to need to
mess around with the string's internals. That increases the coupling between
buffers and strings. Coupling is bad. ;)
> >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.
The interpreter knows the internals of the stack structure and is
responsible for managing it. To change the stack implementation, we'll
have to carefully examine all the interpreter 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.
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. There should be an API for calling ops
so we don't have to jump through the same hoops required for perl 5.
> 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. Sometimes compile-time checking is possible. We
should try to take as much advantage of those situations as possible.
For example, in Win32 we *know* that certain things are 16 bit Unicode.
If we try to build a utf8 parrot_string with them, the compiler should
barf.
> 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?
- Ken
