On Mar 31, 2017, at 9:19 AM, Michael Jones <michael.jo...@gmail.com
<mailto:michael.jo...@gmail.com>> 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 <egonel...@gmail.com
<mailto: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/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
<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/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 golang-nuts...@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
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
Michael T. Jones
michael.jo...@gmail.com <mailto: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
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
