On Fri, Sep 03, 2004 at 11:41:05AM +0100, Tim Bunce wrote:
: On Thu, Sep 02, 2004 at 04:47:40PM -0700, Larry Wall wrote:
: >
: > =head1 Compact structs
: >
: > A class whose attributes are all low-level types can behave as
: > a struct.
:
: "all low-level types" or "all low-level *sized* types"?
: (I'm wondering about char arrays, string and pointers.)
I'm not intending to run this all the way into C madness. :-)
The problem with arrays, even arrays that are of fixed shape, is
that someone has to remember that shape, and in the case of a dynamic
language, that's not always going to be the compiler. So either we
have to find someplace related to the object to tuck an invisible array
header, or we force the programmer to keep track of lengths as C does.
I am presuming the former is the better approach. I really only care
if it's efficient to serialize to and from C structs, not whether the
in-memory representation is identical.
: I presume a char[n] array within a structure could be represented
: as an array of int8. That might be uncomfortable to work with.
Not a lot more uncomfortable to work with than in C. :-)
But I'm guessing the low-level C<str> type is a buffer of bytes. Probably
means we say
has str $s is bytes($n)
or
has str[n] $s
or some such.
: And that a pointer would be... what? Some platforms has odd
: sizing issues for pointers. Perhaps a "voidp" type is needed?
: (Which would just be an intN where N is sizeof(void*)*8.)
Eh, pointer? I don't see any pointers around here...but then I
haven't looked very hard on purpose...
: If a "class whose attributes are all low-level types can behave as
: a struct", is that class then also considered a "low-level type"?
: (So other structs can be composed from it.)
It should be easy to serialize.
: I think that's important because it allows you to avoid having
: to build too much into the base perl6 language. Semantics like
: turning an array of int8 with a string with or without paying
: attention to an embedded null, can be provided by classes that
: implement specific behaviours for low level types but can still
: be considered low level types themselves.
That's fine, but you have to expect the objects to keep extra info
around to manage some of the low-level types according to the desired
semantics. What this probably means is that objects might have extra
parameters that aren't expected to officially serialize/deserialize.
I don't profess to be an expert on that subject. I just want it to
be fairly efficient to interface to C and C++ libraries that return
structures. But only to the extent that it doesn't warp Perl into C.
I'm just trying to tell the implementors that they are allowed to
go as far as they reasonably can in that direction, as long as they
don't feel like they have to go unreasonably far. :-)
: > (Access from outside the class is still only through
: > accessors, though.) Whether such a class is actually stored compactly
: > is up to the implementation, but it ought to behave that way,
: > at least to the extent that it's trivially easy (from the user's
: > perspective) to read and write to the equivalent C structure.
:
: Is there some syntax to express if the struct is packed or
: needs alignment? (Perhaps that would be needed per element.)
Would be easy to specify with traits.
: Certainly there's a need to be able match whatever packing
: and alignment the compiler would use.
It only has to look like that. :-)
: (I'm not (yet) familiar with Parrot's ManagedStruct and UnManagedStruct
: types but there's probably valuable experience there.)
Quite likely.
: > That is, when byte-stringified, it should look like the C struct,
: > even if that's not how it's actually represented inside the class.
: > (This is to be construed as a substitute for at least some of the
: > current uses of C<pack>/C<unpack>.)
:
: Whether elements are packed or not for byte stringification is,
: perhaps, orthognal to whether they're packed internally.
Well, I don't know if it's 90° in practice because of efficiency concerns,
but in the abstract that's about right.
: Network i/o would prefer packed elements and structure interfacing
: would need aligned elements.
Presumably. I expect the default would be aligned.
Larry
