[go-nuts] Re: Generics and parentheses

Proposals that employ the type keyword, look more Go-ish. Go is already doing many things differently than other PLs in C-ish family - the if without parentheses and no semicolon are two of things that hit most when switching frequently between Go and another PL. func SomeContext() { var

[go-nuts] Re: Golang Templates

https://github.com/ali2210/WizDwarf/blob/master/visualize.html On Wednesday, July 15, 2020 at 3:14:51 PM UTC+5, Ali Hassan wrote: > > > {{range .}} > {{if ne .Symbol " "}} >{{.Symbol}} > {{end}} >{{end}} > > > var div=document.getElementById('List'); > var point =

[go-nuts] Re: Golang Templates

yes it is https://github.com/ali2210/WizDwarf/blob/master/main.go [line: 150-158] On Wednesday, July 15, 2020 at 3:14:51 PM UTC+5, Ali Hassan wrote: > > > {{range .}} > {{if ne .Symbol " "}} >{{.Symbol}} > {{end}} >{{end}} > > > var

[go-nuts] Re: Golang Templates

Yes it is func Visualize(w http.ResponseWriter, r *http.Request){ temp := template.Must(template.ParseFiles("visualize.html")) if r.Method == "GET" { fmt.Println("Url:", r.URL.Path) fmt.Println("Method:" + r.Method) temp.Execute(w,LifeCode) } } On Wednesday, July 15, 2020 at 3:14:51 PM UTC+5,

[go-nuts] Re: Golang Templates

Yeah this is Javascript and Go https://github.com/ali2210/WizDwarf/blob/master/visualize.html https://github.com/ali2210/WizDwarf/blob/master/js/visual.js func Visualize(w http.ResponseWriter, r *http.Request){ temp := template.Must(template.ParseFiles("visualize.html")) if r.Method ==

Re: [go-nuts] Generics and parentheses

On Wed, 2020-07-15 at 18:09 -0700, lotus.developer.mas...@gmail.com wrote: > Personally think this way is easier to read. In this way, I wrote a > few examples, which may be different from the creator Please post in unstyled plain text. It is almost impossible to read the code examples you have

Re: [go-nuts] Generics and parentheses

Personally think this way is easier to read. In this way, I wrote a few examples, which may be different from the creator * For example: define a node type Node struct{ prev *Node data T //data *T next *Node } * Call request var node Node * Let's take another example, such as the

[go-nuts] Re: Generics and parentheses

Hi, Why do we have to allow people to write something like `w(z)` or `w(x,y)(z)` or `w[x,y](z)`? It's not "go-style" stuff. Something more in "go-style" should be: ``` wxy := w a, b = wxy(z) ``` It is much more clear and elegant, just like what we have for error handling. In this way,

Re: [go-nuts] Generics and parentheses

Perhaps another source of resistance to < > is the trauma many of us have from its major obfuscation of C++ code? - Randy > On Jul 15, 2020, at 3:13 PM, Yaw Boakye wrote: > > To summarize the thread so far: > > - parenthesis is a no-no > - angle brackets are popular/common but that alone

Re: [go-nuts] Generics and parentheses

The big argument I always found less and greater signs to be not visually distinctive enough, at least with fonts I am using. [ and ] are larger and I was really happy with them in Scala although I dislike the language in general. Seriously though, the real big argument is [] are already used

Re: [go-nuts] Generics and parentheses

On Wed, Jul 15, 2020 at 3:27 PM Bakul Shah wrote: > > The syntax rule I envisioned was this: > type: ... | type generic-type | ... > > To me, using full parenthesization, this would be > func() int pair pair" == "((func() int) pair)pair --(1) > What you seem to want is > (func() (int pair)) pair

Re: [go-nuts] Generics and parentheses

On Wed, 2020-07-15 at 15:27 -0700, Bakul Shah wrote: > The second issue is the usage for generic functions. Contrast > > (float64, int)PowN(1.2, 3) > with > PowN[float64, int](1.2, 3) > or currently > PowN(float64, int)(1.2, 3) > > I find the alternate syntax easier because

Re: [go-nuts] Generics and parentheses

> On Jul 15, 2020, at 1:49 PM, Ian Lance Taylor wrote: > > On Tue, Jul 14, 2020 at 11:06 PM Bakul Shah wrote: >> >> I don't much like square brackets or angle brackets or guillemets. But here >> is a different way >> of reducing the need for parentheses at least for the common case: >> >>

Re: [go-nuts] Generics and parentheses

On Wed, 2020-07-15 at 17:10 -0500, Seebs wrote: > That said, if people don't like square brackets, I'm totally prepared > to make worse suggestions until they give up and say square brackets > aren't that bad. > Let's bring back the special five keywords! func despiteallobjections F insofaras

Re: [go-nuts] Generics and parentheses

To summarize the thread so far: - parenthesis is a no-no - angle brackets are popular/common but that alone doesn't make good argument. some languages have already deviated. scala is popular, uses square instead of angle brackets. - go's current pseudo-generic data structure, the map, already

Re: [go-nuts] Generics and parentheses

On Wed, 15 Jul 2020 14:51:17 -0700 jimmy frasche wrote: > I didn't care about () except for having to then have extra parens > around types in a lot of places which was very annoying and came up > often. If [] fixes that, great! I was pretty unhappy with () just because there's too many () and

Re: [go-nuts] Generics and parentheses

On Wed, 2020-07-15 at 14:36 -0700, Randall O'Reilly wrote: > And the use of [ ] in map is more semantically associated with its > conventional use as an element accessor in arrays / slices, not with > some more general kind of type parameter. The [] syntax can be viewed as an indexing operation

Re: [go-nuts] Generics and parentheses

I didn't care about () except for having to then have extra parens around types in a lot of places which was very annoying and came up often. If [] fixes that, great! On Wed, Jul 15, 2020 at 2:47 PM Ian Lance Taylor wrote: > > On Wed, Jul 15, 2020 at 2:36 PM Randall O'Reilly wrote: > > > >

Re: [go-nuts] Generics and parentheses

On Wed, Jul 15, 2020 at 2:36 PM Randall O'Reilly wrote: > > Regarding the parsing: as I suggested in my email, but perhaps was unclear, > in case of two conflicting *purely syntactic* interpretations (without using > any type information), you could just choose the more high-frequency >

Re: [go-nuts] Generics and parentheses

This is what I was thinking. Format for the common case. At compile/link time you would be able to figure out the conflict and throw an error and the dev could add the parens to make it unambiguous. > On Jul 15, 2020, at 4:36 PM, Randall O'Reilly wrote: > > Regarding the parsing: as I

Re: [go-nuts] Generics and parentheses

Regarding the parsing: as I suggested in my email, but perhaps was unclear, in case of two conflicting *purely syntactic* interpretations (without using any type information), you could just choose the more high-frequency interpretation (i.e., type parameters) and force the programmer to use

Re: [go-nuts] Generics and parentheses

But Scala doesn’t use [] for anything else - Go does. > On Jul 15, 2020, at 9:58 AM, 'Nic Long' via golang-nuts > wrote: > > Square brackets work great. Scala uses them for generics to great effect. > They also make me think of Clojure, which introduced them to Lisp for similar > reasons

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

On Wed, Jul 15, 2020 at 7:59 AM kaleidawave wrote: > > Correct me if I am wrong but wouldn't square bracket syntax have an ambiguity > around calling a function pointer at a position in a slice: > > z := []func() int{x, y}; > a := z[0](); A parsing ambiguity arises when the same code can be

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

On Wed, Jul 15, 2020 at 7:59 AM jpap wrote: > > Two thoughts: > > 1. How useful is it in practice to have separate start and end delimiters? > Does it matter for nested declarations? I didn't see any nested declarations > in the Draft Design document, for example. If allow the same token on

Re: [go-nuts] Generics and parentheses

On Wed, Jul 15, 2020 at 5:44 AM Jan Mercl <0xj...@gmail.com> wrote: > > My 2c - Alternative type parameters syntax (ab)using @$: > https://docs.google.com/document/d/1AoU23DcNxYX2vYT20V2K16Jzl7SP9taRRhIT8l_pZss/edit?usp=sharing Thanks for the detailed writeup. I'm a bit concerned about name

Re: [go-nuts] Generics and parentheses

On Tue, Jul 14, 2020 at 11:06 PM Bakul Shah wrote: > > I don't much like square brackets or angle brackets or guillemets. But here > is a different way > of reducing the need for parentheses at least for the common case: > > A proposal for fewer irritating parentheses! > > One thing to note is

Re: [go-nuts] Generics and parentheses

On Jul 15, 2020, at 2:48 PM, Ian Lance Taylor wrote: > > More seriously, though, let's look closely at Robert's example: > > a, b = w < x, y > (z) TBH, I think a big argument in favor of square brackets over angle brackets is that they ascend above the center line in most typefaces, which

Re: [go-nuts] Generics and parentheses

On Wed, 15 Jul 2020 12:26:15 -0700 Ian Lance Taylor wrote: > The suggested syntax, whether with parentheses or square brackets, has > what I consider to be a very nice property: the definition and use > syntaxes are very similar. For the definition we write > > func F[type T]() {} > > For the

Re: [go-nuts] Generics and parentheses

On Tue, Jul 14, 2020 at 10:06 PM Paul Johnston wrote: > > If the generic expression was always attached/constrained to the "type" > or "func" keyword (rather than the type or function name), perhaps this would > decrease the lookahead problems with lexing? For example: > > type Point struct {

Re: [go-nuts] [generics]The ability to allow different length arrays and slices

Why not just accept slices only and expect the caller to add a `[:]`? It's not quite as ergonomic, but should have the same effect and we wouldn't need to add complexity to the design. On Wed, Jul 15, 2020 at 4:58 PM wrote: > Right now as I understand it, I would still have to write a different

Re: [go-nuts] Generics and parentheses

Correction: I think it is much more important that Go remains internally consistent in its use of "square" brackets. On Wednesday, July 15, 2020 at 8:54:58 PM UTC+2 Hein Meling wrote: > When you refer to beginners, I think you mean developers from other > languages (Java/C#/C++...) that

Re: [go-nuts] Generics and parentheses

When you refer to beginners, I think you mean developers from other languages (Java/C#/C++...) that already know the concept of generics. I don't think they will have problems adapting to a square brackets notation... they are smart people, and after all they have to learn many other

Re: [go-nuts] Generics and parentheses

On Tue, Jul 14, 2020 at 9:45 PM robert engels wrote: > > My opinion is that every major language (no flames please… lots of developers > write lots of programs and make money doing it) that supports generics uses < > > for generic types, so Go should too - since there is no reason to deviate >

[go-nuts] Re: Generics and parentheses

I really like this square bracket syntax and I'm glad that Go does not repeat the mistakes other languages have made.. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an

Re: [go-nuts] Generics and parentheses

Agreed. I've been a happy Gopher since 2011 and would really like to see <> or even [] instead of (). On Wednesday, 15 July 2020 20:03:40 UTC+3, Dan Markham wrote: > > On Tuesday, July 14, 2020 at 9:45:41 PM UTC-7, robert engels wrote: >> >> My opinion is that every major language (no flames

[go-nuts] Re: Considering dropping GO386=387

I make a GO386=387 build for rclone, eg https://github.com/rclone/rclone/issues/437 People love running rclone on ancient computers to rescue data off them I guess. This would affect a very small percentage of users and there are always older versions of rclone they can use so I'm not too

Re: [go-nuts] Generics and parentheses

On Tuesday, July 14, 2020 at 9:45:41 PM UTC-7, robert engels wrote: > > My opinion is that every major language (no flames please… lots of > developers write lots of programs and make money doing it) that supports > generics uses < > for generic types, so Go should too - since there is no >

[go-nuts] Re: Generics and parentheses

Dear Developers: You have spent several years on this and I'm impressed by the result, it looks beautiful! I'm stunned. As you can see from the recent spotlight shown on this syntax, in the meanwhile people have resorted to using unicode characters that sort of look like delimiters but are

Re: [go-nuts] Generics and parentheses

On Tue, 14 Jul 2020 23:19:40 -0700 (PDT) Fino wrote: > I vote for <: and :> I'm conflicted on it. <> match what several other languages do, but are problematic for the parser. () is definitely overused. [] is tolerable. I'd like to bring up the possibility of ??( and ??), mostly so that

Re: [go-nuts] Generics and parentheses

This is similar to C++ template, and it's very clear to understand. On Wednesday, July 15, 2020 at 1:06:24 PM UTC+8, Paul Johnston wrote: > > If the generic expression was always attached/constrained to the > "type" or "func" keyword (rather than the type or function name), perhaps > this

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

I'm in favor of the square brackets. scala has them as well so we're not exactly blazing a new trail. I'm not in favor of a second `type` keyword whose benefit is to disambiguate syntax to the parser. we already use significant whitespace to identify tokens. for example, we expect to be parsing a

[go-nuts] Re: Generics and parentheses

Square brackets feel much better. It removes a lot of ambiguity in reading code. Actually I personally wouldn't mind to have double square brackets as "Generics" indicator just to remove also what little reading ambiguity they can cause with indices. type A[[N]] E On Tuesday, July 14,

Re: [go-nuts] Generics and parentheses

Square brackets work great. Scala uses them for generics to great effect. They also make me think of Clojure, which introduced them to Lisp for similar reasons to here - to avoid too much overload of regular parentheses - and which people have been very happy with. On Wednesday, 15 July 2020

[go-nuts] Re: Generics and parentheses

Here's my 2cents: I actually don't mind the parenthesis.. I've written a bunch of functions with them now ( https://github.com/DylanMeeus/hasgo2/tree/master/functions) and they become readable quickly. (Although I also enjoy LISP flavours, so maybe that biases my view of parenthesis :D) But

[go-nuts] Re: Generics and parentheses

Two thoughts: 1. How useful is it in practice to have separate start and end delimiters? Does it matter for nested declarations? I didn't see any nested declarations in the Draft Design document ,

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

Go code use a Syntax analog to casting instead of the type keyword. f.[int](args) or var x map[string]GType.[int] That does not collide with other language features in function declaration, type definitions, inner types in structs or interfaces, variable declarations, type alias declarations

[go-nuts] [generics]The ability to allow different length arrays and slices

Right now as I understand it, I would still have to write a different generic function for different length arrays, or one that accepted slices. as per: // Accept slices of T func someSliceFunc(type T)(s []T){ ... } // Accept a 1 member array of T func someArrayFunc(type T)(a [1]T){ ... } ... //

[go-nuts] Re: Generics and parentheses

Correct me if I am wrong but wouldn't square bracket syntax have an ambiguity around calling a function pointer at a position in a slice: z := []func() int{x, y}; a := z[0](); https://play.golang.org/p/lekFJlvbRTD On Tuesday, July 14, 2020 at 10:56:01 PM UTC+1 gri wrote: > We have received a

[go-nuts] Re: Generics and parentheses

Hello all, I'd first like to say thanks to the go team for their incredible work on delivering such a usable tool as go. I will then proceed to bring my 2 cents to the World Bikeshedding Foundation :) I would add a vote to have something more differenciating to indicate "this is a generic

Re: [go-nuts] Generics and parentheses

On Jul 15, 2020, at 4:47 AM, Nick Craig-Wood wrote: > > In my mind the use of [ ] clashes horribly with the array declaration > syntax. When I see [int] in particular my brain says, ah array declaration of > size int, what, no wait... On the other hand, this is already how maps are declared

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

On Jul 15, 2020, at 12:13 AM, Ian Lance Taylor wrote: > > The disadvantage of guillemets is that they are hard to type on many > keyboards. So to me either square brackets or angle brackets would be > better than guillemets. Not to mention that, while Go *is* officially in UTF-8, the chance of

Re: [go-nuts] Generics and parentheses

On Tue, Jul 14, 2020 at 11:55 PM 'Robert Griesemer' via golang-nuts wrote: > The time has come to revisit this early decision. If square brackets alone > are used to declare type parameters, the array declaration My 2c - Alternative type parameters syntax (ab)using @$:

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

Angle brackets are only problematic in expressions in the bodies of functions when specializing a function or a type, right? They are not problematic in signatures and type definitions. What about using a dot when specializing in bodies? func zero() T { var z T return z }

[go-nuts] Re: Golang Templates

What language is that code written in? It looks more like Javascript than Go to me. If you have a problem with some Go code, please can you show the Go code - ideally as a self-contained runnable example at play.golang.org -- You received this message because you are subscribed to the Google

[go-nuts] Golang Templates

{{range .}} {{if ne .Symbol " "}} {{.Symbol}} {{end}} {{end}} var div=document.getElementById('List'); var point = div.getElementsByTagName('span'); console.log(point[0].innerHTML) Actual Output: Empty string Excepted Output: Y How to resolve this -- You

Re: [go-nuts] Generics and parentheses

On Wed, Jul 15, 2020 at 11:27 AM Randall O'Reilly wrote: > wouldn't gofmt remove the superfluous (z) in this case (and even with a > more complex expression inside the parens, as the > operator would have > appropriate precedence?), in existing code? And thus, would it not be > reasonable to

Re: [go-nuts] Generics and parentheses

Sorry to perseverate and belabor the point, but here's an analogy that makes the point perhaps more strongly and succinctly: Imagine that, for some reason, Go didn't have the array/slice element operator syntax, [ ], and it was now going to be introduced in Go2, but instead of using this

Re: [go-nuts] Generics and parentheses

On Wed, Jul 15, 2020 at 10:47 AM Nick Craig-Wood wrote: > In my mind the use of [ ] clashes horribly with the array declaration > syntax. When I see [int] in particular my brain says, ah array declaration > of size int, what, no wait... > > This makes [identifier] mean two different things

[go-nuts] Re: Generics and parentheses

Great! Those multiple parenthesis were a beat on unredable side indeed, and I always was in the pro-square party as I always found less and greater signs to be unreadable. As much as I disliked Scala in general I liked their generic syntax. This is a really good news Go will have the same.

Re: [go-nuts] Generics and parentheses

On Wed, Jul 15, 2020 at 8:25 AM Michael Jones wrote: > nice. "gen" here is akin to the existing forward declaration of recursive > inner functions. it says, "you are about to see something special and you > need to know *this* about it." > > The real name is "forall", and it presents a binding

[go-nuts] Generics and parentheses

In my mind the use of [ ] clashes horribly with the array declaration syntax. When I see [int] in particular my brain says, ah array declaration of size int, what, no wait... This makes [identifier] mean two different things depending on whether indentifier is a const integer or whether

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

I think square brackets are better than parentheses for several reasons: 1. fewer parser ambiguities (see the post that started this thread) - thus fewer cases where programmers must remember "oh, this is a special case, I must put additional parentheses somewhere" 2. programmers can

Re: [go-nuts] Generics and parentheses

As I wrote, parentheses are not needed for the common case of single type parameter. If you have more than one, you need parentheses but note that this is a *prefix* and any parsing ambiguities can removed by using a - if needed. For your example it will be something like (float64,int)PowN(1.2,

Re: [go-nuts] Generics and parentheses

On Tue, 2020-07-14 at 23:53 -0700, Randall O'Reilly wrote: > So, essentially, this puts the onus back on the parser programmers to > definitively *rule out* the use of < > -- is it really that difficult > / costly to do a bit of look-ahead and disambiguate the different use > cases? The absence

Re: [go-nuts] Generics and parentheses

On Tue, 2020-07-14 at 23:05 -0700, Bakul Shah wrote: > I don't much like square brackets or angle brackets or guillemets. > But here is a different way > of reducing the need for parentheses at least for the common case: > > A proposal for fewer irritating parentheses! > > One thing to note

Re: [go-nuts] Generics and parentheses

Tagging onto this point: while Go deviates from other languages in a number of important ways, syntax at the level of things like parens, brackets, etc is not one of these key differences. It is almost entirely consistent with the "de facto" C-style choices in this respect (to the extent that

Re: [go-nuts] Generics and parentheses

nice. "gen" here is akin to the existing forward declaration of recursive inner functions. it says, "you are about to see something special and you need to know *this* about it." On Tue, Jul 14, 2020 at 11:06 PM Bakul Shah wrote: > I don't much like square brackets or angle brackets or

Re: [go-nuts] Generics and parentheses

I vote for <: and :> type more on traditional keyboard is acceptable for me, since I don't use generics much. too much parentheses ( and ) in declaration is really hard to read, confused my mind. square brackets [ and ] should reserve for array and slice. and, look ahead, we are able to

Re: [go-nuts] Generics and parentheses

I don't much like square brackets or angle brackets or guillemets. But here is a different way of reducing the need for parentheses at least for the common case: A proposal for fewer irritating parentheses! One thing to note is that generic functions & types are *different* from existing things

[go-nuts] Re: exec.Cmd.Process.Kill doesn't unblock exec.Cmd.Wait

Not a direct answer to your question, but I've come across plenty of issues that prevented reliable termination of external processes (along with their children). Eventually I came to this solution, it's been thoroughly tested in production: func KillProcess(proc *os.Process)