Re: [go-nuts] Reflecting on an outer struct from a method of an inner one.

[Nigel Tao]

On Fri, Sep 7, 2018 at 1:53 PM Eric Raymond  wrote:
> ...provided, that is, that it's possible to get from the member name to a 
> function pointer that can be called like a closure.  Does the reflection 
> system support such a call-indirect method?

Yep. No embedding or other inheritance-like feature needed:
https://play.golang.org/p/SPcJnV0VCr5

-- 
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.

Re: [go-nuts] Reflecting on an outer struct from a method of an inner one.

[Todd Neal]

Eric Raymond  writes:

> Obviously we can't use inheritance in the normal sense here, but I was 
> hoping that if an embedded instance of Cmd could discover the struct 
> instance it's part of, a similar thing could be pulled off.  Alas, your 
> answer that this can't be done is unsurprising and I was half expecting 
> it.  Calling one function to pass in the outer type beats having to declare 
> all the command handlers individually

There's no typename to reflected type or enumeration of all types that
implement a particular interface at runtime, unless you build it
yourself.

You might be interested in the init() documentation at
https://golang.org/doc/effective_go.html#init .  You can declare
multiple init functions (say one in each file where you define a
command), and if you write the registration when you write the command,
you would get the automatic registration you're looking for.  A 'gotcha'
to watch out for is that the init function won't run if the package
isn't imported, leading to imports like this:

import (
_ "github.com/someuser/somepackage"
)

which are common for the database drivers.  The package is imported
solely to cause the init function to run.  See
https://golang.org/doc/effective_go.html#blank_import for more info.

> ...provided, that is, that it's possible to get from the member name to a 
> function pointer that can be called like a closure.  Does the reflection 
> system support such a call-indirect method?

Sure, see an example I put together at
https://play.golang.org/p/divEOT31i-4  which shows two ways that the
receiver can be captured, one without reflection and one with.


- Todd

-- 
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.

Re: [go-nuts] Reflecting on an outer struct from a method of an inner one.

[Eric Raymond]

On Thursday, September 6, 2018 at 9:45:37 PM UTC-4, Nigel Tao wrote:
>
> Asking about embedding and reflection sounds like an XY problem 
> (http://xyproblem.info/). Can you elaborate on what "walk through the 
> user-defined methods of a Cmd-like interpreter instance" is? 
>

Sure.  My reposurgeon program uses the Python Cmd class:

https://docs.python.org/2/library/cmd.html

The Go translation needs an emulation of Cmd, which my talented and 
hardworking apprentice Ian Bruene has just shipped an 0.1 version of:

https://gitlab.com/ianbruene/Kommandant

The main remaining issue with his implementation is that he has to 
explicitly register command handlers, linking them to names. This is an 
obviously error-prone pain in the ass, and I want to make it work more like 
the Python original.  In that original, you declare a class that inherits 
from Cmd.  Cmd then walks through your interpreter class picking out method 
names beginning with "doX" and binding them to be fired by the command 
string X.

Obviously we can't use inheritance in the normal sense here, but I was 
hoping that if an embedded instance of Cmd could discover the struct 
instance it's part of, a similar thing could be pulled off.  Alas, your 
answer that this can't be done is unsurprising and I was half expecting 
it.  Calling one function to pass in the outer type beats having to declare 
all the command handlers individually

...provided, that is, that it's possible to get from the member name to a 
function pointer that can be called like a closure.  Does the reflection 
system support such a call-indirect method?

-- 
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.

[go-nuts] Re: Why can't we use unicode? [Go2 Generics]

[Fino]

need buy new keyboard to support these,

or by IME,  input method 

BR fino

在 2018年9月7日星期五 UTC+8上午7:34:36，ohir写道：
>
> I can not understand why, way in the XXIst century, in a language that 
> from 
> the beginning supports for unicode identifiers we are at ascii charset 
> overloading bikeshed. Why type `type` or (in other proposal $, or <> or [] 
> or 
> whatever<128) if I might press Super-T and get ʧ. Or press Super-G and get 
> ʭ. 
>
> I hear that only gurus will write generic code. Might it be, but thousands 
> of 
> rookies should be able to read this generic code before they make their 
> first 
> commit. 
>
> Gurus will know how to map their keyboards. Rookies on their (win) 
> machines 
> have circa 1000 glyphs in basic system fonts. (On any linux distro have 
> over 
> 3000). 
>
> Why on earth keep on ascii? 
>
> IPA: ʅ ʧ ʭ (0x285, 0x2a7, 0x2ad) 
> Latin-E: « » ¦ 
> Latin-A: Ħ ŧ Ŧ Ɏ 
> Latin-B: ǁ ǂ 
>
> -- 
> Wojciech S. Czarnecki 
>  << ^oo^ >> OHIR-RIPE 
>
>

-- 
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.

Re: [go-nuts] Reflecting on an outer struct from a method of an inner one.

[Nigel Tao]

On Fri, Sep 7, 2018 at 9:34 AM Eric Raymond  wrote:
> The attached program lists

For future reference, it would probably be easier for the mailing list
to discuss example code via a link to the Go playground, especially
for runnable code. In this case: https://play.golang.org/p/IripNZNYIgo


> In the attached program, I would like to be able to remove the  argument 
> from ListFields.  That is, I want the Inner code to be able to reflect on the 
> Outer instance without having to be fed the address of the Outer instance 
> explicitly.  I specifically do *not* want to move the method to Outer - 
> reflection  from within Inner is the point of the exercise.

The short answer is no, not possible. Embedding Inner is not
inheritance. It is essentially sugar, as if you said

type Outer struct {
fieldName Inner
id int
}

and for every method foo on Inner, there was an implicit forwarding method:

func (o *Outer) foo(etc) { o.fieldName.foo(etc) }

it's just that you don't have to explicitly type "fieldName", or those
forwarding methods.

But that's it. Unlike Java's "(almost) everything is an Object", a
value's type is a compile time concept, not a runtime one (ignoring
Go's interface types, for now). If you have an Inner, all you have is
an Inner, and you can't distinguish "an Inner inside an Outer struct"
or "an Inner inside an array of 10 Inners" or "an Inner inside a Bar
struct inside a Qux struct". But also unlike Java, you can embed
multiple concrete types (the embeddee also doesn't have to be the
first field), just like a struct can have multiple fields: "type Outer
struct { Inner0; Inner1; id int; Inner3; }".

To repeat, embedding isn't inheritance. It's not that the Outer value
is-a Inner, it's that it contains-a Inner.


> Is there a way for a struct instance to get its own address through the 
> runtime?

In "func (x *Inner) Etc(etc)", the address of the struct is the
variable "x": https://play.golang.org/p/PP7LKDxEHrg

But I don't think that's going to help you. You can't go from a
pointer-to-Inner to a pointer-to-Outer without knowing (i.e. passing)
the Outer type (assuming that there's more than one Outer type), and
if you're passing the Outer type, you might as well pass the Outer
pointer.


> The application would be to walk through the user-defined methods of a 
> Cmd-like interpreter instance.

Asking about embedding and reflection sounds like an XY problem
(http://xyproblem.info/). Can you elaborate on what "walk through the
user-defined methods of a Cmd-like interpreter instance" is?

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[Nigel Tao]

On Fri, Sep 7, 2018 at 9:29 AM 'Axel Wagner' via golang-nuts
 wrote:
> On Fri, Sep 7, 2018 at 12:37 AM Ian Lance Taylor  wrote:
>> Interesting point.  But is there any way to solve it short of
>> explicitly listing types?  Is there any generics system in any
>> language that avoids this problem?
>
> I'm not saying this would be the solution, but since you asked: Refinement 
> types (implemented e.g. in Liquid Haskell).

Drifting off-topic, but while refinement types sound similar, they're
not really applicable (and refinement types are obviously type related
but not generics related), right?

IIUC, refinement lets you narrow the set of acceptable *values*,
starting from a given *type*. For example, given an "integer" type,
derive a new type "positive integer", or given a "binary tree" type,
derive a new type "balanced binary tree". Refinements are predicates
on *values*: whether or not a value is in the smaller subset.

But what we'd want here is predicates on *types*, such as "we accept
all numeric types T that can represent -1". It's not immediately
obvious how to express a type-predicate using value-predicates
(refinements). It's also not obvious, starting from any given type,
how to 'narrow' it (conditional on *value*) to enforce "the *type* can
represent -1", or if that's even the right way to think about it.

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[xingtao zhao]

Aha, I see what the other set of operators are. While what I thought still 
stands: All of these operators should be handled by the compiler, the user 
no need to think about them at all - let the compiler retrieves them 
implicitly from the function body. In terms of convertible, I think it is 
neat to express them in contract.

On Thursday, September 6, 2018 at 5:12:08 PM UTC-7, Axel Wagner wrote:
>
> On Fri, Sep 7, 2018 at 2:00 AM xingtao zhao  > wrote:
>
>> Try to raise my point here (from another thread):
>>
>> I think all of the operator constraints should be retrieved implicitly. 
>> The proposal of the contract on operators seems a design flaw to me: why do 
>> we express that if < is in the contract, all other operators are also 
>> allowed? I think we do not have to express them in contract. In go, we may 
>> add new methods to a type, but we can not change the operator set. This 
>> means that there are only few operator sets: arithmetic operators, equality 
>> operators, dereference operator, addable(?). I can not figure out other set 
>> of operators.
>>
>
> There is also ==nil (which works differently from == itself), the 
> arithmetic operators split into multiple classes (floats/complex don't have 
> % or <>), you have real/imag/complex, make, make2, make3, an unbounded 
> number of index(K,V), <-, ->, close, [:], copy, append, dereferencing, an 
> unbounded number of convertible(T), assignable(T)…
> I think I've run out.
>
> I'm not saying this is not possible to model with a relatively small set 
> of constraints (especially if you're fine ignoring the less important 
> ones), but it's not *quite* as simple.
>
> And in go, as we never concern about the operators availability before, I 
>> think in generic we could still keep the same and just let the compiler 
>> knows these constraints on operators. 
>>
>> It is still good to be able to explicitly express type conversion in 
>> contract, which is very clear. 
>>
>> On Thursday, September 6, 2018 at 4:29:55 PM UTC-7, Axel Wagner wrote:
>>>
>>> On Fri, Sep 7, 2018 at 12:37 AM Ian Lance Taylor  
>>> wrote:
>>>
 On Thu, Sep 6, 2018 at 3:04 PM, Axel Wagner
  wrote:
 Interesting point.  But is there any way to solve it short of
 explicitly listing types?  Is there any generics system in any
 language that avoids this problem?

>>>
>>> I'm not saying this would be the solution, but since you asked: 
>>> Refinement types (implemented e.g. in Liquid Haskell).
>>>
>>> But FWIW, I was using that as an example. There are others, where e.g. 
>>> range allows ranging, but has vastly different semantics for string, map, 
>>> channel and slice. Or the string(v) example I mentioned, where []rune 
>>> passes the contract
>>> contract foo(v T) {
>>> for i, b := range string(v) {
>>> }
>>> }
>>> But if the author was not considering that, might end up with unexpected 
>>> results when indexing. Or make(T, N), which is semantically very different 
>>> for maps, channels and slices (among other things, for slices, 
>>> len(make(T,N)) == N, for the others len(make(T,N)) == 0).
>>>
>>> The other day I had a lengthy conversation with Rog Peppe, David 
>>> Crawshaw and Nate Finch on twitter and I'd argue that neither of us would 
>>> really count as a Go-novice and we *still* weren't always clear what types 
>>> certain contracts allowed and excluded.
>>>
>>> I believe that these cases will become more and more clear, when it 
>>> comes to actually write a type-checker, so I don't even really think we 
>>> have to talk about all of them or compile a list. I just went away from 
>>> having these conversations with the clear impression that contracts are a 
>>> non-obvious way to express constraints.
>>>
>>> I think it is clear that we are not going to do that.

>>>
>>> But there will be *some* implied capabilities, I assume (and FWIW, the 
>>> example I mentioned is IMO pretty similar to ==/!= and />=). For 
>>> example, the design explicitly calls out that == will allow using something 
>>> as a map-key:
>>>
>>> https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#map-keys
>>> Note, that contract { var _ map[T]bool } would also work and be 
>>> explicit. But it already shows that at least *some* implicit constraints 
>>> will probably be desirable.
>>>
>>> I understand the arguments in favor of contracts. Personally, I just 
>>> tend to think that the disadvantages outweigh them. But that's just, like, 
>>> my opinion :) There's still lots of time to see.
>>>
>>> > Of course that doesn't *have* to happen - you could just literally only
 > allow the expressions given in the contract, but then the contract
 > potentially becomes very verbose, as it has to cover lots of ground. 
 For
 > example, `a[0]` allows integer-indexing, but it technically only 
 allows to
 > pass 0. Extending that to arbitrary integers is what's probably going 
 to
 > happen (and an example of an 

Re: [go-nuts] Re: Generics as builtin typeclasses

['Axel Wagner' via golang-nuts]

On Fri, Sep 7, 2018 at 2:00 AM xingtao zhao  wrote:

> Try to raise my point here (from another thread):
>
> I think all of the operator constraints should be retrieved implicitly.
> The proposal of the contract on operators seems a design flaw to me: why do
> we express that if < is in the contract, all other operators are also
> allowed? I think we do not have to express them in contract. In go, we may
> add new methods to a type, but we can not change the operator set. This
> means that there are only few operator sets: arithmetic operators, equality
> operators, dereference operator, addable(?). I can not figure out other set
> of operators.
>

There is also ==nil (which works differently from == itself), the
arithmetic operators split into multiple classes (floats/complex don't have
% or <>), you have real/imag/complex, make, make2, make3, an unbounded
number of index(K,V), <-, ->, close, [:], copy, append, dereferencing, an
unbounded number of convertible(T), assignable(T)…
I think I've run out.

I'm not saying this is not possible to model with a relatively small set of
constraints (especially if you're fine ignoring the less important ones),
but it's not *quite* as simple.

And in go, as we never concern about the operators availability before, I
> think in generic we could still keep the same and just let the compiler
> knows these constraints on operators.
>
> It is still good to be able to explicitly express type conversion in
> contract, which is very clear.
>
> On Thursday, September 6, 2018 at 4:29:55 PM UTC-7, Axel Wagner wrote:
>>
>> On Fri, Sep 7, 2018 at 12:37 AM Ian Lance Taylor 
>> wrote:
>>
>>> On Thu, Sep 6, 2018 at 3:04 PM, Axel Wagner
>>>  wrote:
>>> Interesting point.  But is there any way to solve it short of
>>> explicitly listing types?  Is there any generics system in any
>>> language that avoids this problem?
>>>
>>
>> I'm not saying this would be the solution, but since you asked:
>> Refinement types (implemented e.g. in Liquid Haskell).
>>
>> But FWIW, I was using that as an example. There are others, where e.g.
>> range allows ranging, but has vastly different semantics for string, map,
>> channel and slice. Or the string(v) example I mentioned, where []rune
>> passes the contract
>> contract foo(v T) {
>> for i, b := range string(v) {
>> }
>> }
>> But if the author was not considering that, might end up with unexpected
>> results when indexing. Or make(T, N), which is semantically very different
>> for maps, channels and slices (among other things, for slices,
>> len(make(T,N)) == N, for the others len(make(T,N)) == 0).
>>
>> The other day I had a lengthy conversation with Rog Peppe, David Crawshaw
>> and Nate Finch on twitter and I'd argue that neither of us would really
>> count as a Go-novice and we *still* weren't always clear what types certain
>> contracts allowed and excluded.
>>
>> I believe that these cases will become more and more clear, when it comes
>> to actually write a type-checker, so I don't even really think we have to
>> talk about all of them or compile a list. I just went away from having
>> these conversations with the clear impression that contracts are a
>> non-obvious way to express constraints.
>>
>> I think it is clear that we are not going to do that.
>>>
>>
>> But there will be *some* implied capabilities, I assume (and FWIW, the
>> example I mentioned is IMO pretty similar to ==/!= and />=). For
>> example, the design explicitly calls out that == will allow using something
>> as a map-key:
>>
>> https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#map-keys
>> Note, that contract { var _ map[T]bool } would also work and be explicit.
>> But it already shows that at least *some* implicit constraints will
>> probably be desirable.
>>
>> I understand the arguments in favor of contracts. Personally, I just tend
>> to think that the disadvantages outweigh them. But that's just, like, my
>> opinion :) There's still lots of time to see.
>>
>> > Of course that doesn't *have* to happen - you could just literally only
>>> > allow the expressions given in the contract, but then the contract
>>> > potentially becomes very verbose, as it has to cover lots of ground.
>>> For
>>> > example, `a[0]` allows integer-indexing, but it technically only
>>> allows to
>>> > pass 0. Extending that to arbitrary integers is what's probably going
>>> to
>>> > happen (and an example of an implicit capability) - but then that code
>>> is
>>> > less type-safe then it needs to be, as Arrays already provide tight
>>> bounds
>>> > for constant-indices. You can say that `a[N]` then allows indexing
>>> with any
>>> > constant <= N (to make those bounds explicit), but at that point I
>>> would
>>> > criticize that the argument "contracts are just familiar Go syntax"
>>> becomes
>>> > less and less convincing, because you are introducing all these special
>>> > semantical meanings to expressions.
>>>
>>> Sure, but I didn't introduce them.  Go already 

Re: [go-nuts] Why can't we use unicode? [Go2 Generics]

[Mhd Shulhan]

>
> Why on earth keep on ascii?
>
> IPA: ʅ ʧ ʭ (0x285, 0x2a7, 0x2ad)
> Latin-E: « » ¦
> Latin-A: Ħ ŧ Ŧ Ɏ
> Latin-B: ǁ ǂ
>

Probably because its hard to type on most non ASCII keyboard.

>

-- 
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.

Re: [go-nuts] Why can't we use unicode? [Go2 Generics]

['Axel Wagner' via golang-nuts]

And while we're at it, why "func", instead of the far simpler λ, or "type"
instead of τ, or "include", instead of ι, "const" instead of κ and "war"
instead of ω. We can do ρ instead of "range", φ instead of "for", ν is
"new" and μ is "make", obviously. And while we're at it, let's also use ≥
and ≤ and ≠. No * and /, just • and ÷. ¬, ∨, ∧ of course for booleans. ←
and → for channel ops and short variable declaration with ≔.

The answer is, that most people don't know how to enter any of these and
the ones that do don't want to be bothered having to change their
keyboard-mapping or hammering there num-block for every (or, really, any)
line of code :)

On Fri, Sep 7, 2018 at 1:34 AM Wojciech S. Czarnecki 
wrote:

> I can not understand why, way in the XXIst century, in a language that from
> the beginning supports for unicode identifiers we are at ascii charset
> overloading bikeshed. Why type `type` or (in other proposal $, or <> or []
> or
> whatever<128) if I might press Super-T and get ʧ. Or press Super-G and get
> ʭ.
>
> I hear that only gurus will write generic code. Might it be, but thousands
> of
> rookies should be able to read this generic code before they make their
> first
> commit.
>
> Gurus will know how to map their keyboards. Rookies on their (win) machines
> have circa 1000 glyphs in basic system fonts. (On any linux distro have
> over
> 3000).
>
> Why on earth keep on ascii?
>
> IPA: ʅ ʧ ʭ (0x285, 0x2a7, 0x2ad)
> Latin-E: « » ¦
> Latin-A: Ħ ŧ Ŧ Ɏ
> Latin-B: ǁ ǂ
>
> --
> Wojciech S. Czarnecki
>  << ^oo^ >> OHIR-RIPE
>
> --
> 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.
>

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[xingtao zhao]

Try to raise my point here (from another thread):

I think all of the operator constraints should be retrieved implicitly. The 
proposal of the contract on operators seems a design flaw to me: why do we 
express that if < is in the contract, all other operators are also allowed? 
I think we do not have to express them in contract. In go, we may add new 
methods to a type, but we can not change the operator set. This means that 
there are only few operator sets: arithmetic operators, equality operators, 
dereference operator, addable(?). I can not figure out other set of 
operators. And in go, as we never concern about the operators availability 
before, I think in generic we could still keep the same and just let the 
compiler knows these constraints on operators. 

It is still good to be able to explicitly express type conversion in 
contract, which is very clear. 

On Thursday, September 6, 2018 at 4:29:55 PM UTC-7, Axel Wagner wrote:
>
> On Fri, Sep 7, 2018 at 12:37 AM Ian Lance Taylor  > wrote:
>
>> On Thu, Sep 6, 2018 at 3:04 PM, Axel Wagner
>> > wrote:
>> Interesting point.  But is there any way to solve it short of
>> explicitly listing types?  Is there any generics system in any
>> language that avoids this problem?
>>
>
> I'm not saying this would be the solution, but since you asked: Refinement 
> types (implemented e.g. in Liquid Haskell).
>
> But FWIW, I was using that as an example. There are others, where e.g. 
> range allows ranging, but has vastly different semantics for string, map, 
> channel and slice. Or the string(v) example I mentioned, where []rune 
> passes the contract
> contract foo(v T) {
> for i, b := range string(v) {
> }
> }
> But if the author was not considering that, might end up with unexpected 
> results when indexing. Or make(T, N), which is semantically very different 
> for maps, channels and slices (among other things, for slices, 
> len(make(T,N)) == N, for the others len(make(T,N)) == 0).
>
> The other day I had a lengthy conversation with Rog Peppe, David Crawshaw 
> and Nate Finch on twitter and I'd argue that neither of us would really 
> count as a Go-novice and we *still* weren't always clear what types certain 
> contracts allowed and excluded.
>
> I believe that these cases will become more and more clear, when it comes 
> to actually write a type-checker, so I don't even really think we have to 
> talk about all of them or compile a list. I just went away from having 
> these conversations with the clear impression that contracts are a 
> non-obvious way to express constraints.
>
> I think it is clear that we are not going to do that.
>>
>
> But there will be *some* implied capabilities, I assume (and FWIW, the 
> example I mentioned is IMO pretty similar to ==/!= and />=). For 
> example, the design explicitly calls out that == will allow using something 
> as a map-key:
>
> https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#map-keys
> Note, that contract { var _ map[T]bool } would also work and be explicit. 
> But it already shows that at least *some* implicit constraints will 
> probably be desirable.
>
> I understand the arguments in favor of contracts. Personally, I just tend 
> to think that the disadvantages outweigh them. But that's just, like, my 
> opinion :) There's still lots of time to see.
>
> > Of course that doesn't *have* to happen - you could just literally only
>> > allow the expressions given in the contract, but then the contract
>> > potentially becomes very verbose, as it has to cover lots of ground. For
>> > example, `a[0]` allows integer-indexing, but it technically only allows 
>> to
>> > pass 0. Extending that to arbitrary integers is what's probably going to
>> > happen (and an example of an implicit capability) - but then that code 
>> is
>> > less type-safe then it needs to be, as Arrays already provide tight 
>> bounds
>> > for constant-indices. You can say that `a[N]` then allows indexing with 
>> any
>> > constant <= N (to make those bounds explicit), but at that point I would
>> > criticize that the argument "contracts are just familiar Go syntax" 
>> becomes
>> > less and less convincing, because you are introducing all these special
>> > semantical meanings to expressions.
>>
>> Sure, but I didn't introduce them.  Go already permits indexing [N]int
>> with variables with values larger than N.  Go has no way of expressing
>> that kind of type constraints.  I don't see any reason why we should
>> try to express it in a generics implementation.
>>
>> Ian
>>
>

-- 
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.

[go-nuts] Re: [ANN] goey - Declarative, cross-platform GUIs

[Richard Wilkes]

Hi, Robert.

Do you have any plans to add macOS support to this?

- Rich

On Wednesday, September 5, 2018 at 9:07:41 PM UTC-7, Robert Johnstone wrote:
>
> This is an initial announcement of goey, a package for declarative, 
> cross-platform GUIs.  The range of controls, their supported properties and 
> events, should roughly match what is available in HTML.  However, 
> properties and events may be limited to support portability.  Additionally, 
> styling of the controls will be limited, with the look of controls matching 
> the native platform.
>
> A minimal example of a complete application can be found at 
> https://godoc.org/bitbucket.org/rj/goey/example/onebutton.
>
> * README:  https://bitbucket.org/rj/goey/src/default/README.md
> * godoc: https://godoc.org/bitbucket.org/rj/goey
>
> Feedback welcome.
>
>

-- 
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.

[go-nuts] Reflecting on an outer struct from a method of an inner one.

[Eric Raymond]

This question is intended to assist implementation of a Go workalike for 
the Python Cmd library.  This workalike will be made publicly available,

The attached program lists

Inner
id

as expected - that is, the fieldnames of the Outer structure. But 
ListFields is a method of Inner.

In the attached program, I would like to be able to remove the  argument 
from ListFields.  That is, I want the Inner code to be able to reflect on 
the Outer instance without having to be fed the address of the Outer 
instance explicitly.  I specifically do *not* want to move the method to 
Outer - reflection  from within Inner is the point of the exercise.

Is there a way for a struct instance to get its own address through the 
runtime? 

The application would be to walk through the user-defined methods of a 
Cmd-like interpreter instance.

-- 
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.


innerclass.go
Description: Binary data

[go-nuts] Why can't we use unicode? [Go2 Generics]

[Wojciech S. Czarnecki]

I can not understand why, way in the XXIst century, in a language that from
the beginning supports for unicode identifiers we are at ascii charset
overloading bikeshed. Why type `type` or (in other proposal $, or <> or [] or
whatever<128) if I might press Super-T and get ʧ. Or press Super-G and get ʭ.

I hear that only gurus will write generic code. Might it be, but thousands of
rookies should be able to read this generic code before they make their first
commit.

Gurus will know how to map their keyboards. Rookies on their (win) machines
have circa 1000 glyphs in basic system fonts. (On any linux distro have over
3000).

Why on earth keep on ascii?

IPA: ʅ ʧ ʭ (0x285, 0x2a7, 0x2ad)
Latin-E: « » ¦ 
Latin-A: Ħ ŧ Ŧ Ɏ 
Latin-B: ǁ ǂ 

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

['Axel Wagner' via golang-nuts]

On Fri, Sep 7, 2018 at 12:37 AM Ian Lance Taylor  wrote:

> On Thu, Sep 6, 2018 at 3:04 PM, Axel Wagner
>  wrote:
> Interesting point.  But is there any way to solve it short of
> explicitly listing types?  Is there any generics system in any
> language that avoids this problem?
>

I'm not saying this would be the solution, but since you asked: Refinement
types (implemented e.g. in Liquid Haskell).

But FWIW, I was using that as an example. There are others, where e.g.
range allows ranging, but has vastly different semantics for string, map,
channel and slice. Or the string(v) example I mentioned, where []rune
passes the contract
contract foo(v T) {
for i, b := range string(v) {
}
}
But if the author was not considering that, might end up with unexpected
results when indexing. Or make(T, N), which is semantically very different
for maps, channels and slices (among other things, for slices,
len(make(T,N)) == N, for the others len(make(T,N)) == 0).

The other day I had a lengthy conversation with Rog Peppe, David Crawshaw
and Nate Finch on twitter and I'd argue that neither of us would really
count as a Go-novice and we *still* weren't always clear what types certain
contracts allowed and excluded.

I believe that these cases will become more and more clear, when it comes
to actually write a type-checker, so I don't even really think we have to
talk about all of them or compile a list. I just went away from having
these conversations with the clear impression that contracts are a
non-obvious way to express constraints.

I think it is clear that we are not going to do that.
>

But there will be *some* implied capabilities, I assume (and FWIW, the
example I mentioned is IMO pretty similar to ==/!= and />=). For
example, the design explicitly calls out that == will allow using something
as a map-key:
https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#map-keys
Note, that contract { var _ map[T]bool } would also work and be explicit.
But it already shows that at least *some* implicit constraints will
probably be desirable.

I understand the arguments in favor of contracts. Personally, I just tend
to think that the disadvantages outweigh them. But that's just, like, my
opinion :) There's still lots of time to see.

