Re: [go-nuts] Generics - please provide real life problems

[Tristan Colgate]

If Go with generics wax released tomorrow  I have about 8 kubernetes
controllers that I'd be porting to use a type safe version  of the work
queue  to.
 This isn't theoretical, I will do this week 1 of generics being available.
It is all production code.

On Thu, 24 Dec 2020, 06:15 Martin Hanson, 
wrote:

> I have been arguing passionately against adding generics to Go because
> I truly believe that it is going against the simplicity of Go and the
> philosophy behind the design of Go.
>
> I believe that the resilience of Go against unnecessary change is of
> vital importance. The experience provided by Ken Thompson, Rob Pike and
> Robert Griesemer in designing Go the way they did speaks for itself.
>
> I feel and believe it is of imperative importance to avoid adding things
> to Go that doesn't present a true and real life day-to-day problem
> and so far none of the examples the pro-generics camp has provided has
> been more than minor theoretical examples that do not present any real
> life problems.
>
> I therefore propose that the pro-generics camp provide real examples of
> problems they have faced that was such a big issue that it justifies
> adding generics to Go.
>
> If all we're presented are these small theoretical examples of sorting
> lists, etc., then clearly this is nothing but hype that needs to go
> away.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/19560461608790506%40sas1-75175cadc2b3.qloud-c.yandex.net
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPGZSGJOuB9G5DS%2BvO5X1RudTOWAzfOD2eBW36JwMPyNXdAZ_g%40mail.gmail.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Tristan Colgate]

It is not possible to infer the intent of a chunk of code purely from
the expressions. You can see what it does, not what it meant to do.
One way of labeling the intent is to put that code in a function. A
well chosen name can let someone determine what the function was
intended to do, and fix it if it is doing something else. You can also
test that intention holds for some reasonable set of values, and
people can expand that set of values if they find ones for which that
function seems to do something else.

So, if the choice you propose is between an function with a series of
steps, all in line, vs a function with a series of named steps that
are elsewhere, then yes, I'll go with you're option one because I'd
rather read.

  func (a *thing) processThing() error{
a.tidyTheThing()
a.mungeTheThing()
a.augmentTheThing()
  }

Than a function of potentially unbounded length which is just a frenzy
of activity on that thing.

The problem is that you are advocating for what most people would
consider to be the day 1 programming experience, where experience and
industry best practice has show us that it is better to structure
things more clearly. You are the first person I've seen actually
advocate for this approach, where my own experience, and the
experience of every text I've read, advocates for the opposite.

On Tue, 3 Mar 2020 at 22:38, Warren Stephens
 wrote:
>
> rog,
>
> Very well said -- but everyone keeps talking about improving the 
> maintainability without talking about the "comprehensiblity".
>
> Look at the 2 things below.  Which is more quickly comprehensible?  We cannot 
> conceive of a way to have the upper one and still test each piece???
>
> Warren
>
> AAA
> BBB
>www
> CCC
>xxx
>   yyy
> DDD
>zzz
>
> ===
>
> AAA
> BBB
> www
> CCC
> xxx
> yyy
> DDD
> zzz
>
>
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/be59057f-bd56-4b57-9e23-3c59b1153a47%40googlegroups.com.



-- 
Tristan Colgate-McFarlane

  "You can get all your daily vitamins from 52 pints of guiness, and a
glass of milk"

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPGZSG%2B6KbYTOxeThC6PcxskGSXckebPb%2BUmJ6acp_e%3DRFO%3DRg%40mail.gmail.com.

Re: [go-nuts] Language proposal: labelled "with" statements to help make test code easier to write

[Tristan Colgate]

While pure TDD as defined by its canonical text can be frustrating and time
consuming, simply not writing tests is not really a defensible position,
and definitely not one that Go, or any other language, should attempt to
make easier.
  Writing testable code, and writing tests, does not have to mean TDD. In
my experience it always results in better code, and us tasty slower to
write because you spend less time in dead ends.
  I've done my share of time restricted, stream of consciousness
programming. The results are almost always unmaintainable.
  Saying you should write tests, and write code intending to be tested, is
the right kind of virtue signalling. Tests are one of the few things we
have that gives any meaning to words Software Engineer.


On Mon, 2 Mar 2020, 13:45 Warren Stephens, 
wrote:

> Misha,
>
> Wonderful!  This view is the furtherest away from mere TDD "virtue
> signaling"!
>
> Warren
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/9e906437-f68f-4564-b7dc-1af31c4eb7cd%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPGZSGKY49u8Ju2NyR_tj0oWVjHTgsnR%3DnJLt_k5GknK%2Beuaew%40mail.gmail.com.

Re: [go-nuts] Question about the zero-value design: Why pointers zero value is not the zero value of what they points to?

[Tristan Colgate]

It's also worth pointing out that a nil pointer value can still be useful.
You can still call methods on it.

On Sat, 15 Feb 2020, 13:13 ,  wrote:

> Woah! that's a killer reason, the one I was searching for. Thanks for
> pointing it out, as you have saved me a lot of time discarding the proposal
> I had in mind.
>
> I will need to go in other direction.
>
> El viernes, 14 de febrero de 2020, 15:52:07 (UTC), Brian Candler escribió:
>>
>> In addition, consider:  how would you implement the zero default when the
>> type is self-referential? For example:
>>
>> type Treenode struct {
>>   left *Treenode
>>   right *Treenode
>> }
>>
>> var Tree1, Tree2 *Treenode
>>
>> Also consider deeply nested types which include pointers to structs which
>> contain pointers etc.
>>
>> You can design a language where pointers can never be nil - but then you
>> have to deal with "does not point to anything" some other way (e.g. Maybe
>> values).  That ends up with a very different language.
>>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/e2969605-f82f-4b38-a390-87539c9f3041%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAPGZSG%2BN9YcGe4cvNsa%2B4X%3DGQ7pBqovsm%3Dt7tKH4wEkzR55WGw%40mail.gmail.com.

Re: [go-nuts] Re: Should IP.DefaultMask() exist in today's Internet?

[Tristan Colgate]

Just on a point of clarity. DefaultMask is returning the mask associates
with the network class. RFC1918 specifies a bunch of class A,B and C
networks for private use. E.g. 192.168/16 is a set of 256 class C networks.
The correct netmask for one of those class Cs is 255.255.255.0 (/24). So
the function returns the correct thing by the RFC.


On Sun, 3 Mar 2019, 15:57 John Dreystadt,  wrote:

