Skip Menu |
Report information
Id: 132148
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: bri [at] abrij.org
Cc:
AdminCc:

Severity: (no value)
Tag: (no value)
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [RFC] native 'str' type unspecced, undocumented, and ill-defined
Download (untitled) / with headers
text/plain 548b
We've had a native 'str' type for a while, and still have one even though NativeCall decided to go with Str and 'is encoded'. Currently it seems to just be a Str under the hood which has very few restrictions, other than not allowing binding to a Str. What exactly is a 'str'? Is it null terminated or does it know its length? Does it have an encoding? Roast indicates it knows how to take an assignment from a Str literal (but no literal is used that pushes any boundaries) and can be used in multi-dispatch and... that's really about all.
RT-Send-CC: perl6-compiler [...] perl.org
Download (untitled) / with headers
text/plain 1.8k
On Fri, 22 Sep 2017 16:40:35 -0700, bri@abrij.org wrote: Show quoted text
> > We've had a native 'str' type for a while, and still have one even > though NativeCall decided to go with Str and 'is encoded'. >
It's not native in the sense of same sense that NativeCall uses the word. Show quoted text
> Currently it seems to just be a Str under the hood which has very > few restrictions, other than not allowing binding to a Str. >
That's the wrong way around. A Str boxes a str under the hood, much like Num boxes a num. Show quoted text
> What exactly is a 'str'? Is it null terminated or does it know > its length? Does it have an encoding? >
Str uses the P6opaque representation. It's defined as something like: class Str { has str $!value; ... } This means it can support things like mixins. The `str` instance is what actually holds the string data buffer. It is always in NFG. Its representation is implementation-defined, but no implementation that provides it supports mixing in to it, which a high-level type like Str should support. So, much like num is an unboxed Num, str is an unboxed Str. It's used quite a bit inside of Rakudo, as it's what all the nqp:: ops for str use. However, there are user-level places one might wish to have it if dealing with a large number of strings. For example: my str @loads-of-strings; Will be far more compact in memory than: my Str @loads-of-strings; Since the latter stores a Scalar pointing to Str pointing to str, while the former is just a bunch of str. Show quoted text
> Roast indicates it knows how to take an assignment from a Str literal > (but no literal is used that pushes any boundaries) and > can be used in multi-dispatch and... that's really about all. >
I'm sure there's room for more tests, though given that it's on the inside of every Str, then its functionality is largely covered implicitly (and any method call on a str will box it to the Str object type to actually call the method).
Subject: Re: [perl #132148] [RFC] native 'str' type unspecced, undocumented, and ill-defined
From: Brandon Allbery <allbery.b [...] gmail.com>
Date: Thu, 28 Sep 2017 13:56:36 -0400
CC: bri [...] abrij.org
To: Carl Mäsak via RT <perl6-bugs-followup [...] perl.org>
Download (untitled) / with headers
text/plain 355b
Possibly the right thing here is for perl 6 to reserve the name for implementations, and otherwise leave it unspecced.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b@gmail.com                                  ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org