Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

native 'str' type unspecced, undocumented, and ill-defined #6544

Open
p6rt opened this issue Sep 22, 2017 · 4 comments
Open

native 'str' type unspecced, undocumented, and ill-defined #6544

p6rt opened this issue Sep 22, 2017 · 4 comments
Labels
RFC Request For Comments

Comments

@p6rt
Copy link

p6rt commented Sep 22, 2017

Migrated from rt.perl.org#132148 (status was 'open')

Searchable as RT132148$

@p6rt
Copy link
Author

p6rt commented Sep 22, 2017

From @skids

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.

@p6rt
Copy link
Author

p6rt commented Sep 28, 2017

From @jnthn

On Fri, 22 Sep 2017 16​:40​:35 -0700, bri@​abrij.org wrote​:

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.

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.

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.

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).

@p6rt
Copy link
Author

p6rt commented Sep 28, 2017

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Sep 28, 2017

From @geekosaur

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

@p6rt p6rt added the RFC Request For Comments label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
RFC Request For Comments
Projects
None yet
Development

No branches or pull requests

1 participant