[go-nuts] SQL Interceptor

Hi, I'm thinking of an addition to the sql package. I like to call an interceptor on each completed statement. I'm interested in timing information (prometheus in my case) and status codes. There may be other useful information, such as, number of rows (for "selects"), which we could make avail

Re: [go-nuts] modules and package cyclic dips

Well, ok. Did you mean if A v1.12 of a module depends on v1.3 of B which depends on v1.11 of A? So go modules don't actually necessarily depend on the listed dependencies? That is quite counteruintintive to me. It is much simpler in any case to use acyclic dependencies. Scott On 10 September

Re: [go-nuts] Operator Overloading Implies Generics?

i think the lack of implicit casts makes the idea much better in Go. I was just thinking of my admiration for goimport sand how nicely that enriches he programming practice. if the argument-distinguished function names have the same base name ("MakeCircle$" where $ is one of PointRadius, ThreePoi

Re: [go-nuts] Operator Overloading Implies Generics?

On Sunday, 9 September 2018 15:54:34 UTC+2, Michael Jones wrote: > > > On the down side, if things go wrong, you don't know what source code to > go look at. I admit being confused before (C++) as to which overloaded > function/method was being called because of default type casts. That is > f

[go-nuts] Windows 10 x64 - the program can't start because libz-1.dll is missing from your computer.

robotgo uses CGO, some C code so a C compiler is needed. Maybe that's where it links against libz. The README mentions libpng requirement, maybe libpng needs libz. CGO is not go, a cgo program has some parts in C, that involves every problem a C program can have. -- You received this message

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

On Sunday, 9 September 2018 18:46:55 UTC+2, Eric Raymond wrote: > > > This morning, casting about for a "how to do it right" example, I > invented a way to implement sum types using composition and some > simple field-resolution rules. Zero new syntax. If I'm feeling brave when > my Python tr

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

On Sunday, 9 September 2018 15:50:17 UTC+2, Robert Engels wrote: > > Which is why I believe this can happen with existing interfaces and > compiler magic. (along with my other proposal regarding carrying the > concrete type in slices). > > I think this is an admirable objective, if it can be ach

Re: [go-nuts] modules and package cyclic dips

I think there's a disconnection between how you and I understand this system works. In a given build, there is only a single version of a module; there cannot be multiple copies, let alone many copies.So if v1.11 of module A depends on v1.3 of module B, which in turn depends on v1.12 of module A, t

[go-nuts] Windows 10 x64 - the program can't start because libz-1.dll is missing from your computer.

Compiled a small app w/ Go 1.11 and only used one 3rd-party import ("github.com/go-vgo/robotgo"). GOARCH=amd64; GOOS=windows. Runs fine on the computer I used to build it. I copy it in a VMWARE instance of Windows 10 x64, and I get that 'libz-1.dll' is missing from your computer when I try t

[go-nuts] Performance difference between named and literal stack variables

I'm curious about why go 1.11 compiler is doing different things for functions f1 and f2 in the following example: type T [512]byte //go:noinline func use(*T) {} func f1() { s := T{} use(&s) } func f2() { use(&T{}) } T{} stays on the stack in both cases according to -gcflags=-m, but b

Re: [go-nuts] A thought on contracts

On Tuesday, September 4, 2018 at 11:49:23 AM UTC-5, rog wrote: > > 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. > > In your example, you co

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

The implicit nature of contracts seems like a major sticking point. If you are writing something like 1 << t to express “unsigned integer” then it seems like it would obviously be more explicit to directly state “unsigned integer”. contracts look really elegant, powerful, and well-defined from

[go-nuts] Re: Link: Getting specific about generics

Great discussion, thanks for the comments! I wrote a bit more responding to things I saw here and elsewhere: https://emilymaier.net/words/another-generic-post/ Emily On Sunday, September 2, 2018 at 4:08:48 AM UTC-4, Charlton Trezevant wrote: > > Link: [Getting specific about generics, by Emily

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

> > I get that it avoids introducing those properties directly into the > > language but it also locks the language into those properties. You can > > never change https://github.com/golang/go/issues/19113 after > > introducing contracts because there could be a contract somewhere that > > uses 1 <

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

I don't think saying that is is productive. contracts are more than just "identifiers used as constraints", they are also a syntactic construct to specify those. I specifically don't allow that and that's the whole point I'm making. So this doesn't seem like a particularly nice way to have a discus

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

On Sun, Sep 9, 2018 at 11:08 PM Jonathan Amsterdam wrote: > func ShortestPath(type G Graph(Node, Edge), Node, Edge) (g G, from, to >> Node) []Edge >> > > I don't think this syntax is valid according to the draft design, or your > blog post. Node and Edge are used before they are declared. > I h

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

On Sunday, September 9, 2018 at 3:19:16 PM UTC-4, Axel Wagner wrote: > > On Sun, Sep 9, 2018 at 8:49 PM Jonathan Amsterdam > wrote: > >> The problem is that this program seems to type-check, but it is invalid. >> The == operator is specified to work on operands of the same type, and it >> is b

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

> > > func ShortestPath(type G Graph(Node, Edge), Node, Edge) (g G, from, to > Node) []Edge > I don't think this syntax is valid according to the draft design, or your blog post. Node and Edge are used before they are declared. Maybe func ShortestPath(type Node, Edge, G Graph(Node, Edge)

Re: [go-nuts] Re: How to setup your development environment using Go modules

Hi all, Also, for reference, here are three other related issues: #26640 "cmd/go: allow go.mod.local to contain replace/exclude lines" https://github.com/golang/go/issues/26640 #26377 "proposal: cmd/go: module semantics in $GOPATH/src" https://github.com/golang/go/issues/26377 #2754

Re: [go-nuts] Re: How to setup your development environment using Go modules

Seth and/or Mirko, What would you think about one of you opening a new issue that covers the possible approach you were outlining earlier in this thread: "Another idea is to have a sort of "publish local" semantics, where the go tool has support for something like -devel tags, which override

[go-nuts] [Go2 generics] Craftsman pov, craftsman wishes

Finally I got some spare hours to dive into go-nerics proposal. So far it seems to me like a construct __derived__ from the mental sketch of an easy implementation. But in its current shape it **DESTROYS** the most important trait of the language: readability **in place**. Now Go1 guarantees tha

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

This is where the “compiler magic” happens… the interfaces are checked internally - if the compiler can find a method where the receiver type matches the parameter type, and it returns a value which is the receiver type, it can use the + operator on it, if not it is a compiler error. As others

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

The reason I'm trying to keep things separate (at least in my head) is that it allows to split the implementations. For example, it would be possible to first add type-parameters, then add constraints (however) and then add a way to allow constraints enabling operators (however). Each step would be

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

Oh, I actually wanted to add something about this: Whether or not this will *actually* end up being static or dynamic dispatch is, AIUI, intentionally left open in the proposal. The current thinking, AIUI, is t

Re: [go-nuts] Operator Overloading Implies Generics?

I think that is a small matter, and the compiler could easily prevent these overlapping method signatures. I think you rarely have that anyway in well designed code, because you don’t need the single parameter version, as the multiple parameter version also covers the single parameter case, but

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

On Sun, Sep 9, 2018 at 12:18 PM, 'Axel Wagner' via golang-nuts wrote: > > I disagree with the premise that we need operators for generics - when I > think of "generics", I usually think of "type-safe, constrained, parametric > polymorphism". Without operators, generic code would still fulfill that

Re: [go-nuts] Re: How to setup your development environment using Go modules

Hi all, This thread is hitting on a fairly important set of topics. It certainly seems some additional brainstorming and community discussion about how things could or should work regarding multi-module workspaces would be beneficial. A file tree with a `go.mod` has been described as something

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

On Sun, Sep 9, 2018 at 8:49 PM Jonathan Amsterdam wrote: > The problem is that this program seems to type-check, but it is invalid. > The == operator is specified to work on operands of the same type, and it > is being used on operands of different types. > Good point. I have to think about it.

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

True. You can get static dispatch by func ShortestPath(type G Graph(Node, Edge), Node, Edge) (g G, from, to Node) []Edge On Sun, Sep 9, 2018 at 8:21 PM Jonathan Amsterdam wrote: > >> FWIW, in my pseudo-interface description >> , >> >

[go-nuts] Re: A "not-so-alien" syntax for error check.

See the feedback wiki . I encourage you to read the links there, then post your own. On Saturday, September 8, 2018 at 10:44:00 PM UTC-7, nvcnvn wrote: > > With the current proposal >

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

On Saturday, September 8, 2018 at 11:58:46 PM UTC-4, Robert Engels wrote: > > For the math operator, since Go already doesn’t do automatic numeric > conversions, all of the operators are almost trivially implemented as > methods, e.g. operator + is > > pseudo generic interface - not really req

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

> > FWIW, in my pseudo-interface description > ... > You mention that comparable is a pseudo-interface, which means the type supports the == and != operators. You say that comparable and the other pseudo-interfaces are types. So I

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

> > > FWIW, in my pseudo-interface description > , > Unrelated to this particular issue, but since you link to your blog post, I just want to mention that in your graph example, func ShortestPath(type Node, Edge) (g Graph(Node,

Re: [go-nuts] modules and package cyclic dips

Hi Sameer, Thanks for asking, here are some thoughts, With time, this could create man many many copies of (different versions) of a module. this would slow down fetch, storage, compilation, etc potentially a lot, and it would only get worse and worse over time. if a security patch is applied to

Re: [go-nuts] modules and package cyclic dips

If a module depends on an earlier version itself, and successive versions are backwards compatible, why is it not OK for the current version to satisfy that dependency? On Sun, Sep 9, 2018 at 1:13 PM Scott Cotton wrote: > Hi Sameer, > > When I had a module self-dependency, I considered the fact t

Re: [go-nuts] modules and package cyclic dips

Hi Sameer, When I had a module self-dependency, I considered the fact that it worked a bug. I had not followed closely enough til this discussion to think of it as expected. As someone who has a tendency to often ask themself: "worse case how can this be a problem?" the list is indeed long and

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

robert engels : > Which is why I believe this can happen with existing interfaces and compiler > magic. (along with my other proposal regarding carrying the concrete type in > slices). > > You can do operator overloading and type conversion with interfaces. > (although not a big fan of operator

Re: [go-nuts] modules and package cyclic dips

With respect to errors, I'm asking how things failed when you had a cyclic module dependency. My expectation is that this should just work. If your module 0.12 has a dependency on itself with min version 0.11, then 0.12 satisfies that dependency (as long as it's following the import compatibility r

Re: [go-nuts] Curious about fixed heap mappings

On Sun, Sep 09, 2018 at 04:23:42AM -0700, Ian Lance Taylor wrote: > On Sat, Sep 8, 2018 at 4:31 PM, Shawn Webb wrote: > > > > I've read through a previous discussion in 2012 about golang's use of > > deterministic memory allocations here: > > https://groups.google.com/forum/#!msg/golang-nuts/Jd9tl

Re: [go-nuts] Operator Overloading Implies Generics?

On September 9, 2018 1:43:09 PM UTC, robert engels wrote: >I think the lack of method overload is a poor choice. > > … > >I would much rather write > >NewCircle([]Point) >NewCircle(center Point,radius int) > >than > >NewCircleFromPoints >NewCircleFromCenterWithRadius > >and this is just a very

Re: [go-nuts] modules and package cyclic dips

Hi Paul, On 9 September 2018 at 16:26, Paul Jolly wrote: > Hi Scott, > > > Yes I see that in terms of compatibility it "all works out", but it seems > > underspecified what should happen. > > Which bit do you think is underspecified? > Perhaps how to ensure a security patch is actually applied

Re: [go-nuts] modules and package cyclic dips

Hi Scott, > Yes I see that in terms of compatibility it "all works out", but it seems > underspecified what should happen. Which bit do you think is underspecified? To my mind the behaviour is very clearly defined, notwithstanding the next point. > Also, although your experience reports are > c

Re: [go-nuts] Operator Overloading Implies Generics?

I don’t see how that works - the details struct would need to be very complex, and the NewCircle would need to figure out which method the caller is intended (e.g. is the points nil, then the user must want to do center and radius) - very error prone too IWT. > On Sep 9, 2018, at 8:54 AM, Micha

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

On Sun, Sep 9, 2018 at 6:51 AM, Ignazio Di Napoli wrote: > > Thank you, I see your point. This is less powerful than contracts, but Go > proved me that less is more, as long as it is enough. My point is: do we > really need a so powerful version of generics or maybe operators and > interfaces a

Re: [go-nuts] Operator Overloading Implies Generics?

It is a good example of good and bad. NewCircle(details) is conceptually optimal. Everyone knows what is intended, and it is easier to type. On the down side, if things go wrong, you don't know what source code to go look at. I admit being confused before (C++) as to which overloaded function/me

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

Thank you, I see your point. This is less powerful than contracts, but Go proved me that less is more, as long as it is enough. My point is: do we really need a so powerful version of generics or maybe operators and interfaces are enough? For the many keywords added and to manage conversions, w

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

Which is why I believe this can happen with existing interfaces and compiler magic. (along with my other proposal regarding carrying the concrete type in slices). You can do operator overloading and type conversion with interfaces. (although not a big fan of operator overloading…) Method overl

Re: [go-nuts] Operator Overloading Implies Generics?

I think the lack of method overload is a poor choice. A simple review of the stdlib shows a lot of XFromInt XFromUnit and that is workable, but when you have complex structs as parameters, then the naming because really long… and the fact that you don’t have file level hiding, means even for loc

Re: [go-nuts] modules and package cyclic dips

Hi Paul, Yes I see that in terms of compatibility it "all works out", but it seems underspecified what should happen. Also, although your experience reports are clearly presented and make sense, when I step back my own impression is: that's not simple. I'd rather be spending time coding than figu

Re: [go-nuts] modules and package cyclic dips

Hi Sameer, I don't know what is considered an error and not an error with cyclic module dependencies. Honestly, it makes my head hurt and simply requires too much thought that I'd rather spend on the code. For example, I don't want to think what will happen to some SCC in a module dependency gra

[go-nuts] Go modules: go get installs binary

Does it correct that go get (with modules enabled) installs binary. I thought it must only download / update dependencies in modules mode? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails f

Re: [go-nuts] modules and package cyclic dips

> Interesting. I'm not sure what cyclic module dependencies means. I do know > some package managers (not go) boast of having a "solid transitive dependency > model". I hope that any cycles in modules dependencies are either avoided or > treated in a very clear simple way by go's modules. In

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

Ian Lance Taylor : > As I've said before, I would very much like to avoid adding many > different names to the language. I've been staying out of the forward-looking language-design discussions so far, and intend to keep pretty quiet on that front until I feel my grasp on idomatic Go as she is now

Re: [go-nuts] Operator Overloading Implies Generics?

On Sat, Sep 8, 2018 at 6:58 PM, Rick wrote: [ replacing "operator" by "method" since that seems to be what was intended ] > Is support for [method] overloading implied by support for generics? No. > Is it > possible to have one with the other? Yes, they are entirely independent. > To be hone

Re: [go-nuts] modules and package cyclic dips

Are you seeing errors when there are cyclic module dependencies? As I recall, cyclic dependencies between modules (not packages) must be allowed: https://research.swtch.com/vgo-mvs "Note that F 1.1 requires G 1.1, but G 1.1 also requires F 1.1. Declaring this kind of cycle can be important when sin

Re: [go-nuts] Re: Operator Overloading Implies Generics?

Lucio : > Method overloading opens the kind of can of worms Go has been very good at > avoiding. Once the compiler needs to recognise the applicable instance of a > method or function by its signature or even worse by parts of its > signature, a lot of guarantees fly out of the window. I don't t

Re: [go-nuts] modules and package cyclic dips

Hi Paul, On 9 September 2018 at 13:44, Paul Jolly wrote: > Hi Scott, > > > Should cyclic module dependencies be allowed? > > Yes, indeed in some situations they are totally necessary. > > I wrote up an experience report on this very topic: > https://gist.github.com/myitcv/79c3f12372e13b0cbbdf041

Re: [go-nuts] modules and package cyclic dips

Hi Scott, > Should cyclic module dependencies be allowed? Yes, indeed in some situations they are totally necessary. I wrote up an experience report on this very topic: https://gist.github.com/myitcv/79c3f12372e13b0cbbdf0411c8c46fd5 > Should a module, following a cycle, be able to depend on an

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

On Sun, Sep 9, 2018 at 9:35 AM Ian Lance Taylor wrote: > As I've said before, I would very much like to avoid adding many > different names to the language. Also, there are many different cases > to handle. Consider type conversions, for example; how do you express > that you want to have two t

Re: [go-nuts] Curious about fixed heap mappings

On Sat, Sep 8, 2018 at 4:31 PM, Shawn Webb wrote: > > I've read through a previous discussion in 2012 about golang's use of > deterministic memory allocations here: > https://groups.google.com/forum/#!msg/golang-nuts/Jd9tlNc6jUE/qp2oyfEEfjQJ > > Back then, -buildmode=pie didn't exist back then, so

[go-nuts] Re: Operator Overloading Implies Generics?

On Sunday, 9 September 2018 11:49:12 UTC+2, alan...@gmail.com wrote: > > [ ... ] > > I'm not even sure that it would help all that much with the Go 2 generics > design as there are some aspects even with the use of operators for the > built-ins which are difficult or tedious to express in any gen

[go-nuts] modules and package cyclic dips

Hi all, I am wondering about cyclic dependencies w.r.t. modules. I haven't been able to find anything related, but also haven't verified all the possible related discussion venues, which would take a while. Let me start out with an observation: Suppose module A has packages A A/x modu

[go-nuts] Re: Operator Overloading Implies Generics?

One of the things that attracted me to Go in the first place was its lack of function/method overloading! Having programmed for many years in other languages that had this feature, I'd concluded that it was both confusing and difficult to compile because of potential ambiguities in deciding whi

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

On Sat, Sep 8, 2018 at 7:53 PM, Jonathan Amsterdam wrote: >> When is it important to not just express what operations are >> required for a type, but also to try to rule out some types? > > > I think the short answer is: numeric code. That's when one thinks about > which types make sense for an a

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

On Sat, Sep 8, 2018 at 6:10 PM, Rob Pike wrote: > "A contract is a compile-time description of which types are permitted > for a polymorphic function or type." > > No, it's not. It's a collection of statement-like operations that must be > legally compilable, under restricted circumstances, by the

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

On Sat, Sep 8, 2018 at 2:23 PM, jimmy frasche wrote: > > I get that it avoids introducing those properties directly into the > language but it also locks the language into those properties. You can > never change https://github.com/golang/go/issues/19113 after > introducing contracts because there

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

On Sat, Sep 8, 2018 at 3:47 PM, Ignazio Di Napoli wrote: > I'd really like to read a reply to Lucio's argument about operator > overloading. > > Once we define that: > 1. a 2. a==b is the same as a.Equals(b); > 3. the other comparaison operators are defined using these two (e.g.: a>b is > !a.Les