Rename bitstype or isbits?

[simonster]

The naming here implies that isbits should return true iff the type was defined as a bitstype, but that hasn't been the case since the introduction of immutables. As a result, when one talks about a "bits type," it's not always immediately apparent whether they mean an isbits type or a bitstype. As one possible suggestion, HDF5 calls types of the kind defined with bitstype "opaque types."

[JeffBezanson]

Fair point. I don't think "opaque" is the right term though; to me that sounds like void*.

[StefanKarpinski]

"value type"? This is a tough naming problem.

[stevengj]

bitfieldtype?

[StefanKarpinski]

What are the exact criteria for isbits these days?

[yuyichao]

isbits(t::DataType) = !t.mutable & t.pointerfree & isleaftype(t) # reflection.jl

[quinnj]

Would it be worth considering a larger change to merge the two (immutable
and bitstype)? I believe @carnaval mentioned something about being able to
treat them more similarly through GC stack scanning?

i.e.
immutable 32 Int32 <: Integer

On Tue, Jun 23, 2015 at 2:53 PM, Stefan Karpinski [email protected]
wrote:

What are the exact criteria for isbits these days?

—
Reply to this email directly or view it on GitHub
#11822 (comment).

[ScottPJones]

I'd be against that, purely from an understandability POV. bitstype tells me that the 32 afterwards are bits.

[JeffBezanson]

Brainstorming:

primtype
bitstring
bitstringtype
atomictype
scalartype

[yuyichao]

I kind of like @StefanKarpinski 's value type since that's the condition that we can pass the object by value...

[StefanKarpinski]

It's also arguable that this is an implementation detail that may change so shouldn't be exposed at all...

[JeffBezanson]

since that's the condition that we can pass the object by value

I don't think that's true; we can pass immutable struct types by value as well. However this touches on an important point, which is that bitstype uses a different calling convention. The ABI can specify different treatment for int and a struct containing a single int.

[simleb]

What isbits is checking is close to C++'s POD (plain old data) structs. Should it be renamed ispod and bitstype would remain unchanged?

[StefanKarpinski]

ispod is a pretty good name.

[stevengj]

ispod seems really obscure to me; I'd rather rename bitstype if people feel this is a problem.

[johnmyleswhite]

ispod reminds me of Perl's POD, so I'm sympathetic to SGJ's feeling that it's an obscure name.

[ScottPJones]

bitstype matches what it does, so I don't think it should change, but isbits has been overloaded, maybe it should only be true for things that are bitstype, and another function with another name (sorry, ispod makes me think of a movie with Donald Sutherland! :grinning) should be added for the current meaning (maybe isprimitive?)

[simonster]

So far I think primitivetype (actually spelling the whole thing out) is the least ambiguous option.

[stevengj]

(To be honest, I think that naming conventions in an obscure corner of the language like this are relatively unimportant. But primitivetype as a replacement for bitstype sounds fine to me.)

[ScottPJones]

@stevengj I don't think though that primitivetype should replace bitstype, just isbits.

[ScottPJones]

👍 for primitivetype (to replace isbits)

[JeffBezanson]

primitivetype is a good name for bitstype, but not for isbits. isbits can be true of a complicated struct.

[ScottPJones]

So you'd have: primitivetype 32 ...? primitivetype sounds fine to me.
I just don't get a good feeling for isbits on a complicated structure, would somebody thing it's asking if something is a bit array? Is there another possibility that would be clearer?

[JeffBezanson]

Maybe something like isplaindata? Or ispointerfree?

[ScottPJones]

isplaindata sounds like a good idea (positive description), I think better than ispointerfree (negative description)

[StefanKarpinski]

I think I like ispointerfree the best despite the awkward negative in there. It's the only name that actually describes what the criterion means in a meaningful way. To avoid the negative we could have haspointers or ispointy and then just write !haspointers(x) or !ispointy(x) :-)

[carnaval]

well it also has to be immutable so pointerfree does not tell the full story, even if it is the most important criterion for this predicate. As it is now, this predicate is mostly a synonym of is_inlined_into_other_objects and can_be_stack_allocated, and I hope we will soon be able to relax this to include immutables with pointers in it, so that the isbits() thing is less useful.

[StefanKarpinski]

That's kind of my feeling – isbits is not going to be a good criterion in the fairly near future.

[JeffBezanson]

True, we might need more detailed predicates, but it is still very useful to check for "plain old data", whose definition is not so implementation-dependent. "Plain old data" is the right term here, it's just weird and ugly.

[StefanKarpinski]

Does that include immutability? Is POD necessarily immutable? This seems closer to "value type".

[JeffBezanson]

Yes, IMO that includes immutability, because otherwise the object's identity is effectively a separate piece of data not contained within the sizeof(x) bytes of the representation.

[simonster]

bitstype was renamed to primitive type in #20418