> Of course that doesn't *have* to happen - you could just literally only
> > allow the expressions given in the contract, but then the contract
> > potentially becomes very verbose, as it has to cover lots of ground. For
> > example, `a[0]` allows integer-indexing, but it technically only allows
> to
> > pass 0. Extending that to arbitrary integers is what's probably going to
> > happen (and an example of an implicit capability) - but then that code is
> > less type-safe then it needs to be, as Arrays already provide tight
> bounds
> > for constant-indices. You can say that `a[N]` then allows indexing with
> any
> > constant <= N (to make those bounds explicit), but at that point I would
> > criticize that the argument "contracts are just familiar Go syntax"
> becomes
> > less and less convincing, because you are introducing all these special
> > semantical meanings to expressions.
>
> Sure, but I didn't introduce them.  Go already permits indexing [N]int
> with variables with values larger than N.  Go has no way of expressing
> that kind of type constraints.  I don't see any reason why we should
> try to express it in a generics implementation.
>
> Ian
>

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[jimmy frasche]

> > Hypothetically, if Go introduced generics where you couldn't write
> > min/max but included min/max builtins, what's the next smallest
> > example where operators are necessary?
>
> // Contains returns whether v is in the slice s.
> func Contains(type T)(s []T, v T) bool {
> for _, x := range s {
> if x == v {
> return true
> }
> }
> return false
> }

That's true. You can have this with interfaces as type constraints
with https://github.com/golang/go/issues/27481 however. That's the
minimally-necessary operator since comparing things is going to come
up more than anything else and == is the only operator not limited to
a small family of types.

There's still the problem with Equals vs ==, but that's a fundamental problem.

> > I'd be happy with generics if I needed to sometimes write a little bit
> > of code to do a few  things but didn't have to write a tremendous
> > amount of code to do most things. That seems like a good trade off,
> > even if it's not necessarily a popular one.
>
> But you can already do that, though, using interfaces.  Before we
> added sort.Slice, people complained quite a bit about sort.Interface,
> and that only required three lines.  Heck, people still complain that
> we have sort.Ints but not sort.Int32s.

In some cases like that. You can't have generic homogeneous type-safe
containers without some form of generics. That was the sort of thing I
was referring to: If I had to write a wrapper type with a Less method
to use a generic B-Tree that's not a big deal compared with writing an
entire B-Tree specialized to a certain type or having to wrap the
whole api to make it type safe.

Very few of the things I've wanted to do with generic require anything
other than at most == and convertibility. The lack of < would be
annoying at times but it's trivial to work around.

> > You could also write a min/max that operates on types with a Less
> > method, like you could under the various just-interfaces schemes.
> >
> > But you can't write one that works on both.
>
> Yes.  Though I'm not clear on whether people want that.  I think we
> need experience with real code here.
>
> If experience show us that this is important, my current guess is that
> the path forward here for Go is type adaptors, in which we say
> something like "if T implements contract C1, then you can
> automatically add this wrapper type and the wrapper type will
> implement contract C2."  But I think that is clearly a problem for
> later.

I forget where, but at some point I mentioned there could be equals(x,
y) and less(x, y) builtins that
- use x.Less(y) if it exists
- if not, use x < y
- if neither fail to compile.
(or Equals/== respectively)

Then you can use them in the contract and generic bodies. That would
only work with the contract proposal and not any of the interface
ones.

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[Ian Lance Taylor]

On Thu, Sep 6, 2018 at 3:04 PM, Axel Wagner
 wrote:
>
> On Thu, Sep 6, 2018 at 9:45 PM Ian Lance Taylor  wrote:
>>
>> On Thu, Sep 6, 2018 at 10:29 AM, jimmy frasche 
>> wrote:
>>
>> This is clearly a key issue.  I happen to think that contracts are
>> fairly clear for the reader: take your type argument and see if the
>> contract body works.  I feel that everyone who knows Go will be able
>> to do that.  But maybe that's just me.
>
>
> I agree with you on this. But I don't think it's enough. To be type-safe
> (from the author perspective), you also need to do the opposite: Take any
> *other* type and make sure that it *doesn't* pass the contract. Because
> otherwise, you might end up with a program that compiles, but is crashing or
> otherwise invalid. And that's what made me turn against contracts, lately.
>
> I name a couple examples in my blog post (linked upthread), but as it just
> came up during a talk at the Zurich Go Meetup: For example, you might have a
> contract like `t%1`, to ensure you get an integer type (sorry, that is
> ad-hoc the best way I can come up to write that contract). Now, say a
> generic function uses that type-parameter for a loop-counter, counting down:
> `for i := T(N); i >= 0; i-- { … }`. They check that `int` types pass their
> contract and everything goes smoothly. At some point, someone uses the
> function with a `uint` argument and you get an endless loop.

Interesting point.  But is there any way to solve it short of
explicitly listing types?  Is there any generics system in any
language that avoids this problem?


> Now, this example is constructed. It will probably not occur in practice.
> But it illustrates why I believe contracts make it relatively hard to write
> type-safe generic code - because the contract does not only has to allow
> everything you want to do, it also has to disallow anything you don't.
> Expressing that syntactically is much harder.
> This gets exacerbated by implied capabilities (though it's not clear yet if
> and how much they exist): i.e. the compiler could prove that only integer
> types allow `%`, so if you put down that constraint, it also allows `+`,
> `*`, conversions to float…

I think it is clear that we are not going to do that.


> Of course that doesn't *have* to happen - you could just literally only
> allow the expressions given in the contract, but then the contract
> potentially becomes very verbose, as it has to cover lots of ground. For
> example, `a[0]` allows integer-indexing, but it technically only allows to
> pass 0. Extending that to arbitrary integers is what's probably going to
> happen (and an example of an implicit capability) - but then that code is
> less type-safe then it needs to be, as Arrays already provide tight bounds
> for constant-indices. You can say that `a[N]` then allows indexing with any
> constant <= N (to make those bounds explicit), but at that point I would
> criticize that the argument "contracts are just familiar Go syntax" becomes
> less and less convincing, because you are introducing all these special
> semantical meanings to expressions.

Sure, but I didn't introduce them.  Go already permits indexing [N]int
with variables with values larger than N.  Go has no way of expressing
that kind of type constraints.  I don't see any reason why we should
try to express it in a generics implementation.

Ian

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[Ian Lance Taylor]

On Thu, Sep 6, 2018 at 2:35 PM, jimmy frasche  wrote:
>
>> It's not necessary to support fields but I think it really is
>> necessary to support operators.  I claim that, other than type safe
>> data structures, the number one generic function that people want to
>> write is Min (or Max).  I don't think we can plausible add a generics
>> system to Go that doesn't permit writing a Min function.
>
> Hypothetically, if Go introduced generics where you couldn't write
> min/max but included min/max builtins, what's the next smallest
> example where operators are necessary?

// Contains returns whether v is in the slice s.
func Contains(type T)(s []T, v T) bool {
for _, x := range s {
if x == v {
return true
}
}
return false
}


> I'd be happy with generics if I needed to sometimes write a little bit
> of code to do a few  things but didn't have to write a tremendous
> amount of code to do most things. That seems like a good trade off,
> even if it's not necessarily a popular one.

But you can already do that, though, using interfaces.  Before we
added sort.Slice, people complained quite a bit about sort.Interface,
and that only required three lines.  Heck, people still complain that
we have sort.Ints but not sort.Int32s.


> But you can't really write a generic min/max with the contracts proposal.
>
> You can write a min/max that operates on all the ordered types, sure.
>
> (The one in the proposal has a bug because it accepts float types but
> doesn't handle the special cases for floats. That can't be repaired
> because while you could assert to float32 or float64 you couldn't
> assert to type MyFloat float64. Though I'm sure there's some contract
> where you can specify < but not floats.)

I think that for most people the Min I wrote above is acceptable even
for floats.

You can write one specifically for floats by having the contract
require convertibility to `float64`, and using `math.IsNaN`.


> You could also write a min/max that operates on types with a Less
> method, like you could under the various just-interfaces schemes.
>
> But you can't write one that works on both.