> Looking at RFC 1918 (which defined the non-routeable address ranges), it
> says that 10.0.0.0 has a 10/8 prefix which matches what DefaultMask()
> returns as a mask. But 192.168.0.0 returns FF00 while the RFC says that
> it should have a 192.168/16 prefix () . And 17.16.0.0 returns
>  while the RFC says that it should have a 17.16/12 prefix
> (FFF0). I also don't see the use case for this function. If this is an
> IP address associated with the current machine, the code should be walking
> the net interfaces and getting the mask from the OS. If this is an IP
> address associated with some other machine, why do you need an IP mask? In
> all of my years programming on the Internet, I never needed to know the
> mask of a remote machine.
>
> On Saturday, March 2, 2019 at 6:07:22 PM UTC-5, Louki Sumirniy wrote:
>>
>> The function is really just looking up the IP prefixes of the
>> non-routeable address ranges. It has nothing to do with CIDR, it is for
>> generating a sane default mask when the user has not specified the mask.
>>
>> It most definitely should not be deprecated, as these nonrouteable
>> addresses are definitely not deprecated, and CIDR is an extension, not a
>> replacement, for IPv4 subnet specification, to give administrators more
>> flexibliity when configuring multiple address ranges in a fairly large
>> intranet.
>>
>> On Saturday, 2 March 2019 22:32:28 UTC+1, John Dreystadt wrote:
>>>
>>> I am new to Go so feel free to point out if I am breaking protocol but I
>>> ran into the function DefaultMask() in the net package and did some
>>> research. This function returns the IPMask by assuming that you are using
>>> IP class A, B, and C addresses. But this concept is from the early days of
>>> the Internet, and was superseded by CIDR in 1993. See
>>> https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing for the
>>> history here. I looked around both this group and on Stack Overflow to see
>>> what people had posted about this function. The only reference in
>>> golang-nuts was to someone using this call to decide if an address was IPv4
>>> or not. As the last posting on that thread pointed out, you can use To4()
>>> for the same purpose (since DefaultMask actually calls To4). The only
>>> reference on Stack Overflow was someone using it to get the "Next IP
>>> address". Sorry but I don't understand what he was doing. If you want the
>>> IPMask for 127.0.0.1, you can just get that interface and get the mask that
>>> way. I even tried Google for "golang DefaultMask" and only found hits about
>>> non network things. So I don't believe that this function is useful today
>>> and should be deprecated, maybe with a message about using To4() if you
>>> just want to see if an address is IPv4.
>>>
>> --
> 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] non-local return?

[Tristan Colgate]

I've never seen a coding guide advocate for setjmp/longjump . And having
worked a bit in scheme with first class continuations, they have their
beauty, but if you want to understand your code a year after you wrote it,
I wouldn't personally recommend it.
I don't miss either of these things in Go . In fact, I feel a sense of
relief that they aren't.

On Fri, 8 Mar 2019, 15:56 Robert Engels,  wrote:

> I did. No good use for them. People that use them probably also think
> exceptions for flow control is a good idea.
>
> > On Mar 8, 2019, at 8:24 AM, Ian Lance Taylor  wrote:
> >
> > On Fri, Mar 8, 2019 at 5:02 AM whitehexagon via golang-nuts
> >  wrote:
> >>
> >> I'm really liking in Go that I can easily pass bits of code around,
> 'closures'?  Apologies if I have terminology wrong, since I'm new here.
> >>
> >> For a typical asynchronous bit of code I like to pass in a 'func' for
> what to do with the result, and also a 'func' to handle any errors.
> >>
> >> I'm struggling to find a clean way to achieve a 'non-local return' i.e.
> return from these closures and return the enclosing function too.
> >>
> >> https://play.golang.org/p/_ANPXKRzibq
> >>
> >> I had a look at the plan9 assembly stuff, and starting to suspect that
> it's probably not possible?
> >>
> >> So I'm wondering how readable my attempt is.  In Objective-C I would
> use named parameters here of 'thenDo' and 'elseDo' to help the
> readability.  And I'm reluctant to try and duplicate that approach using a
> struct in Go.  But I suppose it's the dangling return that I least like...
> >
> > You are correct: Go does not support this.
> >
> > How would a non-local return work from a recursive function closure,
> > or a set of mutually recursive function closures?  In the general case
> > it seems equivalent to an exception with a default handler.  Which of
> > course you can do in Go using panic and recover, although you have to
> > write it yourself.
> >
> > 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.

Re: [go-nuts] Package Stutter

[Tristan Colgate]

Whilst not exaclty the peek of modern tooling, grep is one method of
checking where and how your package is used. That's a lot clearer without
dot imports.
  I've never used a dot import, and don't think I have seen one in the
wild. Allowing dot imports feels like a bit of a wart (but one that is
easily, and widely, avoided).
  FWIW, I definitely did not feel that was on day 1 of my Go journey. All
those package names looked annoying. I can't say when it stopped being
annoying, but it didn't take long at all.

On Mon, 3 Dec 2018 at 16:23 Bakul Shah  wrote:

>
>
> > On Dec 3, 2018, at 8:08 AM, Robert Engels  wrote:
> >
> > I understand that, and when working in code that uses both types, which
> is probably limited, you fully qualify. This is pretty standard stuff in
> the enterprise world, as well architected solutions are segmented, so you
> only encounter this problem at the integration points, and that code is
> qualified.
>
> If you import another package where you are already using a dot import,
> you are already using Employee. You then decide to change the new import
> to dot import, at which point you discover the name clash. Now you have
> to qualify all existing Employee references with the first package. So
> a new import forces you to edit code that may have nothing to do with the
> new import.
>
> If you don't do this, you will have Employee references (to the first pkg)
> that are not qualified and some qualified ones. This will confuse things
> because someone (or you, a few months later) will then go looking for
> the Employee defn in your own package and not find it.
>
> It can all be made to work but why complicate things when a simple rule
> suffices?
>
> >
> > You have a similar problem if both applications have a model package.
> Now you need to override the import on one of them. No difference IMO.
> >
> >> On Dec 3, 2018, at 10:03 AM, Bakul Shah  wrote:
> >>
> >>> On Dec 3, 2018, at 6:52 AM, Robert Engels 
> wrote:
> >>>
> >>> I think people are misunderstanding my equal footing need. I don’t
> mean for all applications, I mean for a application.
> >>>
> >>> Here’s another example. You have a enterprise payroll application. You
> have a model package. You have model.Employee. Having to use model.Employee
> throughout the application is noise. Everyone working on the application
> knows that Employee means model.Employee. It is part of the language (dsl
> in a way) for that application.
> >>
> >> Now suppose you have to write a application that
> >> has to access payroll as well as employee performance
> >> review, health insurance, expense reporting, connect
> >> to 3rd parties for special discounts for various things,
> >> etc. Each of these subsystems may have their own
> >> definition of Employee (which may be stored in their
> >> own databases). This list may grow over time and you
> >> don't want to have to recompile and retest *existing*
> >> packages by changing some central Employee type.
> >
>
> --
> 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] Package Stutter

[Tristan Colgate]

In the cases of time and context, the stutters appear in a primary type
that is important to the package, but rarely appears directly in normal API
usage.
  E.g., time.Now(), context.Background().
  Stutter is to be avoided. The package name can provide context. But
stutter is preferred to, e.g. time.Type, where one package largely operates
on one type
  I doubt there would be a peer reviewed paper on something which is
basically just an opinion held by the language's earliest practitioners. It
doesn't mean the idea does not have merit though.

On Sat, 1 Dec 2018, 14:19 Robert Engels,  wrote:

> In another thread, it has been brought up that things like time.Time are
> no good. But this format is pervasive. Even newer packages like
> context.Context.
>
> It seems to have been this way for a long time.
>
> It there some reasoned paper on why this is now so frowned upon?
>
> --
> 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] How to get request url scheme?

[Tristan Colgate]

On the server side you don't know the scheme used. It isn't part of the
request as such. It has to be determined based on the properties of the
port that got the request (if you are listening with TLS on a port, the
request you got is definitely some flavour of https).
  If you have a reverse proxy, or load balancer in front of your app it
