Re: SvPV*
At 05:04 PM 11/21/00 +, Nicholas Clark wrote: >(I'm not sure if I've missed all the fun here before I subscribed, but >I can't anything on the RFC list that mentions the following) > >perl5 has a tangle of SvPV macros to allow C code to get a pointer >to the scalar. (or the "private", with or without the length, and >more relating to utf8 that don't even appear to be documented) > >Has any thought yet been given to the API to get scalars? Yup. The internal details will be hidden from the extension writer--if you do a get_string(PMC, UTF_8) you get back the UTF-8 encoded version of the scalar that PMC represents, regardless of any internal format. That way if some scalar function writer has some need to do odd things they can without having to worry about telling extension writers. It also means that an extension doesn't have to care that a PMC represents, say, a complex number--they ask for it in UTF-8 format and get back "4 + 3i" and that's fine. This isolation will also reduce cross-version breakage. While I'd like to eliminate that, I doubt it's entirely feasable. It'll be possible to get the gory details if you want them, but then you'll have to go a step lower in the API and, well, the docs say "Here there be dragons". Or they will, at least. One of the things we need to hammer out on the extension API list is exactly what sorts of things need to be generally exposed to extensions and what don't. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: SvPV*
On Tue, Nov 21, 2000 at 05:04:32PM +, Nicholas Clark wrote: > (I'm not sure if I've missed all the fun here before I subscribed, but > I can't anything on the RFC list that mentions the following) > > perl5 has a tangle of SvPV macros to allow C code to get a pointer > to the scalar. (or the "private", with or without the length, and > more relating to utf8 that don't even appear to be documented) > > Has any thought yet been given to the API to get scalars? > > Jarkko posted an idea on p5p of "Virtual Values" which would permit a > scalar to point to another scalar's buffer, rather than its own. That was the other half, yes. The other half was it that a VV would point to a 'window' or 'slice' of the other scalar's buffer, not necessarily the whole buffer. > Currently the perl5 API assumes that you get a read-write pointer, and that > the thing it points to is "\0" terminated. This makes it hard to implement > copy on write, or to allow a pointer to a sub-length of the parent > scalar's buffer. What he said. > IIRC Ilya mailed p5p bemoaning the fact that perl's SVs use a continuous > buffer. A split-buffer representation (where a hole is allowed in the > middle of the buffer data) permits much faster replacement type operations, > as there is less copying, and you can move the hole around to suit your > needs. Yet another bummer of the current SVs is that they poorly fit into 'foreign memory' situations where the buffer is managed by something else than Perl. "No, thank you, Perl, keep your greedy fingers off this chunk. No, you may not play with it." -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
SvPV*
(I'm not sure if I've missed all the fun here before I subscribed, but I can't anything on the RFC list that mentions the following) perl5 has a tangle of SvPV macros to allow C code to get a pointer to the scalar. (or the "private", with or without the length, and more relating to utf8 that don't even appear to be documented) Has any thought yet been given to the API to get scalars? Jarkko posted an idea on p5p of "Virtual Values" which would permit a scalar to point to another scalar's buffer, rather than its own. Currently the perl5 API assumes that you get a read-write pointer, and that the thing it points to is "\0" terminated. This makes it hard to implement copy on write, or to allow a pointer to a sub-length of the parent scalar's buffer. IIRC Ilya mailed p5p bemoaning the fact that perl's SVs use a continuous buffer. A split-buffer representation (where a hole is allowed in the middle of the buffer data) permits much faster replacement type operations, as there is less copying, and you can move the hole around to suit your needs. So I was wondering if perl6 was going to replace SvPV* with something that allows the caller to say whether they'd like * read only or read write * buffer all in one block or can cope with a hole (plus tell me where it is) * null terminated buffer or don't care and possibly * data must be in utf8 or tell me what the data is in although this might be better done as caller specifies 1 or more acceptable encodings they could cope with, and SvPV* returns data in whatever requires least work to translate consistent with maintaining accuracy. In particular specifying read/write versus read only would allow perl to treat scalars as copy-on-write which would mean things like $a=$b wouldn't actually copy anything (wasting time and (shared) memory pages) until either $a or $b got changed. [I have this feeling that there's a bit of this already in sv.c, but I'm not sure how much] Nicholas Clark
Re: Guidelines for internals proposals and documentation
At 02:45 PM 11/17/00 +, David Grove wrote: >Dan Sugalski <[EMAIL PROTECTED]> wrote: > > > At 10:19 AM 11/17/00 -0800, Ken Fox wrote: > > >However, I don't want to see early (premature) adoption of fundamental > > >pieces like the VM or parser. It makes sense to me to explore many > > possible > > >designs and pick and choose between them. Also, if we can keep >external > > API > > >design separate from internal design I think we'll have more wiggle >room > > >to experiment. (That's one of the big problems with perl 5 right now.) > > > > That's one of the reasons I'd like to work on the APIs first. I realize > > > that doing even that will have an effect on the design of the pieces > > behind > > the APIs, but we have to startsomewhere. > >But.. but... but... we don't even have a design spec. I mean, we don't >even know for sure what Perl 6 is going to look like for certain, inside >or outside. Wouldn't we have to know the outside before we try to put the >insides together? No, not really. For the actual code we will, of course, but there's a lot we can do now. (And a good part of the parser could still be written now, since most of the changes will likely be reasonably trivial) The APIs perl presents to the world are pretty much independent of the language. For example, we can take a good stab at the extension API now--regardless of how the language looks, extensions will still need to get and set scalar, hash, and array values. Perl would have to change a *lot* for that to be no longer valid. The API presented to an embedding programs similarly can be worked on--the fact that the language might change doesn't alter the syntax of the run_perl_code() function. (or whatever we call it) We also do have, generally speaking, a picture of both perl (since Larry has said we're not gutting the language entirely) and the internal structure. I've been a bit lax in presenting that internal picture, but I'll fix that in a little bit. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
