News for hackers. Stuff that matters.
Re:Toward Go 2 by slavapestov on Thursday July 13, 2017 @04:37PM (#14764963)
> The basic tradeoff is monomorphization (code duplication) vs. boxing (in Go speak, interface{}).

There is also the approach taken by Swift, where values of generic type are unboxed in memory, and reified type metadata is passed out of band. There's no mandatory monomorphization.

Re:Toward Go 2 by pcwalton on Thursday July 13, 2017 @04:54PM (#14765135)
Really by "boxing" I mean "dictionary passing" (I've also seen the term "intensional type analysis" for it). That encompasses approaches like Java as well as those of Swift.

Hybrid approaches in which the compiler (or JIT!) decides whether to monomorphize or use vtables are also possible.

Re:Toward Go 2 by slavapestov on Thursday July 13, 2017 @05:02PM (#14765202)
"Dictionary passing" is a good term for this implementation strategy, I haven't heard it named before. Do you know of any other languages that take a similar approach?
Re:Toward Go 2 by dbaupp on Thursday July 13, 2017 @05:48PM (#14765579)
Re:Toward Go 2 by slavapestov on Friday July 14, 2017 @04:34PM (#14772951)
I thought Ocaml still boxed values, so there's no equivalent of value witness tables?
Re:Toward Go 2 by dbaupp on Sunday July 16, 2017 @09:48PM (#14785127)
Sure, but it still does basically the same thing of passing around witness tables. Values happen to have a uniform representation, but this seems seems like variation within a cluster of languages that do similar thing rather than something fundamentally new.
Re:Toward Go 2 by dbaupp on Thursday July 13, 2017 @04:53PM (#14765128)
The Swift approach shares many of the same characteristics and trade-offs as "true" (aka Java-style) boxing. Of course, it does avoid some downsides of that, but also brings along some additional ones.
Re:Toward Go 2 by slavapestov on Thursday July 13, 2017 @05:07PM (#14765252)
I think the main difference is that the Swift approach ends up being more memory-efficient, eg consider Swift's Array<Int> is stored as an array of integer values compared to a Java's ArrayList<Integer> where each element is boxed.

Also the Swift optimizer can clone and specialize generic functions within a module, eliminating the overhead of indirection through reified metadata.

Re:Toward Go 2 by dbaupp on Thursday July 13, 2017 @05:53PM (#14765620)
Yes, there's some pitfalls of Java that Swift avoids, like compulsory allocation, but it fundamentally has the same style of indirection (often pointers to stack memory rather than heap, but still pointers), type erasure and pervasive virtual calls, and brings with it even more virtual calls due to needing to go through the value witness table to touch any value (which might be optimised out... or might not, especally with widespread resilience).

The compiler specializing/monomorphizing as an optimisation shows that Swift has a hybrid approach that tries to balance the trade-offs of both (like many other languages, like Haskell, and, with explicit programmer direction, Rust), but the two schemes still fall into the broad categories of monomorphizing vs dictionary passing, not something fundamentally different.

Re:Toward Go 2 by slavapestov on Friday July 14, 2017 @04:33PM (#14772944)
Oh, hi Huon.