maybe get passed the scheme in a header (x-forwarded-proto IIRC)

On Sun, 25 Nov 2018, 08:13 robert engels,  wrote:

> Technically, the Scheme is optional, but if your url has it, it should be
> parsed into that field.
>
>
> On Nov 25, 2018, at 1:19 AM, Anik Hasibul  wrote:
>
> Thank you so much. I thought I did something wrong. But Now I am pretty
> sure that it's a bug.
>
> Issue opened on GitHub!
>
> Here it is: https://github.com/golang/go/issues/28940
>
> Hasibul Hasan (Anik)
>
> Mobile: +8801902566424
> Email  : anikhasi...@outlook.com
> Github: @AnikHasibul
> Medium: @AnikHasibul
>
> --
> *From:* Robert Engels 
> *Sent:* Sunday, November 25, 2018 10:20:46 AM
> *To:* Anik Hasibul
> *Cc:* golang-nuts
> *Subject:* Re: [go-nuts] How to get request url scheme?
>
> That should be it... file a bug
>
> > On Nov 24, 2018, at 9:21 PM, Anik Hasibul  wrote:
> >
> > Hi there!
> > I am working on a web application. And I need to get the scheme of the
> request url.
> > I tried `req.URL.Scheme` it returned empty string.
> > But my expectation was `http` or `https`
> >
> > Any idea to get that?
> >
> > --
> > 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.

Re: [go-nuts] [RFC] Dynamically instrumentation Go binaries

[Tristan Colgate]

Maybe you mean something like support for linux uprobes?
There is some discussion here:
https://github.com/golang/go/issues/22008
Google for "golang uprobes" picks up a couple of other links:
http://www.brendangregg.com/blog/2017-01-31/golang-bcc-bpf-function-tracing.html
https://kinvolk.io/blog/2017/09/an-update-on-gobpf---elf-loading-uprobes-more-program-types/



On Thu, 15 Nov 2018 at 19:22 robert engels  wrote:

> Pike’s “coverage" uses source code rewriting and recompiling, so it is not
> dynamic instrumentation - at least how I would define it. Dynamic
> instrumentation to me means to instrument at runtime on an existing
> binary/distribution.
>
>
> On Nov 15, 2018, at 12:55 PM, Michael Jones 
> wrote:
>
> You could study Rob Pike’s coverage/profiling tool to see how he adds and
> exploits basic block counting.  Good work as always.
>
> On Thu, Nov 15, 2018 at 9:34 AM Robert Engels 
> wrote:
>
>> AFAIK dtrace support is compiled in. If not enabled there are some tricks
>> to make is essentially zero cost, but it is still there from the start.
>> Could be wrong but that’s my understanding.
>>
>> Sent from my iPhone
>>
>> On Nov 15, 2018, at 11:27 AM, Steven Hartland 
>> wrote:
>>
>> dtrace support?
>>
>> On 15/11/2018 16:51, ju...@sqreen.io wrote:
>>
>> Hi,
>>
>> I am working on dynamic instrumentation of Go programs at run time,
>> possibly without static source-code instrumentation. As I would like a
>> solution as close to Go and standard as possible, I was first thinking of
>> using `go generate` to generate a file adding things `reflect` doesn't
>> provide such as the list of packages, functions, global variables... That
>> way, I should be able to use `reflect` to modify any dynamic calls by
>> modifying the method tables of their underlying type representations.
>>
>> But regarding statically linked calls, the less intrusive technique I
>> found are uprobes, which is linux-specific. And at the opposite, there are
>> user-space binary code instrumentation libraries such as dyninst that
>> modify the code at run time...
>>
>> So I am wondering if anyone here has any thoughts on this subject, that
>> doesn't seem to be solved for Go programs.
>>
>> Thanks!
>>
>> Julio
>> --
>> 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.
>>
> --
>
> *Michael T. jonesmichael.jo...@gmail.com *
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> 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: Proposed changes to the Go draft generics design in the light of feedback received

[Tristan Colgate]

It is not at all obvious that you have sufficient experience of writing Go
for anyone to take your, rather disrespectful, comments seriously.
  Ian has been working on finding a workable model for generic programming
in Go for at least 5 years. To many of us, contracts look like a pragmatic
solution.
  A little humility goes a long way.

On Fri, 19 Oct 2018, 18:56 Eric Raymond,  wrote:

>
>
> On Friday, October 19, 2018 at 1:48:36 PM UTC-4, alanfo wrote:
>>
>> In the light of all the feedback there's been, I've put together a
>> proposal which sticks closely to the original design and only changes what
>> most people consider needs to be changed in some way. Some recent ideas
>> which seemed plausible but which I felt had little chance of adoption have
>> been rejected.
>>
>
> Surface changes that don't tackle the fundamental unwieldiness and
> overcomplexity of the  contracts extension.
>
> A good honest effort, Alan, but (with due respect to the people who put in
> cleverness and effort on the original overcomplication, I don't mean to
> insult them) this is lipstick on a pig.
>
> --
> 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: an unwelcome conclusion and a proposal

[Tristan Colgate]

Operator overloading seems completely antithetical to what most seem to
value in Go. Readability is key. Go mostly avoids syntactic sugar (and
where it has it, it is often acknowledged as a mistake).
  To me, the existing contracts design makes it clear when a generic is
being used. It should also make for god's error reporting when a user, or
writer, of a generic type or function does not adhere to that contract.
  People seem to be trying to reduce line count, or minimize the visual
impact of generics. Why? I want big signposts warning me when it's in use.

On Wed, 17 Oct 2018, 11:13 alanfo,  wrote:

> On Wednesday, October 17, 2018 at 12:22:15 AM UTC+1, Patrick Smith wrote:
>>
>> On Tue, Oct 16, 2018 at 3:33 AM alanfo  wrote:
>>
>>> I would also disallow overloading of the =, :=, <-, ..., [], {}, () and
>>> yes - equality operators - as well because I believe to do otherwise would
>>> be very confusing.
>>>
>>
>> If overloading [] were disallowed, how would one write a generic function
>> taking a single argument of type either []int or a user-defined type with
>> similar behavior, and returning the sum of the elements? Sort of the
>> marriage of these two functions:
>>
>> func SumIntSlice(s []int) int {
>>
>> sum := 0
>>
>> for _, i := range s {
>>
>> sum += i
>>
>> }
>> return sum
>>
>> }
>>
>> type IntList interface {
>>
>> Len() int
>>
>> At(int) int
>>
>> }
>>
>> func SumIntList(l IntList) int {
>>
>> sum := 0
>>
>> for n := 0; n < l.Len(); n++ {
>>
>> sum += l.At(n)
>>
>> }
>>
>> return sum
>>
>> }
>>
>
>  I'm wobbling a bit on disallowing the overloading of the indexation
> operator following something Eric said in response to that.
>
> However, as long as the proposal includes the ability to overload
> conversions as well as operators (another point I made earlier), the
> example you gave could be dealt with by implementing a conversion to []int
> so you could then use all the latter's properties to code a common function.
>
> 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.
>

-- 
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 treemap implemented in go

[Tristan Colgate]

In case you haven't already checked it out, you can now see your package at:

https://godoc.org/github.com/willpoint/treemap