Yes.  Though I'm not clear on whether people want that.  I think we
need experience with real code here.

If experience show us that this is important, my current guess is that
the path forward here for Go is type adaptors, in which we say
something like "if T implements contract C1, then you can
automatically add this wrapper type and the wrapper type will
implement contract C2."  But I think that is clearly a problem for
later.


> Even ignoring that, the contracts proposal doesn't let you write a
> generic variadic min/max since there's no way to get the
> smallest/largest value of a type so you can't write
>
> func min(type T ordered)(ts ...T) T {
>   min := LargestPossible(T) // not possible
>   for _, t := range {
> if t < min {
>   min = t
> }
>   }
>   return min
> }
>
> You could get around that with the signature (firstOne T, rest ...T)
> but there's a larger point about the necessity of knowing numeric
> limits and properties for writing that kind of generic code in there.

I agree that this proposal doesn't help with numeric limits.  For that
you have to reach for the reflect package.  I don't know of any other
proposal that does any better in this regard.

For what it's worth, you can write variadic Min like this:

func Min(type T ordered)(s ...T) T {
if len(s) == 0 {
var zero T
return T // or panic or something.
}
m := s[0]
for _, v := range s[1:] {
if v < m {
m = v
}
}
return m
}


> One way around the asymmetry between operators and methods that
> doesn't introduce any issues like operator methods or any of that is
> to have a package that defines types like
>
> package basic // not the best name
>
> type Int int
>
> type Slice(type T) []T
>
> // and so on for all the primitive and basic composite types
>
> and give all of those methods like Less and At. You'd have to do
> int(min(basic.Int(x), basic.Int(y))) but at least you wouldn't have to
> write the trivial wrapper methods. Not especially pretty.

I agree: not pretty.

Ian

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

['Axel Wagner' via golang-nuts]

My point was that type-classes don't really help in and off itself. What
helps is that operators are methods (i.e. Haskell has operator
overloading). If Go had operator methods, that would work too (obviously),
because you could write an interface for them.

Anyway :)


On Fri, Sep 7, 2018 at 12:21 AM jimmy frasche 
wrote:

