Doug Cheney is the generic version of Dave Cheney. ;)
--
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,
Hehe, perhaps. But I am not sure that it makes people much slower if that
assertion is even true.
The thing being that, what is more important for an application algorithm?
The data or the datastructure ?
I would tend to think that the data is more important. The choice of
datastructure is ofte
Lol, Doug Cheney.
--
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/op
On Saturday, July 2, 2016 at 9:12:54 AM UTC-4, Chad wrote:
>
>
>
> The appeal of generics is probably a false appeal.
>
> Then, if you accept the trilemma described at
http://research.swtch.com/generic, that puts you in favor of "slow
programmers"... just kidding. I went back to read all the comm
What's generic programming?
An implementation of overloading for datastructures and function/methods.
The compiler is left in charge of going through the code and specifying
which types should actually be used.
Go restricts the overloading of function/methods.
So we are left with the specificat
IMHO, regarding the trilemma, I want slow compilers. This option means no
penalty unless you actually use the generic feature. Want fast compiles, then
don't use generics. I've never been convinced about the code bloat issue that
gets tagged with slow compiles. I think the code bloat issue shoul
>> I would also like to point out again that I am not arguing in favor or
against the C++ or the Java way. I am simply trying to get you to answer
the question which of the two you are proposing.
Neither one nor the other.
Only the "Go way".
And I am did not propose.
I am only try bring underst
You are still avoiding answering the one simple question that would explain
perfectly well, without any room for misunderstanding, what you are
proposing. I would also like to point out again that I am not arguing in
favor or against the C++ or the Java way. I am simply trying to get you to
answer
>> That there is an indirection in the struct doesn't mean that a function
doesn't need to know the size of the memory it is allocating for a bucket.
Your judgement are now incorrect.
Obtaining the size of the of the type is not so hard at runtime.
It always known from `rtype`
This is how map al
On Fri, Jul 1, 2016 at 10:23 PM, Andrew Mezoni
wrote:
> Can I ask the question out of turn?
> Ok. I ask.
> What wrong in Java way?
> What wrong in C# way?
>
Nothing inherently. It just takes a performance penalty and it needs to be
justified that this performance penalty is worth it. That is the
On Fri, Jul 1, 2016 at 10:00 PM, Andrew Mezoni
wrote:
> >> How does the generic function know the size of the return value?
>
> All your judgement are not correct only because you ask not a correct
> questions.
>
I am not asking the questions you want me to ask, but that doesn't make it
the wron
Can I ask the question out of turn?
Ok. I ask.
What wrong in Java way?
What wrong in C# way?
Of course, they have a boxing/unboxing concepts.
Does this means that boxing/unboxing is very, very, very slow operations
and should not be used even in Java or in C#?
But they used. They used at least in
On Fri, Jul 1, 2016 at 9:51 PM, wrote:
>
> How does the compiler know sizeof(T)?
>>
>
>
> interesting question. About obtaining sizeof(T). The sizeof(T) is known
> from the call site calling the generic function, in particular from the
> type of variable that's passed to the generic function.
>
>> How does the generic function know the size of the return value?
All your judgement are not correct only because you ask not a correct
questions.
They return pointers to appropriate values.
Or you really think that the `map` also returns a value instead of pointer?
How it (map) can know the s
On Fri, Jul 1, 2016 at 12:51 PM, wrote:
>
> Perhaps modify Golang's 2.0 calling convention, that EVERY function must get
> upon compilation one extra invisible-to programmer argument that is pointer
> that
> when said function is generic, points to sizeof(T) storage place .
> If you're calling to
> How does the compiler know sizeof(T)?
>
interesting question. About obtaining sizeof(T). The sizeof(T) is known
from the call site calling the generic function, in particular from the
type of variable that's passed to the generic function. What If generic
function calls another generic fu
Perhaps a better question is: Given a generic function
func Get(l List, i int) E {
…
}
var a List{ 1,2,3}
var b List{"1", "2", "3"}
var c List{1.0, 2.0, 3.0}
fmt.Println(Get(a, 0), Get(b, 1), Get(c, 2))
// Should print "1 2 3.0"
implement the code, a compiler would generate for this, in C (o
You are still not making a clear decision about the generics dilemma here.
On Fri, Jul 1, 2016 at 8:59 PM, Andrew Mezoni
wrote:
> >> Go has to run in environments where runtime code-generation /
> modification is not allowed.
>
> Where you find that I wrote about that?
> The generic code (not a
On Fri, Jul 1, 2016 at 8:34 PM, Andrew Mezoni
wrote:
> >> The generic dilemma is this: *do you want slow programmers, slow
> compilers and bloated binaries, or slow execution times?*
>
> (The Java approach.) Box everything implicitly.
> This slows execution.
>
> I just want to add some clarificat
On Friday, 1 July 2016 21:59:19 UTC+3, Andrew Mezoni wrote:
>
> >> Go has to run in environments where runtime code-generation /
> modification is not allowed.
>
> Where you find that I wrote about that?
>
Yeah, sorry, my mistake:
*1. Information about the types will be obtained not at the com
>> Go has to run in environments where runtime code-generation /
modification is not allowed.
Where you find that I wrote about that?
The generic code (not a parametrized code) executed in the same manner as
the reflection works.
But with a single and very big differnce.
The reflection is slow b
On Friday, 1 July 2016 21:34:10 UTC+3, Andrew Mezoni wrote:
>
> >> The generic dilemma is this: *do you want slow programmers, slow
> compilers and bloated binaries, or slow execution times?*
>
> (The Java approach.) Box everything implicitly.
> This slows execution.
>
> I just want to add som
>> The generic dilemma is this: *do you want slow programmers, slow
compilers and bloated binaries, or slow execution times?*
(The Java approach.) Box everything implicitly.
This slows execution.
I just want to add some clarification.
This does not slows a whole execution.
All that works fast
On Fri, Jul 1, 2016 at 12:40 PM, wrote:
> the parametrized struct got me interested, how to best handle the
> embedding the arbitrary type.
>
> Especially passing said struct to a generic function.
>
>
>
> type S struct {
>
> I1 int
>
> C1 char
>
> *T1 T*
>
> I2 int
>
> *Ts1 [2]T*
>
> Is1 [10
>> I believe you've made a mistake here, elem needs to be *T , not T
This was just an abstract example.
I just wanted to say that if someone want to try implement a transpiller of
the "Go.next" to the "Go" then the better way to represent the data of the
different types (which are specified by t
On Friday, July 1, 2016 at 1:53:46 PM UTC+2, Andrew Mezoni wrote:
>
> >> Now imagine that T=int8
>
> Generic struct always has the same size only because it uses pointers.
>
> type S struct {
> elem ***T
> arr []T
> }
>
> I believe you've made a mistake here, elem needs to be *T , not T
--
>> Now imagine that T=int8
Generic struct always has the same size only because it uses pointers.
type S struct {
elem T
arr []T
}
Is the same as the following struct.
type S struct {
elem unsafe.Pointer
arr []unsafe.Pointer
}
This is because it is designed to be universal.
You may
On Wednesday, June 15, 2016 at 3:04:05 AM UTC+2, xingtao zhao wrote:
>
> Here is my proposal for generic in go:
> https://docs.google.com/document/d/1nO7D15c2B3eq2kF62C0yUs_UgpkyPL2zHhMAmlq1l98/edit?usp=sharing
>
> Many parts has not been finished, and just initial thoughts. In the
> proposal,
On Friday, 1 July 2016 10:32:20 UTC+3, Øyvind Teig wrote:
>
> I assume the scope of the discussion about introducing generics is not how
> Go-generics might hypothetically be transformed to idiomatic Go. I find no
> reference to "unsafe" in neither of these (already mentioned here):
>
>- "Pro
I assume the scope of the discussion about introducing generics is not how
Go-generics might hypothetically be transformed to idiomatic Go. I find no
reference to "unsafe" in neither of these (already mentioned here):
- "Proposal: Go should have generics" by Ian Lance Taylor
https://githu
I assume the scope of the discussion about introducing generics is not how
Go-generics might hypothetically be transformed to idiomatic C. I find no
reference to "unsafe" in neither of these (already mentioned here):
- "Proposal: Go should have generics" by Ian Lance Taylor
https://github
>> it can be done with using unsafe
This is the only available method (and very suitable).
The same method used throughout in the Go language the runtime.
It's very easy to do that.
Problem only to find appropriate syntax for the current Go grammar for to
be look as idiomatic Go.
I still not fou
torsdag 30. juni 2016 18.04.13 UTC+2 skrev charr...@gmail.com følgende:
>
>
>
> On Wednesday, June 29, 2016 at 3:42:51 PM UTC+2, Øyvind Teig wrote:
>>
>> The suggestions of generics discussed here and in the referenced
>> documentation, will it be possible to compile the "Go-with-generics"
>> l
On Wednesday, June 29, 2016 at 3:42:51 PM UTC+2, Øyvind Teig wrote:
>
> The suggestions of generics discussed here and in the referenced
> documentation, will it be possible to compile the "Go-with-generics"
> language into some idiomatic Go and compile it with the standard compiler?
> (I gues
The suggestions of generics discussed here and in the referenced
documentation, will it be possible to compile the "Go-with-generics"
language into some idiomatic Go and compile it with the standard compiler?
(I guess *what* idiomatic means is the real question here..). Or would it
break idioma
On Wednesday, 29 June 2016 14:45:09 UTC+3, Sean Russell wrote:
>
> On Wednesday, June 29, 2016 at 2:31:59 AM UTC-4, Egon wrote:
>>
>> Just to be clear what I consider a *great example* for analyzing
>> generics:
>>
>> 2. 3+ real-world packages/applications use that package
>> * By real-world her
On Wednesday, June 29, 2016 at 2:31:59 AM UTC-4, Egon wrote:
>
> Just to be clear what I consider a *great example* for analyzing generics:
>
> 2. 3+ real-world packages/applications use that package
> * By real-world here I mean it wasn't written for learning or fun, but
> rather solving a conc
On Wednesday, 29 June 2016 06:35:03 UTC+3, Egon wrote:
>
> On Wednesday, 29 June 2016 01:51:58 UTC+3, Mandolyte wrote:
>>
>> Earlier someone asked about real world examples. The obvious standard
>> library was mentioned. It only took me a few seconds to remember Jan
>> Mercl's interval package. A
On Wednesday, 29 June 2016 01:51:58 UTC+3, Mandolyte wrote:
>
> Earlier someone asked about real world examples. The obvious standard
> library was mentioned. It only took me a few seconds to remember Jan
> Mercl's interval package. A quick look suggests that the current 1200+
> lines of code wo
Earlier someone asked about real world examples. The obvious standard library
was mentioned. It only took me a few seconds to remember Jan Mercl's interval
package. A quick look suggests that the current 1200+ lines of code would be
reduced to about 250.
If this sort of code is written very oft
On Thursday, 23 June 2016 07:59:16 UTC+3, Henry wrote:
>
>
> Having completed an earlier project, my colleagues and I sat down to
> review the team performance and what we could do better next. My colleague
> proposed an intriguing idea and we decided to randomly pick two components
> of our p
On Thursday, 23 June 2016 06:41:07 UTC+3, Thomas Bushnell, BSG wrote:
>
> This is why I like this example. Generics induce people to write the wrong
> thing instead of thinking about the right thing. When you start thinking of
> the right thing, you often discover better solutions.
>
*It's also
Having completed an earlier project, my colleagues and I sat down to
review the team performance and what we could do better next. My colleague
proposed an intriguing idea and we decided to randomly pick two components
of our past projects that could be implemented independently from the rest
This is why I like this example. Generics induce people to write the wrong
thing instead of thinking about the right thing. When you start thinking of
the right thing, you often discover better solutions.
I think the sort package's way of doing sorting and binary search are so
clearly better than
Yes, for floats with NANs and the like, you must specialize. My replacement
for the standard library sort (3x to 10x faster in the common case) had to
have more macro generators than expected just to handle the "uncomparables"
in float32 and float64.
You are right about that issue.
P.S. By the wa
But Michael, that implementation isn't right for floats! Check out the
actual source for math.Max.
On Wed, Jun 22, 2016, 6:31 PM Michael Jones wrote:
> The wonderful history of symbolic algebra at IBM (Scratchpad, Scratchpad
> II) resulted in a third system, Axiom, that has always seemed to me a
The wonderful history of symbolic algebra at IBM (Scratchpad, Scratchpad II)
resulted in a third system, Axiom, that has always seemed to me a bright lesson
in types. It boldly goes into the topic with rigor, using category theory to
decide what relationships make sense and what the nature of a
Really? How would you implement math.Max with generics?
Thomas
On Wed, Jun 22, 2016, 5:45 AM Viktor Kojouharov
wrote:
> https://golang.org/pkg/math/ and https://golang.org/pkg/container/ are
> just two stdlib packages that would greatly benefit from some kind of
> generics. I'm pretty sure ther
On Wed, Jun 22, 2016 at 2:55 PM, Viktor Kojouharov
wrote:
>
> And yet the 'K' and 'V' within the struct are generic types. A struct is
> never simple. That's its whole point.
>
I don't know what you mean by that. A struct is very simple, it's flat data.
> A lot of these 'applications' that you
>> The fact still remains that unlike a lot of other proposed languages
additions that are immediately dropped, generics are still open for
discussion by the language developers themselves.
I think that the problerm only in the Go developers brcause them even does
try to implement them experim
On Tuesday, June 21, 2016 at 10:29:37 AM UTC-4, Henry wrote:
> You still haven't provided any argument why generics is indispensable.
That can't be the litmus for language feature inclusion; if it was, Go would
resemble ASM.
In my personal experience, something North of 50% of my non-trivial
On Wednesday, 22 June 2016 15:32:53 UTC+3, Andrew Mezoni wrote:
>
> >> The version without generics is necessary to compare how well a
> particular generics approach improves the current language and code.
>
> I am sorry but this is obviously that any useful feature (in the context
> of solving p
On Tuesday, June 21, 2016 at 9:56:01 PM UTC+3, Axel Wagner wrote:
>
> The issue is, that a "KeyValuePair" (no matter if you implemented it
> via generics or like you mention via interfaces) is a fundamentally useless
> type and generics encourage people to add useless types. A "KeyValuePair V>"
https://golang.org/pkg/math/ and https://golang.org/pkg/container/ are just
two stdlib packages that would greatly benefit from some kind of generics.
I'm pretty sure there are more packages in the stdlib that would be greatly
improved. And that's just the standard library.
On Tuesday, June 21
>> The version without generics is necessary to compare how well a
particular generics approach improves the current language and code.
I am sorry but this is obviously that any useful feature (in the context of
solving problems) improves the current language and code.
Another question: how new
On Wednesday, 22 June 2016 13:02:20 UTC+3, andrew...@gmail.com wrote:
>
> >> You are not bringing anything new to the table here, except the attempt
> to insult my intelligence, apparently.
>>
>>
> I do not have any claims to anyone personally.
> I only defend my own point of view.
>
> P.S.
>
>
>> You are not bringing anything new to the table here, except the attempt
to insult my intelligence, apparently.
>
>
I do not have any claims to anyone personally.
I only defend my own point of view.
P.S.
Also I don't love to see or use some (not my own) code which written like a
mess.
If I ca
You are not bringing anything new to the table here, except the attempt to
insult my intelligence, apparently.
There are huge software projects out there written in languages that are
less type safe than go and the vast majority of code written is not
reusable. Both also aren't absolutes. There is
>> And my point is and was: It doesn't *need* to be both type safe *and*
reusable, unless you are focusing your energy on writing frameworks or
treating type safety as a goal solely for it's own sake.
It does NEED to be BOTH type safe and reusable.
1. Type safety prevent the programmers to make
As a general suggestion:
Do not use fabricated examples, use concrete real-world examples.
Fabricated examples make harder to examine the practical side of generics
-- i.e. how would you solve a particular problem with/without generics. The
fabricated examples can suggest a problem where there
Sorry for typo and possible spam but correct example here:
type Foo interface {
Get(key K) V
Set(key K, val V)
}
func foo() (int, Foo) {
// Typo: foo := &Foo{}
foo := &fooStruct{}
// ...
foos := []Foo{}
// ...
k := "London"
// ...
return 55, foo2(foos, 55, k)
}
// This code is
And my point is and was: It doesn't *need* to be both type safe *and*
reusable, unless you are focusing your energy on writing frameworks or
treating type safety as a goal solely for it's own sake. It's perfectly
fine to write small stuff yourself (for example like this) with explicit
types and it'
>> perfectly type safe.
Perfectly type safe but not perfectly reusable.
What If we slightly complicate the task?
Now is my code and I want to see on your code exampe (perfectly type safe
but and perfectly reusable)
type Foo interface {
Get(key K) V
Set(key K, val V)
}
func foo() (int, Foo)
I don't know what you are doing, here, but…
func some() string {
foo := struct{ Key string, Value int }{}
// some code
// compie error: Can't use foo.Key (type string) as int
acceptInt(foo.Key)
// compile error: mismatched types string and int
if foo.Key == foo.Value {
>> The issue is, that a "KeyValuePair" (no matter if you implemented
it via generics or like you mention via interfaces) is a fundamentally
useless type and generics encourage people to add useless types. A
"KeyValuePair" is a "struct { Key K, Value V }", plain and simple.
It's not an interface
I think I have to agree with most of the posters here about generics. In
theory, I miss them. However, in practice, I find that there are usually
only a few times during the course of a project where I wish I had
generics. And then after writing a few lines of code to do what the
generic wou
generics would greatly improve code reuse for many algorithms- this one
fact alone trumps all opposition. In fact, go's builtin container types
have generics-like functionality already. Imagine arrays, slices, maps
without this functionality- exactly, enough said. the arguments against
generics
On Tuesday, June 21, 2016 at 2:56:01 PM UTC-4, Axel Wagner wrote:
>
> The issue is, that a "KeyValuePair" (no matter if you implemented it
> via generics or like you mention via interfaces) is a fundamentally useless
> type and generics encourage people to add useless types. A "KeyValuePair V>"
On Tue, Jun 21, 2016 at 9:38 PM, xingtao zhao wrote:
> I totally agree that I always want generics mainly when I am writing a
> framework. But I do not agree with you on that "go is pretty much a
> language for writing applications". I don't think go is powerful enough
> that we do no need any fr
I totally agree that I always want generics mainly when I am writing a
framework. But I do not agree with you on that "go is pretty much a
language for writing applications". I don't think go is powerful enough
that we do no need any framework. I don't think we can always develop
applications f
The issue is, that a "KeyValuePair" (no matter if you implemented it
via generics or like you mention via interfaces) is a fundamentally useless
type and generics encourage people to add useless types. A "KeyValuePair" is a "struct { Key K, Value V }", plain and simple. It's not an
interface and it
For example:
type Int int
func (i Int) Add(j Int) Int { return i + j }
type Number> interface {
Add(j T) T
}
If we want Int satisfy the interface Number, we have to create two
versions of function Int.Add, one for concrete type Int, one with generic
type T
And if we want to support:
var
On Tuesday, 21 June 2016 17:18:04 UTC+3, andrew...@gmail.com wrote:
>
> >> increase in cognitive load to decipher chains of type definitions.
>
> Sorry, but who are members of this mail lists?
> This is a first time when I hear about such loads such as the `cognitive
> load`.
>
https://docs.googl
>> What I mean is that most people who have followed the past generics
discussions already know it's possible to implement them with efficient
memory use and performance. So they don't need to worry much about that.
Thank you for explanation.
>> can they be implemented without making Go a much
You still haven't provided any argument why generics is indispensable.
The reason why I am no longer sure about my position in this issue is because
-while I agree that generics is useful- I don't think that generics is
essential. In fact, all of C++ features are useful and implemented in a ver
On Tue, Jun 21, 2016, at 03:17 PM, andrew.mez...@gmail.com wrote:
> >>increase in cognitive load to decipher chains of type definitions.
>
> Sorry, but who are members of this mail lists?
> This is a first time when I hear about such loads such as the
> `cognitive load`.
> Also I am possible here
>> increase in cognitive load to decipher chains of type definitions.
Sorry, but who are members of this mail lists?
This is a first time when I hear about such loads such as the `cognitive
load`.
Also I am possible here a single person who does not know anything about
the `cognitive load to dec
On Tue, Jun 21, 2016, at 01:45 PM, andrew.mez...@gmail.com wrote:
> >>I am not saying that generics is bad, but I am questioning whether
> >>generics is necessary.
>
> Please, do not panic.
> If you worry about the following things:
> - Generated code will grow when used generics
> - Generated co
>> I am not saying that generics is bad, but I am questioning whether
generics is necessary.
Please, do not panic.
If you worry about the following things:
- Generated code will grow when used generics
- Generated code will be more complex when used generics
- Execution performance will slow down
I am not saying that generics is bad, but I am questioning whether generics
is necessary.
On Tuesday, June 21, 2016 at 3:45:08 PM UTC+7, andrew...@gmail.com wrote:
> >> I was one of the generics supporters for Go in this forum, but now I am
> not so sure.
>
> But why?
> Generic types is the sa
>> I was one of the generics supporters for Go in this forum, but now I am
not so sure.
But why?
Generic types is the same types as and the regular types.
Difference only in that the regular types does not have a parameters but
generic types are always have at least one parameter.
This is why th
I think we should carefully consider whether generics is worthy enough to be
added into the language. It is easy to add a feature, but nearly impossible to
remove one without breaking the backward compatibility promise.
One thing for sure is that we are in the middle of a paradigm shift. I am
>> While later I realized that we still need some parameter check in the
callee code to satisfy the interface matching (the generic version of each
function in my proposal).
A am sorry but your judgements is not correct.
Here is a proofs:
1. It is redundant to perform check of the correctness of
That was my original thought. While later I realized that we still need
some parameter check in the callee code to satisfy the interface matching
(the generic version of each function in my proposal). And we need special
assembler function for dynamic interface cast.
On Monday, June 20, 2016 at
Overhead at runtime will be not very big;
1. Generate each time an instance of specific generic type with arguments
2. Perform generic specific type checks before any kind of an assignements
1. The first overhead can be reduced (eleminated) by the static code
generation of specified generic types
As for me then everything is much more simple if Go language (as the
starting point) will introduce a non-reified generics.
Non reified generics does not requires a complex runtime support (static
code which was generated by the compiler will be enough).
Type checking of the type arguments perfo
A good compromise would be to only implement "parametric" functions. append
and make are" parametric" functions as they know what is their return type
at *compile time , *no matter what type the array/slice argument is . That
way people who don't want a generic type are happy as no generic type
87 matches
Mail list logo