You can do a sort of "GoDoc Driven Design" here, look at the godoc, and
decide if the interface is something you would like to use.

Some suggestions:

- A destination io.Writer is tradionally places as the first argument to a
function.
- DrawTreemap doesn't actually mention that the package writes SVG, the
function names could make it clearer.
- Along a similar line, maybe you could have a DrawToSVG that took an
*svg.SVG instead of a writer (or, better still, define an WriteSVG
interface that just includes the methods on the SVG that you use, this
would allow others to swap out the SVG implementation that was used. This
could allow an SVG to be drawn into an existing svg the user is building up
in sections.. DrawTreemap could still fall back to the default one).
- similarly, you could provide a method that draws to a pre-existing image
- in some scenarios, width/height might be inferrable, from some container
you might want to draw something in to.
- building on a richer underlying drawing abstraction might make things
more re-usable, The SVG interface thing above helps with that, you could
also look at something like https://godoc.org/github.com/llgcode/draw2d (though
that obviously introduces depedencies).

Note that none of these are "the right way", they give you options to make
the code more reusable.


On Wed, 3 Oct 2018 at 13:49 Uzondu Enudeme  wrote:

> Hi Tristan,
>
> Thanks again for your helpful feedback. Based on your observations, here's
> what I've done so far:
>
> This would be more useful as a package than a single program. You could
>> move main into an example/ folder and keep the rest of the content in the
>> top level as a package. Move the explanatory comment up as a Package
>> comment.
>
>
> I have now moved main to an example folder and left the rest as a package.
> I then defined an interface `TreeMapper` that represents any type that can
> be drawn by the treemap's DrawTreemap function.
>
> The standard library includes color handling, check the image package.
>
> I haven't yet figured this out. I'd look more carefully into the image
> package.
>
> The strconv wrapper is probably a bit excessive for the sake of the cast
>> (you might not need it if you use color.Color anyway)
>
> I removed the strconv wrapper, it really seemed excessive. I'm still yet
> to implement the use of color.
>
> The orientation might be better off as a tyoed parameter, look for docs on
>> typed constants.
>
>
> I read this article <https://blog.golang.org/constants> on the subject
> and found it really great! I have updated to code to reflect that.
>
> Any further advice would be greatly appreciated. The link still remains
> https://github.com/willpoint/treemap
>
> Thanks,
>
> Uzondu
>
> On Wed, Oct 3, 2018, 09:13 Uzondu Enudeme  wrote:
>
>> Thanks a lot Tristan,
>>
>> The points you mentioned are really all very important ones.
>>
>> I'm currently following all your suggestions and would repost the link to
>> the updated code in case I missed some points.
>>
>>
>> On Wed, Oct 3, 2018, 06:52 Tristan Colgate  wrote:
>>
>>> A couple of quick observations.
>>>
>>> This would be more useful as a package than a single program. You could
>>> move main into an example/ folder and keep the rest of the content in the
>>> top level as a package. Move the explanatory comment up as a Package
>>> comment.
>>>
>>> The standard library includes color handling, check the image package.
>>>
>>> The strconv wrapper is probably a bit excessive for the sake of the cast
>>> (you might not need it if you use color.Color anyway)
>>>
>>> The orientation might be better off as a tyoed parameter, look for docs
>>> on typed constants.
>>>
>>>
>>>
>>>
>>>
>>> On Tue, 2 Oct 2018, 23:06 Uzondu Enudeme,  wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> I've been following the golang-nuts' email threads for a while now and
>>>> I'm amazed at how much I've learnt seeing ways solutions are profferred.
>>>>
>>>> I implemented a treemap for data visualization, and wrote a process.md
>>>> file giving some sort of background and detail.
>>>>
>>>> I want to use this opportunity to learn what I could have done better
>>>> by asking that the code be reviewed, it's in a single main.go file at
>>>> github.com/willpoint/treemap
>>>>
>>>> Thanks in advance for the time that

Re: [go-nuts] A treemap implemented in go

[Tristan Colgate]

A couple of quick observations.

This would be more useful as a package than a single program. You could
move main into an example/ folder and keep the rest of the content in the
top level as a package. Move the explanatory comment up as a Package
comment.

The standard library includes color handling, check the image package.

The strconv wrapper is probably a bit excessive for the sake of the cast
(you might not need it if you use color.Color anyway)

The orientation might be better off as a tyoed parameter, look for docs on
typed constants.





On Tue, 2 Oct 2018, 23:06 Uzondu Enudeme,  wrote:

> Hi everyone,
>
> I've been following the golang-nuts' email threads for a while now and I'm
> amazed at how much I've learnt seeing ways solutions are profferred.
>
> I implemented a treemap for data visualization, and wrote a process.md
> file giving some sort of background and detail.
>
> I want to use this opportunity to learn what I could have done better by
> asking that the code be reviewed, it's in a single main.go file at
> github.com/willpoint/treemap
>
> Thanks in advance for the time that would be spent and any advice given.
>
>
> Uzondu
>
>
> --
> 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] ticker for poisson processes?

[Tristan Colgate]

Both use the runtime timers underneath. Ticker requires an extra channel
send.

Tracking this down was interesting!

On Thu, 27 Sep 2018, 14:56 David Wahlstedt, 
wrote:

> I mean that an ordinary go thread executing a sleep instruction may risk
> to be starved by the scheduler, so the real sleeping time is likely to be
> longer. But with the ticker, a incoming message in the channel waking up a
> routine that waits for it, things may behave differently?
>
> /David
>
>
> Den onsdag 26 september 2018 kl. 17:33:29 UTC+2 skrev Sebastien Binet:
>>
>>
>>
>> On Wed, Sep 26, 2018 at 2:29 PM David Wahlstedt 
>> wrote:
>>
>>> Thanks--nice!
>>> Will this be less reliable than the built-in Ticker (that uses
>>> runtimeTimer), besides the intentional randomness?
>>>
>>
>> modulo the possible bug(s) I may have unintentionally introduced, I think
>> it should be as reliable.
>> (perhaps a bit less efficient than runtimeTimer, I haven't had the
>> intellectual curiosity to look at what runtimeTimer does.)
>>
>> -s
>>
>>
>>>
>>> /David
>>>
>>> Den tisdag 25 september 2018 kl. 18:43:33 UTC+2 skrev Sebastien Binet:



 On Tue, Sep 25, 2018 at 11:34 AM David Wahlstedt <
 david.wah...@gmail.com> wrote:

> Hi,
> What would be a nice way to implement a ticker that generates events
> according to a Poisson process?
> The built-in Ticker in ticker.go uses a runtimeTimer that has a field
> called period.
> I would like to implement a "random ticker" such that each tick
> interval is random, using ExpFloat64() * d, with average duration d,
> instead of a fixed interval.
> I could have a go routine that sleeps a random amount of time in a
> loop, but it would be nice to use something similar to the ticker.
>

 just for fun:  https://play.golang.org/p/kt0qVQ41E1C
 (yes, it uses a goroutine that sleeps a random amount of time in a
 loop.)

 -s

>>> --
>>> 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 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] why does go reverse the order of name and type? "i int" vs "int i"

[Tristan Colgate]

But every aspect of that still reads unambiguously in a left to right
order. Actually understanding C declarations can be extremely challenging.

On Thu, 20 Sep 2018, 06:47 Sathish VJ,  wrote:

