Compile-time logic feels like a baby/bathwater issue to me. With M4 and then CPP on the scene, new kinds of adaptable code became possible in C. It was such a compelling benefit (I still have the CSTRs) that it grew to ubiquity and finally to a monsterous horror in C++ that in recent decades, through bost-style all-header code and huge autoconfiguration, leads to source code where it is impossible to know by inspection what source code is being compiled.
The benefits are still phenomenal but now the cost of obscurity is as phenomenal. Go came to life in the time of backlash against such problems. Even so. might we not consider the problems as "bathwater" and still love the baby? There is an inherent 'switch' in any kind of generality. It might be hidden at compile time, as in the different meaning and opcode in addition of "5+5" and "3.1+6.7", or at runtime type switches, or in magical JIT Java compilation, or in the core Smalltalk message dispatch, or exposed nakedly in "#ifdef", but it is still there. In generics it must still be there as well, some way to say "to de-abstract this do X." Might there not be a clean/clear/comprehensible, Go-worthy, way to specify compile-time logic? On Wed, Sep 12, 2018 at 10:05 AM Ian Lance Taylor <i...@golang.org> wrote: > On Wed, Sep 12, 2018 at 7:49 AM, Wojciech S. Czarnecki <o...@fairbe.org> > wrote: > > On Wed, 12 Sep 2018 06:33:59 -0700 > > Ian Lance Taylor <i...@golang.org> wrote: > > > > Addenum: > > > >> You need to have a way to say "compile this code under certain > >> conditions based on the type argument, otherwise compile this code." > >> That is, the compiler is directed, at compile time, as to which code > >> should be compiled. That is metaprogramming. > > > > This is not metaprogramming! > > > > Every and each statement is written by the human author in plain Go > > and no code is produced by the program itself. > > > > https://en.wikipedia.org/wiki/Metaprogramming > >>>> Metaprogramming is a programming technique in which computer programs > have > >>>> the ability to treat programs as their data. It means that a program > can > >>>> be designed to read, generate, analyse or transform other programs, > and > >>>> even modify itself while running. > > I agree that no code is produced by the program, but you're suggesting > a compile-time decision as to which code should be compiled. We don't > have to call that metaprogramming if you don't want to, but it is > something unlike what can be done in Go today. > > Ian > > -- > 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. > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- 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.
