Re: Random questions...

[Dan Sugalski]

At 1:52 AM -0800 2/5/03, David wrote:

Wow, Parrot has certainly made a lot of progress since I've last looked at it.

I see Leo's answered a bunch of this already, but since I'm digging through my mail, I'll do it as well.

1. How do you handle variant (either string or numeric) data? Do you set up
one of the string registers with a string "ssnnnnssnnnn" to keep track of
datatypes?

? I'm not sure what you're talking about here. If you mean data that's almost but not quite a builtin string/int/float, then you'd use a custom PMC class. If that's not what you mean, then I'm not sure.

2. What happens if a routine needs more than 32 variables of one datatype? Do
you use hash tables? (Sounds like Lua)

If you're passing it in (as a sub call) the overflow goes in a stack segment. Inside routines things get pushed and popped onto the stack.

3. What about variant arrays? Hash tables again?

? Probably with a custom PMC class.

4. What's a frame? (ex: push_p : Push the current frame of the PMC...)

A register set--all the int, string, float, or PMC registers. Each register set has a separate backing stack, and when you push a frame you push all the registers of a particular type onto their backing stack in one go.

5. How are pointers from DLLs handled? For example, I might have a DLL routine
which returns a pointer of some flavor, or expects pointers as parameters. Is
there a 'void *' PMC?

Either unmanagedstruct or managedstruct objects. And if those aren't enough, we can build another PMC class that works. (I expect we'll have a PMC class that holds a struct pointer put can pull fields out by name at some point)

6. What's a "scratchpad?" Is it different from a "pad?" What are they used
for?

Holding lexical variables for a scope.

7. How are pad *descriptors* created? They are specified in the constant area
of the bytefile, but it's not clear how they get there. Then again, I'm not
entirely clear on what they are, either.

8. How do you store things in non-global pads? There is a store_global opcode,
but no store_lex opcode.

There is a store_lex opcode, amongst others. I see PDD06 desperately needs updating. The docs are in core.ops, and if you have perl installed you can use perldoc to extract and read it. (Or the other pod tools, such as pod2html) It'd look like:

perldoc core.ops

9. Is there a substring op? If not, how do you get a substring?

Yup--substr.

10. I didn't see any equality (eq, gt, le, etc.) opcodes for comparing values.

They're in there too.

11. There's no opcode for supporting a for loop?

Who's for, C's or perl's? C's for doesn't need an opcode. Perl's arguably might, but I think we'll be better off putting the count of things into an I register and iterating through the list as an array.

12. There's a string to number op, but no number to string op?

Should be. If not, we should fix.

I've also got a couple questions related to the byetcode file format. These
are more idle curiosity:

1. Was there a compelling reason to mix the strings and numbers into the
constant section, instead of creating a seperate string and numeric section?

Well... Hysterical Raisins. That arguably should be fixed.

2. Are duplicate values (strings, numbers) consolidated in the data section?

If they're not now, they should be.

3. Why store numbers in binary format instead of text format? Doesn't that
limit precision?

It avoids conversion loss. Besides, it's faster, and that's the point. :)
--
                                        Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk