Making Numeric Literals More Intuitive (DWIM)

[ParadaCarleton]

Quoting Stefan Karpinski on an idea I proposed to him on Slack today:

having literals produce a weak version of what they produce today seems like the best way to go in this direction
it would be an interesting experiment

The proposal is, specifically, that we create a new parametric type, Weak{<:Number}, that promotes differently from current behavior. So, x::Weak{Int64} + y::Int32 will return z::Int32. When combined with other weak types, weak types will promote as usual.

EDIT: @Seelengrab has come up with a better version of this idea later in the thread, where Int always means a weak integer. Whenever a weak number comes into contact with a non-weak number, the weak type will "Give way," and all integer literals are parsed as Int.

The goal here is to make literals as non-disruptive as possible, by parsing all literals as weak literals. Usually, when someone types y = x + 1, what they really meant is y = x + one(x). This would avoid type-instabilities or type disruption when using literals, avoiding one of the more common pitfalls for new users learning Julia.

[KristofferC]

Are functions going to specialize on that? Seems annoying that if you pass a 1 to your solver that propagates "untouched" through many functions you have to compile even though you have compiled it for Int64.

[Seelengrab]

on an idea I proposed to him on Slack today:

Let's also not forget your request to me for opening an issue after I proposed the original idea, which I didn't do because I felt the idea wasn't thought through yet, alright? Taking credit for other peoples ideas is not cool.

Not to mention that the discussion then continued with the unresolved issue of what 1+1 would have to return, and the conclusion that a parametrized version doesn't solve that. Then there's also the issue of what type 2147483647 + 1 would return, as @StefanKarpinski then asked.

As I understood it, we pretty much came to the conclusion that making Int resolve at compile time to a concrete size instead of at parse time was both safer and less confusing for newcomers ("integer literals have the size of the platform your code runs on" vs. "here's a second set of integers with slightly different promotion behavior").

Are functions going to specialize on that?

As discussed on Slack, no, not really. The original idea behind making integer literals not immediately the same as a Int64 (or Int32 on 32 bit host system) as soon as they're parsed is to not make them unnecessarily larger than necessary, e.g. when compiling for an architecture with 16-bit words. Emulating 64 bit arithmetic there is expensive, and at least on AVR you run out of registers very quickly (and LLVM will actually yell at you for using too many registers).

[ParadaCarleton]

Let's also not forget your request to me for opening an issue after I proposed the original idea, which I didn't do because I felt the idea wasn't thought through yet, alright? Taking credit for other peoples ideas is not cool.

As I mentioned in the relevant Slack thread, this is an idea I independently thought of about a year ago. I apologize for not mentioning you; the chat left me confused as to whether you were proposing the idea outlined in this post or the very different idea of having Int resolve at compile time (which is different from what's laid out here). I'd be happy to say you deserve co-credit for independently coming up with the idea, and I apologize for any miscommunication on my part.

[ParadaCarleton]

I do think the two issues you laid out got responses here:

In terms of what we'd settled on, I was under the impression that Stefan wanted both ideas (Int behaving as Intx depending on the platform, but also being "weak").

But I definitely might have misunderstood what he meant.

[Seelengrab]

I don't mean to "take credit" for the idea, since as I mentioned on Slack, that initial idea of a "ParsedInt" came from me reading about how Go does things (which we can't replicate due to us wanting to preserve referential transparency). I just wanted to point out that there's a whole lot more context & prior art here than your initial post suggests. Some of that prior art is Haskell requiring typeclasses to do the same thing, which we don't have.

As I mentioned in the relevant Slack thread, this is an idea I independently thought of about a year ago.

I haven't seen you mention that on Slack and your questions about why it can't be an unparametrized WeakInt seem to suggest the opposite; that this idea of giving it a type parameter only came from the discussion itself, so if anything, that context is very important due to the specifics discussed. Especially since the parametrization part seems to originate from @tecosaur, before which type parametrization wasn't even talked about.

I do think the two issues you laid out got responses here:

You're leaving out the fact that 2147483647 + 1 needs to return some value, because its type is observable runtime information, which got mentioned right after your screenshots:

This is also what @KristofferC is referring to above - by making that type visible (and potentially doubling the number of integer types), it's very likely to produce A LOT of recompilation and code churn if the fact that an integer came from a literal value finds its place in the type system as its own type.

---

Regardless, I took the last comment mentioned ("you can get away with just making Int be of a platform-specific size, distinct from Int32 and Int64 with weak promotion behavior") to mean that there's no need for type parametrization if you make Int !== Int64 and Int !== Int32, and have Int be the sole type with that kind of "weak promotion" (which is what I was describing at the beginning of the conversation, when I first brought up that parsing a literal Int should not directly produce a type of concrete size from the parser).

