On Sunday, 9 September 2018 04:53:00 UTC+2, Jonathan Amsterdam wrote: > > When is it important to not just express what operations are >> required for a type, but also to try to rule out some types? >> > > I think the short answer is: numeric code. That's when one thinks about > which types make sense for an algorithm, not just which operations. > > I'm not exactly sure why. It could be because Go doesn't support operator > overloading. In C++ with concepts, maybe the concept for writing some > generic math function wants operator+ and operator/, and no one cares that > that may result in nonsense for some implementations of those operators. > > In Go 1, we write numeric code with specific types: float64 and not > int64, for instance. Go insists on conversions between numeric types to > keep us out of trouble: you can't call func Average(a, b float64) on ints > without explicitly converting them. It seems natural to want to keep that > precision and safety, but generalize it. > > I really feel out of place making suggestions here, my foundations are old and crumbly for this type of intellectual exercise and I don't want to make assertions that would be laughable when looked at under a microscope I simply don't own.
That said, I want to thank Ignazio for outlining my thoughts so clearly, at least I know I did not fail to get the point across as I feared I may have. At the same time, purely on a philosophical (for want of a better adjective) level, it is important to keep in mind that a pragmatic solution to the problem of generics is far more useful than a purely theoretical one and that the Go developers have tasked themselves to address a *real* problem and arrive at a *real* solution, without knowing that such a solution exists in the space defined by the many constraints involved. On the pragmatic side, we know that the Go compiler has little difficulty applying the Go discipline regarding numeric (more generic than other) types, it therefore is possible to instruct the compiler to apply analogous capabilities to arbitrary types, if we give the code writer (me and you) access to the decisions making applied within the compiler. That may be very hard to express, but there is definite, readily accessed, prior art. On the other extreme, as I have expressed in private correspondence with Ian, one could at least theoretically remove all aspects of expression evaluation out of Go (that is what, in my ignorance, I just realised functional languages do) and leave merely the language constructs in place (assignment, decision making, loops, function invocations, goroutines, channel operations) and allow modular interpreters to play arbitrarily fast and loose in the expression space, as long as they interface correctly with the compiler's expectations.Therein remains the type-checking strength of Go and I don't expect anyone to argue that it is valuable. But the essence then becomes the ability to define the interface to such an interpreter (imagine the target being APL, a long-lost relative returning) at a higher (?) level than types, the way functions presently do, because, as numeric constants already do, we know we can leave the business of dealing with that to the interpreter. So, like it or not, we then need to be able to describe types, not operators, in terms of groups of the subtypes we enjoy now; the operators, as Ignazio so clearly describes, are just syntactic sugar we use out of tradition, not part of the essence. Of course, I do take Ian's point that generics should not force us to adopt a language readily distinguishable from Go, as what is described above is not the Go we know and love, but perhaps there is a middle ground that will prepare us for the next step (ten years, they blew over very quickly, didn't they?) for the next generation. My own habits encourage me to open rather than close doors, but I understand Ian's position well, we "need" an answer to the perennial questions raised in this forum and others; but if the present solutions shuts the doors to a Go 3 that could be a much better answer to the needs of developers who, like me, have not been able to get a full education in the subtleties of compiler designing and writing, then I would be disappointed to see that Go 2. Still, the nag remains: what formal mechanism can we define that describes how the Go 1 compiler already deals with numerics (keep in mind the breadth of scope of numeric constants already embraced by it) and how do we offer that to the average Go developer in a form that is not just a complexity trap? Lucio. -- 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.