> I meant without having to use a wrapper but still accepting all three.
> I certainly agree that it not the Go way or the way to go.
> On Thu, Sep 6, 2018 at 3:16 PM Axel Wagner
>  wrote:
> >
> > On Thu, Sep 6, 2018 at 11:36 PM jimmy frasche 
> wrote:
> >>
> >> To unify those cases you need something like haskell-style typeclasses
> >> where you can say this type satisfies this contract using these
> >> methods/operators.
> >
> >
> > FWIW, the Go way of doing that is embedding it in a new struct and
> overwriting the methods - which is pretty much the only way to do it while
> maintaining the property that only the owner of a type can define methods
> on it.
> >
> > So, you can already do this. But it requires you to write it. Which is
> boilerplate.
> > (which I'm personally fine with, FTR :) )
> >
> >>
> >>
> >>
> >> Even ignoring that, the contracts proposal doesn't let you write a
> >> generic variadic min/max since there's no way to get the
> >> smallest/largest value of a type so you can't write
> >>
> >> func min(type T ordered)(ts ...T) T {
> >>   min := LargestPossible(T) // not possible
> >>   for _, t := range {
> >> if t < min {
> >>   min = t
> >> }
> >>   }
> >>   return min
> >> }
> >>
> >> You could get around that with the signature (firstOne T, rest ...T)
> >> but there's a larger point about the necessity of knowing numeric
> >> limits and properties for writing that kind of generic code in there.
> >>
> >>
> >> One way around the asymmetry between operators and methods that
> >> doesn't introduce any issues like operator methods or any of that is
> >> to have a package that defines types like
> >>
> >> package basic // not the best name
> >>
> >> type Int int
> >>
> >> type Slice(type T) []T
> >>
> >> // and so on for all the primitive and basic composite types
> >>
> >> and give all of those methods like Less and At. You'd have to do
> >> int(min(basic.Int(x), basic.Int(y))) but at least you wouldn't have to
> >> write the trivial wrapper methods. Not especially pretty.
> >>
> >> --
> >> 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.
>

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[jimmy frasche]

I meant without having to use a wrapper but still accepting all three.
I certainly agree that it not the Go way or the way to go.
On Thu, Sep 6, 2018 at 3:16 PM Axel Wagner
 wrote:
>
> On Thu, Sep 6, 2018 at 11:36 PM jimmy frasche  wrote:
>>
>> To unify those cases you need something like haskell-style typeclasses
>> where you can say this type satisfies this contract using these
>> methods/operators.
>
>
> FWIW, the Go way of doing that is embedding it in a new struct and 
> overwriting the methods - which is pretty much the only way to do it while 
> maintaining the property that only the owner of a type can define methods on 
> it.
>
> So, you can already do this. But it requires you to write it. Which is 
> boilerplate.
> (which I'm personally fine with, FTR :) )
>
>>
>>
>>
>> Even ignoring that, the contracts proposal doesn't let you write a
>> generic variadic min/max since there's no way to get the
>> smallest/largest value of a type so you can't write
>>
>> func min(type T ordered)(ts ...T) T {
>>   min := LargestPossible(T) // not possible
>>   for _, t := range {
>> if t < min {
>>   min = t
>> }
>>   }
>>   return min
>> }
>>
>> You could get around that with the signature (firstOne T, rest ...T)
>> but there's a larger point about the necessity of knowing numeric
>> limits and properties for writing that kind of generic code in there.
>>
>>
>> One way around the asymmetry between operators and methods that
>> doesn't introduce any issues like operator methods or any of that is
>> to have a package that defines types like
>>
>> package basic // not the best name
>>
>> type Int int
>>
>> type Slice(type T) []T
>>
>> // and so on for all the primitive and basic composite types
>>
>> and give all of those methods like Less and At. You'd have to do
>> int(min(basic.Int(x), basic.Int(y))) but at least you wouldn't have to
>> write the trivial wrapper methods. Not especially pretty.
>>
>> --
>> 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.

-- 
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.

Re: [go-nuts] A thought on contracts

[David Anderson]

On Thu, Sep 6, 2018 at 3:16 PM Thomas Wilde 
wrote:

> Thanks for the response. I think the question then becomes: if the syntax
> in contract bodies was an unrestricted Go block, then why do I need to
> repeat my function's operations in a contract?
>
> If the syntax of contract bodies is free, then the Go compiler could
> easily deduce all my constraints from a function body directly -- no need
> for a separate contract.
>

Having a separate contract constrains *both* the caller and the
implementation. If you infer a contract from the implementation, it's
trivial to break all your callers by accidentally adding new assumptions to
your implementation.

With a contract in place, changing the implementation in an incompatible
way is a compile error - "hey, your implementation is trying to do stuff
your contract doesn't allow!" This makes it hard to accidentally break your
callers, because you have to take an explicit action to change the
contract, if you want to allow your implementation to do more things.

- Dave


>
> Thanks again and all the best,
> - Tom
>
> On Thu, Sep 6, 2018, 22:26 Ian Lance Taylor  wrote:
>
>> On Tue, Sep 4, 2018 at 7:41 AM, thwd  wrote:
>> >
>> > From the draft proposal I gather two open questions:
>> >  - How free or restricted should contract bodies be?
>>
>> I believe it's useful to have contract bodies simply be arbitrary
>> function bodies, as the current design draft suggests.  This is
>> because I believe that is conceptually the simplest choice.  You don't
>> have to remember two different syntaxes, one for code and one for
>> contract bodies.  You just have to remember a single syntax, one you
>> must know in any case to write any Go code at all.
>>
>> >  - How many implicit constraints can be inferred from usage?
>>
>> As few as we can get away with.
>>
>>
>> > If too much syntax is allowed in contract bodies and no implicit
>> constraints
>> > are gathered:
>> > people will copy and paste function bodies into contracts to cover all
>> > constraints.
>>
>> People do suggest that that will happen but I think it is extremely
>> unlikely in practice.  It's obviously a terrible coding style, and
>> almost all generic functions have trivial contract requirements.
>>
>> Ian
>>
> --
> 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.
>

-- 
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.

Re: [go-nuts] A thought on contracts

[jimmy frasche]

If the contract for a type is entirely inferred in order to know the
types it accepts you have to read all of its code, every line. The
contract let's you boil that down to the salient points so you can
read line a few lines instead of a few hundred or a few thousand.
On Thu, Sep 6, 2018 at 3:15 PM Thomas Wilde  wrote:
>
> Thanks for the response. I think the question then becomes: if the syntax in 
> contract bodies was an unrestricted Go block, then why do I need to repeat my 
> function's operations in a contract?
>
> If the syntax of contract bodies is free, then the Go compiler could easily 
> deduce all my constraints from a function body directly -- no need for a 
> separate contract.
>
> Thanks again and all the best,
> - Tom
>
> On Thu, Sep 6, 2018, 22:26 Ian Lance Taylor  wrote:
>>
>> On Tue, Sep 4, 2018 at 7:41 AM, thwd  wrote:
>> >
>> > From the draft proposal I gather two open questions:
>> >  - How free or restricted should contract bodies be?
>>
>> I believe it's useful to have contract bodies simply be arbitrary
>> function bodies, as the current design draft suggests.  This is
>> because I believe that is conceptually the simplest choice.  You don't
>> have to remember two different syntaxes, one for code and one for
>> contract bodies.  You just have to remember a single syntax, one you
>> must know in any case to write any Go code at all.
>>
>> >  - How many implicit constraints can be inferred from usage?
>>
>> As few as we can get away with.
>>
>>
>> > If too much syntax is allowed in contract bodies and no implicit 
>> > constraints
>> > are gathered:
>> > people will copy and paste function bodies into contracts to cover all
>> > constraints.
>>
>> People do suggest that that will happen but I think it is extremely
>> unlikely in practice.  It's obviously a terrible coding style, and
>> almost all generic functions have trivial contract requirements.
>>
>> Ian
>
> --
> 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.

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

['Axel Wagner' via golang-nuts]

On Thu, Sep 6, 2018 at 11:36 PM jimmy frasche 
wrote:

> To unify those cases you need something like haskell-style typeclasses
> where you can say this type satisfies this contract using these
> methods/operators.
>

FWIW, the Go way of doing that is embedding it in a new struct and
overwriting the methods - which is pretty much the only way to do it while
maintaining the property that only the owner of a type can define methods
on it.

So, you can already do this. But it requires you to write it. Which is
boilerplate.
(which I'm personally fine with, FTR :) )


>
>
> Even ignoring that, the contracts proposal doesn't let you write a
> generic variadic min/max since there's no way to get the
> smallest/largest value of a type so you can't write
>
> func min(type T ordered)(ts ...T) T {
>   min := LargestPossible(T) // not possible
>   for _, t := range {
> if t < min {
>   min = t
> }
>   }
>   return min
> }
>
> You could get around that with the signature (firstOne T, rest ...T)
> but there's a larger point about the necessity of knowing numeric
> limits and properties for writing that kind of generic code in there.
>
>
> One way around the asymmetry between operators and methods that
> doesn't introduce any issues like operator methods or any of that is
> to have a package that defines types like
>
> package basic // not the best name
>
> type Int int
>
> type Slice(type T) []T
>
> // and so on for all the primitive and basic composite types
>
> and give all of those methods like Less and At. You'd have to do
> int(min(basic.Int(x), basic.Int(y))) but at least you wouldn't have to
> write the trivial wrapper methods. Not especially pretty.
>
> --
> 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.
>

-- 
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.

Re: [go-nuts] A thought on contracts

[Thomas Wilde]

Thanks for the response. I think the question then becomes: if the syntax
in contract bodies was an unrestricted Go block, then why do I need to
repeat my function's operations in a contract?

If the syntax of contract bodies is free, then the Go compiler could easily
deduce all my constraints from a function body directly -- no need for a
separate contract.

Thanks again and all the best,
- Tom

On Thu, Sep 6, 2018, 22:26 Ian Lance Taylor  wrote:

> On Tue, Sep 4, 2018 at 7:41 AM, thwd  wrote:
> >
> > From the draft proposal I gather two open questions:
> >  - How free or restricted should contract bodies be?
>
> I believe it's useful to have contract bodies simply be arbitrary
> function bodies, as the current design draft suggests.  This is
> because I believe that is conceptually the simplest choice.  You don't
> have to remember two different syntaxes, one for code and one for
> contract bodies.  You just have to remember a single syntax, one you
> must know in any case to write any Go code at all.
>
> >  - How many implicit constraints can be inferred from usage?
>
> As few as we can get away with.
>
>
> > If too much syntax is allowed in contract bodies and no implicit
> constraints
> > are gathered:
> > people will copy and paste function bodies into contracts to cover all
> > constraints.
>
> People do suggest that that will happen but I think it is extremely
> unlikely in practice.  It's obviously a terrible coding style, and
> almost all generic functions have trivial contract requirements.
>
> Ian
>

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[Ian Lance Taylor]

On Thu, Sep 6, 2018 at 2:32 PM,   wrote:
>
> Here's a few points which I noticed when reading through the draft design
> which I thought people might have trouble getting their heads around:
>
> 1. The use of untyped numeric constants where you might need to specify the
> exact value needed to get the thing to work. I don't think anyone could
> describe that as obvious.
>
> 2. The inability to specify in a simple way that a method doesn't have a
> return value, can take a variable number of arguments or (a particularly
> nasty one) to distinguish a method call from a struct field of function
> type. I thought folks might thrash around quite a bit trying to figure these
> out before they released they'd have to use a conversion to a suitable
> interface type.
>
> 3. The difficulty of distinguishing between methods which take a value and a
> pointer receiver.
>
> 4. The 'nil' value problem. In C# they overload the 'default' keyword (i.e.
> default(T)) to produce the default value (all bits set to zero) for a type
> T. Maybe we could do something like this?

Thanks for the list.

Ian

-- 
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.

Re: [go-nuts] generic proposal timeline for next iteration

[Ian Lance Taylor]

On Thu, Sep 6, 2018 at 2:30 PM, Scott Cotton  wrote:
>
> I am interested in potentially putting some time into reviewing and possibly
> writing up the results of reviewing the generics proposal.
>
> As I'm quite stretched for time to do this, it would help me plan if the go
> team could say anything about timelines for the next round or rounds of such
> feedback.  For example, is there is a plan to revise the draft proposal
> based on feedback for 1.12?  Is there some tentative goal to have a working
> prototype by some specific version?

I'm very confident that there will be no changes in 1.12.

The next step is to produce a tool that can type check code written
using some design.  After that we will try to produce a tool that can
rewrite generic code into standard Go 1 code, by renaming functions.
This may only work on one package to start.  That will let us actually
experiment with almost-real code.  After that, we will see.

I have no timelines for any of this, but it's clearly on the order of months.

Ian

-- 
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.

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

[jimmy frasche]

I'd quite prefer [] over (). It would make F[t](v) distinct from
F(x)(y) even if it's not distinct from m[x](y).
On Thu, Sep 6, 2018 at 3:02 PM Ian Lance Taylor  wrote:
>
> On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche  wrote:
> >
> > Wouldn't there be an issue with fp := AFunc[int] ?
>
> I don't think so.  AFunc[int] would be parsed as an index operation,
> and after name lookup it would resolve into either an array lookup or
> a function instantiation, depending on the meaning of `int` in the
> current scope.  This is not very different from the way that t(v)
> resolves to either a function call or a type conversion after name
> lookup.  It's quite different from using <>, which has to be parsed
> quite differently depending on whether it is an instantiation or a
> comparison.
>
>
> > Though for that matter I wouldn't mind if the type part were repeated
> > for instantiations like AFunc[type int] or even AFunc(type int)
>
> That would be possible but seems unnecessary.  I personally would
> prefer to avoid it.
>
>
> > For that matter, always writing type would let you use < > since the
> > parser could plausibly enter a separate mode when it hit the < token
> > followed by type.
> >
> > Noisy but obvious at a glance what's happening.
>
> Yes, that is true except for the >> issue.
>
> Ian

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

['Axel Wagner' via golang-nuts]

Hi Ian,

On Thu, Sep 6, 2018 at 9:45 PM Ian Lance Taylor  wrote:

> On Thu, Sep 6, 2018 at 10:29 AM, jimmy frasche 
> wrote:
>
> This is clearly a key issue.  I happen to think that contracts are
> fairly clear for the reader: take your type argument and see if the
> contract body works.  I feel that everyone who knows Go will be able
> to do that.  But maybe that's just me.
>

I agree with you on this. But I don't think it's enough. To be type-safe
(from the author perspective), you also need to do the opposite: Take any
*other* type and make sure that it *doesn't* pass the contract. Because
otherwise, you might end up with a program that compiles, but is crashing
or otherwise invalid. And that's what made me turn against contracts,
lately.

I name a couple examples in my blog post (linked upthread), but as it just
came up during a talk at the Zurich Go Meetup: For example, you might have
a contract like `t%1`, to ensure you get an integer type (sorry, that is
ad-hoc the best way I can come up to write that contract). Now, say a
generic function uses that type-parameter for a loop-counter, counting
down: `for i := T(N); i >= 0; i-- { … }`. They check that `int` types pass
their contract and everything goes smoothly. At some point, someone uses
the function with a `uint` argument and you get an endless loop.

Now, this example is constructed. It will probably not occur in practice.
But it illustrates why I believe contracts make it relatively hard to write
type-safe generic code - because the contract does not only has to allow
everything you want to do, it also has to disallow anything you don't.
Expressing that syntactically is much harder.
This gets exacerbated by implied capabilities (though it's not clear yet if
and how much they exist): i.e. the compiler could prove that only integer
types allow `%`, so if you put down that constraint, it also allows `+`,
`*`, conversions to float…
Of course that doesn't *have* to happen - you could just literally only
allow the expressions given in the contract, but then the contract
potentially becomes very verbose, as it has to cover lots of ground. For
example, `a[0]` allows integer-indexing, but it technically only allows to
pass 0. Extending that to arbitrary integers is what's probably going to
happen (and an example of an implicit capability) - but then that code is
less type-safe then it needs to be, as Arrays already provide tight bounds
for constant-indices. You can say that `a[N]` then allows indexing with any
constant <= N (to make those bounds explicit), but at that point I would
criticize that the argument "contracts are just familiar Go syntax" becomes
less and less convincing, because you are introducing all these special
semantical meanings to expressions.

This just walks very roughly through one of these cases - but the more I
talked to people, the more of these we discovered. Personally, I just don't
find contracts a very good format to provide type-constraints - because to
a human, something might be obvious, that isn't to the compiler; causing
things that look like they *should* work not to work or things that don't
look like they work to work (for example, I recently re-discovered that
[]rune allows converting to string too, but has completely different range
and index semantics…).

Sorry for rambling a bit :-/


>
>
> > Scaling back the problem to simply not include operators and fields at
> > all looks like it eliminates so much of the complexity in the
> > implementation and its user interface. Any such limited solution
> > increases the boilerplate of using generics when operators and fields
> > come in to play, certainly, but I think the majority of use-cases for
> > generics are going to be data structures and algorithms more generally
> > expressible without operators anyway (few types have a < operator but
> > any type can have a Less method and without type classes in the
> > haskell/etc. there still isn't a way to handle both without accepting
> > a Less method and requiring a wrapper for types that have a <
> > operator).
> >
> > Is it really *necessary* for generics to support operators and fields?
>
> It's not necessary to support fields but I think it really is
> necessary to support operators.  I claim that, other than type safe
> data structures, the number one generic function that people want to
> write is Min (or Max).  I don't think we can plausible add a generics
> system to Go that doesn't permit writing a Min function.
>
> contract comparable(x T) {
> x < x
> }
>
> func Min(type T comparable)(a, b T) T {
> if a < b {
> return a
> }
> return b
> }
>
> Ian
>
> --
> 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.
>

-- 
You received this message because you are 

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

[Ian Lance Taylor]

On Thu, Sep 6, 2018 at 2:03 PM, jimmy frasche  wrote:
>
> Wouldn't there be an issue with fp := AFunc[int] ?

I don't think so.  AFunc[int] would be parsed as an index operation,
and after name lookup it would resolve into either an array lookup or
a function instantiation, depending on the meaning of `int` in the
current scope.  This is not very different from the way that t(v)
resolves to either a function call or a type conversion after name
lookup.  It's quite different from using <>, which has to be parsed
quite differently depending on whether it is an instantiation or a
comparison.


> Though for that matter I wouldn't mind if the type part were repeated
> for instantiations like AFunc[type int] or even AFunc(type int)

That would be possible but seems unnecessary.  I personally would
prefer to avoid it.


> For that matter, always writing type would let you use < > since the
> parser could plausibly enter a separate mode when it hit the < token
> followed by type.
>
> Noisy but obvious at a glance what's happening.

Yes, that is true except for the >> issue.

Ian

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[jimmy frasche]

> This is clearly a key issue.  I happen to think that contracts are
> fairly clear for the reader: take your type argument and see if the
> contract body works.  I feel that everyone who knows Go will be able
> to do that.  But maybe that's just me.

For complicated contracts—and I mean even ones reduced by a tool to
their minimum—that turns into a puzzle solving contest. For ones that
aren't reduced, it's easy for them to be misleading, like: x % 5 == 0

I agree that it's something where eventually standardized practices
and tooling would fill in the gaps to the extent that these issues
would come up rarely. I'm mostly worried about the time between their
introduction and the stabilization because it will be measured in
years and remembered for longer.

> Something like the convert example in the design draft would still
> need contracts that are unlikely to be defined in the standard
> library.

In my draft proposal, I handled this like
  (type S, T interface{} | S(T))
which introduces two type parameters with no restrictions other than
that values of T must be convertible to S. It's treated specially but
it is somewhat special because it's a property between two types. It
was the only such property I found necessary.

> It's not necessary to support fields but I think it really is
> necessary to support operators.  I claim that, other than type safe
> data structures, the number one generic function that people want to
> write is Min (or Max).  I don't think we can plausible add a generics
> system to Go that doesn't permit writing a Min function.

Hypothetically, if Go introduced generics where you couldn't write
min/max but included min/max builtins, what's the next smallest
example where operators are necessary?

I'd argue that min and max are the only ones that would seriously be
impacted. Every other example is large enough that any boilerplate to
wrap methods would pale compared to the coding saved by being able to
safely reuse a large chunk of code.

I'd be happy with generics if I needed to sometimes write a little bit
of code to do a few  things but didn't have to write a tremendous
amount of code to do most things. That seems like a good trade off,
even if it's not necessarily a popular one.

But you can't really write a generic min/max with the contracts proposal.

You can write a min/max that operates on all the ordered types, sure.

(The one in the proposal has a bug because it accepts float types but
doesn't handle the special cases for floats. That can't be repaired
because while you could assert to float32 or float64 you couldn't
assert to type MyFloat float64. Though I'm sure there's some contract
where you can specify < but not floats.)

You could also write a min/max that operates on types with a Less
method, like you could under the various just-interfaces schemes.

But you can't write one that works on both.

If there were operator overloading any type could have < and you could
specify < in interfaces and then you could work on primitive and user
types equally.

But even then you still couldn't write a min/max that transparently
works on time.Time since it has Before not Less.

To unify those cases you need something like haskell-style typeclasses
where you can say this type satisfies this contract using these
methods/operators.


Even ignoring that, the contracts proposal doesn't let you write a
generic variadic min/max since there's no way to get the
smallest/largest value of a type so you can't write

func min(type T ordered)(ts ...T) T {
  min := LargestPossible(T) // not possible
  for _, t := range {
if t < min {
  min = t
}
  }
  return min
}

You could get around that with the signature (firstOne T, rest ...T)
but there's a larger point about the necessity of knowing numeric
limits and properties for writing that kind of generic code in there.


One way around the asymmetry between operators and methods that
doesn't introduce any issues like operator methods or any of that is
to have a package that defines types like

package basic // not the best name

type Int int

type Slice(type T) []T

// and so on for all the primitive and basic composite types

and give all of those methods like Less and At. You'd have to do
int(min(basic.Int(x), basic.Int(y))) but at least you wouldn't have to
write the trivial wrapper methods. Not especially pretty.

-- 
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.

Re: [go-nuts] go1.11 no longer supports compressed hostnames in SRV lookup replies

[mikioh . mikioh]

On Friday, September 7, 2018 at 5:43:24 AM UTC+9, Jason Newman wrote:
>
> I pinged a couple of people associated with kube-dns and they were able to 
> reproduce the issue on the latest kube-dns release (1.14.10). They are 
> planning on tagging a new release of kube-dns that includes an improvement 
> to the behavior. Thank you all for the guidance.
>

can you please fine an issue in the go issue tracker too? the issue, 
especially regarding dns-sd, is a real issue and could be a roadblock in 
near future. thanks.

-- 
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.

Re: [go-nuts] Help

[andybons via golang-nuts]

On Wednesday, September 5, 2018 at 2:01:20 PM UTC-4, Matthias B. wrote:
>
> On Wed, 5 Sep 2018 19:14:43 +0530 
> Kathiresh Kumar > wrote: 
>
> > How can I connect golang with mongoDB 
> > 
>
> http://lmgtfy.com/?q=How+can+I+connect+golang+with+mongoDB%3F%3F%3F%3F 
>

This is not a particularly helpful response. Please be sure to adhere to 
the values described at https://golang.org/conduct#values

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[alan . fox6]

Ian,

Here's a few points which I noticed when reading through the draft design 
which I thought people might have trouble getting their heads around:

1. The use of untyped numeric constants where you might need to specify the 
exact value needed to get the thing to work. I don't think anyone could 
describe that as obvious.

2. The inability to specify in a simple way that a method doesn't have a 
return value, can take a variable number of arguments or (a particularly 
nasty one) to distinguish a method call from a struct field of function 
type. I thought folks might thrash around quite a bit trying to figure 
these out before they released they'd have to use a conversion to a 
suitable interface type.

3. The difficulty of distinguishing between methods which take a value and 
a pointer receiver.

4. The 'nil' value problem. In C# they overload the 'default' keyword (i.e. 
default(T)) to produce the default value (all bits set to zero) for a type 
T. Maybe we could do something like this?


On Thursday, September 6, 2018 at 8:52:03 PM UTC+1, Ian Lance Taylor wrote:
>
> On Thu, Sep 6, 2018 at 12:05 PM, alanfo > 
> wrote: 
> > 
> > So, yes, there'd be a lot to learn but there'd also be a lot to learn to 
> > write 'full-blooded' contracts effectively some aspects of which are 
> quite 
> > subtle. 
>
> I would like to more clearly understand which aspects seem subtle when 
> reading the code.  Where does it become confusing? 
>
>
> > I suspect that, if you can make contracts work in the way the draft 
> > envisages, then folks will write the function first and then write the 
> > contract afterwards to try and fit in with what they've done. Tooling 
> would, 
> > of course, help though I wonder whether it will be able to deal with all 
> the 
> > subtleties? 
>
> My sense is that *if* we can write a compiler that is able to type 
> check a contract, which is unproven, then it will automatically follow 
> that we can write a tool that deals with all subtleties. 
>
> Ian 
>

-- 
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.

[go-nuts] generic proposal timeline for next iteration

[Scott Cotton]

Hi all,

I am interested in potentially putting some time into reviewing and
possibly writing up the results of reviewing the generics proposal.

As I'm quite stretched for time to do this, it would help me plan if the go
team could say anything about timelines for the next round or rounds of
such feedback.  For example, is there is a plan to revise the draft
proposal based on feedback for 1.12?  Is there some tentative goal to have
a working prototype by some specific version?

Best,

Scott

-- 
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.

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

[jimmy frasche]

I meant that if the instantiation syntax is T. Though
it'd probably have to treat a >> token as two separate > in
declarations which is annoying.
On Thu, Sep 6, 2018 at 2:07 PM Jan Mercl <0xj...@gmail.com> wrote:
>
>
>
> On Thu, Sep 6, 2018, 23:03 jimmy frasche  wrote:
>>
>> Wouldn't there be an issue with fp := AFunc[int] ?
>>
>> Though for that matter I wouldn't mind if the type part were repeated
>> for instantiations like AFunc[type int] or even AFunc(type int)
>>
>> For that matter, always writing type would let you use < > since the
>> parser could plausibly enter a separate mode when it hit the < token
>> followed by type.
>
>
> The parser does not and not easily can know if 'a' in ' type name.
>
> --
>
> -j

-- 
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.

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

[Jan Mercl]

On Thu, Sep 6, 2018, 23:03 jimmy frasche  wrote:

> Wouldn't there be an issue with fp := AFunc[int] ?
>
> Though for that matter I wouldn't mind if the type part were repeated
> for instantiations like AFunc[type int] or even AFunc(type int)
>
> For that matter, always writing type would let you use < > since the
> parser could plausibly enter a separate mode when it hit the < token
> followed by type.
>

The parser does not and not easily can know if 'a' in ' --

-j

-- 
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.

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

[jimmy frasche]

Wouldn't there be an issue with fp := AFunc[int] ?

Though for that matter I wouldn't mind if the type part were repeated
for instantiations like AFunc[type int] or even AFunc(type int)

For that matter, always writing type would let you use < > since the
parser could plausibly enter a separate mode when it hit the < token
followed by type.

Noisy but obvious at a glance what's happening.
On Thu, Sep 6, 2018 at 1:43 PM Ian Lance Taylor  wrote:
>
> On Thu, Sep 6, 2018 at 1:38 PM, xingtao zhao  wrote:
> >
> > But we can still using [type T] instead.
>
> That is a very good point.  Thanks.  As far as I can see we could
> plausibly switch to square brackets if we prefer them.
>
> Ian
>
>
>
> > On Thursday, September 6, 2018 at 6:45:07 AM UTC-7, Ian Lance Taylor wrote:
> >>
> >> On Thu, Sep 6, 2018 at 5:28 AM,   wrote:
> >> >
> >> > Am Donnerstag, 6. September 2018 13:43:32 UTC+2 schrieb Christophe
> >> > Meessen:
> >> >>
> >> >> I understand your example, but it wouldn't be a problem anymore with a
> >> >> special character like a $ sign. D use the !.
> >> >
> >> >
> >> > Scala uses [ and ] instead of < and > to avoid the problem that < and >
> >> > mean
> >> > something different depending on the context.
> >>
> >> Note that simple [ and ] don't work in Go, as explained in the
> >> generics design draft.
> >>
> >> Ian
> >
> > --
> > 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.
>
> --
> 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.

-- 
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.

[go-nuts] Re: last pointer standing

[Yamil Bracho]

You are not creating a new pointer, so just do

c1.Lookup = {xt1.CodeId, xt1.Description, xt1.Active}

El jueves, 6 de septiembre de 2018, 14:59:44 (UTC-5), davidg...@gmail.com 
escribió:
>
> Am looking for insight into why the dataArray_LookupCode output array is 
> partially correct.
> The newUUID() function correctly assigns to each element of the 
> dataArray_LookupCode array, but the *LookupCode field values are all the 
> values of the last element of the LookupCodes data source array. 
> Why?
>
> package main
>
> import (
> "crypto/rand"
> "strconv"
> "fmt"
> "io"
> //"encoding/json"
> //"time"
> )
>
> func newUUID() (string, error) {
> uuid := make([]byte, 16)
> n, err := io.ReadFull(rand.Reader, uuid)
> if n != len(uuid) || err != nil {
> return "", err
> }
> // variant bits; see section 4.1.1
> uuid[8] = uuid[8]&^0xc0 | 0x80
> // version 4 (pseudo-random); see section 4.1.3
> uuid[6] = uuid[6]&^0xf0 | 0x40
> return fmt.Sprintf("%x-%x-%x-%x-%x", uuid[0:4], uuid[4:6], uuid[6:8], 
> uuid[8:10], uuid[10:]), nil
> }
>
> type LookupCode struct
> {
>   CodeIdstring`json:"codeid"`
>   Descriptionstring`json:"description"`
>   Activebool`json:"active"`
> }
>
> type UUID_LookupCode struct
> {
> UUID string `json:"uuid"`
> lookup*LookupCode `json:"lookup"`
> // *LookupCode  [does not work]
> }
>
> var LookupCodes []LookupCode
> var dataArray_LookupCode []UUID_LookupCode
>
> func init() { 
> LookupCodes = []LookupCode {
> LookupCode {
> Active: true,
> CodeId: "USA_00",
> Description: "All US States",
> },
> LookupCode {
> Active: true,
> CodeId: "USA_01",
> Description: "All US Western compact States",
> },
> }
>
> dataArray_LookupCode := make([]UUID_LookupCode, 0)
> for _, xt1 := range LookupCodes {
> c1 := _LookupCode{}
> c1.lookup = 
> //c1.LookupCode.CodeId = xt1.CodeId
> typeKey, err := newUUID()
> if err == nil {
> c1.UUID = typeKey
> }
> fmt.Println(c1.lookup.CodeId )  // correct output: USA_00 USA_01
> dataArray_LookupCode = append(dataArray_LookupCode, *c1) 
> }
> fmt.Printf(strconv.Itoa(len(dataArray_LookupCode)))  // correct output: 2
> fmt.Println(dataArray_LookupCode[0].lookup.CodeId,dataArray_LookupCode[1].lookup.CodeId)
>   
> // incorrect output: USA_01 USA_01
>
> }// init
>
> func main() {
> }
>
>

-- 
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.

[go-nuts] Re: last pointer standing

[Yamil Bracho]

El jueves, 6 de septiembre de 2018, 14:59:44 (UTC-5), davidg...@gmail.com 
escribió:
>
> Am looking for insight into why the dataArray_LookupCode output array is 
> partially correct.
> The newUUID() function correctly assigns to each element of the 
> dataArray_LookupCode array, but the *LookupCode field values are all the 
> values of the last element of the LookupCodes data source array. 
> Why?
>
> package main
>
> import (
> "crypto/rand"
> "strconv"
> "fmt"
> "io"
> //"encoding/json"
> //"time"
> )
>
> func newUUID() (string, error) {
> uuid := make([]byte, 16)
> n, err := io.ReadFull(rand.Reader, uuid)
> if n != len(uuid) || err != nil {
> return "", err
> }
> // variant bits; see section 4.1.1
> uuid[8] = uuid[8]&^0xc0 | 0x80
> // version 4 (pseudo-random); see section 4.1.3
> uuid[6] = uuid[6]&^0xf0 | 0x40
> return fmt.Sprintf("%x-%x-%x-%x-%x", uuid[0:4], uuid[4:6], uuid[6:8], 
> uuid[8:10], uuid[10:]), nil
> }
>
> type LookupCode struct
> {
>   CodeIdstring`json:"codeid"`
>   Descriptionstring`json:"description"`
>   Activebool`json:"active"`
> }
>
> type UUID_LookupCode struct
> {
> UUID string `json:"uuid"`
> lookup*LookupCode `json:"lookup"`
> // *LookupCode  [does not work]
> }
>
> var LookupCodes []LookupCode
> var dataArray_LookupCode []UUID_LookupCode
>
> func init() { 
> LookupCodes = []LookupCode {
> LookupCode {
> Active: true,
> CodeId: "USA_00",
> Description: "All US States",
> },
> LookupCode {
> Active: true,
> CodeId: "USA_01",
> Description: "All US Western compact States",
> },
> }
>
> dataArray_LookupCode := make([]UUID_LookupCode, 0)
> for _, xt1 := range LookupCodes {
> c1 := _LookupCode{}
> c1.lookup = 
> //c1.LookupCode.CodeId = xt1.CodeId
> typeKey, err := newUUID()
> if err == nil {
> c1.UUID = typeKey
> }
> fmt.Println(c1.lookup.CodeId )  // correct output: USA_00 USA_01
> dataArray_LookupCode = append(dataArray_LookupCode, *c1) 
> }
> fmt.Printf(strconv.Itoa(len(dataArray_LookupCode)))  // correct output: 2
> fmt.Println(dataArray_LookupCode[0].lookup.CodeId,dataArray_LookupCode[1].lookup.CodeId)
>   
> // incorrect output: USA_01 USA_01
>
> }// init
>
> func main() {
> }
>
>

-- 
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.

Re: [go-nuts] go1.11 no longer supports compressed hostnames in SRV lookup replies

[jason]

I pinged a couple of people associated with kube-dns and they were able to 
reproduce the issue on the latest kube-dns release (1.14.10). They are 
planning on tagging a new release of kube-dns that includes an improvement 
to the behavior. Thank you all for the guidance.

On Friday, August 31, 2018 at 1:13:45 AM UTC-6, mikioh...@gmail.com wrote:
>
> On Friday, August 31, 2018 at 2:54:08 PM UTC+9, Jason Newman wrote:
>>
>> Is it worth creating an issue around this? We have extracted the DNS 
>> client from `net` and are currently using it with the compressed flag 
>> enabled to allow compressed hostnames - the behavior that existed in go 
>> 1.10 and earlier.
>>
>
> sure, please file an issue, at least we need to discuss how to deal 
> with srv rrs not only for classical unicast dns but for the latest unicast 
> dns, multicast dns and dns-sd, though there's no guarantee that the 
> previous wrong behavior will be back in future releases.
>
> for the record:
> - in rfc2782, "... name compression is not to be used for this field."
> - in rfc6762, "One specific difference between Unicast DNS and Multicast 
> DNS is that ... all Multicast DNS implementations are REQUIRED to decode 
> compressed SRV records correctly."
> - in rfc6763, "Using DNS name compression ..."
>
> unfortunately, the dns specifications are everybody's friend; it's hard 
> to tame, to make a one-fits-all solution for the specs.
>
>>

-- 
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.

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

[Ian Lance Taylor]

On Thu, Sep 6, 2018 at 1:38 PM, xingtao zhao  wrote:
>
> But we can still using [type T] instead.

That is a very good point.  Thanks.  As far as I can see we could
plausibly switch to square brackets if we prefer them.

Ian



> On Thursday, September 6, 2018 at 6:45:07 AM UTC-7, Ian Lance Taylor wrote:
>>
>> On Thu, Sep 6, 2018 at 5:28 AM,   wrote:
>> >
>> > Am Donnerstag, 6. September 2018 13:43:32 UTC+2 schrieb Christophe
>> > Meessen:
>> >>
>> >> I understand your example, but it wouldn't be a problem anymore with a
>> >> special character like a $ sign. D use the !.
>> >
>> >
>> > Scala uses [ and ] instead of < and > to avoid the problem that < and >
>> > mean
>> > something different depending on the context.
>>
>> Note that simple [ and ] don't work in Go, as explained in the
>> generics design draft.
>>
>> Ian
>
> --
> 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.

-- 
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.

Re: [go-nuts] last pointer standing

[davidgnabasik]

Ian, thanks. Adding  xt1 := xt1 // create a new 'xt1'   inside the 
for-range loop provided the expected output.


On Thursday, September 6, 2018 at 2:11:18 PM UTC-6, Ian Lance Taylor wrote:
>
> > 
> > for _, xt1 := range LookupCodes { 
> > ... 
> > c1.lookup =  
>
> Don't do that.  See https://golang.org/doc/faq#closures_and_goroutines 
> .  You aren't using a closure, but the issue is the same. 
>
> Ian 
>

-- 
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.

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

[xingtao zhao]

But we can still using [type T] instead.

On Thursday, September 6, 2018 at 6:45:07 AM UTC-7, Ian Lance Taylor wrote:
>
> On Thu, Sep 6, 2018 at 5:28 AM,  > wrote: 
> > 
> > Am Donnerstag, 6. September 2018 13:43:32 UTC+2 schrieb Christophe 
> Meessen: 
> >> 
> >> I understand your example, but it wouldn't be a problem anymore with a 
> >> special character like a $ sign. D use the !. 
> > 
> > 
> > Scala uses [ and ] instead of < and > to avoid the problem that < and > 
> mean 
> > something different depending on the context. 
>
> Note that simple [ and ] don't work in Go, as explained in the 
> generics design draft. 
>
> Ian 
>

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[Ian Lance Taylor]

On Thu, Sep 6, 2018 at 1:21 PM, Caleb Spare  wrote:
> On Thu, Sep 6, 2018 at 9:54 AM Ian Lance Taylor  wrote:
>>
>> Personally I think an important feature of the current design draft is
>> that it adds relatively few new concepts to the language.  While
>> concepts are of course a new feature, a contract looks like a
>> function.  If you can read a function, you can read a contract.  You
>> don't need to understand a new set of ideas to know what a contract
>> is.  With your proposal, everybody has to learn a new set of
>> predeclared identifiers.  You list 14 new ones, including $struct.  I
>> count 39 existing predeclared identifiers, so this is a significant
>> increase.  Also, of course, the new identifiers don't look like any
>> existing ones, with the $, but perhaps that could be changed.  I would
>> very much prefer to not add so many new names.
>
> In practice, reading a contract is not really like reading a function at all.
>
> Like the compiler, the reader is interested in understanding the set
> of operations a contract allows. When reading a function, the reader
> pieces together a sequence of computations in order to understand the
> function's behavior.

Fair enough, but I still feel that it is an advantage to not have to
learn additional names or syntax beyond what you already know.


> I think we'll find that we need to think and talk about contracts as
> sets of allowed operations and giving names to those operations makes
> that easier. Writing contracts as code to avoid naming the operations
> doesn't mean we can avoid thinking about them, it just hides them a
> little.

We already have names for those operations: the less than operator,
the equality operator.  We don't have to use explicit names in the
code to understand what we are reading.

Ian

-- 
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.

Re: [go-nuts] A thought on contracts

[Ian Lance Taylor]

On Tue, Sep 4, 2018 at 9:49 AM, roger peppe  wrote:
>
> For example, the Stringer contract in the
> design doc purports to check that there's a method named String, which
> it does not - it could be a function-valued field instead.
>
> So if you've written something like this:
>
> func FastString(type T stringer)(x T) string {
> switch x.(type) {
> case myType:
>  return x.String()
> default:
>  // Slow path: fall back to fmt.
>  return fmt.Sprint(x)
> }
> }
>
> you might expect that fmt.Sprint will call the String method that's
> defined on x, but that's not guaranteed.

That's a good point though note that for a case like this you could of
course write

contract stringer(x T) {
var _ fmt.Stringer = x
}

-- 
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.

Re: [go-nuts] A thought on contracts

[Ian Lance Taylor]

On Tue, Sep 4, 2018 at 9:17 AM, roger peppe  wrote:
>
> As I understand it, if a contract doesn't allow it, you won't be able to do 
> it.
> That is, the contract is scanned for "operations" (however they might be
> defined), and then it will be a compiler error if a function uses an operation
> not permitted in the contract.
>
> An empty contract body permits no operations other than those available
> on every Go value (copying, taking address of, passing as a parameter, etc).
>
> So I'm not entirely sure what you mean by "implicit constraints".

The current design draft does suggest a couple of implicit constraints:

1) Using any of "==" or "!=" implies that the function body can use
either operation.

2) Similarly, using any of "<", "<=", ">=", ">" implies that the that
function body can use any operation, as well as "==" and "!=".