At the very least, such a change in promotion behavior of literals is breaking, since currently zero(Int32) + 1 is a Int64 on a 64 bit machine, but would be an Int32 with WeakInt (in any form). I suspect there's some more subtleties like that floating around in this idea space, but as I mentioned above, the idea hasn't yet had time to mature.

[ParadaCarleton]

You're leaving out the fact that 2147483647 + 1 needs to return some value, because its type is observable runtime information, which got mentioned right after your screenshots:

To clarify, when I said "I would like that, but [...]" I was responding to tecosaur's message, not Stefan's. I considered the question solved in support of just always parsing integer literals as WeakInt before applying any operations; Teco's comment about waiting to decide was broadly similar to my original proposal to always parse integers as a weakened form of BigInt, then avoiding performance penalties by replacing BigInt with a more optimal type whenever possible. In both cases the ability to avoid overflow would've been nice, but definitely not worth it.

Regardless, I took the last comment mentioned ("you can get away with just making Int be of a platform-specific size, distinct from Int32 and Int64 with weak promotion behavior") to mean that there's no need for type parametrization if you make Int !== Int64 and Int !== Int32, and have Int be the sole type with that kind of "weak promotion" (which is what I was describing at the beginning of the conversation, when I first brought up that parsing a literal Int should not directly produce a type of concrete size from the parser).

Ohhhh, I understand what you mean now. I thought your suggestion was just that Int should always be interpreted as IntXX for XX-bit systems (including 16-bit systems). I actually like this idea better than my/Teco's version with weak types corresponding to the original types, now that I understand it. Thanks!

One caveat is I think this should also include a Float type for literal floats, and a Rational type for literal rationals, instead of just Int. But apart from that, I like it.

[Seelengrab]

Ohhhh, I understand what you mean now. I thought your suggestion was just that Int should always be interpreted as IntXX for XX-bit systems (including 16-bit systems).

That is pretty much spot on with what I'm suggesting, yes. The only frontend change would be to actually emit Int instead of the Int64 type in the parser, and resolving Int to the platform specific integer type only when actually compiling for that platform. I.e., this:

julia> Meta.@dump f() = 1
Expr
  head: Symbol =
  args: Array{Any}((2,))
    1: Expr
      head: Symbol call
      args: Array{Any}((1,))
        1: Symbol f
    2: Expr
      head: Symbol block
      args: Array{Any}((2,))
        1: LineNumberNode
          line: Int64 1
          file: Symbol REPL[2]
        2: Int64 1

would become this

julia> Meta.@dump f() = 1
Expr
  head: Symbol =
  args: Array{Any}((2,))
    1: Expr
      head: Symbol call
      args: Array{Any}((1,))
        1: Symbol f
    2: Expr
      head: Symbol block
      args: Array{Any}((2,))
        1: LineNumberNode
          line: Int64 1 # it's fine to track these as Int64, since they are an artifact from the host system
          file: Symbol REPL[2]
        2: Int 1 # this is the only change

Note the Int 1 at the end. This would then only be changed to Int64/Int32/Int16 before/during abstract interpretation/compilation, when we're conceptually starting to "run" the code.

This is consistent with the current behavior of one(Int32) + 1 still promoting to Int64 on 64 bit systems, as happens today, while not changing behavior on 32 bit systems (and still resulting in 32 bit after the addition even on 16 bit systems, due to regular type promotion taking place). This also wouldn't make Int be a proper type in the type system, since it only exists right up until type inference runs and resolves Int to something else. Whether that Int then has different promotion behavior (i.e. whether the addition should return Int32 even on 64 bit systems) is best left for a future breaking release. Luckily, the two changes are complementary, rather than contradictory.

One caveat is I think this should also include a Float type for literal floats, and a Rational type for literal rationals, instead of just Int

Floats luckily don't have the same ambiguity as Int, since there is already syntax to distinguish the different sizes, in 0.0 vs 0.0f0. That's not to say it couldn't be done, just that it's a much rarer case to run into, as the different sizes in floating point literals are very often chosen deliberately, to account for the difference in precision between the two.

[ParadaCarleton]

Well, the difficulty is in using literal floats non-disruptively. In general, literals tend to be pretty disruptive, and it would be better if it was easier to preserve types.

The syntax for specifying floats of a specific type is fine, but it’s just like how Int(x) and Int32(x) aren’t adequate replacements for this proposal.

[Seelengrab]

The difference to integers is that there isn't a "platform specific" floating point size. You either explicitly use 32 bit, or explicitly use 64 bit (or 16 bit on specialized hardware), because both of those are already extensions to the underlying architecture and writing 0.0 already is semantically a Float64, which isn't the case for 0.

[mcabbott]

Re floats, things like x .* 1/size(x,1) and x .* 2pi are easy ways to accidentally promote an array of Float32, probably more common than using the wrong literal like x ./ 2.0.

There was a proposal (not mine) that the promotion rule in such cases should be that the non-default type wins, rather than the larger type as now. It seems rare to accidentally contaminate your Float64 calculation with one Float32. But the reverse is common (and an extreme performance bug on most GPUs).

[ParadaCarleton]

The difference to integers is that there isn't a "platform specific" floating point size. You either explicitly use 32 bit, or explicitly use 64 bit (or 16 bit on specialized hardware), because both of those are already extensions to the underlying architecture and writing 0.0 already is semantically a Float64, which isn't the case for 0.

Right--what I'm saying is that literals, including things like 0.0, should behave like weak floats (probably Float64 by default), so that something like x .* 2pi won't immediately promote. For consistency with Int, we could call this type Float. In this case, 2*pi is a composition of literals, so it stays weak. Operations between weak types promote analogously to usual types, e.g. a Float times an Int would be a Float.

(In cases where a strong Float64 is desired, just using Float64(0.0) would work, just like Int64(0) does.)

[Seelengrab]

Re floats, things like x .* 1/size(x,1) and x .* 2pi are easy ways to accidentally promote an array of Float32, probably more common than using the wrong literal like x ./ 2.0.

That's more an argument for having 1 and 2 be a WeakInt than changing whether or not floating point literals are a WeakFloat though. The promotion happens due to the Int64ness of the 1, not due to the Float64ness of 0.0. pi as an Irrational already has the weak promotion behavior:

julia> 2.0 * pi |> typeof
Float64

julia> 2.0f0 * pi |> typeof
Float32

If anything, this suggests that things like WeakInt * Irrational are a lot more tricky to figure out what to do with, because we definitely don't want to turn julia into a CAS. This computation has to have a result and defined type though.

[JeffBezanson]

To me the trade-off here is not worth it: the upside is some cases give a better answer, while the downside is more complexity, more specialization, and more potential for type instability (*). I frankly don't consider this design intuitive, since nobody knows what a WeakInt is, and it would likely need to be explained very early in a tutorial.

(*) I see that one of the goals here is to increase type stability, for example giving (x::T + 1)::T more often. But that's only true in specific cases. For the infamous array summing loop initialized with sum = 0, you will have type stability for Array{WeakInt} but not Array{Int}. Of course, this is a problem we already have now, but the point is adding more types only makes it worse instead of fixing it.

[ParadaCarleton]

That's more an argument for having 1 and 2 be a WeakInt than changing whether or not floating point literals are a WeakFloat though. The promotion happens due to the Int64ness of the 1, not due to the Float64ness of 0.0.

Right, but any kind of numeric constant will cause the same problems. Trying either (pi / 2) .* x or ((sqrt(5) + 1) / 2) .* x or 2.71828 .^ x will cause the exact same problems. If we treat pi / 2 as promoting to a float, it's still likely to be accidentally disruptive.

