For the math operator, since Go already doesn’t do automatic numeric
conversions, all of the operators are almost trivially implemented as methods,
e.g. operator + is
pseudo generic interface - not really required
type PlusOperator<type A> interface {
Plus(A) A
}
and given
type MyStruct struct {
}
func (MyStruct) Plus(other MyStruct) MyStruct {
…
}
The the + sign is just syntactic sugar. The compiler could easily determine and
call these methods as needed. It would be limited, but still very useful for
numeric programming. But then you probably want other math operators, like sum,
etc. and then it starts getting really complex if you want to define them all.
The map/indexing operators don’t matter, because they can only work on the
built in slice and maps.
I admit that this is not my area of expertise, but I’ve used Go enough now to
like it, barring some limitations. At this point I am not sure it needs a full
blown generics system, maybe a simple built-in temple code generator like I
proposed, or just some additional “built-in” interfaces you can implement with
special support from the compiler to make most of generics possible without all
of the fuss.
As I pointed out in the sample code in another thread, Java is type-safe but
still allows you to encounter a runtime type exception - so not fully type
safe, and it hasn’t stopped its adoption or success.
I’ll say it again, focus on the 90% most useful/helpful constructs, maybe with
some limitations, and be done with it.
You can already shoot yourself in the foot with unsafe or CGO, why does the
generics support need to be any different...
> On Sep 8, 2018, at 10:36 PM, Lucio <lucio.d...@gmail.com> wrote:
>
>
>
> 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
> <mailto:golang-nuts+unsubscr...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <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.