> So, you are saying it is only for readability?
>
> But even in go we can write convoluted functions like:
> func f(func(*int, *string) *int, []*byte) (func(*int, *float32), error)
>
>
> On Thursday, 20 September 2018 11:09:23 UTC+5:30, kortschak wrote:
>>
>> To avoid having to have something like this:
>>
>> http://c-faq.com/decl/spiral.anderson.html
>>
>> On Wed, 2018-09-19 at 22:30 -0700, Sathish VJ wrote:
>> > I've been asked this question a few times and I haven't been able to
>> > find
>> > an answer.  Why does go reverse the order of variable
>> > declaration:  "i int"
>> > vs "int i"
>> >
>> > Is there anything in the language design that requires this or was it
>> > based
>> > on readability/writability or related to the parsing process or
>> > something
>> > else?
>> >
>>
> --
> 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: Scrapping contracts (was: "Generics as bultin typeclasses")

[Tristan Colgate]

(I'm acutely aware that there's a limit to how useful endless back and
forth on this stuff is, and I definitely have to yield on the technical
details here, I'll leave the grown up to discuss after this I promise)

On Tue, 11 Sep 2018 at 14:26 Axel Wagner 
wrote:

> There is no accounting for taste, of course, but I wildly disagree. In
> particular, the constraint solver and type-checker for what I described is
> trivial to write and understand, including good error messages. AIUI it is
> currently not clear whether the contract design can actually be
> type-checked in practice (and, personally, I am predicting the things I and
> others are bringing up to be exactly the things that will come up as
> difficultlies).
>

I guess if I were going to critique this I would say that optimising for
ease of compiler implementation may not be the best thing. *If* the
existing design can be made to work (and that's clearly a big "if"), then I
think I would still find it preferable, as you say, no accounting for taste.

Having a package of pre-defined contracts, and a tool and that can produce,
and reduce contracts, if possible, would simplify things.

To be completely honest, I think I'd be happy with your design if it just
stopped before "Getting rid o boilerplate", I'd rather just live with the
boilerplate than introduce the taxonomy that comes after. Also, personally,
I'd rather leave interfaces alone and have the typed interfaces be a
separate thing, but I don't understand this well enough to know if that
really works.

func Foo(w io.Writer) { fmt.Fprintln(w, "Hello world") }
> func main() { Foo(os.Stdout) }
>
> The compiler could decide to devirtualize the interface, to generate a
> boxed version or to do a hybrid approach (e.g. compile a boxed version and
> devirtualize for certain types based on usage). Exactly like with the
> contract designs.
>

It could, but this would change how people currently understand interfaces
to work, e.g. in regard to nil-ness of interface values. This is already a
bit of  a hurdle for beginners.


> I still believe that if there's a simpler alternative (and I consider my
> design simpler, for the implementation, the author and the user of generic
> code. But I'm obviously biased) that creates higher levels of type-safety,
> while not giving up a significant amount of expressive power, then that
> should be at least considered. Because it's just as much not obvious that
> contracts provide the wrong level of type-safety, as it's obvious that they
> provide the only correct level of type-safety.
>

Things certainly look hopeful.

-- 
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: Scrapping contracts (was: "Generics as bultin typeclasses")

[Tristan Colgate]

On Tue, 11 Sep 2018, 18:12 jimmy frasche,  wrote:

> Using the interface type to constrain type parameters at compile-time
> does not necessarily imply using the interface value to implement
> generics at runtime.


No, but this does imply that we override what an interface is. They are
already one of the more awkward parts of the language for beginners (e.g.
nil interfaces vs an interface with a nil dynamic value). Overloading the
syntax will make this situation worse.

-- 
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] Scrapping contracts (was: "Generics as bultin typeclasses")

[Tristan Colgate]

I think the point is that by implementing Getter/Setter methods, which are
trivially inline-able there's no real downside to skipping fields and just
allowing method calls.
If it makes it easier to unify contracts and interfaces, I think that may
be a hit worth taking (though I still say, getters and setters are terribly
idiomatic, and have been actively discouraged in the past. This will make
them far more common, I'm not really sure that's a good thing.

On Wed, 12 Sep 2018 at 14:15 Mandolyte  wrote:

> On field accessors...
>
> - Algorithms for X,Y points requiring them to be members of a struct type.
>
> - Algorithms to manipulate colors, requiring R,G, and B to be members.
>
> In an image processing library with its own rich set of struct types, such
> accessors would prove productive.
>
> Are these the kind of examples you meant?
>
> --
> 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: Scrapping contracts (was: "Generics as bultin typeclasses")

[Tristan Colgate]

It feels like, so far, all of the attempts to simplify the original design
wind up looking more complicated for little benefit (and reduced
functionality).

Re-using interfaces seems like it would mandate boxing, (or interfaces are
no longer interfaces as currently described, which would also be a major
change).

The original generic types and functions as described would permit unboxed,
direct access to fields, without relying on inlining, which can't be
achieved with the interface approach.

Whilst contracts do introduce some ambiguities, it's not obvious that these
are of genuine practical concern. E.g., yes calls on a field function type
look like method calls, but the contract just says you should be able to
call a thing, if you care that that is a method vs a value, you probably
aren't writing a very generic function.

Ian has pointed out before, this isn't really any different from types that
coincidentally support an interfaces method set, sort.Sort will not do
anything useful if you're types doesn't implement the correct semantic
contract required. It's not obvious that contracts should attempt to be any
more accurate.


On Tue, 11 Sep 2018 at 12:40 Jonathan Amsterdam 
wrote:

> * I think constraining type-parameters to channel/slice/map types might
>> not be needed at all. Instead of, say "func Foo(type T channelOfBar) (ch
>> T)", ISTM that we can use "func Foo(ch chan Bar)". Since any channel-type
>> with element type Bar can be assigned to `chan Bar`, this would already
>> allow most of the useful patterns. As-is there is a slight reduction in
>> power over the contracts design, because `contract channelOfBar(v T) { ch
>> <- Bar{} }` also allows element types that Bar is assignable to.
>> `assignableFrom(Bar)` would enable pseudo-interfaces to do that too. But
>> IMO it would be helpful to see cases where that's needed (AFAICT none of
>> the ones mentioned in the design doc or problem overview do).
>>
>
> Some of the examples could be generalized. For instance, Copy(dest []T1,
> src []T2) where T2 is assignable to T1.
>
> How about merging channels c1 and c2 into c3? You could write this as
>
>func Merge(type T)(c1, c2, c3 chan T)
>
> but  the more general version is
>
>func Merge(type T1, T2, T3)(c1 chan T1, c2 chan T2, c3 chan T3)
>
> where you can assign T1 and T2 to T3.
>
> --
> 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] SQL Interceptor

[Tristan Colgate]

It's worth considering that gRPC interceptors are not passive participants
in gRPC requests. They can actively modify the requests, and responses
(e.g. to enforce authentication). It's not obvious what that would look
like for SQL, or if that is even desirable.
  There is a pre-existing db/sql issue to discuss tracing (which would also
facilitate metrics collection):
https://github.com/golang/go/issues/18080


On Mon, 10 Sep 2018 at 09:22 Conrad Wood  wrote:

> On Mon, 2018-09-10 at 09:05 +0100, Tristan Colgate wrote:
> > There are two existing projects used to achieve similar goals:
> >
> > https://github.com/ExpansiveWorlds/instrumentedsql
> > https://github.com/gchaincl/sqlhooks
> >
> > native support could probably improve things a little, but this is a
> > very reasonable approach.
>
> tldr; It's definitely a valid approach - I still think it is benefitial
> to include in sql core package.
>
> In my view, there are two benefits to adding it to the main sql package
> compared to wrapping a driver:
>
> 1) It makes it very simple, and thus encourages, the monitoring of sql
> queries, which I think is a good addition to the core golang libraries.
>
> 2) The interceptor can be added/removed at runtime. Of course, this
> could also be done with a driver-wrapper, but not quite as elegantly
> and IMHO with more potential to subtle race-conditions.
>
> 3) gRPC already has such mechanism (which is very useful) and being in-
> line and consistent with another package, namely gRPC, makes life
> easier for golang developers.(SQL Queries to a database are in my view
> similar to RPC calls, since both call external systems),
>
> 4) we can encourage 3rd parties to add interceptors to their products.
> For example: I like to see a hook to expose metrics to prometheus.
> currently the default client exposes useful golang core metrics (e.g.
> "go_gc_duration_seconds"). Adding it to core language (and applying the
> compatibility guarantees) is likely to increase uptake and we all
> benefit. Thus I could submit a patch to prometheus and say "look, this
> exposes more core metrics"  ;)
>
>
>
>
>

-- 
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] SQL Interceptor

[Tristan Colgate]

There are two existing projects used to achieve similar goals:

https://github.com/ExpansiveWorlds/instrumentedsql
https://github.com/gchaincl/sqlhooks

native support could probably improve things a little, but this is a very
reasonable approach.

On Mon, 10 Sep 2018 at 08:59 Conrad Wood  wrote:

> On Mon, 2018-09-10 at 09:44 +0200, Jan Mercl wrote:
> >
> > On Mon, Sep 10, 2018 at 8:16 AM Conrad Wood 
> > wrote:
> >
> > > Wdyt? Is that a patch that would be acceptable and generally
> > useful?
> >
> > It could be tried and evaluated first as an external package.
> >
> > --
> > -j
>
> Not sure I understand. The patch would have to be to sql.DB, wouldn't
> it?
>
> I currently open the DB Connection like so:
>
> db, err = sql.Open("postgres", dbinfo)
>
> (db is *sql.DB)
>
> This is current definition of:
>
> func Open(driverName, dataSourceName string) (*DB, error)
>
> There's no way atm to pass in an interceptor.
>
> I am thinking of adding to sql.go:
>
> 1) type SQLInterceptor func(QueryResult)
>
> 2) to "type DB struct": interceptor SQLInterceptor
>
> 3) func (d *DB) SetInterceptor(SQLInterceptor)
>
> 4) modify the query/exec functions to call the interceptor, if it is
> set and if so, call it after the query returns. If no interceptor is
> set, it'll continue as currenty.
>
> How would I test it with an external package? Do you mean copying the
> sql package, modifying that and running that instead?
>
>
>
>
> --
> 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

[Tristan Colgate]

You lose the ability to see changes of contract in your diff (which I think
is the thing I most want).


On Fri, 7 Sep 2018 at 15:56 Robert Johnstone 
wrote:

> Hello,
>
> This seems more like a question for tooling.  It has already been
> discussed that there should be a tool to read a body and provide a
> minimised or canonical contract.  Perhaps we forgo writing the contract in
> code, and rely on godoc to determine the contract for the documentation?
>
> The contracts will be useful if they are used to constrain the
> implementation.
>
> - Robert
>
>
> On Thursday, 6 September 2018 18:18:13 UTC-4, soapboxcicero wrote:
>
>> 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...@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.

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
>>> <https://golang.org/ref/spec#Method_values>, 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 {
>>>> ze

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.

Re: [go-nuts] A thought on contracts

[Tristan Colgate]

One thing that has been occurring to me on this is that it is probably
reasonably practical to have a tool infer and update the contracts. The
tool could limit itself to a restricted set of statements, without the spec
needing to actually limit them directly.

On Wed, 5 Sep 2018 at 09:17 thwd  wrote:

> If you can't use operations not explicitly stated in a contract: the more
> reason to copy-paste a function body into a contract.
>
> What I mean by implicit constraints is what the draft calls "implied
> constraints".
>
> --
> 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

[Tristan Colgate]

Without though, people maybe encouraged to create getters and setters,which
is very un-Go.
  Contracts can match a method explicitly if needed.


On Tue, 4 Sep 2018, 17:49 roger peppe,  wrote:

> On 4 September 2018 at 17:30, Tristan Colgate  wrote:
> > This would disallow contracts on presence and type of fields right?
> >   The existing design permits them, and disallowing them feels a little
> > arbitrary.
>
> It would, yes. But on balance, I think that the presence of selectors
> in contracts makes for them harder to understand. For example, the
> rather arbitrary rules about value methods go away if you don't allow
> selectors. The ambiguity between a field selector and a method
> selector goes away too. 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.
>
> The selector operation does so much work in Go that it's hard to
> classify it as a single operation, and I think that disallowing it
> lets values focus more on behaviour and less on appearance, as
> interfaces do.
>
> >
> > On Tue, 4 Sep 2018, 17:17 roger peppe,  wrote:
> >>
> >> On 4 September 2018 at 15:41, thwd  wrote:
> >> > From the draft proposal I gather two open questions:
> >> >  - How free or restricted should contract bodies be?
> >> >  - How many implicit constraints can be inferred from usage?
> >> >
> >> > 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.
> >> >
> >> > If only restricted syntax is allowed in contract bodies and a lot of
> >> > implicit constraints are gathered:
> >> > people will write empty contracts and hope for the compiler to pick up
> >> > on
> >> > all the constraints.
> >> >
> >> > These two questions are related.
> >>
> >> 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".
> >>
> >> 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.
> >>
> >>   cheers,
> >> rog.
> >>
> >> --
> >> 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

[Tristan Colgate]

This would disallow contracts on presence and type of fields right?
  The existing design permits them, and disallowing them feels a little
arbitrary.

On Tue, 4 Sep 2018, 17:17 roger peppe,  wrote:

> On 4 September 2018 at 15:41, thwd  wrote:
> > From the draft proposal I gather two open questions:
> >  - How free or restricted should contract bodies be?
> >  - How many implicit constraints can be inferred from usage?
> >
> > 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.
> >
> > If only restricted syntax is allowed in contract bodies and a lot of
> > implicit constraints are gathered:
> > people will write empty contracts and hope for the compiler to pick up on
> > all the constraints.
> >
> > These two questions are related.
>
> 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".
>
> 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.
>
>   cheers,
> rog.
>
> --
> 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] Link: Getting specific about generics

[Tristan Colgate]

It's a great read, clarified stuff for me. An approach that embraces
interfaces feels preferable to me.


On Sun, 2 Sep 2018, 09:09 'Charlton Trezevant' via golang-nuts, <
golang-nuts@googlegroups.com> wrote:

> Link: [Getting specific about generics, by Emily Maier](
> https://emilymaier.net/words/getting-specific-about-generics/)
>
> The interface-based alternative to contracts seems like such a natural
> fit- It’s simple, straightforward, and pragmatic. I value those aspects of
> Go’s philosophy and consider them to be features of the language, so it’s
> encouraging to see a solution that suits them so well. The author also does
> a great job of contextualizing the use cases and debate around generics,
> which I found incredibly helpful.
>
> Any thoughts?
>
> --
> 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] Alternate syntax for Go2 generics and contracts

[Tristan Colgate]

Just read:

https://emilymaier.net/words/getting-specific-about-generics/

I think I concur, keep specification of behaviour in interfaces if possible.

Contracts overlap too much. If interfaces can do the job, all be it less
elegantly, the extra verbosity seems worth it to avoid the feature overlap.

What I'm mostly worried about is a future where new comers have to learn
two overlapping features. Inevitably people won't stop using interfaces.

Contracts are too expensive, cognitively, if they aren't going to become
pervasive, but that seems to throw out interfaces (even if they can be made
to cooperate).


On Sat, 1 Sep 2018, 21:55 roger peppe,  wrote:

> FWIW I've published some ideas about how contracts and interface types
> could be partially unified, and contracts significantly simplified,
> which I think is quite pertinent to the above discussion.
>
> Doc here:
>
> https://gist.github.com/rogpeppe/45f5a7578507989ec4ba5ac639ae2c69
>
>
>
> On 1 September 2018 at 20:15, Scott Cotton  wrote:
> >
> >
> > On Saturday, 1 September 2018 20:29:31 UTC+2, Axel Wagner wrote:
> >>
> >> I don't understand what you are trying to say. You assert that there
> >> wouldn't be a type-error, but you don't actually justify that.
> >
> >
> > There are 2 examples,  both are (to me) intuitive suggestions and not the
> > result of a phd thesis worth of research :)  continued below.
> >
> >
> >
> >> It seems pretty obvious to me, that if you instantiate my MultiReader
> >> example to, say, *strings.Reader, it would fail to compile. Because
> >> *multiReader is not a *strings.Reader (and you'd have to replace R with
> >> *strings.Reader everywhere in the signature, that is the exact reason we
> >> want generics to begin with).
> >
> >
> > That's why I didn't use R for another, distinct Reader.  For the
> signature
> > of your MultiReader example I changed the return type from "R" (the type
> > argument) to "Reader" (the name of the contract).  In a hand-wavy formal
> > way, the return type would serve as a new type argument to Reader,
> > independent of R.  Put in an intuitive (to me) way: Since MultiReader
> > returns something which presumably conforms to the contract Reader, why
> not
> > just say that instead of the type argument R?
> >
> >
> >>
> >> The example you give for "unifying this" isn't actually syntactically
> >> correct, AFAICT. At least I can't find anything in the design that would
> >> allow using the identifier of the contract in its arguments - and it's
> >> unclear to me what that would mean.
> >
> >
> > Apologies, I'm responding to the proposal, just giving my 2 cents.  I am
> not
> > asserting that the examples I give are syntactically correct according to
> > the proposal.  I am suggesting that the concepts of "contract" and
> > "interface",  can (probably) be defined for Go
> > in a unified way.  I am not  supposing the definitions in the proposal of
> > "interface" and "contract" in suggesting this; to the contrary I am
> > suggesting these concepts are what Go would define them to be and hence
> are
> > flexible and not yet fixed.  I do not think saying interfaces and
> contracts
> > are different because the proposal or other background such as Haskell or
> > type theory treat them differently is a convincing counterargument to my
> > suggestion of exploring the unification of contract and interface.
> >
> >>
> >>
> >> To provide another way to clarify that interfaces and contracts are
> >> different:
> >
> >
> > This again assumes a priori interfaces and contracts are different.  I am
> > trying to suggest to drop this assumption and see what happens.  To me,
> it
> > seems, so far, good things would happen.
> >
> >>
> >> * How would you build fmt.Println using contracts?
> >>
> >> * One of the main motivators behind adding generics is the lack of
> >> type-safety for containers (say, container/list). While all methods
> mention
> >> the same type, interface{}, it is not checked for consistency between
> >> invocations. This is a bug for type-safe containers, but it's a feature
> for
> >> fmt.Println.
> >
> >
> > So perhaps containers could use a contract which does not instantiate
> each
> > type argument distinctly, forcing uniformity of types and
> > more or less like in the proposal.  And perhaps situations desiring
> > heterogenous types, such as fmt,*f(), could use a different kind of
> > contract which instantiates each type argument independently at the call
> > site.  To distinguish them, some syntax could be proposed such as
> >
> > contract Reader(r Reader.(*)) { ... }
> > vs
> > contract Reader(r Reader) {...}
> >
> > I am far from the genius who is capable of thinking this idea through and
> > making it as solid as the proposal overnight.  Just expressing the
> opinion
> > that unifying the concepts of contract and interface seems to me like a
> good
> > idea to explore, and that a priori assuming they are different doesn't
> help
> > advance exploring it.
> >
> > Scott
> >
> >
> >
> 

Re: [go-nuts] Alternate syntax for Go2 generics and contracts

[Tristan Colgate]

Also, and I think this probably applies to the existing syntax in the
design.
This example seems like a pathological use of generics. What would be the
advantage over  just declaring the function takes a Stringer? Am I missing
something (presumably this is potentially avoids the interface call
allocation?).
This is a good example of my gut feeling about generics, I realise they'll
be valuable, but do they devalue interfaces? They do not seem like an
orthogonal feature. Of the two, interfaces feel like they encourage me to
write better structured code.
This could also just be fear of change.


On Fri, 31 Aug 2018 at 14:34 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> A contract can include multiple type parameters:
> https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md#mutually-referential-type-parameters
> AIUI your syntax can't cover that. And FWIW, I find the syntax of
> contracts in the doc far less "magic" than yours, but YMMV of course.
>
> On Fri, Aug 31, 2018 at 6:43 AM Manlio Perillo 
> wrote:
>
>> I just read the "official" proposal for Go2 generics and contracts.
>> The current proposal makes the function syntax more complex, and the
>> syntax for the contract is a bit magic.
>>
>> What about something like:
>>
>>
>> type stringer template
>>
>> contract (x stringer) {
>> var s string = x.String()
>> }
>>
>> func Stringify(s []stringer) (ret []string) {
>>  for _, v := range s {
>> ret = append(ret, v.String())
>> }
>> return ret
>> }
>>
>> instead of
>>
>>
>> contract stringer(x T) {
>> var s string = x.String()
>> }
>>
>> func Stringify(type T stringer)(s []T) (ret []string) {
>>  for _, v := range s {
>> ret = append(ret, v.String())
>> }
>> return ret
>> }
>>
>>
>> Thanks
>> Manlio
>>
>> --
>> 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.

Re: [go-nuts] Re: Generics and readability

[Tristan Colgate]

It would be great to hear from those that have written extensive code
generation tools as to what changes, if any, Go2 could bring to make code
generation easier.
  Code generation feels more idiomatic to Go. I'm tempted by some kind of
package level generics, but I'm terrified that the standard library might
end up using them. If I don't like the idea of debugging other people's
generics code, i probably shouldn't expect other people's to use mine.
  I've used syntax-case in scheme, and c++ templates, a reasonable amount.
