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
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 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
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 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>"
>> 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
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
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
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
56 matches
Mail list logo
