In addition, there are also the notion of "staging meta-compilation" as witnessed in e.g., BER-MetaOCaml.
The idea is that if you want the best program efficiency, no compiler is able to carry out the needed optimizations. So you start meta-compiling by staging the compiler and generating code at each stage for the next one. Preferably in a type-safe manner. You can get some tremendously fast computational kernels out of this method. Usually, such speed only matter to a small part of a code base, so the effort is well spent doing these kinds of optimizations. Or it matters a lot in which case you need a GPU, FPGA or ASIC to make it run fast enough. Generics are trying very hard to be a lot of things at the same time: Convenient notation, Efficency, and Type safety. This means it has to make trade-offs along those areas, one way or the other. As for Code Size and icache misses: back in the day, the MLton project found that code expansion usually happens on a few types. Less than a handlful is the common case. And because (polyvariant) inlining follows, there are a lot of situations where the code size expansion doesn't matter at all to a modern largeish icache. Of course, this was 15 years ago, so many things may have happened in the meantime. On Mon, Mar 27, 2017 at 3:11 PM David Collier-Brown <davecb...@gmail.com> wrote: > Folks, is this something that we should do with a template processor? > More topically, is this a set of somethings that we should prototype each > of, using templates? > > I'd love to see actual experiments in computer "science" (;-)) and a > debate about the tradeoffs based on code. > > --dave > > > > On Monday, March 27, 2017 at 2:40:12 AM UTC-4, Egon wrote: > > On Monday, 27 March 2017 04:06:17 UTC+3, Mandolyte wrote: > > I agree that it makes the suitable trade-offs. And Linq is doing pretty > well without generics (https://github.com/ahmetb/go-linq); not familiar > with Rx. > > When I consider the dilemma, the two things I don't want are slow > programmers and slow execution, leaving "slow compilers and bloated > binaries". But here is how I think about this option: > - There are alternatives that only impact compiler speed if they are > actually used. I think that's fair. > > > The unfortunate reality is that when you add generics to a language it > will be almost impossible to avoid it. > > And the dilemma is not a binary-yes-no... e.g. would you give 100x > performance to have fast programmers, fast execution and no code-bloat... > or would you give 10% performance for medium speed programmers, fast > execution and some code-bloat? > > It's better to view the dilemma as a rating system. As a facilitated > example: > > *copy-paste:* > 1. convenience: 0/10 > 2. code size: 10/10 > 3. performance: 10/10 > 4. flexibility: 10/10 > 5. readability: 5/10 > > *interfaces:* > 1. convenience: 4/10 > 2. code size: 0/10 > 3. performance: 2/10 > 4. flexibility: 6/10 > 5. readability: 8/10 > > *type-level generics with boxing:* > 1. convenience: 7/10 > 2. code size: 0/10 > 3. performance: 5/10 > 4. flexibility: 8/10 > 5. readability: 1/10 > > *package-level generics with out-of-bounds boxing:* > 1. convenience: 6/10 > 2. code size: 3/10 > 3. performance: 8/10 > 4. flexibility: 5/10 > 5. readability: 7/10 > > *Obviously, do not take these numbers seriously.* > > - There are alternatives that result in binaries hardly any larger than if > you copy-pasted. Again, I think that's reasonable. > > > Here you are making a trade-off... it's not just about size, but also > about performance. More code means more icache misses. > > The main point is that *"there are approaches that produce less code than > copy-pasting"*. So ideally we want smaller binaries than you would get > from copy-pasting. > > As I understand it, the package template approaches fall into this camp. > So with the above restrictions, count me in favor of slow and bloated :-) > > > Not necessarily. I suspect it will be faster to compile than most generics > packages and similarly dealing with bloat will be easier. > > > On Sunday, March 26, 2017 at 9:08:20 AM UTC-4, Egon wrote: > > On Sunday, 26 March 2017 15:30:30 UTC+3, Mandolyte wrote: > > @Bakul - is your approach documented in Egon's collection? I think it is > essentially the same as Egon's at > https://groups.google.com/d/msg/golang-nuts/JThDpFJftCY/1MqzfeBjvT4J > > Perhaps your syntax is cleaner, simpler. I also like this general > approach. In Egon's document, this approach has nearly no downsides. > > > Depending what do you want to use generics for, there are significant > downsides. Mainly, you cannot create chained general purpose functions... > e.g. LINQ, Rx... *in the summary document see problems "functional code" > and "language extensions".* > > You could argue that using such approaches is not good for Go... but this > wouldn't invalidate that this generics approach doesn't solve these > problems nicely. > > You are always making trade-offs. > > *Personally, I think it makes trade-offs that are suitable to Go... but I > understand why people would disagree with it.* > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