(Also, I just realized as I was typing this out that I probably messed up the type-propagation for some code I wrote in a package elsewhere 😅 I've been writing Julia for years, so that probably says something about the ease with which the current design lets bugs up.)

I get what you mean by not wanting to turn Julia into a CAS, but I don't think this goes much further in a CAS-y direction than including Rational does. We're not trying to calculate exact, symbolic solutions to equations or anything like that. The goal is just to "avoid" evaluating literals until they come into contact with a non-literal they can "steal" their type from.

[ParadaCarleton]

To me the trade-off here is not worth it: the upside is some cases give a better answer, while the downside is more complexity, more specialization, and more potential for type instability

Maybe I should explain the new proposal, which does not involve WeakInts at all.

Literal integers will always have type Int, just like they do now. The only difference is the promotion rule is changed to promote(Int, T) = T. The size of an Int is 32 or 64 bits depending on platform (but importantly, Int != Int64, or Int32). In cases where users specifically want an Int64 or an Int32, they can specify Int64(1) or Int32(1).

This adds exactly 1 extra type (since Int == Int64 no longer holds).

[JeffBezanson]

That's basically the same thing, just with a better (albeit less descriptive) name.

[Seelengrab]

Literal integers will always have type Int, just like they do now. The only difference is the promotion rule is changed to promote(Int, T) = T. The size of an Int is 32 or 64 bits depending on platform (but importantly, Int != Int64, or Int32). In cases where users specifically want an Int64 or an Int32, they can specify Int64(1) or Int32(1).

No, that is NOT what I'm proposing! I'm not proposing to add a new type. I'm proposing to assign Int64/Int32 later in the pipeline, to variables that the parser tagged with Int (which, for parsing purposes would be distinct from Int64/Int32) only when actually compiling/interpreting for a target with Int64/Int32 as its native bitsize (or Int16, if that is the native bitsize for that target). This doesn't affect types at all - the runtime type is still Int64/Int32 and no new runtime visible types are introduced and no promotion rules are changed.

Int === Int64 still holds on 64 bit platforms, just like it does now. On 32 bit platforms, this already doesn't hold, and my proposal preserves that behavior, while also allowing cross compilation of code containing integer literals. What I mean when I say that I don't want Int === Int64 is that the parser should not assume that to be the case and leave that decision up to the interpreter. @StefanKarpinski mentioned that this would be similar to how BigInt is treated in the parser and would kind of generalize that a bit, though I haven't looked into the details of that yet.

[timholy]

To add to the feeling of pickiness,

what they really meant is y = x + one(x)

it should be "what they really meant is y = x + oneunit(x). one(x) is the multiplicative unit, oneunit(x) is the additive unit. (Think of x = 1m as in the physical unit meters, in that case one(x) = 1 and oneunit(x) = 1m.)

But I too wouldn't change this. This seems like a job to delegate to a linter or your favorite AI coding assistant, rather than adding more complexity to the language. We're in an era where coding details like this seem likely to be of diminishing concern.

[Seelengrab]

Since this discussion revolves mostly around changing the actual type that's being emitted, I've opened a seperate issue to discuss my proposal for only changing what the parser emits, without introducing new types #49223

[ParadaCarleton]

But I too wouldn't change this. This seems like a job to delegate to a linter or your favorite AI coding assistant, rather than adding more complexity to the language. We're in an era where coding details like this seem likely to be of diminishing concern.

I think that's backwards. Both from and from talking to people experienced in how coding assistants work, we're entering an era where coding details are likely to be the only concern left for humans. What coding assistants are good at is understanding high-level abstractions.

When I tried out GPT-4, I asked it to implement a mixed integer linear programming algorithm in Julia from scratch. It was able to generate mathematically/conceptually correct code on the first try. But the code had lots of bad behavior for high-performance or production code, e.g.:

1. Indexing with 1:length(x),
2. Using x[a:b] and generating lots of copies, instead of using views,
3. Generating type instabilities,
4. Assuming all arguments satisfy implicit "interfaces" without actually checking they do (e.g. taking code that's supposed to work for arbitrary Numbers and then writing code that assumes all inputs are actually Float64), and
5. Disrupting types by adding things like x .* π / 2 (and not understanding that 2.0 * x !== 2x).

In other words, if you want to know "What kinds of mistakes will coding assistants make?" you should be asking yourself, "What kinds of mistakes would a brand-new user make?"

This is likely to remain the case for the foreseeable future, because LLMs are trained on real code, most of which:

• is written by beginners making intuitive mistakes (or just don't care), and
• is written in Python or JavaScript, where types are much less important and code like x + 1 "just works." LLMs don't really understand Julia, because they haven't seen much of it. But they understand math (from papers) and Python (there's lots of that), which is good enough to translate if you've also seen just a handful of examples of Julia.

The only part of coding that LLMs can't automate is debugging of minor details like preserving types. That means that Julia code needs to either "Just work" even if poorly written, or it needs to aggressively throw errors (preferably at compile time).

[StefanKarpinski]

• is written in Python or JavaScript, where types are much less important and code like x + 1 "just works."

To be fair, x + 1 "just works" in Julia in the sense that it gives you the right value. You're just unhappy that it doesn't necessarily give you a value of the same type as x. But that's not actually that big a concern, imo. As long as you get the right value, the type is of secondary importance, just as in Python or JavaScript.

[ParadaCarleton]

In a sense, the ideal language for an LLM is Rust (throw lots of errors at compile time that catch mistakes), but more readable (so I can verify the code is correct).

[timholy]

we're entering an era where coding details are likely to be the only concern left for humans

I see things differently especially w.r.t. the "only" part of your statement, but perhaps it's not worth hashing out here as it's a bit off-topic. Even supposing you're right about the limitations of the AIs, this is certainly the kind of thing that can be analyzed & caught in a linter.

Anyway, it seems the proposal is still a bit in flux. #49207 (comment) has its own downsides: suppose I'm trying to calculate the mean intensity in an 8-bit grayscale image. I might use an accumulator to first sum the pixels, and Int or UInt are natural accumulators. (If it's a difference image, it's probably encoded in Int8 and hence Int is the only viable accumulator.) A rule causing promote_type(Int, T) == T would introduce surprising & breaking behavior.