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 <egonel...@gmail.com> 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/1vrAy9gMpMoS3uaVphB3
>>>> 2uVXX4pi-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 <egon...@gmail.com> 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/1vrAy9gMpMoS3uaVphB32
>>>>> uVXX4pi-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
>>>>>>>
>>>>>>> As you might guess, it is chock-full of generics. Yeah, I'm a little
>>>>>>> envious. :-) enjoy...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> #1 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/to
>>>>> pic/golang-nuts/VbWfF865C3s/unsubscribe.
>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>> golang-nuts...@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.
>
--
Michael T. Jones
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.