I'm not sure whether this is a good idea or not.


> That said, it is my opinion that it is very hard to read an arbitrary 
> constraint
> body and infer the set of possible operations that can be performed.
> It's not that much easier to look at it and work out what types might satisfy
> the contract either.
>
> My suggestion (that I've written up here:
> https://gist.github.com/rogpeppe/45f5a7578507989ec4ba5ac639ae2c69) is
> that, at least to start with, we allow only a very restricted set of
> contract bodies.
>
> Specifically, in my suggestion, every statement in a contract body
> must consist of exactly one expression.
> Identifiers in the expression can only reference types or the
> contract's parameters.
> The expression must reference at least one of the contract's type parameters.
> The expression must exactly one of:
>  - any unary or binary operator (but not a field or method selector)
>  - a function invocation
>  - a type conversion
>  - an index expression
>
> Intuitively I'd like a single statement in the expression to specify
> exactly a single operation which should be clear from the operands of
> the expression.
>
> Thus if you look down the contract and you don't see the operation
> you're looking for, then you can't do it.

I think that the hypothetical contract simplifier tool (gocontracts)
should turn most contracts into exactly what you say.

Ian

-- 
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.

Re: [go-nuts] A thought on contracts

[Ian Lance Taylor]

On Tue, Sep 4, 2018 at 7:41 AM, thwd  wrote:
>
> From the draft proposal I gather two open questions:
>  - How free or restricted should contract bodies be?

I believe it's useful to have contract bodies simply be arbitrary
function bodies, as the current design draft suggests.  This is
because I believe that is conceptually the simplest choice.  You don't
have to remember two different syntaxes, one for code and one for
contract bodies.  You just have to remember a single syntax, one you
must know in any case to write any Go code at all.

>  - How many implicit constraints can be inferred from usage?

As few as we can get away with.


> If too much syntax is allowed in contract bodies and no implicit constraints
> are gathered:
> people will copy and paste function bodies into contracts to cover all
> constraints.

People do suggest that that will happen but I think it is extremely
unlikely in practice.  It's obviously a terrible coding style, and
almost all generic functions have trivial contract requirements.

Ian

-- 
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.

Re: [go-nuts] A thought on contracts

[Ian Lance Taylor]

On Wed, Sep 5, 2018 at 8:26 PM, Steve Phillips  wrote:
> Interesting idea, but has the Go team expressed interest in creating such a 
> tool?

Yes, I think it's become clear that we should have a tool that, given
a contract body, produces a minimal contract body that expresses the
same contract.  I believe that if we are able to write a type checker
for the design draft, it will be a minor straightforward extension to
that code to produce such a tool.

And, of course, given such a tool, it's a trivial extension to take an
arbitrary function body and produce a minimal contract body for that
function.

Ian

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[Caleb Spare]

On Thu, Sep 6, 2018 at 9:54 AM Ian Lance Taylor  wrote:
>
> On Thu, Sep 6, 2018 at 8:20 AM,   wrote:
> >
> > As I wasn't happy with some aspects of it, I've rewritten my feedback on the
> > Go 2 Generics draft and deleted the original gist. Here's the link to the
> > new gist for anybody who's interested:
> > https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251
> >
> > This is still based on the type-class idea though I'm now proposing a
> > simplified contracts approach to go with it rather than trying to make
> > interfaces fit. It seems to deal easily now with all the examples in the
> > draft paper though no doubt there will be stuff that it can't do or that
> > I've overlooked.
>
> Thanks for writing this.  I never got around to reading the earlier
> feedback.  And thanks for working out the examples.
>
> Personally I think an important feature of the current design draft is
> that it adds relatively few new concepts to the language.  While
> concepts are of course a new feature, a contract looks like a
> function.  If you can read a function, you can read a contract.  You
> don't need to understand a new set of ideas to know what a contract
> is.  With your proposal, everybody has to learn a new set of
> predeclared identifiers.  You list 14 new ones, including $struct.  I
> count 39 existing predeclared identifiers, so this is a significant
> increase.  Also, of course, the new identifiers don't look like any
> existing ones, with the $, but perhaps that could be changed.  I would
> very much prefer to not add so many new names.

In practice, reading a contract is not really like reading a function at all.

Like the compiler, the reader is interested in understanding the set
of operations a contract allows. When reading a function, the reader
pieces together a sequence of computations in order to understand the
function's behavior.

I think we'll find that we need to think and talk about contracts as
sets of allowed operations and giving names to those operations makes
that easier. Writing contracts as code to avoid naming the operations
doesn't mean we can avoid thinking about them, it just hides them a
little.

>
> If new features are added to the language, your approach may require
> new predeclared identifiers, whereas the contract approach will
> automatically adjust.
>
> It's worth noting that your suggestion is less powerful than the
> design draft, in that you can't express the notion of type parameter
> that must be a channel type or a slice type.  This may not matter very
> much, because the generic function can always write chan T or []T.
>
>
> > It looks to me as though, if it requires a contract at all, you might end 
> > up writing one from scratch for most generic functions/types you need. Even 
> > if the commoner ones could be included in a 'contracts' package in the 
> > standard library, you'd still need to import that package and then write 
> > stuff like 'contracts.Comparable' which is a bit verbose.
> >
> > Even if the present design prove workable, I think writing contracts may 
> > prove a bit of a black art and that, if things are at all complicated, some 
> > programmers may just give it up and embed the function's code in the 
> > contract which defeats the object of having them in the first place!
>
> I believe we can use tooling to make these operations easier.  For
> example, assuming we can make contracts work at all, it should be
> straightforward to write a tool that can minimize a contract given an
> existing contract definition, and therefore can produce a minimal
> contract for an existing function body.
>
> Note that while I think it's important that there be some way to
> express complex contracts, I think they will be used quite rarely.
>
>
> > The more I look at this, the more complicated it seems to get :(
>
> Yes.
>
> Ian
>
> --
> 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.

-- 
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.

Re: [go-nuts] last pointer standing

[Ian Lance Taylor]

>
> for _, xt1 := range LookupCodes {
> ...
> c1.lookup = 

Don't do that.  See https://golang.org/doc/faq#closures_and_goroutines
.  You aren't using a closure, but the issue is the same.

Ian

-- 
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.

[go-nuts] last pointer standing

[davidgnabasik]

Am looking for insight into why the dataArray_LookupCode output array is 
partially correct.
The newUUID() function correctly assigns to each element of the 
dataArray_LookupCode array, but the *LookupCode field values are all the 
values of the last element of the LookupCodes data source array. 
Why?

package main

import (
"crypto/rand"
"strconv"
"fmt"
"io"
//"encoding/json"
//"time"
)

func newUUID() (string, error) {
uuid := make([]byte, 16)
n, err := io.ReadFull(rand.Reader, uuid)
if n != len(uuid) || err != nil {
return "", err
}
// variant bits; see section 4.1.1
uuid[8] = uuid[8]&^0xc0 | 0x80
// version 4 (pseudo-random); see section 4.1.3
uuid[6] = uuid[6]&^0xf0 | 0x40
return fmt.Sprintf("%x-%x-%x-%x-%x", uuid[0:4], uuid[4:6], uuid[6:8], 
uuid[8:10], uuid[10:]), nil
}

type LookupCode struct
{
  CodeIdstring`json:"codeid"`
  Descriptionstring`json:"description"`
  Activebool`json:"active"`
}

type UUID_LookupCode struct
{
UUID string `json:"uuid"`
lookup*LookupCode `json:"lookup"`
// *LookupCode  [does not work]
}

var LookupCodes []LookupCode
var dataArray_LookupCode []UUID_LookupCode

func init() { 
LookupCodes = []LookupCode {
LookupCode {
Active: true,
CodeId: "USA_00",
Description: "All US States",
},
LookupCode {
Active: true,
CodeId: "USA_01",
Description: "All US Western compact States",
},
}

dataArray_LookupCode := make([]UUID_LookupCode, 0)
for _, xt1 := range LookupCodes {
c1 := _LookupCode{}
c1.lookup = 
//c1.LookupCode.CodeId = xt1.CodeId
typeKey, err := newUUID()
if err == nil {
c1.UUID = typeKey
}
fmt.Println(c1.lookup.CodeId )  // correct output: USA_00 USA_01
dataArray_LookupCode = append(dataArray_LookupCode, *c1) 
}
fmt.Printf(strconv.Itoa(len(dataArray_LookupCode)))  // correct output: 2
fmt.Println(dataArray_LookupCode[0].lookup.CodeId,dataArray_LookupCode[1].lookup.CodeId)
  
// incorrect output: USA_01 USA_01

}// init

func main() {
}

-- 
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.

Re: [go-nuts] Repeated functions with the same output in loops

[Ian Lance Taylor]

On Thu, Sep 6, 2018 at 12:24 PM, mustafa katipoğlu
<98mustafakatipo...@gmail.com> wrote:
>
> If I use len() function inside of a foor loop , does it calculates the
> output each time? or if the output will be the same(like arrays) will it
> calculates the length of the function again ?
>
> var letterRunes =
> []rune("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_")
>
>
> b := make([]rune, usernameLength)
>
>
> for i := range b {
>b[i] = letterRunes[rand.Intn(len(letterRunes))]
> }

It will recalculate the length each time through the loop.

Note that calculating the length of a slice is a fast operation; it's
a single memory load.

Ian

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[Ian Lance Taylor]

On Thu, Sep 6, 2018 at 12:05 PM, alanfo  wrote:
>
> So, yes, there'd be a lot to learn but there'd also be a lot to learn to
> write 'full-blooded' contracts effectively some aspects of which are quite
> subtle.

I would like to more clearly understand which aspects seem subtle when
reading the code.  Where does it become confusing?


> I suspect that, if you can make contracts work in the way the draft
> envisages, then folks will write the function first and then write the
> contract afterwards to try and fit in with what they've done. Tooling would,
> of course, help though I wonder whether it will be able to deal with all the
> subtleties?

My sense is that *if* we can write a compiler that is able to type
check a contract, which is unproven, then it will automatically follow
that we can write a tool that deals with all subtleties.

Ian

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[Ian Lance Taylor]

On Thu, Sep 6, 2018 at 11:40 AM, Matt Sherman  wrote:
>
> Perhaps a compromise position would be that these type
> groups/classes/contracts are not language builtins but in the stdlib?
> contracts.Comparable, etc.

Yes, definitely.


> And, for a first implementation, only the stdlib can define contracts. We
> might find that to be ‘good enough’ (a positive outcome).

Personally I'm very reluctant to limit any language features to the
standard library.  That effectively makes some packages defined by the
language, like the "unsafe" package.  I think we should minimize the
number of such packages.


> The hypothesis (just to reiterate) is that there is a small number of
> contracts that cover the majority of use cases, and so we can exploit that
> fact to minimize new language concepts. 80% benefit for 20% complexity,
> which is how I describe Go’s current type system.

Well, I think we do still need contracts for methods.  Though I
concede that it may be possible to handle those through parameterized
interface types.

Something like the convert example in the design draft would still
need contracts that are unlikely to be defined in the standard
library.

Ian

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[Ian Lance Taylor]

On Thu, Sep 6, 2018 at 10:29 AM, jimmy frasche  wrote:
>
> Contracts are a brilliant solution to the problem on an intellectual
> level. I really am impressed by how deftly they tackle the stated
> problem. But I am concerned about their usability on the practical
> level. The idea is simple but its user interface is not. I don't buy
> the claim that it's okay because a priest-class will be the only ones
> writing generic code. Everyone will still have to read it and deal
> with it.

This is clearly a key issue.  I happen to think that contracts are
fairly clear for the reader: take your type argument and see if the
contract body works.  I feel that everyone who knows Go will be able
to do that.  But maybe that's just me.


> Scaling back the problem to simply not include operators and fields at
> all looks like it eliminates so much of the complexity in the
> implementation and its user interface. Any such limited solution
> increases the boilerplate of using generics when operators and fields
> come in to play, certainly, but I think the majority of use-cases for
> generics are going to be data structures and algorithms more generally
> expressible without operators anyway (few types have a < operator but
> any type can have a Less method and without type classes in the
> haskell/etc. there still isn't a way to handle both without accepting
> a Less method and requiring a wrapper for types that have a <
> operator).
>
> Is it really *necessary* for generics to support operators and fields?

It's not necessary to support fields but I think it really is
necessary to support operators.  I claim that, other than type safe
data structures, the number one generic function that people want to
write is Min (or Max).  I don't think we can plausible add a generics
system to Go that doesn't permit writing a Min function.

contract comparable(x T) {
x < x
}

func Min(type T comparable)(a, b T) T {
if a < b {
return a
}
return b
}

Ian

-- 
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.

Re: [go-nuts] Re: Maybe vet can detect this?

[Burak Serdar]

On Thu, Sep 6, 2018 at 1:32 PM mustafa katipoğlu
<98mustafakatipo...@gmail.com> wrote:
>
> check this documentation. https://golang.org/doc/faq#nil_error

Yes, I am aware of that. This is not specific to errors though, this
is a problem for any interface return value, and vet could warn
against this use.

>
> 6 Eylül 2018 Perşembe 22:15:17 UTC+3 tarihinde Burak Serdar yazdı:
>>
>> https://play.golang.org/p/KLXvFNCewyW
>>
>> Here, f2() never returns nil, because the returned "nil" valued
>> interface is of type *int.
>>
>> It would be really nice if vet could warn if a function returns an
>> interface, and there exist a code path in that function where the
>> return value is set from a reference.
>>
>> I've seen a lot of discussions about not returning interfaces, but
>> sometimes you just have to do it.
>
> --
> 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.

-- 
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.

[go-nuts] Re: Maybe vet can detect this?

[mustafa katipoğlu]

check this documentation. https://golang.org/doc/faq#nil_error 

6 Eylül 2018 Perşembe 22:15:17 UTC+3 tarihinde Burak Serdar yazdı:
>
> https://play.golang.org/p/KLXvFNCewyW 
>
> Here, f2() never returns nil, because the returned "nil" valued 
> interface is of type *int. 
>
> It would be really nice if vet could warn if a function returns an 
> interface, and there exist a code path in that function where the 
> return value is set from a reference. 
>
> I've seen a lot of discussions about not returning interfaces, but 
> sometimes you just have to do it. 
>

-- 
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.

[go-nuts] Repeated functions with the same output in loops

[mustafa katipoğlu]

If I use len() function inside of a foor loop , does it calculates the 
output each time? or if the output will be the same(like arrays) will it 
calculates the length of the function again ?

var letterRunes = 
[]rune("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789_")


b := make([]rune, usernameLength)


for i := range b {
   b[i] = letterRunes[rand.Intn(len(letterRunes))]
}



-- 
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.

[go-nuts] Maybe vet can detect this?

[Burak Serdar]

https://play.golang.org/p/KLXvFNCewyW

Here, f2() never returns nil, because the returned "nil" valued
interface is of type *int.

It would be really nice if vet could warn if a function returns an
interface, and there exist a code path in that function where the
return value is set from a reference.

I've seen a lot of discussions about not returning interfaces, but
sometimes you just have to do it.

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[alanfo]

Ian,

Thanks for taking the time to read through my feedback on this matter. 
You'd didn't miss much by not reading the earlier version as I'd tried to 
marry the 'type group' idea with interfaces and ended up with something 
which was not really coherent.

It is, of course, unfortunate that one needs such a large number of groups 
to cover all combinations of the built-in operators and conversions 
(particularly as many are just unions of other groups) - and there'd be 
even more if $slice and $chan were added! 

So, yes, there'd be a lot to learn but there'd also be a lot to learn to 
write 'full-blooded' contracts effectively some aspects of which are quite 
subtle.

What attracted me to the type group idea was that, if you were writing a 
generic function, you could just say to yourself what types do I need to 
cover with this and, in the majority of cases, you could simply choose the 
appropriate group for your parameter(s) and the job would be half done. You 
wouldn't need to worry about which operators and/or conversions were used 
as you (and the compiler) would know immediately what was supported.

I suspect that, if you can make contracts work in the way the draft 
envisages, then folks will write the function first and then write the 
contract afterwards to try and fit in with what they've done. Tooling 
would, of course, help though I wonder whether it will be able to deal with 
all the subtleties?

Anyway, many thanks for all the work that Robert and yourself must have put 
in to present us with a coherent design. It's certainly stimulated some 
discussion amongst gophers and plenty of decent feedback including great 
contributions from Axel and Matt which I hope you'll also cast your eye 
over - they don't use as many type-classes as me ;)

Alan

 


-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[Matt Sherman]

Thanks Ian, was hoping you’d weigh in.

Perhaps a compromise position would be that these type 
groups/classes/contracts are not language builtins but in the stdlib? 
contracts.Comparable, etc. If we really don’t want to see the dot, we 
import with _.

And, for a first implementation, only the stdlib can define contracts. We 
might find that to be ‘good enough’ (a positive outcome).

The hypothesis (just to reiterate) is that there is a small number of 
contracts that cover the majority of use cases, and so we can exploit that 
fact to minimize new language concepts. 80% benefit for 20% complexity, 
which is how I describe Go’s current type system.


On Thursday, September 6, 2018 at 12:54:24 PM UTC-4, Ian Lance Taylor wrote:
>
> On Thu, Sep 6, 2018 at 8:20 AM,  > wrote: 
> > 
> > As I wasn't happy with some aspects of it, I've rewritten my feedback on 
> the 
> > Go 2 Generics draft and deleted the original gist. Here's the link to 
> the 
> > new gist for anybody who's interested: 
> > https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251 
> > 
> > This is still based on the type-class idea though I'm now proposing a 
> > simplified contracts approach to go with it rather than trying to make 
> > interfaces fit. It seems to deal easily now with all the examples in the 
> > draft paper though no doubt there will be stuff that it can't do or that 
> > I've overlooked. 
>
> Thanks for writing this.  I never got around to reading the earlier 
> feedback.  And thanks for working out the examples. 
>
> Personally I think an important feature of the current design draft is 
> that it adds relatively few new concepts to the language.  While 
> concepts are of course a new feature, a contract looks like a 
> function.  If you can read a function, you can read a contract.  You 
> don't need to understand a new set of ideas to know what a contract 
> is.  With your proposal, everybody has to learn a new set of 
> predeclared identifiers.  You list 14 new ones, including $struct.  I 
> count 39 existing predeclared identifiers, so this is a significant 
> increase.  Also, of course, the new identifiers don't look like any 
> existing ones, with the $, but perhaps that could be changed.  I would 
> very much prefer to not add so many new names. 
>
> If new features are added to the language, your approach may require 
> new predeclared identifiers, whereas the contract approach will 
> automatically adjust. 
>
> It's worth noting that your suggestion is less powerful than the 
> design draft, in that you can't express the notion of type parameter 
> that must be a channel type or a slice type.  This may not matter very 
> much, because the generic function can always write chan T or []T. 
>
>
> > It looks to me as though, if it requires a contract at all, you might 
> end up writing one from scratch for most generic functions/types you need. 
> Even if the commoner ones could be included in a 'contracts' package in the 
> standard library, you'd still need to import that package and then write 
> stuff like 'contracts.Comparable' which is a bit verbose. 
> > 
> > Even if the present design prove workable, I think writing contracts may 
> prove a bit of a black art and that, if things are at all complicated, some 
> programmers may just give it up and embed the function's code in the 
> contract which defeats the object of having them in the first place! 
>
> I believe we can use tooling to make these operations easier.  For 
> example, assuming we can make contracts work at all, it should be 
> straightforward to write a tool that can minimize a contract given an 
> existing contract definition, and therefore can produce a minimal 
> contract for an existing function body. 
>
> Note that while I think it's important that there be some way to 
> express complex contracts, I think they will be used quite rarely. 
>
>
> > The more I look at this, the more complicated it seems to get :( 
>
> Yes. 
>
> Ian 
>

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

['Axel Wagner' via golang-nuts]

FWIW, personally I think type parameters are far more important than 
contracts about the draft design. i.e. I agree, that if you can't make 
contracts work (or decide they aren't a good solution), I'd still think 
it's worth considering to only add type-parameters on their own.

To me, contracts only achieve one thing over interface-constrained 
type-parameters, which is to reduce boilerplate in wrapping operators. IMO 
most everything else about the design (type-checking different 
arguments/returns being consistent, writing generic data structures…) can 
probably be achieved without contracts. Personally, I'd be fine not to use 
operators when writing generic code (and writing wrapper-methods when using 
it), if the alternative is not to be able to write type-safe generic code 
at all.

(I know that some people are unhappy about the syntax of type-parameters 
and I agree. But syntax can be talked about once we know what the semantics 
are it needs to express)

On Thursday, September 6, 2018 at 7:30:02 PM UTC+2, soapboxcicero wrote:
>
> Contracts are a brilliant solution to the problem on an intellectual 
> level. I really am impressed by how deftly they tackle the stated 
> problem. But I am concerned about their usability on the practical 
> level. The idea is simple but its user interface is not. I don't buy 
> the claim that it's okay because a priest-class will be the only ones 
> writing generic code. Everyone will still have to read it and deal 
> with it. 
>
> Scaling back the problem to simply not include operators and fields at 
> all looks like it eliminates so much of the complexity in the 
> implementation and its user interface. Any such limited solution 
> increases the boilerplate of using generics when operators and fields 
> come in to play, certainly, but I think the majority of use-cases for 
> generics are going to be data structures and algorithms more generally 
> expressible without operators anyway (few types have a < operator but 
> any type can have a Less method and without type classes in the 
> haskell/etc. there still isn't a way to handle both without accepting 
> a Less method and requiring a wrapper for types that have a < 
> operator). 
>
> Is it really *necessary* for generics to support operators and fields? 
> On Thu, Sep 6, 2018 at 9:54 AM Ian Lance Taylor  > wrote: 
> > 
> > On Thu, Sep 6, 2018 at 8:20 AM,  > 
> wrote: 
> > > 
> > > As I wasn't happy with some aspects of it, I've rewritten my feedback 
> on the 
> > > Go 2 Generics draft and deleted the original gist. Here's the link to 
> the 
> > > new gist for anybody who's interested: 
> > > https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251 
> > > 
> > > This is still based on the type-class idea though I'm now proposing a 
> > > simplified contracts approach to go with it rather than trying to make 
> > > interfaces fit. It seems to deal easily now with all the examples in 
> the 
> > > draft paper though no doubt there will be stuff that it can't do or 
> that 
> > > I've overlooked. 
> > 
> > Thanks for writing this.  I never got around to reading the earlier 
> > feedback.  And thanks for working out the examples. 
> > 
> > Personally I think an important feature of the current design draft is 
> > that it adds relatively few new concepts to the language.  While 
> > concepts are of course a new feature, a contract looks like a 
> > function.  If you can read a function, you can read a contract.  You 
> > don't need to understand a new set of ideas to know what a contract 
> > is.  With your proposal, everybody has to learn a new set of 
> > predeclared identifiers.  You list 14 new ones, including $struct.  I 
> > count 39 existing predeclared identifiers, so this is a significant 
> > increase.  Also, of course, the new identifiers don't look like any 
> > existing ones, with the $, but perhaps that could be changed.  I would 
> > very much prefer to not add so many new names. 
> > 
> > If new features are added to the language, your approach may require 
> > new predeclared identifiers, whereas the contract approach will 
> > automatically adjust. 
> > 
> > It's worth noting that your suggestion is less powerful than the 
> > design draft, in that you can't express the notion of type parameter 
> > that must be a channel type or a slice type.  This may not matter very 
> > much, because the generic function can always write chan T or []T. 
> > 
> > 
> > > It looks to me as though, if it requires a contract at all, you might 
> end up writing one from scratch for most generic functions/types you need. 
> Even if the commoner ones could be included in a 'contracts' package in the 
> standard library, you'd still need to import that package and then write 
> stuff like 'contracts.Comparable' which is a bit verbose. 
> > > 
> > > Even if the present design prove workable, I think writing contracts 
> may prove a bit of a black art and that, if things are at all complicated, 
> some programmers 

[go-nuts] Re: Performance regression of HTTP requests since Go 1.11

[Vladimir Varankin]

I've seen a similar issue on one of your test hosts and it turned out the 
issue was due to a non-responding NS server in the host's resolv.conf.

See https://github.com/golang/go/issues/27525 DNS regression.

On Wednesday, September 5, 2018 at 5:07:01 PM UTC+2, mrauh wrote:
>
> Thanks for your help!
>
>

-- 
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.

Re: [go-nuts] Re: Generics as builtin typeclasses

[jimmy frasche]

Contracts are a brilliant solution to the problem on an intellectual
level. I really am impressed by how deftly they tackle the stated
problem. But I am concerned about their usability on the practical
level. The idea is simple but its user interface is not. I don't buy
the claim that it's okay because a priest-class will be the only ones
writing generic code. Everyone will still have to read it and deal
with it.

Scaling back the problem to simply not include operators and fields at
all looks like it eliminates so much of the complexity in the
implementation and its user interface. Any such limited solution
increases the boilerplate of using generics when operators and fields
come in to play, certainly, but I think the majority of use-cases for
generics are going to be data structures and algorithms more generally
expressible without operators anyway (few types have a < operator but
any type can have a Less method and without type classes in the
haskell/etc. there still isn't a way to handle both without accepting
a Less method and requiring a wrapper for types that have a <
operator).

Is it really *necessary* for generics to support operators and fields?
On Thu, Sep 6, 2018 at 9:54 AM Ian Lance Taylor  wrote:
>
> On Thu, Sep 6, 2018 at 8:20 AM,   wrote:
> >
> > As I wasn't happy with some aspects of it, I've rewritten my feedback on the
> > Go 2 Generics draft and deleted the original gist. Here's the link to the
> > new gist for anybody who's interested:
> > https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251
> >
> > This is still based on the type-class idea though I'm now proposing a
> > simplified contracts approach to go with it rather than trying to make
> > interfaces fit. It seems to deal easily now with all the examples in the
> > draft paper though no doubt there will be stuff that it can't do or that
> > I've overlooked.
>
> Thanks for writing this.  I never got around to reading the earlier
> feedback.  And thanks for working out the examples.
>
> Personally I think an important feature of the current design draft is
> that it adds relatively few new concepts to the language.  While
> concepts are of course a new feature, a contract looks like a
> function.  If you can read a function, you can read a contract.  You
> don't need to understand a new set of ideas to know what a contract
> is.  With your proposal, everybody has to learn a new set of
> predeclared identifiers.  You list 14 new ones, including $struct.  I
> count 39 existing predeclared identifiers, so this is a significant
> increase.  Also, of course, the new identifiers don't look like any
> existing ones, with the $, but perhaps that could be changed.  I would
> very much prefer to not add so many new names.
>
> If new features are added to the language, your approach may require
> new predeclared identifiers, whereas the contract approach will
> automatically adjust.
>
> It's worth noting that your suggestion is less powerful than the
> design draft, in that you can't express the notion of type parameter
> that must be a channel type or a slice type.  This may not matter very
> much, because the generic function can always write chan T or []T.
>
>
> > It looks to me as though, if it requires a contract at all, you might end 
> > up writing one from scratch for most generic functions/types you need. Even 
> > if the commoner ones could be included in a 'contracts' package in the 
> > standard library, you'd still need to import that package and then write 
> > stuff like 'contracts.Comparable' which is a bit verbose.
> >
> > Even if the present design prove workable, I think writing contracts may 
> > prove a bit of a black art and that, if things are at all complicated, some 
> > programmers may just give it up and embed the function's code in the 
> > contract which defeats the object of having them in the first place!
>
> I believe we can use tooling to make these operations easier.  For
> example, assuming we can make contracts work at all, it should be
> straightforward to write a tool that can minimize a contract given an
> existing contract definition, and therefore can produce a minimal
> contract for an existing function body.
>
> Note that while I think it's important that there be some way to
> express complex contracts, I think they will be used quite rarely.
>
>
> > The more I look at this, the more complicated it seems to get :(
>
> Yes.
>
> Ian
>
> --
> 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.

-- 
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 

Re: [go-nuts] Re: Why does this struct escape to the heap?

[pauldice]

Yes, I came across that post when looking for info on method values and 
allocations. I'm sure that's the root of the problem. But I don't 
understand why the compiler can't figure out that no heap allocation is 
needed. If t doesn't escape when calling t.M(), why can't the compiler work 
out that t.M shouldn't cause t to escape either?

On Thursday, September 6, 2018 at 11:39:41 AM UTC-5, Tristan Colgate wrote:
>
> Perhaps...
>
> https://groups.google.com/forum/m/#!topic/golang-nuts/aMicHmoOH1c
>
> On Thu, 6 Sep 2018, 17:26 , > wrote:
>
>> Using a pointer receiver (as in your noEscape example) just pushes the 
>> problem up the stack. When you try to call it, e.g.
>>
>>
>> func parent() bool {
>> var opts options
>> return noEscape('0', )
>> }
>>
>>
>> you find that  escapes to the heap in the parent function instead.
>>
>> I haven't opened an issue yet (I was hoping to get confirmation that it 
>> was a bug first) but will do so today unless someone posts a definitive 
>> answer here.
>>
>> Thanks...
>>
>>
>> On Thursday, September 6, 2018 at 10:33:17 AM UTC-5, Tristan Colgate 
>> wrote:
>>>
>>>   I think this has to do with the pointer reciever, vs the pass by value:
>>>
>>> func noEscape(r rune, opts *options) bool {
>>>  f := opts.isDigit
>>>  return f(r)
>>> }
>>>
>>> opts here does not escape, but in:
>>>
>>> func escapes(r rune, opts options) bool {
>>>  f := opts.isDigit
>>>  return f(r)
>>> }
>>>
>>> opts is copied, so it is the copy of opts that the compiler believes 
>>> escapes. Perhaps this is because opts could be used by a defer (there is 
>>> none though, the compiler could/should notice that).
>>>
>>> In the following, opts2 even escapes and gets heap allocated.
>>>
>>> func escapes(r rune, opts *options) bool {
>>>   var res bool
>>>   {
>>> opts2 := *opts  
>>>
>>> f := opts2.isDigit
>>> res = f(r)
>>>   }
>>>   return res 
>>> }
>>>
>>> Did you open an issue? I'm curious if there is a reason the escape 
>>> analysis can't pick this up.
>>>
>>>
>>> On Wed, 5 Sep 2018 at 18:06  wrote:
>>>
>> I wonder if this is to do with method values. According to the spec 
 , when you declare a method 
 value like x.M:

 The expression x is evaluated and saved during the evaluation of the 
> method value; the saved copy is then used as the receiver in any calls, 
> which may be executed later.


 So using the method value opts.isDigit in index1 does in fact result in 
  being copied. Maybe this causes opts to escape to the heap (although 
 I don't know why the copy would need to live beyond the scope of index1). 
 This would also explain why opts does not escape in index2 where 
 opts.isDigit() is just a normal method call.

 I tested this theory with two new functions (neither of which call 
 IndexFunc -- that doesn't seem to be part of the problem). One function 
 calls the isDigit method directly and the other uses a method value. 
 They're functionally equivalent but opts only escapes in the second 
 function.


 // isDigit called directly: opts does not escape to heap
 func isDigit1(r rune, opts options) bool {
 return opts.isDigit(r)
 }

 // isDigit called via method value: opts escapes to heap
 func isDigit2(r rune, opts options) bool {
 f := opts.isDigit
 return f(r)
 }


 Does anyone have any insight/views on a) whether this is really what's 
 happening and b) whether this is the desired behaviour? I don't see why 
 using method values in this way should cause a heap allocation but perhaps 
 there's a reason for it.


 On Tuesday, September 4, 2018 at 4:46:09 PM UTC-5, Paul D wrote:
>
> I'm trying to reduce allocations (and improve performance) in some Go 
> code. There's a recurring pattern in the code where a struct is passed to 
> a 
> function, and the function passes one of the struct's methods to 
> strings.IndexFunc. For some reason, this causes the entire struct to 
> escape 
> to the heap. If I wrap the method call in an anonymous function, the 
> struct 
> does not escape and the benchmarks run about 30% faster.
>
> Here is a minimal example. In the actual code, the struct has more 
> fields/methods and the function in question actually does something. But 
> this sample code illustrates the problem. Why does the opts argument 
> escape 
> to the heap in index1 but not in the functionally equivalent index2? And 
> is 
> there a robust way to ensure that it stays on the stack?
>
>
> type options struct {
> zero rune
> }
>
> func (opts *options) isDigit(r rune) bool {
> r -= opts.zero
> return r >= 0 && r <= 

Re: [go-nuts] Re: Generics as builtin typeclasses

[Ian Lance Taylor]

On Thu, Sep 6, 2018 at 8:20 AM,   wrote:
>
> As I wasn't happy with some aspects of it, I've rewritten my feedback on the
> Go 2 Generics draft and deleted the original gist. Here's the link to the
> new gist for anybody who's interested:
> https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251
>
> This is still based on the type-class idea though I'm now proposing a
> simplified contracts approach to go with it rather than trying to make
> interfaces fit. It seems to deal easily now with all the examples in the
> draft paper though no doubt there will be stuff that it can't do or that
> I've overlooked.

Thanks for writing this.  I never got around to reading the earlier
feedback.  And thanks for working out the examples.

Personally I think an important feature of the current design draft is
that it adds relatively few new concepts to the language.  While
concepts are of course a new feature, a contract looks like a
function.  If you can read a function, you can read a contract.  You
don't need to understand a new set of ideas to know what a contract
is.  With your proposal, everybody has to learn a new set of
predeclared identifiers.  You list 14 new ones, including $struct.  I
count 39 existing predeclared identifiers, so this is a significant
increase.  Also, of course, the new identifiers don't look like any
existing ones, with the $, but perhaps that could be changed.  I would
very much prefer to not add so many new names.

If new features are added to the language, your approach may require
new predeclared identifiers, whereas the contract approach will
automatically adjust.

It's worth noting that your suggestion is less powerful than the
design draft, in that you can't express the notion of type parameter
that must be a channel type or a slice type.  This may not matter very
much, because the generic function can always write chan T or []T.


> It looks to me as though, if it requires a contract at all, you might end up 
> writing one from scratch for most generic functions/types you need. Even if 
> the commoner ones could be included in a 'contracts' package in the standard 
> library, you'd still need to import that package and then write stuff like 
> 'contracts.Comparable' which is a bit verbose.
>
> Even if the present design prove workable, I think writing contracts may 
> prove a bit of a black art and that, if things are at all complicated, some 
> programmers may just give it up and embed the function's code in the contract 
> which defeats the object of having them in the first place!

I believe we can use tooling to make these operations easier.  For
example, assuming we can make contracts work at all, it should be
straightforward to write a tool that can minimize a contract given an
existing contract definition, and therefore can produce a minimal
contract for an existing function body.

Note that while I think it's important that there be some way to
express complex contracts, I think they will be used quite rarely.


> The more I look at this, the more complicated it seems to get :(

Yes.

Ian

-- 
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.

Re: [go-nuts] Re: Why does this struct escape to the heap?

[Tristan Colgate]

Perhaps...

https://groups.google.com/forum/m/#!topic/golang-nuts/aMicHmoOH1c

On Thu, 6 Sep 2018, 17:26 ,  wrote:

> Using a pointer receiver (as in your noEscape example) just pushes the
> problem up the stack. When you try to call it, e.g.
>
>
> func parent() bool {
> var opts options
> return noEscape('0', )
> }
>
>
> you find that  escapes to the heap in the parent function instead.
>
> I haven't opened an issue yet (I was hoping to get confirmation that it
> was a bug first) but will do so today unless someone posts a definitive
> answer here.
>
> Thanks...
>
>
> On Thursday, September 6, 2018 at 10:33:17 AM UTC-5, Tristan Colgate wrote:
>>
>>   I think this has to do with the pointer reciever, vs the pass by value:
>>
>> func noEscape(r rune, opts *options) bool {
>>  f := opts.isDigit
>>  return f(r)
>> }
>>
>> opts here does not escape, but in:
>>
>> func escapes(r rune, opts options) bool {
>>  f := opts.isDigit
>>  return f(r)
>> }
>>
>> opts is copied, so it is the copy of opts that the compiler believes
>> escapes. Perhaps this is because opts could be used by a defer (there is
>> none though, the compiler could/should notice that).
>>
>> In the following, opts2 even escapes and gets heap allocated.
>>
>> func escapes(r rune, opts *options) bool {
>>   var res bool
>>   {
>> opts2 := *opts
>>
>> f := opts2.isDigit
>> res = f(r)
>>   }
>>   return res
>> }
>>
>> Did you open an issue? I'm curious if there is a reason the escape
>> analysis can't pick this up.
>>
>>
>> On Wed, 5 Sep 2018 at 18:06  wrote:
>>
> I wonder if this is to do with method values. According to the spec
>>> , when you declare a method
>>> value like x.M:
>>>
>>> The expression x is evaluated and saved during the evaluation of the
 method value; the saved copy is then used as the receiver in any calls,
 which may be executed later.
>>>
>>>
>>> So using the method value opts.isDigit in index1 does in fact result in
>>>  being copied. Maybe this causes opts to escape to the heap (although
>>> I don't know why the copy would need to live beyond the scope of index1).
>>> This would also explain why opts does not escape in index2 where
>>> opts.isDigit() is just a normal method call.
>>>
>>> I tested this theory with two new functions (neither of which call
>>> IndexFunc -- that doesn't seem to be part of the problem). One function
>>> calls the isDigit method directly and the other uses a method value.
>>> They're functionally equivalent but opts only escapes in the second
>>> function.
>>>
>>>
>>> // isDigit called directly: opts does not escape to heap
>>> func isDigit1(r rune, opts options) bool {
>>> return opts.isDigit(r)
>>> }
>>>
>>> // isDigit called via method value: opts escapes to heap
>>> func isDigit2(r rune, opts options) bool {
>>> f := opts.isDigit
>>> return f(r)
>>> }
>>>
>>>
>>> Does anyone have any insight/views on a) whether this is really what's
>>> happening and b) whether this is the desired behaviour? I don't see why
>>> using method values in this way should cause a heap allocation but perhaps
>>> there's a reason for it.
>>>
>>>
>>> On Tuesday, September 4, 2018 at 4:46:09 PM UTC-5, Paul D wrote:

 I'm trying to reduce allocations (and improve performance) in some Go
 code. There's a recurring pattern in the code where a struct is passed to a
 function, and the function passes one of the struct's methods to
 strings.IndexFunc. For some reason, this causes the entire struct to escape
 to the heap. If I wrap the method call in an anonymous function, the struct
 does not escape and the benchmarks run about 30% faster.

 Here is a minimal example. In the actual code, the struct has more
 fields/methods and the function in question actually does something. But
 this sample code illustrates the problem. Why does the opts argument escape
 to the heap in index1 but not in the functionally equivalent index2? And is
 there a robust way to ensure that it stays on the stack?


 type options struct {
 zero rune
 }

 func (opts *options) isDigit(r rune) bool {
 r -= opts.zero
 return r >= 0 && r <= 9
 }

 // opts escapes to heap
 func index1(s string, opts options) int {
 return strings.IndexFunc(s, opts.isDigit)
 }

 // opts does not escape to heap
 func index2(s string, opts options) int {
 return strings.IndexFunc(s, func(r rune) bool {
 return opts.isDigit(r)
 })
 }


 FYI I'm running Go 1.10.3 on Linux. Thanks...


 --
>>> 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...@googlegroups.com.
>>
>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You 

Re: [go-nuts] Re: Why does this struct escape to the heap?

[pauldice]

Using a pointer receiver (as in your noEscape example) just pushes the 
problem up the stack. When you try to call it, e.g.


func parent() bool {
var opts options
return noEscape('0', )
}


you find that  escapes to the heap in the parent function instead.

I haven't opened an issue yet (I was hoping to get confirmation that it was 
a bug first) but will do so today unless someone posts a definitive answer 
here.

Thanks...


On Thursday, September 6, 2018 at 10:33:17 AM UTC-5, Tristan Colgate wrote:
>
>   I think this has to do with the pointer reciever, vs the pass by value:
>
> func noEscape(r rune, opts *options) bool {
>  f := opts.isDigit
>  return f(r)
> }
>
> opts here does not escape, but in:
>
> func escapes(r rune, opts options) bool {
>  f := opts.isDigit
>  return f(r)
> }
>
> opts is copied, so it is the copy of opts that the compiler believes 
> escapes. Perhaps this is because opts could be used by a defer (there is 
> none though, the compiler could/should notice that).
>
> In the following, opts2 even escapes and gets heap allocated.
>
> func escapes(r rune, opts *options) bool {
>   var res bool
>   {
> opts2 := *opts
>  
> f := opts2.isDigit
> res = f(r)
>   }
>   return res 
> }
>
> Did you open an issue? I'm curious if there is a reason the escape 
> analysis can't pick this up.
>
>
> On Wed, 5 Sep 2018 at 18:06 > wrote:
>
>> I wonder if this is to do with method values. According to the spec 
>> , when you declare a method 
>> value like x.M:
>>
>> The expression x is evaluated and saved during the evaluation of the 
>>> method value; the saved copy is then used as the receiver in any calls, 
>>> which may be executed later.
>>
>>
>> So using the method value opts.isDigit in index1 does in fact result in 
>>  being copied. Maybe this causes opts to escape to the heap (although 
>> I don't know why the copy would need to live beyond the scope of index1). 
>> This would also explain why opts does not escape in index2 where 
>> opts.isDigit() is just a normal method call.
>>
>> I tested this theory with two new functions (neither of which call 
>> IndexFunc -- that doesn't seem to be part of the problem). One function 
>> calls the isDigit method directly and the other uses a method value. 
>> They're functionally equivalent but opts only escapes in the second 
>> function.
>>
>>
>> // isDigit called directly: opts does not escape to heap
>> func isDigit1(r rune, opts options) bool {
>> return opts.isDigit(r)
>> }
>>
>> // isDigit called via method value: opts escapes to heap
>> func isDigit2(r rune, opts options) bool {
>> f := opts.isDigit
>> return f(r)
>> }
>>
>>
>> Does anyone have any insight/views on a) whether this is really what's 
>> happening and b) whether this is the desired behaviour? I don't see why 
>> using method values in this way should cause a heap allocation but perhaps 
>> there's a reason for it.
>>
>>
>> On Tuesday, September 4, 2018 at 4:46:09 PM UTC-5, Paul D wrote:
>>>
>>> I'm trying to reduce allocations (and improve performance) in some Go 
>>> code. There's a recurring pattern in the code where a struct is passed to a 
>>> function, and the function passes one of the struct's methods to 
>>> strings.IndexFunc. For some reason, this causes the entire struct to escape 
>>> to the heap. If I wrap the method call in an anonymous function, the struct 
>>> does not escape and the benchmarks run about 30% faster.
>>>
>>> Here is a minimal example. In the actual code, the struct has more 
>>> fields/methods and the function in question actually does something. But 
>>> this sample code illustrates the problem. Why does the opts argument escape 
>>> to the heap in index1 but not in the functionally equivalent index2? And is 
>>> there a robust way to ensure that it stays on the stack?
>>>
>>>
>>> type options struct {
>>> zero rune
>>> }
>>>
>>> func (opts *options) isDigit(r rune) bool {
>>> r -= opts.zero
>>> return r >= 0 && r <= 9
>>> }
>>>
>>> // opts escapes to heap
>>> func index1(s string, opts options) int {
>>> return strings.IndexFunc(s, opts.isDigit)
>>> }
>>>
>>> // opts does not escape to heap
>>> func index2(s string, opts options) int {
>>> return strings.IndexFunc(s, func(r rune) bool {
>>> return opts.isDigit(r)
>>> })
>>> }
>>>
>>>
>>> FYI I'm running Go 1.10.3 on Linux. Thanks...
>>>
>>>
>>> -- 
>> 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...@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 

Re: [go-nuts] Re: Implementing Design by Contract (DbC) paradigm in Go?

[Marko Ristin]

Hi,
I'd like to point you to a go tool that implements contracts (pre and 
postconditions) as part of documentation. The tool translates the contracts 
into code by adding it to the function body. It can also automatically remove 
the checks once you don't need them any more (e.g. in production). 

Here is the repository:
https://github.com/Parquery/gocontracts

We are thinking about implementing the invariants in a similar way. Please have 
a look at this post if you'd like to discuss the details or contribute:
https://groups.google.com/forum/?hl=uk=true#!topic/golang-nuts/zKQA0Lh116k

-- 
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.

Re: [go-nuts] Re: Why does this struct escape to the heap?

[Tristan Colgate]

  I think this has to do with the pointer reciever, vs the pass by value:

func noEscape(r rune, opts *options) bool {
 f := opts.isDigit
 return f(r)
}

opts here does not escape, but in:

func escapes(r rune, opts options) bool {
 f := opts.isDigit
 return f(r)
}

opts is copied, so it is the copy of opts that the compiler believes
escapes. Perhaps this is because opts could be used by a defer (there is
none though, the compiler could/should notice that).

In the following, opts2 even escapes and gets heap allocated.

func escapes(r rune, opts *options) bool {
  var res bool
  {
opts2 := *opts

f := opts2.isDigit
res = f(r)
  }
  return res
}

Did you open an issue? I'm curious if there is a reason the escape analysis
can't pick this up.


On Wed, 5 Sep 2018 at 18:06  wrote:

> I wonder if this is to do with method values. According to the spec
> , when you declare a method
> value like x.M:
>
> The expression x is evaluated and saved during the evaluation of the
>> method value; the saved copy is then used as the receiver in any calls,
>> which may be executed later.
>
>
> So using the method value opts.isDigit in index1 does in fact result in
>  being copied. Maybe this causes opts to escape to the heap (although
> I don't know why the copy would need to live beyond the scope of index1).
> This would also explain why opts does not escape in index2 where
> opts.isDigit() is just a normal method call.
>
> I tested this theory with two new functions (neither of which call
> IndexFunc -- that doesn't seem to be part of the problem). One function
> calls the isDigit method directly and the other uses a method value.
> They're functionally equivalent but opts only escapes in the second
> function.
>
>
> // isDigit called directly: opts does not escape to heap
> func isDigit1(r rune, opts options) bool {
> return opts.isDigit(r)
> }
>
> // isDigit called via method value: opts escapes to heap
> func isDigit2(r rune, opts options) bool {
> f := opts.isDigit
> return f(r)
> }
>
>
> Does anyone have any insight/views on a) whether this is really what's
> happening and b) whether this is the desired behaviour? I don't see why
> using method values in this way should cause a heap allocation but perhaps
> there's a reason for it.
>
>
> On Tuesday, September 4, 2018 at 4:46:09 PM UTC-5, Paul D wrote:
>>
>> I'm trying to reduce allocations (and improve performance) in some Go
>> code. There's a recurring pattern in the code where a struct is passed to a
>> function, and the function passes one of the struct's methods to
>> strings.IndexFunc. For some reason, this causes the entire struct to escape
>> to the heap. If I wrap the method call in an anonymous function, the struct
>> does not escape and the benchmarks run about 30% faster.
>>
>> Here is a minimal example. In the actual code, the struct has more
>> fields/methods and the function in question actually does something. But
>> this sample code illustrates the problem. Why does the opts argument escape
>> to the heap in index1 but not in the functionally equivalent index2? And is
>> there a robust way to ensure that it stays on the stack?
>>
>>
>> type options struct {
>> zero rune
>> }
>>
>> func (opts *options) isDigit(r rune) bool {
>> r -= opts.zero
>> return r >= 0 && r <= 9
>> }
>>
>> // opts escapes to heap
>> func index1(s string, opts options) int {
>> return strings.IndexFunc(s, opts.isDigit)
>> }
>>
>> // opts does not escape to heap
>> func index2(s string, opts options) int {
>> return strings.IndexFunc(s, func(r rune) bool {
>> return opts.isDigit(r)
>> })
>> }
>>
>>
>> FYI I'm running Go 1.10.3 on Linux. Thanks...
>>
>>
>> --
> 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.
>

-- 
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.

[go-nuts] Re: Go concurrency performance

[ffm2002]

It seems that in your Put function you are creating a new hashTable for 
every single put with the values from the existing hashTable being moved 
over to the new hashTable. Why are doing that? Just add the new value for 
the given key to the hashTable for the segment obtained by key.Hash() % 16 
and you are done. 

Am Donnerstag, 6. September 2018 15:00:18 UTC+2 schrieb Robert Engels:
>
> Hi, 
>
> I posted this to golang-dev, and the consensus seems to be this is a 
> better forum to address the issue? 
>
> Anyway, you can review the project 
> https://github.com/robaho/go-concurrency-test 
>
> The readme.md details the experiment. 
>
> It does some analysis of the Go concurrency primitives, in the context of 
> writing a ‘shared cache’. The conclusion is that there is a lot of room for 
> improvement, at least when compared to Java. 
>
> With a larger audience it might be possible for someone to actually run 
> the test (strange how people see the results and critique without ever even 
> attempting to run them…), hopefully on additional platforms like Linux, and 
> possibly a higher core machine (and then increase the number of threads). 
>
> Anyway, let me know your thoughts. Thanks. 
>
>
>
>
>

-- 
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.

[go-nuts] Re: Generics as builtin typeclasses

[alan . fox6]

As I wasn't happy with some aspects of it, I've rewritten my feedback on 
the Go 2 Generics draft and deleted the original gist. Here's the link to 
the new gist for anybody who's interested: 
https://gist.github.com/alanfo/5da5932c7b60fd130a928ebbace1f251

This is still based on the type-class idea though I'm now proposing a 
simplified contracts approach to go with it rather than trying to make 
interfaces fit. It seems to deal easily now with all the examples in the 
draft paper though no doubt there will be stuff that it can't do or that 
I've overlooked. 

The more I look at this, the more complicated it seems to get :(

-- 
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.

Re: [go-nuts] confused about assignability

[Ian Lance Taylor]

On Thu, Sep 6, 2018 at 7:00 AM, Jonathan Amsterdam
 wrote:
> Consider
>
> type Int int
> var y int = Int(3)
>
> The spec says
>
> A value x is assignable to a variable of type T ("x is assignable to T") if
> one of the following conditions applies:
>
> x's type V and T have identical underlying types and at least one of V or T
> is not a defined type.
> [other conditions]
>
>
> Here, x's type V is Int, whose underlying type is int, so the underlying
> types are the same. And one of V and T (namely, T, which is int) is not a
> defined type.
>
>
> So the spec says the assignment should work. But the playground says
>
>
> cannot use Int(3) (type Int) as type int in assignment

`int` is a defined type.  See the bottom of the
https://golang.org/ref/spec#Numeric_types section.

Ian

-- 
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.

[go-nuts] confused about assignability

[Jonathan Amsterdam]

Consider

type Int int
var y int = Int(3)

The spec says

A value x is assignable to a variable 
 of type T ("x is assignable to T") 
if one of the following conditions applies:


   - x's type V and T have identical underlying types 
   and at least one of V or T is not 
  a defined  type.
  - [other conditions]
   

Here, x's type V is Int, whose underlying type is int, so the underlying 
types are the same. And one of V and T (namely, T, which is int) is not a 
defined type.


So the spec says the assignment should work. But the playground says


cannot use Int(3) (type Int) as type int in assignment


-- 
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.

[go-nuts] Bizarre linker error when creating custom GOOS for Webassembly stuff

[Christine Dodrill]

Hello,

I am working on server-side webassembly stuff and the fact that I am not a 
javascript interpreter was getting in the way due to nearly all the 
standard library pulling in syscall/js. To obviate this problem, I have 
created a custom GOOS that I will not link any javascript code to. I have 
been having a strange issue when trying to test a "Hello world" program via 
this 
fork: https://github.com/Xe/go/commit/37bc30ec064a32a630cdad325f83020c1f5be976

The program in question:

// main.go
package main

func main() {
  println("hello, world!")
}

Yields this error

~/Code/godagger/bin $ GOOS=dagger GOARCH=wasm ./go build -o main.wasm -v -x 
main.go
WORK=/var/folders/90/m9qxx4xn30j6qb9_kmyz85gcgn/T/go-build069828174
mkdir -p $WORK/b001/
cat >$WORK/b001/importcfg.link << 'EOF' # internal
packagefile 
command-line-arguments=/Users/cadey/Library/Caches/go-build/55/55f7fdd8d4421dbcf4f7086d0f8340cf6ecd0eda676e8f50afcd3c96a8bc56ff-d
packagefile 
runtime=/Users/cadey/Library/Caches/go-build/67/6714236b47a70990fb0340fe648fd0e231957e66e66f6d4e0b90bc00bac56821-d
packagefile 
internal/bytealg=/Users/cadey/Library/Caches/go-build/5a/5a1eaeacdfbfd8980aaa38233ba37799dc4586554c2f9644f5cf112ee2de67d2-d
packagefile 
internal/cpu=/Users/cadey/Library/Caches/go-build/86/86d373925de1c5e6175ca992d172e639189a2a4f620eeef7924585ac1a828e0d-d
packagefile 
runtime/internal/atomic=/Users/cadey/Library/Caches/go-build/88/88207d5f364c51cfd7fb7df7be3c10cef8b1ef1dccf48b8c30e98e93f31e520c-d
packagefile 
runtime/internal/sys=/Users/cadey/Library/Caches/go-build/c6/c6325bb1714391e476d316b6c6f8862eef903eae90ec2c950de6c3cb7ca8e2d2-d
EOF
mkdir -p $WORK/b001/exe/
cd .
/Users/cadey/Code/godagger/pkg/tool/darwin_amd64/link -o $WORK/b001/exe/a.out 
-importcfg $WORK/b001/importcfg.link -buildmode=exe 
-buildid=qUazlQjl5WNuE_nxTSUB/wxw_T9z-Fi14c-8QHTjK/qSmPArTKnJaVIYdqMrzQ/qUazlQjl5WNuE_nxTSUB
 -extld=clang 
/Users/cadey/Library/Caches/go-build/55/55f7fdd8d4421dbcf4f7086d0f8340cf6ecd0eda676e8f50afcd3c96a8bc56ff-d
(hash) command-line-arguments
type.*: phase error: addr=0x11e8 but sym=0x10 type=8

In a failed attempt to debug this further, I have added some debugging calls to 
that part of the linker and gotten this information:

/home/xena/code/godagger/pkg/tool/linux_amd64/link -o $WORK/b001/exe/a.out 
-importcfg $WORK/b001/importcfg.link -buildmode=exe 
-buildid=lTuDD7l8NofYrQu5290j/4J8rA7P-Z303raUCyHDx/w2G2ociXd8XhV0dnVhOW/lTuDD7l8NofYrQu5290j
 -w -extld=gcc 
/home/xena/.cache/go-build/a7/a7bb24f76c378aab3f926f3008fe40a7d0d5fa9f3fbe1736242aad551faf1cee-d
# command-line-arguments
2018/09/05 18:56:52 {Name:"type.*", Type:0x8, Version:0, Attr:520, 
Dynid:-1, Align:0, Elfsym:0, LocalElfsym:0, Value:16, Size:0, 
Sub:(*sym.Symbol)(nil), Outer:(*sym.Symbol)(nil), Gotype:(*sym.Symbol)(nil), 
File:"", auxinfo:(*sym.AuxSymbol)(nil), Sect:(*sym.Section)(0xc000cd0140), 
FuncInfo:(*sym.FuncInfo)(nil), Lib:(*sym.Library)(nil), P:[]uint8(nil), 
R:[]sym.Reloc(nil)}
2018/09/05 18:56:52 i: 0, s.Value: 10 addr: 11e8, eaddr: 11e8
type.*: phase error: addr=0x11e8 but sym=0x10 type=8

I tried skipping over this block of code in the linker, but that produced an 
obviously wrong binary output (less than 1024 bytes). 

What did I do wrong?

Christine Dodrill

-- 
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.

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

[Ian Lance Taylor]

On Thu, Sep 6, 2018 at 5:28 AM,   wrote:
>
> Am Donnerstag, 6. September 2018 13:43:32 UTC+2 schrieb Christophe Meessen:
>>
>> I understand your example, but it wouldn't be a problem anymore with a
>> special character like a $ sign. D use the !.
>
>
> Scala uses [ and ] instead of < and > to avoid the problem that < and > mean
> something different depending on the context.

Note that simple [ and ] don't work in Go, as explained in the
generics design draft.

Ian

-- 
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.

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

[Ian Lance Taylor]

On Thu, Sep 6, 2018 at 12:49 AM, Christophe Meessen
 wrote:
>
> I know about the problems it raised with C++, but Go is different. Go2 draft
> restricts generic parameters to types.
> The only case where there might eventually be an ambiguity is with
> specialized functions in expressions.
>
> I would like to determine if it's still possible to use < > and avoid the
> pitfalls.
>
> One of the option to consider is to use a special character to signal the
> specializing of a generic. Such a special character could be $ for instance.
>
> A generic type or function would be instantiated by the following expression
> :
>
> foo$(...)
> bar$(...)
> foo2$>(...)
>
> When there is only one generic parameter, we could use a concise form
>
> foo$int(...) == foo$(...)
> foo2$List$float(...) == foo2$>(...)
>
> My current understanding is that the $ would remove ambiguity in parsing.


Thanks.  I agree that that your suggestion work.  It just boils down
to aesthetic preference.


> The reason I would prefer to use < > is to
> - satisfy to rule of least surprise.

Your suggested syntax is not the same as any existing language I know
of, so I don't think it's reasonable to claim that it is unsurprising.

> - readability

One of the goals of Go is to look light on the page.  Personally I
don't think scattering $ around the code looks good.  I think it is
less readable.  But, as I say, this is an aesthetic preference.  If
there is a consensus in favor of your syntax, or some other
unambiguous syntax, I'm OK with that.

Ian

-- 
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.

[go-nuts] Go concurrency performance

[robert engels]

Hi,

I posted this to golang-dev, and the consensus seems to be this is a better 
forum to address the issue?

Anyway, you can review the project 
https://github.com/robaho/go-concurrency-test 

The readme.md details the experiment.

It does some analysis of the Go concurrency primitives, in the context of 
writing a ‘shared cache’. The conclusion is that there is a lot of room for 
improvement, at least when compared to Java.

With a larger audience it might be possible for someone to actually run the 
test (strange how people see the results and critique without ever even 
attempting to run them…), hopefully on additional platforms like Linux, and 
possibly a higher core machine (and then increase the number of threads).

Anyway, let me know your thoughts. Thanks.




-- 
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.

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

[ffm2002]

Am Donnerstag, 6. September 2018 13:43:32 UTC+2 schrieb Christophe Meessen:
>
> I understand your example, but it wouldn't be a problem anymore with a 
> special character like a $ sign. D use the !. 
>

Scala uses [ and ] instead of < and > to avoid the problem that < and > 
mean something different depending on the context. 

-- 
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.

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

[Christophe Meessen]

I understand your example, but it wouldn't be a problem anymore with a special 
character like a $ sign. D use the !. 


--
Bien cordialement,
Ch.Meessen

> Le 6 sept. 2018 à 09:56, Jan Mercl <0xj...@gmail.com> a écrit :
> 
> On Thu, Sep 6, 2018 at 9:49 AM Christophe Meessen 
>  wrote:
> 
> func f(bool) { ... }
> 
> func g() { f(ad) }
> 
> an similar constructs require unlimited look ahead to distinguish the above 
> example from something generics. The current Go parser can always decide 
> where to go based on just the next symbol.
> 
> -- 
> -j

-- 
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.

[go-nuts] Upload Website Golang on Linux ( centOS 7) - Help me!

[Seven Dang]

I upload website build Golang on Linux (centOS 7)

Folder Website

 public
--- views
|-backend
|-frontend
main ( build)
--img for folder

[image: img1.jpg] 

[image: img2.jpg] 

[image: img3.jpg] 



i run ssh :

> ./donghogold --> web run ok ( ip:port)


next run file service


--> created file 


cd /etc/systemd/system


nano dongho.service

[Unit]

Description=Go Server

[Service]

ExecStart=/var/www/web/donghogold

User=root

Group=root

Restart=always

[Install]

WantedBy=multi-user.target

--- save


systemctl enable dongho.service

systemctl start dongho.service

systemctl status dongho.service


---> Website no run (ip:port)


 Help me ...! thanks so much






-- 
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.

Re: [go-nuts] Re: Can't print GO2 draft documents with firefox 61.0.1 (64 bits) Ubuntu

[Anny G (annygakh)]

I have tested this on top of the tree for Firefox and only one page was 
showing up in the print preview, so I filed a bug on bugzilla 
https://bugzilla.mozilla.org/show_bug.cgi?id=1489012

- Anny

On Wednesday, September 5, 2018 at 6:28:08 PM UTC-7, peterGo wrote:
>
> Sam,
>
> What happenned when you followed the instructions I gave to Christophe?
>
> Peter
>
> On Wednesday, September 5, 2018 at 6:34:00 PM UTC-4, Sam Whited wrote:
>>
>> On Wed, Sep 5, 2018, at 15:04, peterGo wrote: 
>> > Print the draft documents from Firefox Quantum 61.0.1 (64-bit) for 
>> Mozilla 
>> > Firefox for Ubuntu canonical - 1.0. 
>>
>> I'm using Firefox 63.0a1 nightly cut 2018-08-19 and am also getting only 
>> one page; I had to download a new browser to print. 
>>
>> —Sam 
>>
>

-- 
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.

Re: [go-nuts] Re: Can't print GO2 draft documents with firefox 61.0.1 (64 bits) Ubuntu

[Sam Whited]

On Wed, Sep 5, 2018, at 20:28, peterGo wrote:
> What happenned when you followed the instructions I gave to Christophe?

I believe this is exactly what I was doing before; I don't love having to use 
the simplify option though, so it's possible I left it off and didn't notice. 
I'll try again at some point and follow up if something was off.


—Sam

-- 
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.

[go-nuts] Re: Can't print GO2 draft documents with firefox 61.0.1 (64 bits) Ubuntu

[peterGo]

Christophe,

I gave you precise, tested instructions on how to print from your current 
Firefox browser. Did you follow the instructions?

Peter

On Thursday, September 6, 2018 at 3:29:56 AM UTC-4, Christophe Meessen 
wrote:
>
> Thank you for the suggestions peterGo, but that is my current browser. 
> I finally used Chrome to print.
>
> Le mercredi 5 septembre 2018 10:10:22 UTC+2, Christophe Meessen a écrit :
>>
>> Hello, 
>>
>> when I try to print the draft documents, only the first page is printed. 
>> It's not related with the printer because I get the same result when I 
>> try to print in a document (pdf). 
>>
>> Is it possible to provide the documents also in pdf format ?
>>
>

-- 
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.

Re: [go-nuts] Why can't we use < > for the Go generic parameters ?

[Jan Mercl]

On Thu, Sep 6, 2018 at 9:49 AM Christophe Meessen <
christophe.mees...@gmail.com> wrote:

func f(bool) { ... }

func g() { f(ad) }

an similar constructs require unlimited look ahead to distinguish the above
example from something generics. The current Go parser can always decide
where to go based on just the next symbol.

-- 

-j

-- 
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.

[go-nuts] Why can't we use < > for the Go generic parameters ?

[Christophe Meessen]

I know about the problems it raised with C++, but Go is different. Go2 
draft restricts generic parameters to types. 
The only case where there might eventually be an ambiguity is with 
specialized functions in expressions. 

I would like to determine if it's still possible to use < > and avoid the 
pitfalls.

One of the option to consider is to use a special character to signal the 
specializing of a generic. Such a special character could be $ for 
instance. 

A generic type or function would be instantiated by the following 
expression :

foo$(...) 
bar$(...)
foo2$>(...)

When there is only one generic parameter, we could use a concise form

foo$int(...) == foo$(...)
foo2$List$float(...) == foo2$>(...)

My current understanding is that the $ would remove ambiguity in parsing. 

The reason I would prefer to use < > is to 
- satisfy to rule of least surprise.
- readability 

-- 
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.

[go-nuts] Re: Can't print GO2 draft documents with firefox 61.0.1 (64 bits) Ubuntu

[Christophe Meessen]

Thank you for the suggestions peterGo, but that is my current browser. 
I finally used Chrome to print.

Le mercredi 5 septembre 2018 10:10:22 UTC+2, Christophe Meessen a écrit :
>
> Hello, 
>
> when I try to print the draft documents, only the first page is printed. 
> It's not related with the printer because I get the same result when I try 
> to print in a document (pdf). 
>
> Is it possible to provide the documents also in pdf format ?
>

-- 
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.