Re: [go-nuts] What happens when you call another method within a method set at the end of a method
Quoting Robert Engels (2019-04-06 08:00:02)
>But yes, similar to how all recursive functions can be rewritten using
>loops, which are more efficient, that is essentially what tail call
>optimization does - just that the process it automatic.
Not all recursive functions -- just tail calls. If you do stuff after
the call then you need to save state, which is what the call stack is
for.
You *could* use an explicit stack instead of using the call stack, but
whether this is more or less efficient is highly dependent on your
language implementation and the stack data structure you're using; I see
no reason to believe it would necessarily be more efficient in general.
---
Adding tail calls also has a few gotchas depending on how it interacts
with other parts of the language. For example, in the case of:
```
func foo () {
...
defer x.Close()
...
return bar()
}
```
The call to `bar()` is *NOT* a tail call, because `x.Close()` must be
called before the function actually returns. So this means they interact
in non-obvious ways with other parts of the language. One of the things
I like about Go is that most of the features interact in ways that are
easy to predict.
--
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] Learning Data Structures and algorithms with Golang
Quoting Bhagvan Kommadi (2019-04-05 10:28:51) > #machinelearning #go #fintech #algorithms #datastructures 1. This isn't twitter, it's a mailing list. 2. What on earth does this have to do with machine learning or fintech? -- 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] protobuf and golang
This might be more directly what you're after: https://kaitai.io/ Though disclaimer, I haven't used it myself. Quoting Wojciech S. Czarnecki (2019-03-19 20:25:08) > On Mon, 18 Mar 2019 09:59:59 -0700 (PDT) > R Srinivasan wrote: > > > my intial attempts to define the data structures have hit a roadblock - > > support for data types such as uint16, int16, uint8, int8. Is this an > > inherent protobuf limitation or am i overlooking something. > > Yep. Protobuf is an exchange format of its own. > > https://github.com/google/flatbuffers should give you more flexibility. > If your binary is tightly packed it will not be effortless, but doable. > > If you need to support bitfields you may also look at the 'bitpeek' > simple parser code for inspiration: > > https://github.com/ohir/bitpeek > > Hope this helps, > > > -- > Wojciech S. Czarnecki > << ^oo^ >> OHIR-RIPE > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: [CoC] screenshot images. Lazines or incompetence?
(For those who can't see the image: it's a photo of a monitor with the original message in this thread, with the words "too incompetent to learn how to copy/paste text" highlighted). I feel like I'm missing something; I hate having to ask for a joke to be explained, but...? -Ian Quoting Chris FractalBach (2019-03-12 06:57:44) >Sorry in advance, but I just couldn't resist the opportunity to lighten >the mood in this thread:� > >lol.jpg >I thought this was objectively funny =) > >-- >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 [1]golang-nuts+unsubscr...@googlegroups.com. >For more options, visit [2]https://groups.google.com/d/optout. > > Verweise > >1. mailto:golang-nuts+unsubscr...@googlegroups.com >2. 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] [CoC] screenshot images. Lazines or incompetence?
Quoting Lucio (2019-03-12 02:13:00) >specially in IM, because screenshots are a lot more informative (think >graphics) and, these days, very easily accomplished. The context of the discussion was screenshots *of text*, so this doesn't really apply. >The CoC should penalise only wanton usage and leave it to fate to >punish less intentional misuse. I'm definitely not keen on "punishing" people making honest mistakes -- but I also think that we should push back on this, point out that it is a problem and why, and expect people to be willing to learn. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] [CoC] screenshot images. Lazines or incompetence?
Right, I understood what you were saying, but the fact is people *are* posting *screenshots* to the list. (I imagine others are *also* pasting from an IDE, but like you say a screen reader should have no trouble with those, so I assume a blind user wouldn't even notice anything off about those messages. I don't notice because I use a terminal mail client which runs html mail through `lynx -dump`). -Ian Quoting Robert Engels (2019-03-11 13:56:31) > That’s not exactly what I meant. I meant that copy and pasting from an IDE > will often result in colored formatted text like looks like a screenshot but > it is not, and a screen reader should have no problem with it. > > > On Mar 11, 2019, at 12:49 PM, Ian Denhardt wrote: > > > > Quoting Robert Engels (2019-03-11 09:36:40) > >> I think you are confusing screenshots and copy and paste as html. The > >> latter works with screen readers and still gives colored text because most > >> likely the person is using an IDE. > > > > I suspect Wojciech is not confusing these two, seeing as just now I was > > reading another thread in which the question included an attachment of a > > raster image of plain text. > > > > It's probably worth just getting into the habit of responding to these > > with a canned response: > > > >> Please do not post screenshots of text to the mailing list. Not > >> everyone on this list can see, so doing so excludes people. Rather, > >> copy and paste the text into the body of the email. > > > > It takes < 30 seconds to do so, and I think pushing for norms that keep > > our technology accessible are worth much more than that. > > > > -Ian > > > > -- > > You received this message because you are subscribed to the Google Groups > > "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to golang-nuts+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > -- 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] [CoC] screenshot images. Lazines or incompetence?
Quoting Robert Engels (2019-03-11 09:36:40) > I think you are confusing screenshots and copy and paste as html. The latter > works with screen readers and still gives colored text because most likely > the person is using an IDE. I suspect Wojciech is not confusing these two, seeing as just now I was reading another thread in which the question included an attachment of a raster image of plain text. It's probably worth just getting into the habit of responding to these with a canned response: > Please do not post screenshots of text to the mailing list. Not > everyone on this list can see, so doing so excludes people. Rather, > copy and paste the text into the body of the email. It takes < 30 seconds to do so, and I think pushing for norms that keep our technology accessible are worth much more than that. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: non-local return?
Most of what you'd use promises for in Javascript would be better done
with channels & goroutines in Go, e.g:
resultChan := make(chan SomeType, 1)
go func() {
// do stuff
resultChan <- result
} ()
// do other stuff
result := <-resultChan // wait for the result.
The buffer size of 1 is a common pattern that makes sure that the
sending goroutine can exit without waiting for the result to be picked
up.
Sometimes though, promises are just used to not block other threads,
even when the thread waiting on them doesn't want to do anything in the
meantime. In this case you don't even need an analogue of a promise,
just launch the work to do in a separate goroutine:
go func() {
// do stuff
}()
// do stuff
..no need for promises or other machinery.
-Ian
Quoting clementauger...@gmail.com (2019-03-08 11:48:39)
>hi,
>i might be wrong, it looks likes to me that you want promise in go.
>something like this https://github.com/chebyrash/promise
>I personally don t like this pattern, even in javascript. but anyways,
>example below looks really weird to me and difficult to figure out what
>means to
>"reject but not to return, so the execution continues?"
>https://github.com/Chebyrash/promise/blob/master/examples/http_request/
>main.go
>in this version https://github.com/fanliao/go-promise
>same reject with naked return code that does not speak to me,
>but this https://github.com/fanliao/go-promise#promise-pipelining
>seems to answer one of your request, to quit early before step2.
>by wrapping step1 and step2 in order you might get the expected result.
>I have my own answer, not a promise, to the question, example
>https://github.com/clementauger/st/tree/master/http
>which i like because it helps to eliminate all this dead code that goes
>into my way.
>in the given example i have only one err variable to manage,
>the early return is managed by the pipeline and with all the
>reflections involved,
>the type assertions are gone and I just have to plugin the right func
>types et voil� .
>its not perfect because type errors are runtime fatal but when it is
>setup, i like it.
>in any cases, if i were beginner today, i would start by learning chan
>and go style at first
>before i import patterns from other languages.
>my 2 satoshis.
>Le vendredi 8 mars 2019 14:02:31 UTC+1, whiteh...@googlemail.com a
>écrit� :
>
>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.
>[1]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 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 [2]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [3]https://groups.google.com/d/optout.
>
> Verweise
>
>1. https://play.golang.org/p/_ANPXKRzibq
>2. mailto:golang-nuts+unsubscr...@googlegroups.com
>3. 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] distribution of go executables
Quoting Space A. (2019-02-26 20:58:40) > and stdlib only when redistributed separately as a whole in binary > form. When stdlib is used to compile regular binary, it's not > "redistributed" This is not my understanding; in general static linking constitutes distribution (though you are correct re: compiler output of your own code). > Correct answer The "correct answer," really, is to ask someone actually qualified to give you legal advice. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] efficient random float32 number generator?
Quoting Marvin Renich (2019-02-26 07:11:47) > * Louki Sumirniy [190226 06:22]: > > Assuming there is bytes in the system's entropy pool, you can also skip the > > scrambling step, though I don't know what overhead consuming these bytes > > entails compared to a standard PRNG. Then the biggest part of it is making > > the raw bytes into float. I'm not sure - could you take 4 random bytes, > > grab the unsafe pointer and cast back to float32? > > No, you could get one of many NANs. However, converting uint16 to > float32 (or float64) should be very efficient, then you have one > floating point divide by constant to get the desired range. See my comment elsewhere in the thread from yesterday; you could just hard code the sign bit and the exponent (an exponent of -24 will make sure you get the right range), and then fill in the fractional part of the float with random bits. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] How is a for loop preempted in Go?
Quoting David Finkel (2019-02-23 16:09:18) >Not only is fmt.Printf a function call, but it makes a blocking >syscall >(write specifically), >which gives the go runtime license to spin up a new OS thread and >immediately schedule the other goroutine. >runtime.GOMAXPROCS(1) only tries to guarantee that one OS thread >executing Go code will be executing at a time. >(this has no bearing on the revised version without a call to >fmt.Printf().) Good point. This is also important because "pre-emption at function calls" is not entirely reliable, since a function call could possibly be in-lined or otherwise optimized in a way that mucks with things -- whereas blocking is going to be more reliable in this way. -- 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 is a for loop preempted in Go?
In the new example, goroutine 2 should get pre-empted at time.Sleep.
goroutine 1 may hog a CPU however. There's an open issue about this,
which is being worked on.
https://github.com/golang/go/issues/10958
I think it's always been the intent that from the programmer's
perspective goroutines don't block one another at all; they're just
like threads but cheaper -- and indeed most of the time you can write
code that acts like that's true and never see a problem -- but the
reality of the implementation is that right now it is possible to
tight-loop and block other goroutines.
-Ian
Quoting Jingguo Yao (2019-02-22 03:31:55)
>Yes, my fault. Thanks for pointing it out.�
>What happens if I remove the fmt.Printf function calls to have the
>following code:
>package main
>import (
>"fmt"
>"runtime"
>"time"
>)
>func main() {
>count := runtime.GOMAXPROCS(1)
>fmt.Printf("GOMAXPROCS: %d\n", count)
>� // goroutine 1
>go func() {
>for {
>}
>}()
>� // goroutine 2
>go func() {
>for {
>}
>}()
>time.Sleep(10 * time.Second)
>}
>Can goroutine 1 or goroutine 2 be preempted? If yes, by which
>mechanism?
>On Friday, February 22, 2019 at 4:20:12 PM UTC+8, Ian Denhardt wrote:
>
> Quoting Jingguo Yao (2019-02-22 03:17:33)
> > � � Since both goroutines do not make any function calls
> fmt.Printf is a function.
>
>--
>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 [1]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [2]https://groups.google.com/d/optout.
>
> Verweise
>
>1. mailto:golang-nuts+unsubscr...@googlegroups.com
>2. 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 is a for loop preempted in Go?
Quoting Jingguo Yao (2019-02-22 03:17:33) >Since both goroutines do not make any function calls fmt.Printf is a function. -- 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] Is WASM support planned in go 1.12 ?
Quoting Tharaneedharan Vilwanathan (2019-02-06 15:30:51) >Somehow I was dreaming I can use Go for frontend too, instead of JS. Is >my thinking right? If that's your interest use gopherjs instead: https://github.com/gopherjs/gopherjs It's been around a long time and is pretty mature. As others have said, talking to the DOM in wasm is clumsy at best (and there's nothing Go-specific about this). If you want to make significant use of browser APIs, Javascript is a better target. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Why is "v" prefix for VCS tag required for ?
Also, on a more pragmatic level, what do you do if a repository has both tags: is the "real" version "v2.0.0" or "2.0.0"? But I generally agree with the other arguments; machines should be opinionated about the color of the shed, so humans can argue about things that actually matter (see also gofmt). -Ian Quoting gudv...@gmail.com (2019-02-04 13:24:55) >If you start with two options you open up a flood of endless > >discussions about why just these two and not that other > >too. > >� >No, it won't. Current version of semver convention (which is 2.0.0 ATM >and not 1.0.0)� says (as I mentioned) that any prefix violates (mildly >though) semver. >And they mentioned explicitly only "v" prefix. No "r", no any other >ridiculous ones since it's semver, not semrelease or semútgáfa. >Other than that is just a faulty generalization and shouldn't be used >against this point. >I actually had nothing against� this particular prefix. >It just shouldn't be the only option since semver itself doesn't have >requirements on tagging notation (at least anymore) and even states >against that. > > And the v prefix is pretty common > >Yep, and that's as common as no-prefix format. > > And retagging a "3.1.4" as "v3.1.4" is dead simple. > >Also changing go-semver standard to support non-prefixed tags without >losing any backward compatibility. >Current standard which meant to be implemented currently not >implementing semver as it is. >On Monday, February 4, 2019 at 11:31:58 AM UTC+3, Volker Dobler wrote: > >Well, it is good to have exactly one valid format. >With two options like "vN.M.L" and "N.M.L" confusion starts >to spread and why not allow a capital "V" too and a "ú" too >for "útgáfa" and "r" for "release" should be allowed too. >If you start with two options you open up a flood of endless >discussions about why just these two and not that other >too. >So the whole question is "why v.N.M.M and not N.M.L ?" >This might be a question of taste and thus unanswerable. >I personally think the v prefix makes it clear it is a version tag. >Even Semver 1.0.0 suggested to prefix the version number >with v in the VCS. >And the v prefix is pretty common: Docker, Kubernetes, CoreOS. >And retagging a "3.1.4" as "v3.1.4" is dead simple. >In summary. There is one format and that one is v; >it is a standard and standards are to be implemented. >V.� >On Monday, 4 February 2019 07:52:09 UTC+1, Maxim S wrote: > >Now go mod requires to have prefix "v" for it's tag in VCS and it's >mandatory so you can't use tags in form of "A.B.C" in your workflow. >But this limitation has little to zero reason to exist so why is it >strict requirement? Why not to allow use both "vA.B.C" and "A.B.C" >tags?� Who are using "A.B.C" tags for anything but version? >It can be done without modifying current .mod files by just ignoring >"v" prefix during repository search. >Many teams use prefix-less tags for versions (both for Go before >modules and non-Go projects). Not to mention that it's [1]not a valid >semver� (but very common though) and thus requirement even less >understandable. > >-- >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 [2]golang-nuts+unsubscr...@googlegroups.com. >For more options, visit [3]https://groups.google.com/d/optout. > > Verweise > >1. > https://github.com/semver/semver/blob/master/semver.md#is-v123-a-semantic-version >2. mailto:golang-nuts+unsubscr...@googlegroups.com >3. 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] Naming convention for accessor functions?
Some standard library function names to possibly take inspiration from: * regexp.MustCompile * template.Must. Quoting Randall O'Reilly (2019-02-03 23:26:04) > I’m trying to figure out the best convention for the basic function of > accessing elements in a container (specifically in the context of GUI > elements in the case of GoGi / GoKi https://github.com/goki/gi, and also in > our new biological neural network simulator in Go: > https://github.com/emer/emergent). > > The key issue is that we have containers that return an interface, which the > user then needs to convert into a particular type. If you have multiple > return values from the accessor, then you cannot do this conversion directly > in one line. Sometimes you know your access will succeed, and other times > you don’t — if you’re unsure, you’ll be checking for failure anyway.. > > So, first of all, it seems like we need two methods, one with a single return > value of the interface, and another with two return values (either an > additional error or a bool — there is another question as to which..). The > native Go map accessor nicely gives you the option depending on how many > variables you give it, but we don’t have that luxury with regular methods > (Go2 proposal??). > > The question is: which method should be the “default” and which should be > “marked” with an extra label, and what should that label be? > > Option 1: fast, risky version is the default, use “Check / WErr / Safe” (or > another better name?) for the safer version that returns an error. E.g., > when looking up an element by Name, you might have: > > • ThingByName(name string) Thing > • ThingByNameCheck(name string) (Thing, error) // or WErr (“with err”) or > Safe or ?? > > Option 2: opposite: > > • ThingByName(name string) (Thing, error) > • KnownThingByName(name string) Thing > > I have used option 2 in GoGi / GoKi, and like the label “Known” as capturing > the idea that you don’t need an error because you know it will work (although > are there even better options?), but I also feel like I use the “Known” case > more frequently, and therefore it should be the unmarked default, and provide > the affordance for new users that they should generally use that version and > do their conversions directly and efficiently, e.g., foo := > Container.ThingByName(“foo”).(*Actual). > > Thanks for any advice! > > - Randy > > ps. while I’m emailing, I just setup a google groups email list for anyone > using GoGi / GoKi etc: https://groups.google.com/forum/#!forum/goki-gi — I’m > planning to do a lot of work soon getting the 3D part of it working finally, > and will email updates there — will be a fair bit of disruption for a while, > though the 2D API should remain largely stable (also modulo the outcome if > this discussion..) > > -- > 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: Memory usages
Quoting Michael Jones (2019-01-30 23:15:51) >very close. One more idea: typed constants only exist during >compilation. I assume you meant "untyped constants" here. But yes, exactly. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: What does a deadlock mean in golang?
Quoting 伊藤和也 (2019-01-29 05:00:32)
>I know the general meaning of a deadlock, but I don't know the meaning
>of a deadlock in golang. For example, I send 4 values to a buffered
>channel whose maxmum size is 3 and a deadlock occurs. I think this is
>just "values are out of bounds" like array. What does a deaklock mean
>in golang?
A deadlock means the same thing in Go as it does in general; there's no
language-specific concept here.
The error you're seeing isn't an "out of bounds" error, rather, on the
last send the channel is already full so the sending goroutine waits until
there is space to insert the new item. Since there is nothing that will
ever take stuff out of the channel, this is never going to happen --
therefore you have a deadlock.
If you modify the program so there is another goroutine which will
receive a value from the channel:
package main
import (
"time"
)
func main() {
ch1 := make(chan int, 3)
go func() {
time.Sleep(10 * time.Second)
<-ch1
}()
ch1 <- 10
ch1 <- 10
ch1 <- 30
ch1 <- 40
}
then you won't get that error -- after the 10 second sleep, the spawned
goroutine will pull a value out of the channel, making space for one
more. At this point the send succeeds, the first goroutine is unblocked,
and the program finishes successfully.
Normally, the result of a deadlock is that things just hang, but because
channels are built-in to the language, and the compiler and runtime know
about them, it's possible for the runtime to spot certain patterns of
deadlocks. I mentioned this in another comment, but basically what's
happening is when the goroutine scheduler notices it doesn't have any
goroutines that are ready to run, it checks to see if any of them are
waiting on something that might unblock without the help of another
goroutine. If so, it waits until there's something to run. Otherwise it
reports an error, rather than just hanging.
In the first iteration of the program (in your original message), there
are no other goroutines at all, so when the scheduler sees that it's
only goroutine is waiting on a channel, it knows it will never finish
and bails.
In the modified version above, shortly after the program begins, the
original goroutine is again blocked on the channel send, but this time
there is another goroutine, which is blocked on a call to sleep. This
time, when the scheduler notices it has nothing to run, it also sees
that there is a goroutine waiting on sleep() -- which might finish
eventually, so it gives it some time, rather than aborting. When the
sleep completes, that goroutine can be scheduled and we're good.
It is of course possible to cause deadlocks that the runtime won't
catch; a variant of the above example that used os.Pipe() instead of
a channel would just hang, even though the same concurrency patterns
are at fault, because the goroutine scheduler doesn't know about pipes,
only channels.
-Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] What does a deadlock mean in golang?
Yes, exactly. It's a deadlock in the general sense, but this case is
particularly easy to detect: if all of the goroutines in your program
are blocked on some channel operation, then the runtime's scheduler
notices it has nothing it can do and reports that the system has
deadlocked.
-Ian
Quoting diego patricio (2019-01-29 03:59:13)
>Hi,� maybe it's because no goroutine read the channel,� the four
>value cause the deadlock because for write that value there is no space
>in the channel,� sorry by my English, I'm new in go too...�
>
>El mar., 29 ene. 2019 9:55, <[1]kazya.ito.dr...@gmail.com>
>escribió:
>
>I know the general meaning of a deadlock, but I don't know the meaning
>of a deadlock in golang. For example, I send 4 values to a buffered
>channel whose maxmum size is 3 and a deadlock occurs. I think this is
>just "values are out of bounds" like array. What does a deaklock mean
>in golang?
> func main() {
>ch1 := make(chan int, 3)
>ch1<- 10
>ch1<- 20
>ch1<- 30
>ch1<- 40
> }
>
> fatal error: all goroutines are asleep - deadlock!
>
> --
> 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 [2]golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit [3]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 [4]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [5]https://groups.google.com/d/optout.
>
> Verweise
>
>1. mailto:kazya.ito.dr...@gmail.com
>2. mailto:golang-nuts+unsubscr...@googlegroups.com
>3. https://groups.google.com/d/optout
>4. mailto:golang-nuts+unsubscr...@googlegroups.com
>5. 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] Producer-Consumer with Goroutines
In general, after the message send goes through, the two goroutines
involved could start executing again in any order -- so the behavior
you're seeing is expected?
Is there a less toy example that this is supposed to be representative
of? Or were you just expecting it to work differently, and trying to
understand the behavior?
It's hard to give advice without knowing what you're trying to achieve;
If I wanted exactly the output you're going for I'd just do:
for i := 0; i < 10; i++ {
fmt.Printf("Producer %v\n", i)
fmt.Printf("Consumer %v\n", i)
}
..but I imagine that's not the point of the excercise.
-Ian
Quoting diego patricio (2019-01-24 16:48:35)
>Hi, thanks for your response, still� I dont get right result
>image.png
>image.png
>
>El jue., 24 ene. 2019 a las 22:42, Christian Staffa
>(<[1]christian.p.sta...@gmail.com>) escribió:
>
>Hi
>to get a synchronization with goroutines you need to use an unbuffered
>channel. you have used a buffered channel of 1.
>Sent from my iPhone
>On 24. Jan 2019, at 22:11, diego patricio <[2]dipas...@gmail.com>
>wrote:
>
>Hi all, i'am just learning Go and goroutines, I have three goroutines
>(main, producer, consumer) and I dont know how synchronize producer and
>consumer for print one value at time, the output that I want is
>Producer 0
>Consumer 0
>Producer 1
>Consumer 1
>..
>but the output of my program it's diferent.
>the program:
>
>The output:
>
>Sorry about my english
>Regards
>
>--
>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 [3]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [4]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 [5]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [6]https://groups.google.com/d/optout.
>
> Verweise
>
>1. mailto:christian.p.sta...@gmail.com
>2. mailto:dipas...@gmail.com
>3. mailto:golang-nuts+unsubscr...@googlegroups.com
>4. https://groups.google.com/d/optout
>5. mailto:golang-nuts+unsubscr...@googlegroups.com
>6. 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 is Context explicit vs. implicit in Go?
There's actually been a fair amount of conversation on this topic lately. Most recently it came up in this thread: https://groups.google.com/forum/#!searchin/golang-nuts/context|sort:date/golang-nuts/Lqoj5bNQxzg/5LUEYGHAGQAJ My biggest worry about making it implicit is that it becomes hard to tell what APIs actually respect cancellation via context. The context package was introduced at a point when the language was already fairly mature, so much of the standard library and ecosystem doesn't accept context parameters, thus providing no (standard) way of canceling those operations (though some packages have their own ad-hoc mechanisms). I think if you were going to make the context implicit, to keep things sane you'd also have to somehow ensure cancellation is "always" respected. I know of two languages that provide this sort of mechanism -- Erlang and Haskell -- but they do this by means of asynchronous exceptions, which besides having their own pitfalls in the abstract, would completely break essentially all of the resource cleanup code written in Go today, by introducing race conditions, not to mention fundamentally change how error handling has to work. People have pointed out real problems with the current situation, but I haven't seen a good solution yet. -Ian Quoting David Suarez (2019-01-24 12:02:15) >First off, I am really loving Go overall.� I probably did what many do >and started out with less Context use and now it is becoming a standard >for a few tiers which I see was in a blog somewhere from Google as >well.� What I haven't been able to find is if there has ever been a >conversation on making it implicit vs. explicitly passed in method >calls.� In java you can do this to grab, set a context variable and >then pull it a few steps down the request cycle without explicitly >adding it to method signatures in between.� Is there a specific reason >it is not implicit (e.g. readability or other) or just a conversation >that hasn't happened yet?� Should it be a feature request to minimize >its use to only those areas it is really needed?� > >-- >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 [1]golang-nuts+unsubscr...@googlegroups.com. >For more options, visit [2]https://groups.google.com/d/optout. > > Verweise > >1. mailto:golang-nuts+unsubscr...@googlegroups.com >2. 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: do you use binary-only packages?
I feel like I should stress this a bit more, because it's really important: It is under no circumstances reasonable to rely on lack of source code for security. History has taught us time and time again that security through obscurity doesn't work, and home grown/custom algorithms are usually broken. For authentication, you should always be using off-the shelf, open source libraries which implement publicly known algorithms that have been peer reviewed by experts. These will be more secure than anything that hasn't seen the light of day, and don't rely on people not knowing about them. There is no good reason why there should be anything security-sensitive in your source code. -Ian Quoting Ian Lance Taylor (2019-01-22 16:26:27) > On Tue, Jan 22, 2019 at 1:06 PM Wei Tang wrote: > > > > Well, I do think Binary-only packages are very important for some security > > case, such as authentication algorithm in a private enterprise。 > > I would not recommend using them in that way. A binary package should > be thought of as a slightly shrouded form of the original source code. > An attacker with access to the binary-only package can easily > reproduce a variant of the original Go source code. Comments and > local variable names will be lost, but everything else will be there, > including any certificates and all algorithms. > > Ian > > > > 在 2018年10月19日星期五 UTC+8上午1:16:43，Russ Cox写道： > >> > >> The go command supports "binary-only packages", in which > >> the compiled .a file is installed in GOROOT/pkg or GOPATH/pkg > >> but the corresponding source code is only a stub with relevant > >> imports (for linking), a special comment marking it as a binary-only > >> package, and perhaps documentation for exported API. > >> > >> While the go command will use these packages if they exist in > >> GOROOT or GOPATH, 'go get' will not download them: 'go get' > >> is intentionally only about source code distribution. > >> > >> Furthermore, binary-only packages only work when the build is > >> using the exact versions of whatever imported packages are > >> needed by the binary-only package. If there were any important > >> differences in a dependency between compilation and linking, > >> the binary-only portion might have stale information about details > >> of the imported package, such as type sizes, struct field offsets, > >> inlined function bodies, escape analysis decisions, and so on, > >> leading to silent memory corruption at runtime. > >> > >> Binary-only packages also only work when the build is using the > >> exact version of the Go toolchain that was used for compilation. > >> This is at least enforced at link time, with the effect that if your > >> binary-only package only imports the standard library and you don't > >> use any special compilation flags, then the toolchain version check > >> suffices to avoid the silent memory corruption problem described in > >> the previous package. But if your package imports any non-standard > >> package for which that the eventual user might try to combine with > >> a different version, you're in trouble again. > >> > >> Compiled Go programs also contain much richer amounts of runtime > >> information than compiled C programs, so that for example all the > >> details of type declarations, including struct definitions, are in the > >> compiled code, along with file names and line numbers for the compiled > >> code, and increasingly good debug information that was impossible to > >> turn off until very recently. Overall, a binary-only package obscures very > >> little. > >> > >> In short, binary-only packages: > >> > >> - have never been supported by 'go get', > >> so you've had to go out of your way to use them, > >> - aren't even guaranteed to work when you do use them, > >> possibly leading to silent memory corruption, and > >> - still expose quite a lot more than most people would expect > >> about the original source code. > >> > >> For these reasons, we're looking at removing binary-only package > >> support entirely. > >> > >> If you use binary-only packages and think it's important to keep that > >> support around, please let us know either on this thread or at > >> golang.org/issue/28152. > >> > >> Thanks. > >> Russ > > > > -- > > 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
Re: [go-nuts] multiple binaries from a single directory with go modules?
You could just do: go build ./cmd/... cp ./cmd/foo/foo ./ cp ./cmd/bar/bar ./ ..and wrap it up in a script. Quoting Tycho Andersen (2019-01-17 17:47:35) > Hi everyone, > > I'm trying to get an existing project which outputs multiple binaries > to work with go modules. The package follows roughly the recommended > layout: https://github.com/golang-standards/project-layout > > That is, it looks like > > /go.mod > /go.sum > /code.go > /cmd/foo/main.go > /cmd/bar/main.go > > I have a top level make file that looks roughly like: > > all: foo bar > > foo: ... > go build -o foo ./cmd/foo/... > > bar: ... > go build -o bar ./cmd/bar/... > > When I type "make", it seems like go.sum and go.mod end up with only > bar's dependencies, because the last go invocation prunes the "unused" > dependencies from the module files. I've tried various ways of using > mutiple go.mod and go.sum files (one in each binary directory), but I > can't quite get the includes of the top level package right. > > I see https://github.com/golang/go/issues/14295, which will solve this > problem for me, but it doesn't exist yet. > > Is there some clever way of structuring a project like this with go > modules that I haven't figured out yet? > > Thanks, > > Tycho > > -- > 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] what is the use of context in golang RESTful apis?
Quoting Space A. (2019-01-17 16:46:17) > Go's package-level variables are also not "globals". And you can > control access with exported/unexported names or exported/unexported > package-level functions. Exactly. A namespaced global is still a global, and most of the problems with them still apply. This is also why "singletons" are an antipattern -- they're just dressed up globals. -- 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] what is the use of context in golang RESTful apis?
> They are not global variables, they are class variables. There's a > huge difference. Can you elaborate? I don't see a meaningful difference vs. Go's package-level var. -- 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] Using "er" and "able" for interfaces
Quoting Victor Giordano (2019-01-16 12:44:57) >"able" describes things in a more "passive way"� (the thing that you >can "ask it/his/her" to do). Do you find this appreciation correct? Pretty close, but a subtle point is that "-able" makes something the indirect object, so for example it is not quite right to say that a "writable" is something that you can ask to do writing -- it is the thing being written to, whereas the thing doing the writing is a "writer". In the case of io.Writer either one kindof makes sense, but the meaning *is* slightly different. When both are reasonable, -er is generally more idiomatic Go -- but that's not always the case. >The Go idiomatic style is to use the '-er' suffix. But this can >sometimes lead to strange or obscure names even for native English >speakers. >For example, an interface with a "Stale() bool" method seems very >strange when named as "Staler". All these sound weird: Lookuper, >Errorer, Nexter The problem with most of these is that the base words aren't verbs; the -er suffix converts a verb, describing an action, into a noun describing the thing or person that performs that action -- but "next" isn't an action, so "nexter" sounds weird. lookup is a little different -- "I lookup information" scans poorly, and I'd probably write it as "I look up something" or better yet "I look something up" -- so that probably has something to do with it, but I don't know how to describe the rule precisely. Ironically, I often have an easier time describing grammar rules precisely for German, because being a native English speaker I didn't learn English grammar in as structured a way. :P -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Can I say that a pointer is a reference or memory address to a value?
Possibly it's misleading if you're coming from C++ -- but if that's the
case you probably already know what pointers are. It's compatible with
how I've heard the term "reference" used in every other context. The
fact that they are first class values is an important point, however.
-Ian
Quoting Wagner Riffel (2019-01-09 11:31:44)
> i think the term reference is misleading, pointers holds a memory
> address, but they are variables, have their own space in memory.
> var i int
> var p1, p2 = ,
> fmt.Printf("%p, %p, %p", , , ) // 0x1000, 0x1004, 0x1008
>
> while in c++ references variables for example, address are shared for
> referenced and reference.
> int i;
> int =i, =i;
> printf("%p, %p, %p", , , ); // 0x1000, 0x1000, 0x1000
>
> probably "memory address to a value" fits better for pointers.
>
> On Wed, Jan 9, 2019 at 12:44 PM Ian Lance Taylor wrote:
> >
> > On Tue, Jan 8, 2019 at 9:46 PM 伊藤和也 wrote:
> > >
> > > Can I say that a pointer is a reference or memory address to a value?
> >
> > Sure.
> >
> > 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] C++ 11 to Golang convertor
Quoting Andy Balholm (2019-01-03 18:34:35) >It's at [1]https://github.com/rsc/c2go. It might be a good starting >place, but there is one significant difference in approach from what >Eric is proposing. Russ incorporated all of the manual cleanup into the >tool (or config files) as special cases, rather than leaving it as >manual cleanup. Right, the thing that made the project tractable at all was that it was purpose-built for the Go compiler, not intended to be a general purpose tool. As such, it only had to deal with C as used in the Go compiler, not all of C. This approach would also likely be tractable for a specific C++ codebase, but I think a general purpose tool is a lost cause. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] What are the reasonable reasons to use pointers?
Quoting Bakul Shah (2019-01-02 03:07:14)
> On Tue, 01 Jan 2019 22:56:06 -0800 Ian Lance Taylor wrote:
> > On Tue, Jan 1, 2019 at 6:42 PM Bakul Shah wrote:
> > >
> > > On Tue, 01 Jan 2019 03:34:34 -0800 =?UTF-8?B?5LyK6Jek5ZKM5Lmf?=
> > > wrote:
> > > >
> > > > What are the reasonable reasons to use pointers? Are pointers neseccary?
> > >
> > > Pointers are not necessary as a programming language feature
> > > but are necessary in implementing a programming language. As
> > > an example, Scheme doesn't have pointers.
> >
> > Scheme doesn't have pointers in the same sense that Java doesn't have
> > pointers: in both Scheme and Java all non-primitive types are
> > represented using pointers. So while it's true that the languages
> > don't have pointers, you still have to understand that you are always
> > dealing with reference types.
>
> True but I'd rather keep pointers seperate from shared state.
> There are other languages such as k that do pass compound
> objects by value. Thus in k
>
> x:1 2 3 4
> f:{[v]v[1]:5} // similar to (define (f v) (vector-set! v 1 5))
> f x
>
> does *not* modify x. [It does this by using copy-on-write]
Immutability also makes the abstraction less leaky; If you never mutate
(and ignore nils) then the difference between:
struct { int x; Foo y }
and:
struct { int x; Foo *y }
May have performance implications, but is ultimately an implementation
detail. A compiler could even attempt to optimize based on e.g. the size
of Foo.
--
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] In go, are there any naming conventions?
>For example, for packages, variables, constants, functions, struct, >project names, labels, methods and interfaces. https://golang.org/doc/effective_go.html#names That whole document is also worth a read. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] go assembly question
If you pass `-M intel` to objdump it will display intel syntax. Quoting robert engels (2018-12-14 16:41:39) >but the operands are backwards according to MOVQ on Intel, it >should be >dst,src >SO, I'm thinking "intermediate code", so different syntax. Fine, but >then when I use objdump or otool, the assembly still looks backwards, >but matches the above. >Is this because LLVM is also "backwards" ? It's not about intermediate code, Intel just uses different syntax than both the Go and GNU assemblers, which are descendants (in tradition, if not actual code) of the old AT assemblers. The AT syntax uses src,dst. >It there anyway to get objdump or otool to output intel assembly that >matches their documentation ? You can pass objdump `-M intel`. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Pure functions and Go2
Quoting Bakul Shah (2018-12-14 16:11:51)
> > If a function was labeled as pure ("pure func ...") the compiler
> > would not even need think hard, and if purity were a reflectable
> > attribute, then it is imaginable that compiling a function
> > invocation could be:
>
> This would complicate the language unnecessarily in the name
> of optimization. Next on the slipper slope would be declaring
> parameters "pure" and then having two versions of things. e.g.
>
> func intReduce(func(x, y int)int, []int) int
>
> This can be evaluated at compile time if the given func is pure.
> Not worth it, IMHO.
A lot of this can also probably be inferred by the compiler, and then be
just part of the optimizer that isn't exposed to users. Functions only
composed of pure operations are pure, and when a compiler spots this it
can tag the function with some metadata, so it can tell when looking at
a function at a call site whether it is pure.
-Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] tools for testing transport over flakey networks
Quoting robert engels (2018-12-11 19:39:46) > I am not sure you can do this at the application layer - you need kernel > support to drop packets. One could write a mock implementation of e.g. net.Conn that does this kind of simulation; have a goroutine that calls time.Sleep at random intervals in the most basic case. If you want to test UDP, randomly drop packets, reorder, etc. Could get fancier. No external support required. That was the kind of thing I interpreted Dan's question to be asking about. I don't know off-hand of a good library that already does this though. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Generics
It would be easier to help if you gave us a more concrete picture of what you're trying to achieve; if there were a nice drop-in alternative to generics in all circumstances already in the language, we probably wouldn't be talking about adding them in the first place :P. Quoting Tharaneedharan Vilwanathan (2018-12-10 22:00:24) >Hi All, >I have a quick question. >What is the best choice for writing generic code till Go officially >supports generics? Just looking for some guidance. >Regards >dharani > >-- >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 [1]golang-nuts+unsubscr...@googlegroups.com. >For more options, visit [2]https://groups.google.com/d/optout. > > Verweise > >1. mailto:golang-nuts+unsubscr...@googlegroups.com >2. 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
Quoting robert engels (2018-12-02 01:55:17) > added to Go, but I am not sure if the package has a few related types > (which it should IMO) it is any better than > > import . “package” This also exposes stand-alone functions, constants etc. which doesn't come up in Java. I think the stutter really is specific to packages that have a "primary" type, and then it's generally just the one type name around which it occurs. In Elm we tend to do exposing (TheType) and leave everything else qualified. -- 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
Quoting robert engels (2018-12-02 01:43:45) > import * + type inference + dynamic language = hell Can't have type inference without types, so it's just the dynamic bit, but I basically agree -- combined with the fact that you can do nonsense black magic with the import machinery at runtime in Python, it makes it that much worse; you can't even necessarily rely on your tools for figuring out where things are coming from. But the code isn't actually much more readable at a glance when people do it in Haskell; it is at least not *that* hard to track down an identifier due to there being a strong, static type system, but it is in my experience still universally easier to read code when there aren't wildcard imports. I will grant that probably having neither of these things makes wildcard imports less of a problem. But again, it seems like wildcard imports aren't the norm in Java anyway? -- 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
Based on your explanation, my original understanding of the semantics were correct. This: > import java.util.Collections; ..is not a dot import -- a dot import makes visible every (exported) identifier in the package. This just exposes the one identifier -- Collections. I don't have a problem with that. The equivalent in Java to what I'm complaining about is .*, and it seems like (from my skimming) it isn't what people reach for most. (Note that methods are still qualified by classes, because they're methods). Go does not have an equivalent of: import foo.bar.Baz; // java from foo.bar import Baz // Python import Foo.Bar exposing (Baz) // Elm It might be nice if it did; it would be occasionally useful to import single identifiers (e.g. Context from context). -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Package Stutter
Quoting robert engels (2018-12-02 00:59:31)
>Granted, their package structure seems poor in my opinion, but you
>can't talk bad about k8s.
Of course you don't lose anything by getting rid of the package names if
the package structure doesn't make any sense in the first place.
>And probably the most common method signature of them all:
>
> http.HandleFunc("/bar", func(w http.ResponseWriter, r *http.Request) {
>
>are you losing anything if this is:
> http.HandleFunc("/bar", func(w ResponseWriter, r *Request) {
No, and I would go further (if Go permitted it):
http.HandleFunc("/bar", func(w, r) {
...
})
http.HandleFunc is so well known that having the types there at all is
just noise. But I know you don't like type inference.
>All coding requires good development choices - there are many times it
>probably shouldn't be used - but I making a blanket statement its bad
>seems like overreach.
It's bad enough that common Python linters will flag it, and a lot of
large python projects do ban it outright.
Note that nobody in Python land complains about:
from foo import bar, baz
..the equivalent of which is what I've seen in what Java code I have
looked at. Rather, the suspect construct is:
from foo import *
--
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
Quoting Robert Engels (2018-12-02 00:19:40) > I know everyone hates it when I reference java but it has had dot > importsat the package level since day one. I won’t repeat why that > matters. It’s never been a problem. > > I don’t think I ever heard someone complain it was a problem in > working in Java, why is it such a problem in Go? I'll admit to not having much experience with large Java projects, so hard for me to say why this would be in Java. But from browsing through the source of a handful of open source Java projects, my first guess is: nobody uses them. It seems the norm is to just import each class you want to use individually; I don't see much .* This is why it works out in Elm -- because people don't use it much. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Package Stutter
Quoting Robert Engels (2018-12-01 22:25:06) > The way to fix it though it just to use dot imports, and encourage it! > The only time dot imports don't work is when there isn't package > stutter. Seems like a no brainer and you get the best of both worlds. My experience in every language I've worked with that has an equivalent of dot imports has been: this is more trouble than it's worth. It hurts readability of large codebases more than any other single language feature I can think of, and this has been my experience in everything from Python to Haskell. It is sometimes nice for DSLs -- Elm has an Html module that just defines a function per html element, and folks usually "dot import" that whole module. But they basically never "dot import" *anything* else, and doing it in the general case is similarly discouraged. In languages where I've seen *common* use of it, I've come to the conclusion that it basically doesn't scale beyond one package, which has to be something that everyone in the language community knows well. In Elm it's Html. In Go it's the set of built-in identifiers. That's all we get. --- There really is something special about a package's "main" type here (when it has one) that makes the stutter a bit hard to work around sometimes. It's a bit unfortunate to have to write context.Context, but nothing *else* in the context package has this problem. Much of the OCaml community has gone with the convention of just calling the type 't' and using the module name to distinguish, and it works pretty well. In Elm you see a lot of this: import Json.Decoder exposing (Decoder) ..which imports the Decoder type from that module unqualified, and leaves the rest qualified. I find it a bit unfortunate that the stuttery approach to naming primary times has ended up being the norm in Go, but I do think idiom is worth something; doing pkg.T is a little surprising to me when reading Go code, even though it isn't when reading OCaml. >People say, it makes things less clear, and I counter that variable >inference is far worse and it's done for the sake of less verbosity, >and people love it... I don't think we're going to agree on this point any time soon, so I'll just say: this does not square with my own experience. -- 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] [ANN] fixed point math library
Quoting Bakul Shah (2018-11-29 22:13:45)
> I doubt go2 will get generics flexible enough for this!
It can actually already pull much of this off, and you don't even need the
contracts part of the draft. E.g:
// Type 'Money' represents a monetary value. The Currency type parameter
// is unused at runtime, but serves to prevent mixing up different
// currencies:
type Money(type Currency) int64
// These types used as the parameter for 'Money'. They are never used as
// values, just as part of this trick with the type system -- because of
// this you'll sometimes hear them referred to as "phantom types".
type USD struct{}
type EUR struct{}
type GBP struct{}
// ...
var m1 Money(USD) = 5
var m2 Money(USD) = 10
var m3 Money(EUR) = 2
m1 + m2 // ok
m2 + m3 // type error: Money(USD) vs. Money(EUR)
-Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] [ANN] fixed point math library
I believe Jan is talking about bits in the information-theoretic sense. I.e, asking "how much do I know?", not "how much space does this take up?" Quoting robert engels (2018-11-29 17:10:51) >Would you elaborate? I've read the discussion multiple times, and can't >see what other bits you think he is referring to. > >On Nov 29, 2018, at 3:07 PM, Jan Mercl <[1]0xj...@gmail.com> wrote: > >On Thu, Nov 29, 2018 at 10:02 PM robert engels ><[2]reng...@ix.netcom.com> wrote: >> I'm pretty sure that is not correct, see >[3]https://www.maximumcompression.com >> >> Most lossless text compression is > 85 %, and if you use lossy >compression (images, audio) it can be 100:1 >Dan was talking about quite different bits. >-- > >-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 [4]golang-nuts+unsubscr...@googlegroups.com. >For more options, visit [5]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 [6]golang-nuts+unsubscr...@googlegroups.com. >For more options, visit [7]https://groups.google.com/d/optout. > > Verweise > >1. mailto:0xj...@gmail.com >2. mailto:reng...@ix.netcom.com >3. https://www.maximumcompression.com/ >4. mailto:golang-nuts+unsubscr...@googlegroups.com >5. https://groups.google.com/d/optout >6. mailto:golang-nuts+unsubscr...@googlegroups.com >7. 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] contracts thought experiment: dimension checks
Quoting Marko Ristin-Kaufmann (2018-11-27 10:29:15)
> if you could call template hacks really dependent types...
You really couldn't, they're entirely different beasts.
>I expect most applications to need wider family of behavioral contracts
>-- and I doubt that Go would ever support them natively lest there's a
>decision to sacrifice simplicity for modeling correct programs. At the
>company I work at we are currently pretty happy with run-time
>enforcement of the contracts and I'm not even sure whether a static
>checker would be a huge benefit.
Sure, for some things capturing the invariant statically is cumbersome
enough that you get more millage out of `if(...) { panic(...) }`, and it
seems like these contracts are basically syntactic sugar over that --
which is fine. My comments were in the context that Dan had originally
asked about static mechanisms.
>Having something like Optional type would be probably the most
>important contribution to the correctness to prevent nil pointer errors
>(and make writing a static checker easier), but I suppose that would be
>possible with any sort of generic types in Go2.
The problem with doing this in Go: What is the zero value of a
non-optional pointer? (If I were doing a clean-slate Go, I'd probably
leave zero-values out, but I'm not).
--
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] contracts thought experiment: dimension checks
Odd that the paper you chose to link to is one specifically addressing a difficulty integrating the ideas with Java's class hierarchies -- while the broader subject may be relevant to Go, I don't think that paper is. Wrt Dan's question of doing static checks, I'll quote the paper: > In principle, one could try to prove the correctness of behavioral > contracts. For example, the Extended Static Checking group at > Digital has developed verification tools for Java and Modula 3 [3]. > In general, however, the languages used to express behavioral con- > tracts are rich enough that it is not possible to verify statically > that the contracts are never violated. So it's not talking about a compile-time mechanism. To make Tamas's idea work you'd need to (a) have numbers encoded in the type system somehow, and (b) actually be able to relate them to the size of the arrays. You can do this with dependent types, but integrating those into a practical programming language is still a very open research topic. You can hack around this in some circumstances; there are tricks you can play to represent numbers at the type level in a somewhat limited, clumsy way. But most of the trickery I've seen relies on one feature or another that Go doesn't have, and the result is always somewhat cumbersome. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: is it possible to speed up type assertion?
Quoting roger peppe (2018-11-25 12:01:08)
>On Sun, 25 Nov 2018 at 16:54, 'Axel Wagner' via golang-nuts
><[1]golang-nuts@googlegroups.com> wrote:
>
>I'd suggest simply
>func (b *Binlog) writeArgumentToOutput(writer writer, arg uint64) error
>{ /* do the writing */ }
>and doing the actual conversions at the call-site. It's type-safe,
>shorter, faster and more idiomatic - with the tiny downside of a
>`uint64()` here and there.
>Alternatively, use reflect as it's intended to - something like
>func� writeArgumentToOutput(writer writer, arg interface{}) error {
>� � rv := reflect.ValueOf(arg)
>� � var v uint64
>� � if k := rv.Kind(); k >= reflect.Int && k < reflect.Uint {
>
>I know constants are protected by the Go compatibility guarantee, doing
>range comparisons on reflect.Kind constants seems a bit dubious to me.
>Without going to the definitions, it's not clear to the reader which
>exact kinds are included here. I'd suggest enumerating all the expected
>kinds directly in a switch statement (the compiler may well optimize to
>a range comparison for that anyway).
I agree; had to stare at this a bit. Something like:
switch rv.Kind() {
case reflect.Int, reflect.Int8, reflect.Int16, reflect.Int32, reflect.Int64:
v = uint64(rv.Int())
case reflect.Uint, reflect.Uint8, reflect.Uint16, reflect.Uint32,
reflect.Uint64:
v = rv.Uint()
default:
return fmt.Errorf("Unsupported type: %T\n", reflect.TypeOf(arg))
}
Only slightly more verbose, but much easier to understand. But ultimate
Axel's first instinct is I think the right one -- just do the cast at
the call site.
--
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] Syntax highlighting (again) [WAS go language sensitive editor?]
Quoting robert engels (2018-11-25 01:39:30) > You kind of made my point, when you state “it’s either a slice or a > map”… Well, what if the resource needed to be ordered, which is why the > previous method has List in its name, but the method was actually > returning a map. If the authors of meta.ExtractList made this design mistake, why would we expect them not to have done the same thing when declaring a wrapper type? e.g. type List map[string]Resource I'll point again to this snipped from my last email: > > if I'm not already familiar with the APIs involved (which I'm not), > > changing it to e.g: > > > >var objList ResourceList > >objList, err := ... > > > > Does not give me any additional insight. > Yes, someone should of caught that in the code review for the > extractList method, but if someone didn’t, the error is being compounded > here, with no obvious way to detect that during a code review… If I find myself forgetting/misunderstanding bits of an API that I have control over when reviewing places where it's used, I should go fix the API. There is simply no substitute for this. Optimizing for the case where you're already building on a house of cards is a fools errand. This really reads like a case of "new feature is scary, let's put caution tape all over it" that you see people making the case for any time anyone adds a new feature to a language. I think this is more about what you're used to than what actually makes for readable code. -- 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] Syntax highlighting (again) [WAS go language sensitive editor?]
Quoting robert engels (2018-11-25 00:15:21)
> Contrast that with this actual code from the leading Go application (picked
> at random):
>
> func (p *pruner) prune(namespace string, mapping *meta.RESTMapping,
> includeUninitialized bool) error {
> objList, err := p.dynamicClient.Resource(mapping.Resource).
> Namespace(namespace).
> List(metav1.ListOptions{
> LabelSelector:p.labelSelector,
> FieldSelector:p.fieldSelector,
> IncludeUninitialized: includeUninitialized,
> })
> if err != nil {
> return err
> }
>
> objs, err := meta.ExtractList(objList)
> if err != nil {
> return err
> }
>
> for _, obj := range objs {
> metadata, err := meta.Accessor(obj)
> if err != nil {
> return err
> }
>
> You have no way to understand what objList is without going to the source/doc
> of the method, and then it might even be an interface… (hopefully a well
> designed one)
>
> [...]
>
> A “senior developer” should look at this code and say, “wait the result is
> an objList, so it’s a List? Slice?
Having no idea where it's from and without looking anything up:
It's some sequence of objects. Given that ExtractList returns an error
it's probably being streamed from somewhere, though it's possible it's
already in memory and that error is a validation thing. ExtractList is
giving us back either a slice or a map, since we're seeing it used with
range below.
So I don't know what the concrete type of objList is, so what? The
intent of it being some kind of sequence (probably a stream of stuff being
fetched from a REST API) is entirely clear without that information. And
if I'm not already familiar with the APIs involved (which I'm not),
changing it to e.g:
var objList ResourceList
objList, err := ...
Does not give me any additional insight.
> Not to mention that there is not a single comment line describing what a 50+
> line method should do - with a generic name like prune()… maybe with an
> overview of the purpose, the lack of internal documentation might be passable.
The opacity of the code snippet above has more to do with this than it
does the absence of a completely uninformative type annotation. Type
inference is not the problem here. As a reviewer on a patch that added
this method, my approach here would be: skim the thing, make sure the
basic intent seems sane, mention any obvious problems, and ask the
submitter to write some comments, pick more helpful variable names,
then ping me and I'll do another pass.
> And as an aside, any “noise removed” in this case, is certainly added back by
> the “if err != nil” noise, instead of proper exceptions. This is a classic
> case that leads to... “well we don’t really code review, if the test cases
> pass, it must be good”. Don’t want to be the next guy….
In this case the errors actually make a it a bit more clear what's going
on -- if there were no errors we'd assume a completely in-memory
operation where stuff can't fail.
Adding something like the check keyword from the draft design would be
the best of both worlds.
> I know its a balance, and this is a “private” method, so there is leeway
> there, but I think not having declared variables in the code hurts
> maintainability - the only thing being worse are the dynamic languages where
> all hell breaks loose…
Somewhat pedantic, but given the mention of dynamic languages, perhaps
relevant: there *is* a variable declaration -- it just doesn't include
the type. No worrying about where the variable comes from in the first
place.
> Reviewing Go code almost requires an IDE that pops the
> documentation/signatures up as you move over the code.
I find that sort of thing incredibly distracting. I've been using vim
with Go since the beginning; it's never been an issue for me (but then
I've never been much of an IDE user in general).
--
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] Syntax highlighting (again) [WAS go language sensitive editor?]
Quoting robert engels (2018-11-24 17:34:34) > Agreed, but that is why I have a big problem with variable inference as used > in Go (and now Java 9 with var). > > You need to refer to the callee API doc in order to gain understanding of the > code - as the type information is not readily available. Even though there > are less characters, so people claim - easier to read - the loss of > information when dealing with non-common methods is a huge loss in > readability/understanding IMO. Having spent a lot bit of time working in languages which don't require writing as many types, either because they can infer them (like Go, or to a much greater extent ML-family languages), or because they just don't have them (Python), I've found well-designed APIs make the absence of this information at the call site not much of a problem. Designing for the call site is a good idea in any language. What that entails may vary based on the details of the language itself. It always at least involves good names; errors.New is pretty self explanatory. This: var err error = errors.New(...) ..is just noise. > I find myself continually reviewing the documentation when reviewing > Go code - much more so than Java - with external frameworks, etc. If I'm doing code review and I have a hard time understanding it, I usually ask the author to fix the code. If you have control over the callee API it can take the form of improving that, so that the call site is clearer. Sometimes a simple comment will help. Sometimes that means just putting the type annotation there even though you don't have to. This is common in ML family languages, where type annotations are never actually required *anywhere*. All language features are abusable. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Syntax highlighting (again) [WAS go language sensitive editor?]
Quoting robert engels (2018-11-24 17:06:29) > I would argue that good code reads in a linear manner - if it doesn’t > it is a problem with the programmer or the language syntax/grammer. I think this is true on a small scale, but... > On Nov 24, 2018, at 3:28 PM, Dan Kortschak > wrote: > > An interesting point here is that natural language writing like > > reference manuals actually do often include things similar to syntax > > highlighting where key points are bolded, underlined or italicised in a > > manner broader than is common in prose. When looking at a larger codebase, I am typically interested in specific aspects of the code, because I'm trying to either do or understand a particular thing. I'll likely read a function definition start to finish, but not typically a whole file. At the level of packages it's not clear what the start and finish even are, but I'll usually only read part of it. The reference manual analogy actually goes really deep here I think. If a large codebase must be read start to finish, it's probably a sign that there's too little encapsulation -- good code should let you understand it without having to think about more than a few things at a time. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] 3 important things that go should do first
Quoting 'yinbingjun' via golang-nuts (2018-11-19 22:23:35)
> First go should support generic types.
There's ongoing discussion of this in the context of Go 2; see:
https://blog.golang.org/go2draft
Which also links to the full draft designs, as well as feedback pages
(with *lots* of feedback).
> And I recommend go support python’s decorator. It is very useful in
> programming.
I've found Go's anonymous functions cover basically everything you'd
actually want decorators for; This makes sense because python's
decorator syntax is just syntactic sugar, i.e.
@mydecorator
def myfun():
...
Is the same as:
def myfun():
...
myfun = mydecorator(myfun)
This is somewhat useful since Python's lambda is limited to a single
expression, but Go does not have this restriction, so you'd probably
just do:
myfun := mydecorator(func() {
...
})
-Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: Force pointer at compile time to interface{} parameter
Quoting Robert Engels (2018-11-19 15:13:53) > But isn’t that just for safety. Meaning the unmarshall could use it as a > pointer via reflection and mutate it (but that is probably not what the > caller expects in Go) ? No, see: https://play.golang.org/p/MyF0Dx87-1j If you pass in instead and insert the appropriate call to value.Elem(), it works. -- 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: Force pointer at compile time to interface{} parameter
>From an implementation standpoint they are passed by reference (The
representation is actually a pair (pointer to vtable, pointer to
object), but from a semantic standpoint the difference still matters,
because e.g. if the original value was a struct, it still can't be
mutated. There are use cases for what Volker is asking about in the
standard library, even:
package json // import "encoding/json"
func Unmarshal(data []byte, v interface{}) error
Unmarshal parses the JSON-encoded data and stores the result in the value
pointed to by v. If v is nil or not a pointer, Unmarshal returns an
InvalidUnmarshalError.
...
Quoting Robert Engels (2018-11-19 09:57:12)
>Aren't all interface references passed as a pointer? It is a var that
>contains a pointer to the struct and a concrete type of the struct?
>
>On Nov 19, 2018, at 8:45 AM, Volker Dobler
><[1]dr.volker.dob...@gmail.com> wrote:
>
>> Is there a way to force "SomeFunction" to take pointers only at
>compile time?
>No, sorry.
>V.
>
>--
>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 [2]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [3]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 [4]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [5]https://groups.google.com/d/optout.
>
> Verweise
>
>1. mailto:dr.volker.dob...@gmail.com
>2. mailto:golang-nuts+unsubscr...@googlegroups.com
>3. https://groups.google.com/d/optout
>4. mailto:golang-nuts+unsubscr...@googlegroups.com
>5. 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] Generics: an unwelcome conclusion and a proposal
Quoting Steven Wiley (2018-11-05 22:12:40) >And let's face it. Templates, operator overloading, and talk of >generics has swirled around golang since its inception. Separating the >template/generic/operational overload step from the core language via a >pre-compile step� is one way to get the ball rolling. Risks? Yes, >bifurcation of the language I guess, but on the other hand the core of >go remains pure. Thoughts anyone? +1 for gaining some experience to move the discussion forward. The approach you suggest closely mirrors this: https://github.com/albrow/fo ..which was brought up in another thread. --- As an aside, C++ templates and generics as specified in the draft (and most other designs that have been floated) are really entirely different beasts; Emily Maier wrote a post (linked from the feedback wiki) that picks this apart: https://emilymaier.net/words/getting-specific-about-generics/ -- 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: Large (binary or text) File transfers over rpc
https://grpc.io/docs/tutorials/basic/go.html#server-side-streaming-rpc Quoting Ricky (2018-11-05 18:02:38) >how do I make grpc return a stream? are you referring to google rpc >grpc library that is recommended by Golang folks to be used instead of >net/rpc lib which is a frozen package? Interesting ... I didn't know >they had streams > >On Sun, Nov 4, 2018 at 12:20 PM Ian Denhardt <[1]i...@zenhack.net> >wrote: > > What is the functionality that you're not seeing re: how to do file > downloads over net/rpc? > The thing that pops to my mind as likely important is the ability to > stream data, which you indeed cannot do with net/rpc. > If you need that I might suggest using a different rpc system that > has > the expressivity you need. e.g. with grpc you could have a method > that > returns a stream. Cap'n Proto is capable of capturing this kind of > thing > as well. > Quoting Ricky (2018-11-04 14:22:11) > >� � I am sorry I wasn't very forthcoming in the beginning - to > clarify - by > >� � rpc I meant using go net/rpc package. Where I can simply > Register > >� � methods/services that can be called remotely as if they were > >� � functions/methods locally available. This lends to a cleaner > syntax and > >� � more robust code in general from which I have built very > clean > >� � distributed systems in past. > >� � I do not use net/rpc currently - instead I have a worker > running a tcp > >� � server which understands handshakes (control flow) and I > currently move > >� � files using io copy. All this because I only have access to a > single > >� � TCP port on machine where the worker agent is hosted. The > worker is a > >� � tcp server that does io.Copy to give file to calling�� > master. > >� � This flow is a bit crummy in my opinion, there's many chances > of errors > >� � being missed perhaps, I have to do timeout handling, acking > etc which > >� � net/rpc automatically takes care off plus go rpc package > provides many > >� � primitives which I have used in past to just do all of this > kind of > >� � control flow Master calling workers to do a work a but if > work a fails > >� � or errors out, the system has a cleaner way of tracking and > telling me > >� � (via error and replies) - I wanted to use that kind of robust > ness. > >� � I suspect this kind of thing cannot be done with via go > net/rpc > >� � package... but wanted to ask upfront also if I were to > use scp, > >� � sftp etc can I leverage this to be done with single port > (different > >� � port than usual scp sftp ports) - this port restriction is > due to > >� � security and many other reasons � > > > >� � On Sun, Nov 4, 2018 at 1:09 AM Amnon Baron Cohen > <[1][2]amno...@gmail.com> > >� � wrote: > > > >� � And don't forget the bit-torrent class of solutions. > >� � On Friday, 2 November 2018 16:56:17 UTC, Tom Mitchell wrote: > > > >� � Moving files is a solved, non trivial problem > >� � Have you looked at tools like scp (ssh), rsync, kermit, ftp, > sftp, tftp > >� � and network filesystems (nfs and samba)? > >� � Even git and http.�� Error recover, host name lookup, > compression, > >� � restart, safe abort, transport encryption, authentication, > buffering. > >� � > [2][3]https://en.wikipedia.org/wiki/Sorcerer%27s_Apprentice_Syndrome > >� � > [3][4]https://stackoverflow.com/questions/68335/how-to-copy-a-file-t > o-a-re > >� � mote-server-in-python-using-scp-or-ssh > > > >� � On Thu, Nov 1, 2018 at 11:24 PM Tamás Gulácsi > <[5]tgula...@gmail.com> > >� � wrote: > > > >� � 2018. november 2., péntek 6:21:47 UTC+1 id�pontban Anirudh > Vyas a > >� � következ�t �rta: > > > >� � Hello there -� > >� � I am looking for example/help for using rpc to do file > downloads - I am > >� � not sure if this is possible, or recommended or if there is a > >� � better/cleaner way. I like the robust nature of RPCs and have > written a > >� � few good, performant distributed systems in them -
Re: [go-nuts] Re: Large (binary or text) File transfers over rpc
What is the functionality that you're not seeing re: how to do file downloads over net/rpc? The thing that pops to my mind as likely important is the ability to stream data, which you indeed cannot do with net/rpc. If you need that I might suggest using a different rpc system that has the expressivity you need. e.g. with grpc you could have a method that returns a stream. Cap'n Proto is capable of capturing this kind of thing as well. Quoting Ricky (2018-11-04 14:22:11) >I am sorry I wasn't very forthcoming in the beginning - to clarify - by >rpc I meant using go net/rpc package. Where I can simply Register >methods/services that can be called remotely as if they were >functions/methods locally available. This lends to a cleaner syntax and >more robust code in general from which I have built very clean >distributed systems in past. >I do not use net/rpc currently - instead I have a worker running a tcp >server which understands handshakes (control flow) and I currently move >files using io copy. All this because I only have access to a single >TCP port on machine where the worker agent is hosted. The worker is a >tcp server that does io.Copy to give file to calling� master. >This flow is a bit crummy in my opinion, there's many chances of errors >being missed perhaps, I have to do timeout handling, acking etc which >net/rpc automatically takes care off plus go rpc package provides many >primitives which I have used in past to just do all of this kind of >control flow Master calling workers to do a work a but if work a fails >or errors out, the system has a cleaner way of tracking and telling me >(via error and replies) - I wanted to use that kind of robust ness. >I suspect this kind of thing cannot be done with via go net/rpc >package... but wanted to ask upfront also if I were to use scp, >sftp etc can I leverage this to be done with single port (different >port than usual scp sftp ports) - this port restriction is due to >security and many other reasons � > >On Sun, Nov 4, 2018 at 1:09 AM Amnon Baron Cohen <[1]amno...@gmail.com> >wrote: > >And don't forget the bit-torrent class of solutions. >On Friday, 2 November 2018 16:56:17 UTC, Tom Mitchell wrote: > >Moving files is a solved, non trivial problem >Have you looked at tools like scp (ssh), rsync, kermit, ftp, sftp, tftp >and network filesystems (nfs and samba)? >Even git and http.� Error recover, host name lookup, compression, >restart, safe abort, transport encryption, authentication, buffering. >[2]https://en.wikipedia.org/wiki/Sorcerer%27s_Apprentice_Syndrome >[3]https://stackoverflow.com/questions/68335/how-to-copy-a-file-to-a-re >mote-server-in-python-using-scp-or-ssh > >On Thu, Nov 1, 2018 at 11:24 PM Tamás Gulácsi >wrote: > >2018. november 2., péntek 6:21:47 UTC+1 id�pontban Anirudh Vyas a >következ�t �rta: > >Hello there -� >I am looking for example/help for using rpc to do file downloads - I am >not sure if this is possible, or recommended or if there is a >better/cleaner way. I like the robust nature of RPCs and have written a >few good, performant distributed systems in them - was hoping/wondering >if I could use RPC to do downloads - I currently use combination of >io.Copy and a TCP server to do this. > >What kind of RPC ? RPC is just "Remote Procedure Call". >If s `send(data []byte)` won't be enough (size restrictions), you can >copy the io interfaces: >CreateFile(name, perms...) (fileHandle) >WriteFile(fileHandle, chunk) >CloseFile(fileHandle) > > -- > 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 [4]https://groups.google.com/d/optout. > > -- > >� � T o m � � M i t c h e l l > > -- > 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 [5]golang-nuts+unsubscr...@googlegroups.com. > For more options, visit [6]https://groups.google.com/d/optout. > >-- > >Vyas, Anirudh >Computer Science and Math Autodidact >E-Mail: [7]ricky...@gmail.com >Mobile: � (US): 650-727-2636 > >-- >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 [8]golang-nuts+unsubscr...@googlegroups.com. >For more options, visit [9]https://groups.google.com/d/optout. > > Verweise > >1. mailto:amno...@gmail.com >2. https://en.wikipedia.org/wiki/Sorcerer%27s_Apprentice_Syndrome >3.
Re: [go-nuts] Generics: an unwelcome conclusion and a proposal
Quoting Andy Balholm (2018-11-03 16:40:39) > But if a mis-matched type was passed to Less, it would need to panic. > So this option (using the Self type) would somewhat reduce > compile-time type safety. This is why I left `self` out of my own proposal; while I agree it would be more ergonomic, it wasn't immediately obvious what to do about this. I think doing a run-time check is more of a footgun than is justified by what is gained. >From a type-theoretic perspective, it's not hard to actually enforce the `self` constraint statically, even in the case where the code is really using an interface value, not just a type parameter whose bounds are specified by an interface. But from a user's perspective it gets weird, because then if you have: var s []Lesser = ... You can't actually do s[i].Less(s[i+1]), because their 'self' types might not be the same. I don't like exposing this fairly general mechanism for one ergonomic improvement, esp. if we don't have any deeper use cases for actually being able to say `self` -- it seems like we'd be trading a decent chunk of cognitive overhead for a couple keystrokes. You could potentially do more compelling things with methods that return `self`, since then you can actually get more than one value of the `self` type. But my own inclination is to keep things simple. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Code generated by generics draft
>Ah, I see. the albrow/fo package is the equivalent of just pasting the >entire function into the contract. It's not actually -- the rules seem to be those of the draft design, with the contracts mechanism simply omitted. So e.g. there's no way to write a max function; see: https://play.folang.org/p/WdSHO8EpBu9 (which does not compile). -- 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] Code generated by generics draft
It looks like it will treat it as generic type definition only if T is not defined elsewhere: https://play.folang.org/p/lN2b6QfgH38 * Commenting out const Size = ... -- results in an error about a missing type parameter * Deleting the Size constant and declaring a function named Size -- results in an error about the array size not being a constant. I can't say I'm a fan of this behavior; right now you can parse Go without knowing what variables are in scope. I'll have to play with this some more though -- I've been at the point where I don't feel like I have much more insight to gain just from discussing hypothetical generics in Go, so being able to play with them is very useful. Quoting Mandolyte (2018-11-01 14:12:25) >I didn't encounter this when I experimented with the package ([1]here). >So not sure. However, as an array, T cannot be a variable, it must be a >constant... so perhaps it can be figured out - >see� https://play.golang.org/ >On Thursday, November 1, 2018 at 11:54:31 AM UTC-4, Ian Denhardt wrote: > > Quoting Mandolyte (2018-11-01 06:30:30) > > - it uses square brackets instead of (type .. ) for the type > parameters > What does it do with `type Foo [T] int`? The draft design cites this > ambiguity (is it a generic type with an unused parameter, or an > array of > length T?) as the reason for not using square brackets. > (Note that Alan Fox proposed elsewhere using [type T] to declare > type > parameters as a solution, but it doesn't appear that Fo is doing > this). > >-- >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 [2]golang-nuts+unsubscr...@googlegroups.com. >For more options, visit [3]https://groups.google.com/d/optout. > > Verweise > >1. https://github.com/albrow/fo >2. mailto:golang-nuts+unsubscr...@googlegroups.com >3. 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] Code generated by generics draft
Quoting Mandolyte (2018-11-01 06:30:30) > - it uses square brackets instead of (type .. ) for the type parameters What does it do with `type Foo [T] int`? The draft design cites this ambiguity (is it a generic type with an unused parameter, or an array of length T?) as the reason for not using square brackets. (Note that Alan Fox proposed elsewhere using [type T] to declare type parameters as a solution, but it doesn't appear that Fo is doing this). -- 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] Static assert at compile time
It's a little unclear to me what exactly you're trying to check; giving an example might make it easier to advise. But in any case, Go doesn't have anything quite like static_assert in C/C++. Depending on what you're trying to do, you could put a call to panic in an init() function, which would at least catch the error on program start. Quoting hay (2018-10-27 18:07:08) >Hi, >I've a project and it needs static asserts at compile time to check if >string values are not left empty by the programmer. Is this possible in >golang? >Thanks in advance > >-- >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 [1]golang-nuts+unsubscr...@googlegroups.com. >For more options, visit [2]https://groups.google.com/d/optout. > > Verweise > >1. mailto:golang-nuts+unsubscr...@googlegroups.com >2. 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: Go 2 Proposal Comments
Quoting robert engels (2018-10-26 23:31:46) >OK, you got me, I'm sucked in - it was a nice balance of yes, BUT no. > >First, there is simply no debate, Java += Android, and you have the >most successful language/platform ever. NO debate. >Arguing against Java's write-once, run anywhere implementation is a bad >position to take. Yes, if you write a "swing" app, it doesn't run on >Android (at least not easily), but that is not what the promise of >WORA. Any system that has an "exec command" cannot make that guarantee. > In the "real world" the promise was delivered on - at least in >comparison to any competing technology. C may be the "most portable" >language ever, but I can write GUI applications in C that have zero >chance of running on multiple OSes. The position is simply invalid. >Arguing against Java in terms of "generics are done poorly", I'll leave you and Pat to debate this; I don't care all that much. > and citing a third-party FAQ is absurd. This is a fair complaint. The linked FAQ seems rather verbose for its content. > The "core" Java tutorial on generics is a 3-4 pages, Which tutorial are you talking about? The tutorial on Orcale's website is decidedly longer than that: https://docs.oracle.com/javase/tutorial/java/generics/index.html >Claiming students have a problem is akin to saying, "my child was great >at finger paints, but is having a real hard time with differential >equations. Differential equations must be broken". >Are there rare edge cases in Java generics, yes. Do they come into play >in any sort of real-world frequency, no. The problem was not "students have a hard time understanding the concept" so much as "students come to me to ask for help debugging code that is throwing this weird specialized exception that they've never heard of. It's something that should always have been a compile time error, and *not* fixing it makes the language more complex. (It also hurts perf to do the runtime check). NullPointerException is pretty easy to understand too -- that doesn't make it not a source of bugs. >The statement, "Happily, Go doesn't have sub-typing in the first >place", shows the bias. I don't think Go needs sub-typing either - but >I wouldn't use Go in many places I would use Java where sub-typing is a >huge benefit. If you wish to debate the value of OO, please start with >someone other than me, because I will just say, I've done it a lot of >ways, and good OO where it applies is better than any of the >alternatives. Others may have more nuanced opinions. This wasn't meant to be a criticism of subtyping; I was just making the point that we have an easier problem to deal with, because we don't have to worry about interactions between the two. >And not to pick, but "type erasure makes runtime checks not work", is >blatantly false. I hope you meant to say "compile time checks", but >still, in the real-world, it is not an issue. This was in reference to the fact that in Java you can't e.g: * Have arrays of a parametrized type (e.g. Foo[]) -- the runtime check that throws the ArrayStoreException can't work without having the type information available at runtime. * Have exceptions with type parameters -- the dispatching of exceptions is on the type, so this doesn't work if you erase the types at compile time. IIRC there were a few other examples in there. >I think this might be an ivory tower issue. It doesn't seem pure to >some, so it must be bad. This is some combination of ad hominem and straw man. >I'll end with an anecdote from the construction industry. >When laying a deck, you can try to be very accurate and cut all of the >boards to the same length, or you install them, and use a straight edge >to cut off the ends to exact same length. Real world vs. academia. No >experienced carpenter would do it the first way. ..and yet you seem to be the one advocating never fixing things once they're in the field? -- 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: Go 2 Proposal Comments
Quoting Pat Farrell (2018-10-26 21:30:47)
>This leads to my second issue with the OP's ideas. I strongly believe
>that Java has been damaged by its attempt to deliver backward
>compatability. While others have brought up the potential issues with
>keywords, a much more telling disaster was Java's implementation of
>generics. It was done in a language compatable way, but there result
>was design choices and restrictions that make it nearly impossible to
>use Java generics "properly". Lest you think I exaggerate, look at
>Exhibit 1, the FAQ on how to actually use it is huge. It has hundreds
>of edge cases. See
>FAQ.� http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html
>If the implementation had decided to not require backwards
>compatibility, they might have been able to design generics such that
>there is no need for thousands of special case rules that are
>Frequently Asked.
Definitely worth nothing: there *pages* in that FAQ that could have been
cut if they'd just removed covariant array subtyping, to be consistent
with the rules for generics and (more importantly) actually sound.
For anyone who doesn't know what I'm talking about:
class Main {
public void main(String[] args) }
String[] strArray = new String[4];
// Arrays are references, so this points to the same
// memory:
Object[] objArray = strArray;
// Whoops, now there's an integer in your array of
// strings!
objArray[0] = new Integer(80);
}
}
This type-checks. It throws an ArrayStoreException at runtime. I do not
miss explaining ArrayStoreException to students.
It also seems like 25% of the FAQ amounts to "type erasure makes runtime
checks not work."
I don't know of any mistake in Go 1 that's quite as egregious while
being and quite as easily fixed -- but I agree we should keep our eyes
out for designs that are becoming far more complicated for the sake of
backwards compatibility.
---
It is also worth observing that the Java developers were attacking a
much harder problem in adding generics to Java that we are trying to add
them to Go -- subtyping and parametricity have very subtle interactions,
and finding satisfactory ways to mix them has been the subject of a lot
of type-theory research over the past few decades. Prior to the past
couple of years, I would have just advised someone designing a new
language to punt on one feature or the other entirely. I might still,
but there have been a few developments of late that that are
encouraging. Good luck bolting them on to an existing design though.
Happily, Go doesn't have subtyping in the first place.
(there are a few minor things that look like subtyping at first glance,
but I suspect they don't present a problem. It's hard to not be
a bit handwavy here since the language spec is not mathematically
precise wrt the type system).
--
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] New keywords and backwards compatibility
Hey all, Today I've seen a lot of messages re: concerns about adding new keywords and breaking backwards compatibility. People have floated a couple approaches to avoiding breakage. But I feel like all of them that I've seen so far will make code confusing. I'd like to propose an alternative, which doesn't perfectly preserve backwards compatibility, but: 1. Allows go 1 and go 2 to be mixed, provided they're in different source files, and 2. Has a clear and trivial upgrade path that can be automated, and can also be done incrementally in a non-disruptive fashion. Here's the idea: the first Go release that includes the new keywords introduces a new specially-recognized comment, something like // go:keywords 2 This comment can be used to control which version of the language source file is interpreted as. So to opt into the new features, a source can add that comment to a source file. At the top. Other source files will continue to treat the new keywords as identifiers. Note that since the keywords are all lower-case, this won't cause problems with interoperability at the API level; any Go 1 package that currently uses one of these keywords as an identifier only does so privately, so Go 2 code can still import those packages and not run into problems with not being able to specify a name in the package. When we finally release "Go 2.0," the only backwards-incompatible change we make is that that the default is to use the new keywords, and we add another specially-recognized comment: // go:keywords 1 which causes the keywords to be treated as identifiers, as in Go 1. We could also add a flag to go build, so that users wanting to build an old Go 1 codebase can just run: go build -go1 And everything will just work. Updating to the new version is easy and can be done incrementally: just rename any variables that collide with the keyword. Thoughts? -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Failed iterator proposals?
Quoting robert engels (2018-10-22 16:01:18) > I am sure it has been discussed, but why the aversion to using < > in > type declarations? I guess I just don’t understand using bracketing > notations that are already used for something else. This was mentioned in the draft design, but using `<` at the call site means the parser would require infinite lookahead (see the draft design for details). There is also an ambiguity objection raised in the draft for using square brackets, but Alan Fox offered a solution, which I used in my example. I don't personally have anything against angle brackets in principle though. -- 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] Proposed changes to the Go draft generics design in the light of feedback received
Quoting alan.f...@gmail.com (2018-10-20 16:59:52)
>I haven't checked them all but I did notice one example which your
>paper doesn't appear to cover, namely the add1K example which has been
>a stumbling block for a lot of proposals including my own though I did
>eventually find a way of dealing with it.
This is a fair point. I have a couple of initial thoughts, but will
think about it. The contract there actually brings up my other big
complaint about contracts besides non-orthogonality; they are not a good
expression of intent. For reference:
contract add1K(x T) {
x = 1000
x + x
}
While it's possible to piece together what has to be true about a type
to satisfy this contract, it's really not obvious at the outset what the
point of it is. Looking at the contracts in the draft design, I feel
like I would generally speaking have to jump through mental hoops to
understand what concepts were being expressed by a given contract.
>1. If interfaces were used, a way would need to be devised to express
>that a type supports a particular operator or operators. To be
>compatible with methods something like the following seems best:
>� � � +(T, T) T
>However, this would mean that someone writing an interface to be used
>for generic constraint purposes would have to know and write out the
>signature for each operator used.
This seems like a relatively minor problem. Eric sketched out a possible
syntax, here is another:
type Ordered[type T] interface {
operator < (other T) bool
}
func (MyType) operator < (other T) bool { ... }
(where `operator` becomes a keyword)
I'm not convinced having to remember the type signatures is a
problem -- for most operators they are fairly self-evident, and we
already have to do this for a wide range of interfaces in the standard
library. I think adding a whole new concept to the language is a much
bigger cognitive load.
>2. As your own paper clearly shows, it is possible to deal with
>multiple type parameters which refer to each other using an interface
>based approach and even the draft design paper itself admits this is
>possible. However, it seems to me to be less elegant than a contract
>based approach.
>An interface can only express the methods which a single type needs to
>satisfy and so a separate interface is needed for each mutually
>referential type parameter. A contract on the other hand doesn't have
>this constraint and, indeed, the type parameters as a group have to
>satisfy a single contract which, to my mind, ties the whole thing
>together in a much nicer way.
I actually have a fairly clear design in my head for adding associated
types to interfaces, which my current design generalizes to cleanly, but
I left it out because I'm not convinced that this kind of thing is
common enough to be worth optimizing for. My gut is that this kind of
contract will be the exception, rather than the rule, and I would err on
the side of leaving things out. I think it will be common enough that
we'll want it to be *doable*, but I'm not convinced being a little
more concise is worth adding conceptual complexity.
>3. Interfaces don't deal with fields at all and so would need to be
>extended to cope with a struct constraint. To be fair, some people have
>questioned whether such constraints are important enough to be catered
>for at all but the draft design does nevertheless deal with them and so
>does my own paper.
There's an issue on Github that Ian T ha referred to in several threads
re: adding fields to interfaces, which has been rejected. I think
the arguments against it all also apply to using contracts to do the
same thing (see also my complaints about expressing intent) I'm not
convinced that the fact that contracts can express this is a good thing.
>4. There are a number of minor (though tricky) issues which interfaces
>can't currently deal with but contracts can and which I listed in my
>paper. To take one in particular - excluded types - it is difficult to
>see how interfaces could deal with something like that though, as it's
>a novel idea anyway, perhaps some other way could be found to achieve
>the same result.
Are there other use cases for this besides the numeric range issue? If
not I think this falls into the same bucket as the add1k example, and I
will have to think about it.
>5. Finally - and you might think this is a bit silly - but there are a
>lot of people who don't like the idea of generics at all and will
>probably try to avoid them if they can. Now, hopefully they will change
>their minds when they see how convenient generics can be to use.
>Nevertheless, I still think it's important to cater for such people and
>leaving interfaces as they are and confining the generic stuff to
>contracts should help here.
My proposal doesn't really change interfaces
Re: [go-nuts] Avoiding overloading
Quoting Andy Balholm (2018-10-20 17:34:15) > It’s just one of probably dozens of types of operations that people > will want generic types to be able to support, besides method calls and > operators. Adding support for them wouldn’t be very hard either, but by > the time you got done, the result might be about as complicated as > contracts. I am not convinced. My proposal goes through *every* example in the examples section at the end of the draft. Throughout all of the discussions on this list I have seen very few, if any, compelling uses that contracts can handle but operator overloading + interfaces can't (I can't think of one). It's also not just a question of complexity per se -- it's also that contracts have too much overlap with interfaces (which are not going away). I also don't think they provide a very good way of expressing intent. Even so, as I mentioned above, the interfaces + operator overloading route covers basically everything I've seen. And it's still simpler. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Avoiding overloading
Quoting Andy Balholm (2018-10-20 13:30:58)
> There are some contracts in the draft design that can’t be expressed with the
> “implements” syntax as it stands. Some would be fairly simple syntax
> extensions, but others describe the relationship between two types rather
> than just the operations on a single type. No extension of interfaces (except
> perhaps generic interfaces with mutually-referential type parameters) can
> handle those.
>
> The one called convertible is an example of one that would require a fairly
> trivial extension: adding a way to declare that a method implements a type
> conversion.
>
> For an example of the other kind, take G from the graph example. I don’t
> think any of the alternate proposals can handle that situation (at least not
> nearly as succinctly):
>
> contract G(n Node, e Edge) {
> var _ []Edge = n.Edges()
> var from, to Node = e.Nodes()
> }
The graph example is addressed in the context of my proposal here:
https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d#mutually-referential-type-parameters
Granted, it is slightly more verbose -- but I do not think that the
extra concision for this *one* example in the draft is worth introducing
an entirely new non-orthogonal concept.
The convertible example does not seem especially well motivated to me.
FormatUnsigned is defined like this:
func FormatUnsigned(type T convertible(uint64, T))(v T) string {
return strconv.FormatUint(uint64(v), 10)
}
And then used like:
s := FormatUnsigned(rune)('a')
But why not:
func FormatUnsigned(v uint64) string {
return strconv.FormatUint(v, 10)
}
// ...
s := FormatUnsigned(uint64('a'))
I'm quite willing to discard convertible without a more compelling
example.
> Even if we give up on the ability to define relationships between types,
> adding extensions for all the other operations that people will want support
> for will likely take away much of the initial simplicity that makes the
> “implements” syntax attractive—one trivial extension at a time. The
> “contract” proposal, on the other hand, is actually a simple, powerful idea;
> it's working out the implications that ties people’s brains in knots.
Eric has said this elsewhere, but his suggestion (and operator
overloading generally) is not a complete solution (nor is it
intended to be). However, it complements my own proposal (see
above) in a way that allows it to abstract over operators as well as
operators. I haven't seen any *compelling* use cases that can be dealt
with using contracts, but not interfaces + operator overloading.
--
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] Regarding contracts
Quoting robert engels (2018-10-20 12:15:52)
>To be clear, this is only for that "performance case", where I don't
>want LinkedList to allocate internal nodes to hold the elements but the
>reasoning applies when using a simple LinkedList, and I want it to hold
>MyObj (which is not a Node, so the LinkedList needs to create Node
>instances).
Aha, we're talking about intrusive data structures. That makes sense.
I agree it's a bit awkward to have to write:
type HasNode interface {
GetNode() *Node
}
But you could do it and it solves the problem. It's been pointed out
elsewhere that this would also be solved by allowing interfaces to
specify fields:
type HasNode interface {
Node *Node
}
Ian T points out that there is an issue about this, which was rejected:
https://github.com/golang/go/issues/23796
I think most the arguments there apply to the current proposal as well.
It seems like it might have more utility in the presence of generics
though, as it would actually be possible to write the linked list once.
My inclination is still to just punt on the field thing; I don't like
that it encourages specifying implementation rather than behavior, and
it is still possible to write intrusive data structures without it.
-Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Regarding contracts
Quoting Burak Serdar (2018-10-19 17:01:42)
> On Fri, Oct 19, 2018 at 1:09 PM Ian Denhardt wrote:
> >
> > Quoting Burak Serdar (2018-10-19 14:09:46)
> >
> > > It is useful in a linked list. You can instantiate a linked list
> > > template in a package, and use that concrete type in another package
> > > without access to the internals of the linked list.
> >
> > Can you provide an example of what some code using this would look like?
> > The discussion in the abstract just isn't sticking to my brain...
>
>
> I've been thinking about this for the last couple of hours, and I
> have to admit, I got really close to giving up. Maybe a linked
> list is not the best example to illustrate this. Anyway
>
> You would normally implement a linked list like this using parameterized
> types:
>
> package linkedlist
>
> type Node(type T) struct {
> next *Node(T)
> Stuff T
> }
>
> type LinkedList(type T) struct {
> head *Node(T)
> }
>
> func (l *LinkedList(T)) Add(n *Node(T)) {
> n.next=nil
> if l.head==nil {
> l.head=n
> } else {
> l.head.next=n
> }
> }
>
> func (l LinkedList(T)) Itr(f func(*Node(T))) {
> for node:=l.head;node!=nil;node=node.next {
> f(node)
> }
> }
>
>
> Then use this as:
>
> var myList linkedlist.LinkedList(int)
>
>
> However, using the "like" keyword, the following should also
> be possible, which I think is more interesting than the above. I
> needed something like this more than once during my Java days:
>
> (this is different from the linkedlist I had earlier in the thread)
>
> package linkedlist
>
> // Define Node as a template that should satisfy the given struct contract
> type Node like struct {
> next *Node
> }
>
> // LinkedList is a parameterized type, it will use nodes that look like a Node
> type LinkedList(type T like(Node)) struct {
> head *T
> }
>
> // Do we need LinkedList(T)? Maybe not..
> func (l *LinkedList) Add(n *Node) {
> n.next=nil
> if l.head==nil {
> l.head=n
> } else {
> l.head.next=n
> }
> }
>
> func (l LinkedList) Itr(f func(n *Node)) {
> for node:=l.head;node!=nil;node=node.next {
> f(node)
> }
> }
>
> package mypkg
>
> type MyNode linkedList.Node {
> next *MyNode
> Stuff DataType
> }
>
> func f() {
> var myList linkedlist.LinkedList(MyNode)
>
> myList.Add({})
> }
>
>
> Let me know if this makes sense. There is still a lot that needs
> to be figured out, and I wouldn't be surprised if the idea
> collapses completely.
I'm still not seeing what this is actually buying you? The two examples
seem pretty equivalent to me.
--
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] Proposed changes to the Go draft generics design in the light of feedback received
Quoting alan.f...@gmail.com (2018-10-19 16:19:36) >Ian D, >The introduction is certainly not intended to be insulting to those who >have put serious thought into the problem. If it were, then I'd be >insulting myself as I've put serious thought into at least two other >proposals which are nothing like the current one! I apologize if I've interpreted things less charitably that I should have. >It's simply a realization I've come to that there's a lot of mileage in >the original draft which is the culmination of what two very smart >people have been working on for years and should not therefore be >dismissed too readily. I certainly agree with this. My own proposal left type parameters basically untouched, though I have specific criticisms I and many others have made elsewhere regarding contracts. The original draft was indeed *very* thorough, and provided many useful motivating examples that act as some tests for alternatives. The discarded ideas section also provides a justification for each. (This makes it very easy to see that your own square brackets suggestion handles the original objection to this idea, which brings it back into the realm of discussion). On to more technical issues. --- Your post mentions: > However, the problem is that contracts can do a lot more things than > interfaces currently can and it is not easy to extend the latter to > meet this shortfall. My own proposal addressed every single example in the examples section of the draft design, as well as the graph example. Can you describe what you think is missing? It's been linked before, but for reference: https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d (You mention that the graph example is "awkward" to express. This is a bit subjective, but the thing I feel more strongly about is that a single slightly subtle encoding does not justify adding an entirely new non-orthogonal construct to the language). > Stepping back a little, is it really such a big deal to have two > functions for anything involving operators - one for the relevant > built-ins and another for user-defined types which satisfy an equivalent > interface? I talked about this in my original proposal, which left out operator overloading, curious to your thoughts: https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d#operators -- 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] Avoiding overloading
Quoting Eric S. Raymond (2018-10-19 16:15:25)
> Ian Denhardt :
> > What would code making use of a `Sortable` type look like? If you can't
> > actually use "implements <" to overload `<`, it's not clear to me what
> > it would actually do?
>
> Be available to a Sort function. That is, the requirement "Have a Less()"
> would be replaced by "Have an implements-< method".
>
> How this is specified at the callsite is a separate question. I can't
> see any simpler way to do it than writing '<', but if anyone hates
> overloading enough to invent a syntax they can do it ab nd
> I won't complain.
>
> I'm saying I'd prefer that future to heavyweight contracts. Surface
> overloading is *not* the important thing about "implements"; having a
> lightweight way to refer to typeclasses like "Sortable" is.
Ah, so are you just suggesting you'd be able to do (e.g.):
func SortSlice(type T implements <)(slice []T) {
// ...
}
..but not actually be able to redefine `<` for a user-defined 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.
Re: [go-nuts] Regarding contracts
Quoting Burak Serdar (2018-10-19 15:13:20)
> Without operator overloading:
>
> type X interface {
>implements <
> }
>
> means that you want a primitive numeric type or a string. So:
This is not quite quite correct; in Eric's proposal, it is possible to
define (for example):
```
// A Version represents a semver-style version number
type Version struct {
Major, Minor, Micro int
}
// We define a custom definition of `<` that checks which version is
// older.
func (v Version) Less(other Version) bool implements < {
switch {
case v.Major < other.Major:
return true
case v.Major > other.Major:
return false
case v.Minor < other.Minor:
return true
case v.Minor > other.Minor:
return false
default:
return v.Micro < other.Micro
}
}
```
..and then use `<` to compare Versions. By contrast, your proposal does
not make it possible to define custom notions of `<` on user defined
types.
> Another thing that motivated me to start this thread in the first
> place was imagining myself sitting late at night trying to figure out
> how to convert a huge chunk of code to a generic type, and reading
> through to figure out exactly what the contract is. With the "like"
> syntax, I could simply add "like X" to my arguments, and be done with
> it. With interfaces containing "implements", I have to write those
> interfaces and figure out exactly what I need.
With interfaces using implements, you can start off just specifying no
constraints on your generic parameters, and then follow the type errors
until you've added all of the necessary methods.
While pinning down exactly what the contract needs to be is a bit of
extra up-front work, I think it is important to keep these contracts
clear; one of my biggest concerns with the draft design is that I do not
believe it encourages thinking about intent.
> With contracts, I imagine someone would come up with a tool to build
> that from the source if it comes to that.
This could also be built for the interface version; just see what
methods are called and put them in an interface that the parameter must
implement.
Quoting Eric S. Raymond (2018-10-19 16:03:02)
> Both classes want to be selected by a field "name". It's annoying that
> I can't declare an interface that says "has a field 'name'" and instead
> have to declare a getter function with no other point besides sliding
> around that restriction.
>
> But precisely because this could easily be patched into interfaces,
> I think it's not much of an argument for your plan.
To spell out how this would for anyone who doesn't immediately see the
design, you could e.g. extend interfaces to be able to have fields like
so:
type HasName interface {
Name string
}
To implement this, a type would have to have a field Name with the type
string.
I am neutral-to-against doing this, as normally when abstracting over
something, it is a behavior, not a field. But if being able to specify
"must have this field," is deemed necessary, I agree this is the way to
do it.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Avoiding overloading
Quoting Eric Raymond (2018-10-19 14:43:51) >Therefore, as the author of the "implements" proposal, I am declaring >neutrality on whether an "implements" clause should declare an overload >at all! >That is, there is a possible future in which "implements <" on type T� >does not� make a < b legal on non-primitive type T, but is solely a >typeclass declaration associating� T with all other types that >implement <; semantically, a Sortable contract. What would code making use of a `Sortable` type look like? If you can't actually use "implements <" to overload `<`, it's not clear to me what it would actually do? -- 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] Proposed changes to the Go draft generics design in the light of feedback received
First, I find the introduction to this condescending; it amounts to "the Go developers know what they're doing, stop questioning them plebians!" It is phrased more politely, but the content is basically there. This is: 1. Insulting to those of us who also have put serious thought into the problem, and perhaps also have knowledge and experience in this area of programming language design. 2. Largely missing the point of the draft designs, which were meant as a starting point for discussion; the Go developers were explicitly soliciting feedback. 3. Ignores the fact that most of us have been raising specific critiques of the design. While our criticisms are based on substance, you dismiss them entirely without providing a justification other than "Ian and Robert know what they're doing." Second, I agree with Tristan that Eric's sibling comment is a bit sharp; let's be careful to keep this civil, as it's clear that some of us are feeling a bit tense. Ultimately however I agree with Eric that the proposal focuses on relatively superficial issues. That said I do like the idea of using [type T]; while my own focus has been on semantics, like many I agree the existing syntax is not very ergonomic. Quoting alanfo (2018-10-19 13:48:20) >My head has been spinning lately after reading the various generic >counter-proposals and suddenly the original draft design seems a lot >more attractive than it did :) >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. >It's not too long so give it a read and see what you think. >Here's the link: >[1]https://gist.github.com/alanfo/72f07362d687f625a958bde1808e0c87 >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 [2]golang-nuts+unsubscr...@googlegroups.com. >For more options, visit [3]https://groups.google.com/d/optout. > > Verweise > >1. https://gist.github.com/alanfo/72f07362d687f625a958bde1808e0c87 >2. mailto:golang-nuts+unsubscr...@googlegroups.com >3. 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] Regarding contracts
Quoting Burak Serdar (2018-10-19 14:09:46) > It is useful in a linked list. You can instantiate a linked list > template in a package, and use that concrete type in another package > without access to the internals of the linked list. Can you provide an example of what some code using this would look like? The discussion in the abstract just isn't sticking to my brain... -- 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] Regarding contracts
Quoting Burak Serdar (2018-10-19 12:46:19) > Where can I read about this "implements"? Link? This is the thread: https://groups.google.com/forum/#!search/go-nuts/golang-nuts/pR5pmql5olM/RPDuL2BsCAAJ -- 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] Regarding contracts
Quoting Burak Serdar (2018-10-19 12:34:44)
> Re: Ian Denhardt's proposal:
>
> I agree that it handles all the cases in the official proposal,
> but I think the syntax is too verbose and reminds me of
> Java. For instance, the "sorting" example can be written using
> the "like" keyword as:
>
> Template:
>
> type orderedSlice []like (int,string)
>
> func (s orderedSlice) Len() int { return len(s) }
> func (s orderedSlice) Less(i, j int) bool { return s[i] func (s orderedSlice) Swap(i, j int) { s[i], s[j] = s[j], s[i] }
>
> // There is no need for an OrderedSlice function
>
> Concerete use:
>
> type mySlice orderedSlice []int64
>
> v:=mySlice{1,2,3}
> sort.Slice(v)
This example in my proposal was intended to show the minimal change
needed from the draft design, but I also mentioned that you actually
didn't need `orderedSlice` at all to sort slices. If you combine it
with Eric's proposal for operator overloading, you can just write
v := []int64{1,2,3}
sort.Slice(v)
..with no boilerplate type/method definitions, or casts, at all.
> However, one limitation of using interfaces to specify contracts
> is that you can't use a struct type as a basis for your
> contract. For instance, going back to the linked list example:
>
> type Node like struct {
>next *Node
> }
>
> With interfaces as contracts, this becomes:
>
> type Node(type E) interface {
>GetNext()
>SetNext(*Node(E))
> }
This is true; exposing the next-pointer structure of a linked list
through an interface is more verbose. However I'm not convinced there
are good uses for this; Can you provide an example where such a template
would actually be useful?
--
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] Regarding contracts
Quoting robert engels (2018-10-18 15:22:36)
> Can you explain this a bit more, I must be missing something. Using the
> example:
>
> func F(a,b type T like(int,X)) {
> if a ...
> }
> }
>
> How do you pass a struct to F because < isn’t valid on structs ???
>
> Which is why I proposed that < maps to Less() and then the primitives
> simplicity implement these various methods, and user defined structs MIGHT.
>
> That way you write the code using Less(), and it works with primitives as
> well.
This is what I was getting at; simply making the operators correspond to
methods is a well-known and fairly straightforward solution to the
problem, and it seems like the idea proposed in this thread is much more
complex.
Once you allow operators to simply correspond to methods, you can just
worry about how to abstract over methods, which you can do with
interfaces. My proposal outlines a variant of this that is fairly
simple, yet (once adding something like operator overloading) is still
able to handle every single example in the draft.
You can either give the primitive types methods, or allow methods to
override operators; both approaches work.
Burak, apologies if I've misinterpreted your own line of thinking.
-Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Regarding contracts
Quoting Andy Balholm (2018-10-18 14:00:52) > That would also be a weakness of most of the other proposals, > including my own to add operators to interfaces. Contracts are more > powerful, at the expense of extra complexity. Fwiw, my own proposal for "just using interfaces" covered the graph use case. The code doesn't look far off from what Burak sketched in a sibling comment, but does have some key differences that I think are important to bridge the gap: https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d#mutually-referential-type-parameters I think adding operators to that proposal actually covers every use case covered by the draft design. I left them out originally because of a snafu with the == operator, but ESR has offered a way around that. --- I feel like Burak's proposal is falling into the same trap as many others: there is a common feeling that operator overloading is a Pandora's box, so folks are trying to work around it by solving the problem without providing operator overloading. But *the problem itself* is not being able to abstract over operators, so this approach is doomed to failure. You just result in a clumsy design that can't decide if it's trying to allow operators to be abstracted over or not, since the whole point is to allow this, but the particulars of the design are motivated by a fear of actually doing so. I there is a fundamental conflict here. You can express the same concepts as with operator overloading if you're willing to wrap the basic types and use methods like .Less() in generic code. But I think fundamentally folks have to make choice: do we want to be able to write `<` for user defined types, or do we want to be able to look at the `<` operator and know for certain that it's not calling a method? You can't have both. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics
I don't think you even need contracts as such at this point; you can do
a cast without them, so you just need to be able to specify a method set
on type parameters. I would be interested to hear your thoughts on the
proposal I wrote up on how to do this:
https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d
what you're suggesting below lands in a similar spot, though the change
in rules around casting makes it a big more ergonomic. But my version
doesn't introduce a separate contract construct at all; it just uses
interfaces to specify bounds.
When I wrote that I described the lack of being able to deal with
operators as "unsatisfying," but outlined that you could do something
similar to what you describe, and said I preferred that to introducing a
non-orthogonal construct to the language.
Part of why I left out operators was because of the issue with == that I
mentioned earlier, though ESR has offered a possible solution.
-Ian
Quoting roger peppe (2018-10-17 12:43:44)
>While thinking about the draft generics proposal and the complexity of
>contracts, it occured to me that if you relax some of the restrictions
>on type conversion, it's possible to make data structures containing
>basic types amenable to generic algorithms.
>Once upon a time, the Go specification [1]allowed conversion between
>any two values with with same underlying types. You could, for example,
>convert from []int to []time.Month. This� [2]was changed� after [3]some
>discussion.
>As a thought experiment, suppose that rule change was reverted and
>generics were implemented similarly to the draft proposal, but with
>contracts that allowed type conversions only, and no other operators.
>That allows the possibility of "retro-fitting" methods to data
>structures containing basic data types.
>For example, given this generic interface definition:
>� � type Adder(type T) interface {
>� � � � Add(t T) T
>� � }
>and a generic Sum function:
>� � contract Adder(t T) {
>� � � � Adder(T)(t)
>� � }
>� � func Sum(type T Adder)(xs []T) T {
>� � � � var sum T
>� � � � for _, x := range xs {
>� � � � � � sum = sum.Add(x)
>� � � � }
>� � � � return sum
>� � }
>We can make Sum work on []int like this:
>� � type Int int
>� � func (i Int) Add(j Int) Int {
>� � � � return i� + j
>� � }
>� � func main() {
>� � � � ints := []int{3,5,6,7}
>� � � � sum := Sum([]Int(ints))
>� � � � fmt.Println(sum)
>� � }
>One could imagine a new package in the stdlib that provided method
>definitions for all the basic types, and potentially standard
>interfaces too. But there would be no need to define any of that in the
>language specification. The need for arbitrary operators in contracts
>goes away. All generic code can be used with custom types with custom
>behaviour for the operators, because all operations are expressed with
>methods. This provides a clean separation between generic operations
>(they always look like method calls, whether using interfaces or type
>parameters) and built-in operators. The method calls in question can be
>inlined because everything is known statically, so there's
>theoretically zero performance overhead.
>Generic functions that would previously have been able to use operators
>don't look as nice, of course, but maybe that's a price worth paying.
>Unfortunately this idea doesn't work very well because of a few
>reasons. Firstly. anything that is returned by a generic function still
>has the converted type. So the sum variable in main above has type Int,
>not int. Also, if one is converting to other types as a matter of
>course, one loses the type safety that comes with using different
>types.
>That said, maybe there's a glimmer of possibility here. You get a lot
>of potential for a very small language change, so I'm throwing out this
>idea in case someone has a good idea how to circumvent the
>above-mentioned problems.
>
>--
>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 [4]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [5]https://groups.google.com/d/optout.
>
> Verweise
>
>1.
> https://github.com/golang/go/blob/67d30bb696fd28477ec023926b0ead375cf8371e/doc/go_spec.html#L1238-L1242
>2.
> https://github.com/golang/go/commit/63f014910daab38faee6208de2cbdbc191985d8c
>3. https://github.com/golang/go/issues/809
>4. mailto:golang-nuts+unsubscr...@googlegroups.com
>5. https://groups.google.com/d/optout
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group
Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal
Quoting Patrick Smith (2018-10-16 19:21:35)
>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:
Right now there are some common conventions for "iterators" in go, that
if generics entered the language I would expect to end up being written
up and specified more explicitly; I could see some interface like:
type Iterator(type T) interface {
// Same idea as e.g. database/sql.Rows.Next
Next() bool
// Get the currently focused value.
Current() T
}
..and then:
sum := 0
for it.Next() {
sum += it.Current()
}
For slices, you'd end up writing something like:
it := IterSlice(s)
// ...
Where IterSlice returns an iterator for slices. While in general having
to wrap e.g. int, float in OrderedInt, OrderedFloat types sounds painful
to me, this doesn't seem too bad -- and it has a real advantage, as it
covers this use case while being a bit more generally applicable.
My instinct here is to be conservative; we've got a boatload of use
cases for < and ==, a few obvious ones for +, *, / etc, and a long-tail
for operators after that. Eric's proposal makes it trivial to add more
operators to the list of allowed ones, but it's always harder to go the
other way. So my inclination would be to implement this for operators
like `<` that are kinda screaming at us, and then build some experience
with 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.
Re: [go-nuts] Generics with adaptors
Quoting Patrick Smith (2018-10-16 18:32:48)
>The union function could verify that the two adaptors are the same,
>using the == operator, and panic if not. However, this breaks down if
>the adaptors, instead of being defined as struct{}, are defined as
>types which don't support ==.
This works, provided you use the interface approach in most of your
examples. It would be ideal to catch the error at compile time though.
>This could even be construed as a feature. The union function takes two
>sets, possibly with different adaptors, and merges their contents into
>a new set using an adaptor passed as a parameter to union, and which
>could be different from the adaptors for both input sets.
True, although for some cases you really do want to require both
arguments to have the same adaptor. In a persistent set or map based on
persistent trees[1], you can get asymptotic speedups on merge/union
if you can assume the adaptor is the same.
[1]: https://en.wikipedia.org/wiki/Persistent_data_structure#Trees
--
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] Generics with adaptors
Quoting Patrick Smith (2018-10-16 18:04:05) >One way to avoid this is to supply the adaptor when the Set is created, >store it in the Set, and thereafter used the stored adaptor instead of >requiring an adaptor parameter. This works for insert/member, but what about union, which takes two sets? You could still run into problems if the sets were initialized with different adaptors. -- 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] Generics: an unwelcome conclusion and a proposal
Quoting Eric Raymond (2018-10-16 17:28:11) >Fair enough. But is there any way to have a contract system of *any* >kind that doesn't have the identical problem?� Linked elsewhere in this thread, but I sketched something that I think does the trick: https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d As written it punts on operator overloading, but I think given the solution you've described re: ==, it can be updated to support it. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Generics: an unwelcome conclusion and a proposal
Quoting Eric Raymond (2018-10-16 16:37:01) > you either compile "a < b" using the "implements <" method of the > concrete type or throw an error. > This means that a change in the generic function, which happens to > introduce a new use of the parameter, can cause a failure at the > call > site, which may be far away. > > That doesn't seem to me to entail more risk than *any* change to the > generic function would. The trouble is that (in the case where you compile using the implements <, rather than throwing an error) the type signature no longer tells you what the constraints actually are; this information is only in the body of the function, so it's easy to accidentally change it when changing something that you think is just implementation detail. -- 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] Generics: an unwelcome conclusion and a proposal
Quoting Dave MacFarlane (2018-10-16 16:40:59) > (Also, does this mean the compiler wouldn't be able to make any > optimization assumptions regarding whether an operation is > commutative/associative/distributive?) This is true regardless, because we aren't actually *enforcing* these properties; they're just methods. So the compiler can't rely on them any more than it can rely on implementations of io.Writer following the rules written in English in thedocs. As I mentioned in my other message, we should have a clear agreement on what these operators should mean, but the compiler won't know about it. I agree with your other points. -- 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] Generics: an unwelcome conclusion and a proposal
Quoting Eric Raymond (2018-10-16 16:14:46)
>It's up to the programmer to implement things like commutativity.� I
>don't think the language should pre-specify whether < is a partial or
>total ordering.� Any choice of this kind the language makes will
>inevitably turn out wrong a significant percentage of the time.� For
>proper orthogonality we should not specify as much as we can about each
>operator, but as *little* as we can and still have readable code.
>I would say the contract for < is just "takes operands of the same
>unspecified type; returns a bool".
> The fact that this will usually be used to express an order for sorting,
> and that it is anticommutative, is none of the compiler's business.
> It's a convention that libraries will observe and programmers know
> about, but that's a different matter.
What I'm getting at is that we should come to an agreement re: what
these conventions should be. e.g, with io.Writer, the compiler just
knows about:
type Writer interface {
Write(p []byte) (n int, err error)
}
But the docs also say:
Writer is the interface that wraps the basic Write method.
Write writes len(p) bytes from p to the underlying data stream. It returns
the number of bytes written from p (0 <= n <= len(p)) and any error
encountered that caused the write to stop early. Write must return a non-nil
error if it returns n < len(p). Write must not modify the slice data, even
temporarily.
Implementations must not retain p.
My point is just that we need to have a blurb like this somewhere for
each operator we allow to be overloaded; I don't want to see `os.Stdout
<< "Hello, World!"`. And when considering which operators we should
allow to be overloaded, we should consider what the corresponding blurb
should say, and whether it describes something that actually makes sense
to overload.
Given that we'll want a concrete "meaning" for e.g. `<`, even if
only by convention, I don't see that there's any legitimate use for
overloading `>` separately; if `x < y != y > x`, then something is
wrong.
--
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] Generics: an unwelcome conclusion and a proposal
Quoting Ian Lance Taylor (2018-10-16 16:02:57) > On Tue, Oct 16, 2018 at 8:39 AM, Eric Raymond wrote: > > > > New rule: A function on variables of undefined formal-argument types > > compiles to a template (not a textual template - we don't want identifier > > capture). At each callsite of the function, the undefined types in the > > formals are bound to the types of the arguments in the call. If every > > operation in the resulting code is defined, the code compiles as if the > > generic function had been written with the actual argument types at the > > callsite. If not, the compiler throws an error on each undefined operation. What is this intended to buy us? Is this as Ian T suggests in lieu of any kind of contract system? Or is it just to reduce verbosity in type declarations? Or both? If it's the former I agree with Ian T's complaint that this makes the contract brittle. If it's the latter, we could just say that undefined formals have no constraints, and so any use of them that depends on something that not all types support is an error. I'm still not in love with this, as I expect obscure error messages when someone makes a typo, or accidentally being generic when you didn't mean to. I outlined a similar thing in another thread, where you use a lexical convention to distinguish type variables from concrete types, so you don't need an explicit parameter list. But this was in the context of someone having suggested just not supporting bounded type parameters at all, so the question of where you write the bounds didn't come up (and I still think bounds are important). I also still think we should just use interfaces; elsewhere in this thread I linked to my proposal about this, which when you add operator overloading using Eric's solution to the `==` semantics problem covers every concrete issue I've seen raised so far. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Generics: an unwelcome conclusion and a proposal
Quoting Eric Raymond (2018-10-16 15:57:49) >I don't undetstand rte q rte q? I assume this is a typo, but I'm not sure what it was supposed to be... -- 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] Generics: an unwelcome conclusion and a proposal
Quoting Eric Raymond (2018-10-16 13:41:47) >On Tuesday, October 16, 2018 at 1:23:20 PM UTC-4, Dave MacFarlane >wrote: > > [...] > > Would there be any rules defined for relationships between > operators? > For instance, if the "<" operator is defined does "<=" come for free > or does it require a separate overloading? (If so, what about ">"?) > >Good� heavens, no - < doesn't imply a definition of >.� That kind of >spooky side effect would be extremely un-Go-like. The alternative though is having to implement several different methods with obvious implementations in terms of one another, and make sure they're consistent. IMO this is worse than `x > y` desugaring to `y < x`, which at least you can't screw up. `==` is fiddly here, since you want to be able to define it without implementing `<`, but if you have `<` (and we assume it is a total order), it fully determines what `==` should do. >Besides, you don't want it. There are lots of uses for partial >orderings. The partial vs. total order thing brings up another issue that I think needs to be kept in mind: what are the contracts for the various operators? Right now we don't have to be too explicit about what +, *, <, == etc. mean in general, because we have a fixed finite number of them, so we don't have to have a general meaning. If we allow overloading e.g. `<`, we need to be clear on whether it's a partial or total order. I actually think we should require a total order, as all of the existing implementations are total orders (except floats, which violate every rule you might want to believe about numbers...), total orders are likely to be the norm, and I would expect a partial order to catch someone off guard. Most of the existing examples assume a total order. Similar issues come up with the arithmetic operators. For example, must `*` be commutative? If so, then matrix multiplication should not use `*`. Also, right now we have `+` defined on both numbers and strings. What does this operator mean in the general sense? The most specific things I can identify to say about it is that: 1. It is associative. 2. The zero value is an identity on both sides. This is called a Monoid in abstract algebra. It is far from useless; for example, it's exactly the structure you want for map-reduce (though that would be horribly inefficient on strings). But it's also super abstract, and I think not the sort of interface we should have on built-ins in Go. I think there are solutions to all of these things, but they require careful consideration. Importantly, we have to figure out where and how we're going to document these rules so that people actually see and understand them. It's not enough for us to have a thing buried in the spec that `*` should be commutative; the author of that matrix library has to see it. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Generics with adaptors
I write this kind of code a lot when working in Elm (whose generics are
in a similar spot to the place you suggest). It's not the worst, and
there various approaches in related languages use to make the "adaptors"
more ergonomic.
I still like the idea of using interfaces to express constraints better,
but I think it's worth discussing where this might go. Some
observations:
* We don't actually need an adaptor for the zero value, since we can
just declare a variable of the generic type:
func MyFn(type T) {
// x is the zero value, per usual initialization rules:
var x T
// ...
}
* If we don't have any kind of bounding on type variables, then we can
actually omit type parameter lists entirely, and use a lexical
convention to distinguish between concrete and generic types. OCaml
does this by denoting type parameters with a single quote, so 't is a
type variable while t is a concrete type. Borrowing that convention we
could write e.g:
func MapSlice(slice []'src, f func('src) 'dst) []'dst {
// ...
}
...which reduces verbosity a bit.
Haskell and Elm both use case to distinguish, with uppercase variable
names being concrete and lower case being type variables. I like that
a bit better, but Go already uses case to distinguish exported vs.
private.
* Your suggestion of default adaptors is similar to Scala's implicit
parameters: https://docs.scala-lang.org/tour/implicit-parameters.html
One problem with this design, which bounding solves: Suppose we have a
generic set type implemented using binary trees (I will use
the 't notation discussed above, but you could use explicit parameter
lists as well).
type Order('t) interface{
Less(x, y 't)
}
type Set('t) struct {
// ...
}
func (s Set('t)) Insert('t; Order('t))
func (s Set('t)) Member('t; Order('t)) bool
// etc.
What happens if we accidentally pass different adapters to different
calls to the methods? e.g:
type CaseSensitive struct {}
type CaseInensitive struct {}
func (CaseSensitive) Less(l, r string) bool
func (CaseInsensitive) Less(l, r string) bool
// ...
var set Set(string)
set.Insert("Apple"; CaseInensitive{})
set.Insert("Animal"; CaseInsensitive{})
set.Insert("acorn"; CaseInsensitive{})
// Returns false!
set.Member("acorn"; CaseSensitive{})
Depending on scoping issues and how you infer the adaptors, this could
happen by accident, because of different adaptors being visible in
different scopes.
This is a known problem with scala implicits, whereas with rust
traits/haskell type classes, we're able to guarantee that there is only
one instance of an "adaptor" for a given type. But this means giving up
on automatic interface satisfaction, which is... no.
There's a paper that you'll find if you google "ocaml modular implicits"
that solves this issue for OCaml using OCaml's module system, and while
I have some ideas about how we *could* extend Go with the necessary
functionality, it's a much bigger change to the language than adding
bounds based on interfaces.
Quoting Patrick Smith (2018-10-16 06:33:39)
>Yet another generics discussion
>at� [1]https://gist.github.com/pat42smith/ccf021193971f6de6fdb229d68215
>302
>This one looks at what programmers would be able to do if very basic
>generics were added to Go, without contracts. Generic functions may not
>use methods or operators of their type parameters.
>The answer is quite a lot, actually. The code would be verbose, but not
>impossibly so.
>
>--
>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 [2]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [3]https://groups.google.com/d/optout.
>
> Verweise
>
>1. https://gist.github.com/pat42smith/ccf021193971f6de6fdb229d68215302
>2. mailto:golang-nuts+unsubscr...@googlegroups.com
>3. 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] Generics: an unwelcome conclusion and a proposal
Quoting Ian Lance Taylor (2018-10-16 09:44:00) > It's not clear to me what other aspects of various generic proposals > you are picking up here. How are you imagining that we would write > the function that merges two channels? With the current design draft > that looks something like this: > > ... > > Also, how do you write the graph example from the design draft, which > uses two types? > > Ian Through this discussion I'd been mentally grafting Eric's operator solution to my own proposal, which uses interfaces instead of contracts and just punts on operators entirely (due to the fiddly issue I brought up re: pointers, which I hadn't come up with a solution for): https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d The graph example is the more interesting one, here's a direct link to that solution: https://gist.github.com/zenhack/ad508d08c72fce6df945a49945ad826d#mutually-referential-type-parameters The channel example is the same as in the current draft; it doesn't use contracts as-is, so is unaffected by either my own design or Eric's.20 I think Eric's solution is mostly orthogonal to what I discuss in the above design, but solves the most unsatisfying things. I may try to actually write up a version that incorporates it sometime next week. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Generics: an unwelcome conclusion and a proposal
Cute. I think we're better off without it though; the use cases I can
think of for "generic booleans" are all way too clever.
FWIW, the uses of "generic booleans" I've seen in the wild don't
actually work with your proposal, because they really do need to
overload `and` and `or`, not just `not`. But this is getting off into
the weeds.
Quoting Eric Raymond (2018-10-16 00:17:19)
>On Monday, October 15, 2018 at 11:32:23 PM UTC-4, Eric Raymond wrote:
>
>Fair enough.� I am completely willing to discard the possibility of
>overloading && and ||
>
>A little thought showed me that this is not required.
>The straightforward way to write the contract of "!" would be that it
>is a monadic function of any type returning true if the operand is the
>zero value of that type and false otherwise.� It follows that for
>types with "implements !" the expression a && b expands to this:
>if !!a {return !!a} else {return !!b}
>If we want to be more Pythonic and remove the requirement that it
>return bool
>if !!a {return a} else {return b}
>provided a and b are the same 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 [1]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [2]https://groups.google.com/d/optout.
>
> Verweise
>
>1. mailto:golang-nuts+unsubscr...@googlegroups.com
>2. 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] Generics: an unwelcome conclusion and a proposal
Quoting Eric Raymond (2018-10-15 23:32:22) >Fair enough. I am completely willing to discard the possibility of >overloading && and || and almost any other operator that doesn't behave >like a function, because I think we get a rich enough set of contracts >from those that do. As I implied in my proposal, I think what people >really want from contacts is relationals and some operator algebra. +1. == is the sticking point. > That is to forbid "implements" methods on pointer types at compile > time. The other bit of this, that I think is worth making explicit is that normally If you have a method on a type T, you can also call that method on a value of type *T. For this to work you'd also have to have == be an exception to that rule, where == on a type of the form *T is always pointer equality, regardless of what == means on T. I'm not in love with the inconsistency, and expect it to cause some confusion with newbies, but I'd have to use it to see how big of a footgun it is in practice. There are certainly worse ideas. > I can't think of a use case for such overloads that isn't overly clever > to the point of crazy. I am more than willing to chop that off to preserve > the simplicity and transparency of the cases where "implements" is legal. Agree, my only concern is as mentioned above. It's also worth noting that you can always wrap the pointer in a new type if you want to define operators on it. -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Generics: an unwelcome conclusion and a proposal
Quoting Eric Raymond (2018-10-15 22:24:50) >The simplest and most effective way to solve the generics problem is to >embrace operator overloading and the kind of magic method designations >that go with it. This matches my intuition as well, though see below. >Can it even possibly be simpler than this? What, if anything, am I >missing? There are a couple of things I could bikeshed, but instead I'll raise a deeper problem, which none of the operator-overloading designs I've seen (or thought of) have had an answer for, and I think *needs* to be solved for this to work: The semantics of `==` in Go cannot be understood as a method or function. In particular, there is a restriction in the go spec that says you can't implement methods with the same name on both T and *T. However, `==` is defined on pointers, and always computes pointer identity, whereas it may (almost certainly will) do something different on the type that the pointer points to. There are other operators in the language that don't behave like functions or methods (e.g. boolean operators like && and ||, which short-circut), but the rest of them are things that don't have gobs of use cases for overriding anyway, so it's easy to just say "you can't override those." I don't think we can credibly call operator overloading a solution if you can't abstract over ==. Breaking backwards compatibility opens up some options, but I still haven't been able to come up with a solution that has a credible upgrade path. I've mentioned this when it's come up in a couple of other threads, but not everybody reads every rabbit-hole conversation about generics... -Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Unifying the sort functions
Quoting alan.f...@gmail.com (2018-10-13 15:39:46) >Unfortunately, no approach is immune to silly mistakes by yours truly >but, as it's an area where "Effective Go" could offer some pointers, it >need not be unduly error prone in practice. Still, some approaches are more error prone than others. It's hard to make a compelling argument without data, but it seems like directly defining Less() would be easier to get right than having to come up with some encoding that preserves your intended notion of equality. >The problem with associating operators with named methods is that there >will be a lot of names for people to remember (or to list in the spec) I think you could take an approach where you only have one method per "category" of operators. So for example, rather than having separate methods for each of <, >, <=, and >=, you could just have: x < y desugars to x.Less(y) x > y desugars to y.Less(x) x >= y desugars to !x.Less(y) x <= y desugars to !y.Less(x) Similarly, for == and != you could just define a method `Equal`, and have: x == y desugars to x.Equal(y) x != y desugars to !x.Equal(y) There are some deeper problems with overloading == with a method, namely that right now == does different things for Foo and *Foo, which is not something that is generally possible for methods, but your proposal has the same problem. > and, given that the built-ins don't have methods, it is unclear > what mechanism could be used to achieve this association. My first thought is that we could just change the language such that built-in types *do* have methods. -- 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] Unifying the sort functions
Quoting alanfo (2018-10-13 13:26:18)
>Suppose we turn this strategy on its head and instead allow types which
>wouldn't otherwise do so support the ordering operators provided they
>satisfy a simple interface. This interface would have a single method
>which returned a string representation of an object of that type and
>the compiler would use this string to implement the ordering operators.
>which would enable us to do this:
>p1 := Person{"Donald", 1, 20}� � // stringifies as Donald180
>p2 := Person{"Donald", 2, 72}� � // stringifies as Donald128
>b := p1 < p2� // false because p2 is older and therefore sorts first
..but you end up with `Person{"Donald", 3, 101}` < Person{"Donald", 2,
72}` being true, because the 101-year-old overflows the two digit space
you've allocated.
You can make this work by padding out to enough digits to be able to
represent any `uint`, but this example suggests to me that the approach
is likely to be error-prone in practice. My other immediate reaction is
the efficiency concerns, which you bring up yourself.
What is the advantage of the OrderString() approach over e.g. just
having `x < y` desugar to `x.Less(y)` (if a method `Less` is defined on
the type of x)? It is not clear to me what you suggest buys us over
this.
>I apologize if it's already been
>suggested by someone else but I'm losing track of what has been
>suggested in this area.
..it's probably getting to be time to add some organization to the wiki
feedback page.
--
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: A concrete proposal re: using interfaces instead of contracts in Go 2 generics.
Quoting gary.willoug...@victoriaplumb.com (2018-10-11 10:38:38) >Add it to this: https://github.com/golang/go/wiki/Go2GenericsFeedback Already did (before posting to the list); it's at the top. -- 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: A concrete proposal re: using interfaces instead of contracts in Go 2 generics.
Quoting Dean B (2018-10-11 14:58:01)
> Yeah that's why I was about how operators were the primary reason
> interfaces couldn't work out. Your proposal doesn't include operators,
> which was the reason interfaces aren't used. Syntax in Go is pretty
> important, which I imagine is the reason that operators didn't work
> out.
As it stands, I don't really feel like the draft design's solution re:
operators is better than just punting on them. Much of this discussion
is already in my proposal, but:
You still have to either write different versions of your code for types
that support `<` and types that support `.Less()`, or only support one
of these.
Supporting the former means your code can only ever work with basic
types, and I don't feel like the meager extra expressiveness you get
is worth the complexity.
The extensible option is to only support the latter, and if you have
a function that expects something with a `.Less()` method, and you want
to pass it an int64, you define a wrapper type around the int64.
I would imagine in this scenario before long someone would write a
package with a standard set of wrappers around the basic types, covering
the boilerplate once and for all:
```
package ops
type Int64 int64
func (lhs int64) Less(rhs int64) bool {
return lhs < rhs
}
..
```
It probably makes sense in this case to just have part of the generics
design be to add methods to the basic types that are aliases for the
operators, so we can skip the above.
> I'm working on another proposal with a `self` type introduced which
> should be simple. The issue with a `self` type is that interfaces are
> comparable with every other comparable value, so it can't be used in
> that case... I'll figure something out haha.
I considered adding something like self, but my proposal is actually
able to cover the cases where you'd want self as is. Again, this is in
the proposal:
```
// The ordered interface is parametrized over another type. You could
// define a type A that implements Ordered(B), but see below.
type Ordered(type T) interface {
Less(other T) bool
}
// Sort is still able to constrain its parameter to only types which
// implemented Ordered *for themselves*, so it would not accept an A
// which implements Ordered(B). I believe this solves the problems
// that you would want 'self' for, without adding an extra construct.
func Sort(type T Ordered(T))(slice []T) {
// ...
}
```
--
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: A concrete proposal re: using interfaces instead of contracts in Go 2 generics.
Hmm, I suppose I imagined having read a deeper reason than syntax :/. That does seem like an incredibly shallow reason to introduce a whole new non-orthogonal concept (I see others have attempted to tackle the syntax issue, including yourself). There are actually deeper difficulties than syntax with using interfaces to capture the built-in operators, in that some of them have semantics that can't be captured as methods. One approach is to only use interfaces to describe "well-behaved" operators, leaving the rest as special constructs that can't be abstracted over, like today. But `==` falls into this category, since it works on both pointers and structs, and does different things -- whereas it is not generally possible for a method M to do different things for type T vs type *T. The design I sketched actually just punts on operators entirely, which I don't like but I think is better than where contracts put us (esp. since you still can't actually define alternative notions of `<` with contracts, just abstract over existing ones, so it doesn't even give you much extra expressive power)`. I'd like to find a good solution to the operator problem though. -- 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.