They can lead to concise code, but in both cases I've hated the experience
when things go wrong. Operator overloading has a similar effect. Makes code
look pretty as you write it, but hard to navigate when your dropped back in
it after 6 months.
  Conversely most of my code generation experience has been pleasant.
  Maybe we need a dep-like project for generics generation. That could
uncover some features that could be useful.
  The only thing that occurs to me is something akin to C/CPP file and line
pragmas for changing the location for errors reported by the compiler maybe?


On Sun, 27 Aug 2017, 16:21 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> While having generics as part of the language and doing the code-gen in
> the compiler has definite advantages (ease of use and potentially better
> optimization of the generated code), doing it as a separate tool *also*
> has advantages. For example, this way no one is bound to whatever notion of
> generics will eventually be built into the language. Because it *will*
> have limitations and provide a trade-off. With separate tooling outside the
> language, people can make their own tradeoff.
>
> For example, yes, you can do template-like code generation at compile
> time. But you could also box values in interface{} and have a tool that
> verifies your desired notion of type-saftey statically. It's up to you -
> whatever makes more sense for your use case.
>
> Honestly, right now I'd prefer good and easy to use meta-programming tools
> for go. If I can write my own type-checks or code-gen to be run on a go
> build, it enables far more powerful tools than generics alone… (yes, it
> also has drawbacks. I'm aware).
>
> On Sun, Aug 27, 2017 at 5:08 PM,  wrote:
>
>> > That's how C++ started.
>>
>> And that's also why C++ is the ugly monster than it is today; with a
>> design that wasn't quite thought thoroughly. Talking about C++ like it's an
>> example to follow is just preposterous.
>>
>> Le dimanche 27 août 2017 16:25:54 UTC+2, Jan Mercl a écrit :
>>>
>>> And there's nothing wrong in it. That's how C++ started. Codegen allows
>>> for easier protoyping throwaway experiments. Writing a full blown compiler
>>> and realizing afterwards a better language/feature design costs probably
>>> much more work.
>>>
>>> On Sun, Aug 27, 2017, 15:55  wrote:
>>>
 > Codegen can do 100% of what any compiler can do.

 Yes and it is called doing the compiler's job in place of 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...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>> --
>>>
>>> -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.
>>
>
> --
> 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: Generics are overrated.

[Tristan Colgate]

On Mon, 31 Jul 2017, 18:21 roger peppe,  wrote:

>
> > import hpaInformer informer
> >
> > myInformer := hpaInformer.New(sharedUnderlyingCacheThing)
>
> So... to me, the implementation of NewHorizontalPodAutoscalerInformer looks
> pretty much exactly like what you've got there, where
> sharedUnderlyingCacheThing
> is the result of cache.NewSharedIndexInformer as called currently in the
> code. That is, that constructor inside the call to NewSharedIndexInformer
> seems a lot like a constructor for sharedUnderlyingCacheThing to me.
> I'm not entirely convinced that generics would make the code much
> cleaner in this case.
>

The duplication I'm thinking about is more the multiple packages, one for
each type being informed on. If the top level informers package, or
function, were templatable by the type being informed on, there would be no
need for the per-type packages. As it stands there is little benefit from
the godocs for each individual informer. The current docs are verbose well
beyond the value they add.


>
> You might want to experiment by refactoring some of that k8s code to use
> generics (using whatever your preferred formulation might be) and see
> what it might look like, and whether it looks significantly
> nicer/simpler/cleaner
> as a result
>

I might look at something for the informers case, but it's worth pointing
out that I was thinking generics could provide a difference API, rather
than a cleaner implementation of the existing one.


> I suspect that it might not look that much different - whether you're using
> type-parametric polymorphism or interfaces, somehow you've got to
> plug the specific code into the generic code, and that existing k8s code
> doesn't look like it has that much redundant boilerplate to it.
>
>   cheers,
> rog.
>
>

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

[Tristan Colgate]

Re-posting to the list.

On Mon, 31 Jul 2017, 14:15 roger peppe, <rogpe...@gmail.com> wrote:

> On 30 July 2017 at 08:22, Tristan Colgate <tcolg...@gmail.com> wrote:
>
>>
>>
>> On Sat, 29 Jul 2017, 23:59 Shawn Milochik, <shawn.m...@gmail.com> wrote:
>>
>>>
>>>- You don't need generics to write Kubernetes.
>>>
>>> I've had no personal need for generics, but k8s client-go is the one
>> case I've seen where I thought they would help, the informers packages in
>> particular.
>>
>> https://godoc.org/k8s.io/client-go
>>
>
> It's always nice to have experience reports of real world cases, so
> could you expand on this, please? What specific code are you referring to
> here,
> and how would it be improved if Go had generics?
>


I should start by saying that I'm not a contributor to client-go, just a
user,
so can't speak for their actual experience of developing that package.
As I understand it, much of client-go is generated by tools already, so
they have
the particular problem solved, and may well be far happier with what they
have than
a generics solution.

The particular package that triggered the "generics" sensation is
http://godoc.org/k8s.io/client-go/informers and
http://godoc.org/k8s.io/client-go/listers.
These generate code for efficiently watchig and listing resources on kube
cluster using
a nice cacheing mechanism.

All of the individual type specific informers packages have a

func New(f internalinterfaces.SharedInformerFactory) Interface

Interface here is a type in the package such as

type Interface interface {
// HorizontalPodAutoscalers returns a HorizontalPodAutoscalerInformer.
HorizontalPodAutoscalers() HorizontalPodAutoscalerInformer
}

which provides a type-safe way of getting at a the thing being informed on.

Part of me imagines someting like..

import hpaInformer informer

myInformer := hpaInformer.New(sharedUnderlyingCacheThing)

My hunch is that client-go has quite a few of these situations (the listers
package is one,
and general experience with the package suggests there would be others).

Clearly everything is already working pretty well, so there's nothing
"impossible" without generics here. The
client-go package is still reasonably pleasant to use (though, as a
consequence of all the genration the docs
are very verbose, but low content, it took me a long time to actually work
out how to use the shared informers
stuff because I kept start with the voluminous sub packages, rather than
the informers package that got lost in the noise).

And, once again, I'm heavily unqualified to comment on this from the
package maintainers
PoV, if they felt strongly about this, I'm sure they'd be speaking up
already.




>
>

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

[Tristan Colgate]

On Sat, 29 Jul 2017, 23:59 Shawn Milochik,  wrote:

>
>- You don't need generics to write Kubernetes.
>
> I've had no personal need for generics, but k8s client-go is the one case
I've seen where I thought they would help, the informers packages in
particular.

https://godoc.org/k8s.io/client-go

(FWIW, I'd rather there was an effort, like the one for dep, to take
learnings from the existing generics/templating tools, and see what's
needed in the language and tooling to give us one tool in the standard tool
chain)

-- 
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] Announce hugot - a chat bot package

[Tristan Colgate]

Hi All,
  I'd like to announce hugot. An (hopefully) idiomatic library for building
chat bots.
  It is inspired by net/http, and hopefully let's you build bots up how you
want to.
  I'm particularly interested in feedback on the API. (...and test coverage
is next on my list, promise!)
  Hopefully I'll have a few chat ops focused handlers releasable soon.
  See the godocs http://godoc.org/github.com/tcolgate/hugot .I'll be adding
some proper examples in there soon. For the moment, examples are in the
report.

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