IMHO sort() is best thought of as a higher order function (one taking a
functional argument, the comparison function). It would be perfectly fine to
use a > b as this comparison function or a < b or any other compare function a
given type (e.g. case ignoring compare function on strings). Some confusion
may be due to the way Go sort package shoehorns a generic function into Go's
existing machinery. Ideally I’d want something like
func sort(vector []T, func compare(a, b T)bool)
with T to be specified at the call site.
You can achieve this with a parametric package extension (the only new syntax
is in package header and package import. So it is limited but simple to
understand).
What you are asking for (flagging a “semantic fail” at compile time) is perhaps
way beyond what a generics package in a language like Go can do.
> On Mar 31, 2017, at 9:19 AM, Michael Jones <[email protected]> wrote:
>
> There is part of the topic that has always been slightly beyond my grasp.
> (Maybe I do understand...but just lack absolute certainty.) Maybe others know
> the answer...
>
> In a template system (which is what I prefer but that's not the point of this
> email) we have the notion of the TYPE(s) being a formal argument. We presume
> that the code will compile or fail based on the suitability of the
> instantiated type. That is, a templated Min would fail on the comparison "<"
> if the TYPE was "Map[something]something." Call that a lexical fail.
>
> My question is, what about a semantic fail. Say, "<" for floating point. In
> the sort package the Less function does !Less(a,b)&&!Less(b,a) to figure out
> Equal(a,b). That works for ints and strings, but when I templated sort I
> found that it failed in tests with float32 and float64 because of NaN values,
> which are !Less(a,b)&&!Less(b,a) yet !Equal(a,b). I had to make two
> templates, one for floating point values and one for integral/string values.
>
> My uncertainty is in the fact that I only discovered the problem through
> testing--i had failed to anticipate it. It was easy to fix, but only after
> the fact. That makes me wonder about the truly perfect generality of
> templated reusable software, which would be most perfect if it failed to
> compile rather than fail in some rare edge condition under use or testing.
>
> The closest solution I have known about this was IBM Research's AXIOM
> symbolic mathematical system, which had a robust and mathematically pure
> concept of types and operators and commutativity and inverses and the like.
> It was possible to make a function for "two arguments that were elements of a
> ring with property A and B." That made sense to me, but was off-putting to
> some users.
>
> I recalled it i the sort case because I wanted to kinds of typed clients for
> "<", the kind where !Less(a,b)&&!Less(b,a) === Equal(a,b), and the kind where
> that is not the case--and ideally--a way to have instantiation for the first
> kind use path A and the second kind use path B. That would have made the code
> truly general.
>
> I fear this pedantry will make Russ suspicious of slowing compilation AND
> programmers. :-)
>
> Michael
>
> On Fri, Mar 31, 2017 at 2:46 AM, Egon <[email protected]
> <mailto:[email protected]>> wrote:
> On Friday, 31 March 2017 09:02:09 UTC+3, Will Faught wrote:
> >Because it can also be implemented in other ways.
>
> Do you mean interface{} can be implemented in other ways? I couldn't make out
> your meaning.
>
> There are multiple ways of implementing "boxing generics" and "interface{}".
> Implying it has same perf. characteristics as interface{}, implies the same
> implementation as interface{}.
>
>
> >As said... there is a performance upside for some other approaches.
>
> The other approaches have downsides, or at least generation does. Compared to
> using interface{} as is done now, boxing generics improves type safety and
> expressiveness and has no performance regression. That's a clear net win.
>
> I meant other generics approaches (not alternatives).
>
> Boxing generics adds complexity to the compiler, without solving some of the
> problems that generics intends to solve.
> Mainly, implementing highly performant data-structures would still require
> code-generation/copy-paste.
> And that is a pretty big downside.
>
>
> On Wednesday, March 29, 2017 at 9:18:01 PM UTC-7, Egon wrote:
> On Thursday, 30 March 2017 03:15:33 UTC+3, Will Faught wrote:
> Egon:
>
> >See
> >https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#heading=h.j8r1gvdb6qg9
> >
> ><https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#heading=h.j8r1gvdb6qg9>
>
> I don't see the Implicit Boxing section point out that this is what happens
> now when you shoehorn everything into interface{}.
>
> Because it can also be implemented in other ways.
>
> In this sense, I don't see a performance downside for boxing generics
> compared to the current state of things.
>
> As said... there is a performance upside for some other approaches.
>
>
> >You can also use copy-paste, code-generation.
>
> I was referring to the downsides of copy/paste here: "You could have the same
> opt-in performance tax in the form of bloated binaries/slow builds as well,
> but lack of an official debugger right now is predicated on builds being
> fast, so that seems like a no-go."
>
> The builds being fast are necessary for many things, mainly iterating on
> features, tests.
>
>
> >It would be slower than copy-paste and generated approaches.
>
> It wouldn't be slower than interface{}, right?
>
> Yes.
>
>
> >When generics are added, then they will be (almost) impossible to avoid. So
> >the opt-in "slow builds" isn't really opt-in unless you really try...
>
> By opt-in, I meant the code we write ourselves. In shared code, it would be
> no more impossible to avoid generics than interface{} is now, which doesn't
> seem to have been a problem. If there's a case where the performance is too
> slow, one could always copy/paste the code and remove the generics from it.
>
> Copy-paste wouldn't remove generics used in the standard-library... i.e. it's
> hard to avoid the compile-time overhead. I agree, it's possible, but unlikely
> that anyone will do it.
>
>
> On Tue, Mar 28, 2017 at 12:28 AM, Egon <[email protected] <>> wrote:
> On Tuesday, 28 March 2017 07:56:57 UTC+3, Will Faught wrote:
> Something I've never seen addressed in the generics tradeoffs debate (not
> saying it hasn't been, but I haven't see it personally)
>
> See
> https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#heading=h.j8r1gvdb6qg9
>
> <https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#heading=h.j8r1gvdb6qg9>
>
> is that without generics, you're forced to use interface{}
>
> You can also use copy-paste, code-generation.
>
> which just boxes the values anyway. So you're already paying a performance
> cost for type-agnostic code without generics. And if you copy/paste code
> instead of boxing, you're just bloating the size of the binary like generic
> templates would. It seems to me if boxing generics was added, there wouldn't
> be a downside:
>
> It would be slower than copy-paste and generated approaches.
>
> if you didn't want to pay the performance cost of boxing generics, then don't
> use generics; if you can pay the cost, then use them, and it won't perform
> any worse than it would now with interface{}, and perhaps could perform even
> better, depending on the semantics and implementation. You could have the
> same opt-in performance tax in the form of bloated binaries/slow builds as
> well,
>
> When generics are added, then they will be (almost) impossible to avoid. So
> the opt-in "slow builds" isn't really opt-in unless you really try...
>
> but lack of an official debugger right now is predicated on builds being
> fast, so that seems like a no-go.
>
> On Friday, March 24, 2017 at 12:10:08 PM UTC-7, Mandolyte wrote:
> The recent survey reveled that generics was thing that would improve Go the
> most. But at 16%, the responses were rather spread out and only 1/3 seemed to
> think that Go needed any improvement at all - see link #1. I think most will
> concede that generics would help development of algorithms, libraries, and
> frameworks. So in the spirit of friendly rivalry, here is a list of
> algorithms developed for Swift:
>
> https://github.com/raywenderlich/swift-algorithm-club
> <https://github.com/raywenderlich/swift-algorithm-club>
>
> As you might guess, it is chock-full of generics. Yeah, I'm a little envious.
> :-) enjoy...
>
>
>
> #1 https://blog.golang.org/survey2016-results
> <https://blog.golang.org/survey2016-results>
>
> --
> You received this message because you are subscribed to a topic in the Google
> Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/VbWfF865C3s/unsubscribe
> <https://groups.google.com/d/topic/golang-nuts/VbWfF865C3s/unsubscribe>.
> To unsubscribe from this group and all its topics, send an email to
> [email protected] <>.
> 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 [email protected]
> <mailto:[email protected]>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
>
> --
> Michael T. Jones
> [email protected] <mailto:[email protected]>
>
> --
> 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 [email protected]
> <mailto:[email protected]>.
> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
