Rename isleaftype() to isconcrete()

[nalimilan]

For consistency, also change the C function jl_is_leaf_type() to
jl_is_concrete_type(). Replace (almost) all uses of "leaf" which mean
"concrete".

I have left unchanged several functions in src/typemap.c (sig_match_leaf, sig_match_by_type_leaf, is_cache_leaf, is_leaf_bound) and the leaf field of _jl_typemap_entry_t, since the "leaf" term seemed to make more sense there in the context of a type tree. Suggestions welcome.

Fixes #17086.

[StefanKarpinski]

To be completely explicit about it, I'd like to propose that we officially define concrete to mean the following: a type T is concrete if and only if there can exist an object x such that typeof(x) == T. There are some corner cases where x could exist but is not constructible (still counts for the sake of this definition), but I still think that's a pretty clear definition.

[omus]

Related to #17086

[nalimilan]

Thanks. Regarding the definition of "concrete", see in particular the table at #17086 (comment).

[nalimilan]

Looks like I missed non-lowercase occurrences of "lift". Will fix later, after leaving time for other comments.

[nalimilan]

Fixed. Though I've noticed that table is almost impossible to read online. Any ideas how to improve it? Is it possible to force text to wrap instead of going beyond the page limits? Or should we move to a bullet list instead?

[tkoolen]

I happened to notice yesterday that the jldoctest example is missing the closing ```: http://docs.julialang.org/en/latest/stdlib/base.html#Base.isleaftype.

[JeffBezanson]

see in particular the table at #17086 (comment).

Looking at that table is a good way to waste time and become confused.

[StefanKarpinski]

Is there any practical reason to need to distinguish any other meaning of "concrete"? The meaning I've proposed maps well onto whether a field of a type can be stored inline assuming it is a bits type. When would you need any of the other meanings? In particular, the meaning by which Complex is "concrete". Is there any useful, non-internal application of that meaning?

[JeffBezanson]

I'm fine with this renaming, but note that as it is we'd have isconcrete(Type{Int}). Changing that would require a detailed review of all uses to see which ones care about this.

[StefanKarpinski]

Under what theory of concreteness is isconcrete(Type{Int}) true? I'm just curious.

[tkelman]

closing triple backtick missing here, as mentioned by @tkoolen

[nalimilan]

See new commit.

[JeffBezanson]

It's concrete in the sense that you have enough information about the value to do dispatch. Type{Int} is not itself the tag of a value, but the tag can be determined from it. Or put differently, it's the maximum amount of information about a value the type system can express.

This is probably part of why we used the term "leaf type"; if not for that we might have called this "concrete" all along.

[TotalVerb]

But aren't Union, UnionAll, and DataType concrete though, despite not always being enough information to do dispatch?

[JeffBezanson]

Unfortunately it is a bit context-dependent. If you want to know the memory layout of a value, then knowing that it's a DataType is sufficient. But if you pass a type to a function that has ::Type{T} selectors, it's not sufficient for dispatch. This is a long-term issue we'll have to fully resolve eventually.

Here, we can only make sense of isleaftype if we look at what it's used for. The basic use is to ask "do I know exactly what kind of value I'd have, or only some approximation?" We can decide what counts as "exact enough". In most cases we consider DataType "exact enough", e.g.

julia> typeof((Int,Int8))
Tuple{DataType,DataType}

We have a lot of experience with the isleaftype function, and in almost all cases we've wanted both DataType and Type{Int} to give true. Returning false tends to send you to a slow path.

For an example library use, consider the Set constructor on a Generator. If we can infer an isleaftype element type, that's precise enough so we directly use it as the Set's element type. Otherwise we examine the types of everything to pick a result type. For this purpose, clearly both DataType and Type{Int} are acceptable. If we know every element is Type{Int} then we know the exact identity of every value, so examining all of them would be silly. If we know DataType, we consider that good enough for a collection like Set; we don't want to bother checking whether every element is actually the same type. So the current somewhat fuzzy definition of isleaftype has proven itself useful.

[StefanKarpinski]

I propose having isconcrete and isfinal where the former means that it could be the tag of an object and the latter means that we can do dispatch (i.e. has non-empty intersection with exactly one concrete type). If isleaftype were not exported, the naming wouldn't matter, but it is exported so bikeshedding the name and semantics is fair game.

[JeffBezanson]

What is an example use case where you need to know that something could be the direct tag of an object? Or, put differently, an example of where calling Type{Int} leaf or concrete has caused a problem?

[felixrehren]

(Cf. #20555 "A publicly facing reflection API" -> knowing which types you can dispatch on?)

[nalimilan]

Bump. Should I rebase this so that it can be merged?

[nalimilan]

Rebased and added a NEWS.md entry.

[pabloferz]

@deprecate isleaftype isconcrete? Or are you trying to deprecate what you just introduced?... by what you just introduced.

[tkelman]

fixed in 3813421 - I think this was a mistake during the conflict resolution in fd4283c

[StefanKarpinski]

I still much prefer "concrete" to "leaf type" but there's a bit of a fundamental terminology decision to be made here. Does this function actually compute the property that we want to call "concrete"?

[omus]

I added the 1.0 milestone as we should probably make a final decision on this before release

[StefanKarpinski]

@JeffBezanson would you be happier calling this isfinal? The terminology isleaftype is pretty jargony and not entirely accurate since these types are not really the leaves of a tree in any case.

[JeffBezanson]

One good option might be to un-export isleaftype and add isconcrete, with the tag-based meaning (basically x isa DataType && x.layout != C_NULL). That's probably the most useful function (all type-related reflection will succeed on such a type). Replacing uses of isleaftype in the compiler will take more time and can be deferred.

[StefanKarpinski]

That's a good plan.

[JeffBezanson]

Done by #23666