Re: [go-nuts] [generics] replace ()/(type ) with :[]
On Jun 18, 2020, at 12:30 PM, 'Thomas Bushnell, BSG' via golang-nuts wrote: > > On Thu, Jun 18, 2020 at 9:46 AM Kiswono Prayogo wrote: > Personally () parentheses seems like to be harder to read, too similar with > function calls. > > This is exactly why I like it. These are parameters, and should be thought of > just like other parameters in a function call. This is precisely why I don't like it, because they are *metaparameters*. Having a variable length set of options where the length determines what the FIRST options are is actually really confusing, particularly because we already have an optional set of parentheses for the return types. I understand that folks familiar with Lisp/Scheme might be comfortable with it, but I'm very comfortable with both of those and I find this a bit maddening. Could be just me. I really do like the idea of separate characters for metaparameters on functions; another option would be Python/Java style decorators on the function (e.g. @type(A)), though I think in practice that might be a bit unpleasant (I really wish there were a better way to do the decorator pattern in Go, though). I'm somewhat surprised that the parser developers find the variable-length list of parenthetical clauses *easier* to deal with; it seems like a good way to introduce ambiguity in the parsing. That may be part of why the parser currently breaks when returning closures. But then, I'm not the one writing the parser, so I'm running on a lot of assumptions. I'm all for giving this time to settle and see how it plays out, of course. One thing I've learned is that it's generally a fool's errand to optimize for my use cases, at least if anyone else is going to like it. But consider this my vote for alternate delimiters. - Dave -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/D495EE84-B30E-46BD-9DD7-3E4531DFCB18%40gmail.com. signature.asc Description: Message signed with OpenPGP
Re: [go-nuts] [generics] replace ()/(type ) with :[]
" These are parameters, and should be thought of just like other parameters in a function call. .." parameters yes, but not in the current go context of 'parameter' .. Is it not better syntax for 'generic parameters' to use special, distinctive symbols e.g. C++ does via < Type > ?? On Thursday, June 18, 2020 at 12:31:04 PM UTC-4, Thomas Bushnell, BSG wrote: > > On Thu, Jun 18, 2020 at 9:46 AM Kiswono Prayogo > wrote: > >> Personally () parentheses seems like to be harder to read, too similar >> with function calls. >> > This is exactly why I like it. These are parameters, and should be thought > of just like other parameters in a function call. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/03188960-2939-477e-a5ec-66c11f2fa9beo%40googlegroups.com.
Re: [go-nuts] [generics] replace ()/(type ) with :[]
On Thu, Jun 18, 2020 at 9:46 AM Kiswono Prayogo wrote: > Personally () parentheses seems like to be harder to read, too similar > with function calls. > This is exactly why I like it. These are parameters, and should be thought of just like other parameters in a function call. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CA%2BYjuxse-3Y1J201bTDS%3DGq33bqKKzdJ4AHABrqM5PDgrLwKcg%40mail.gmail.com.
[go-nuts] [generics] replace ()/(type ) with :[]
Personally () parentheses seems like to be harder to read, too similar with
function calls.
It would be nicer if we use brackets instead [] like in Nim, since [] only
used in array/slice/indexing (index key or empty), which is more readable
than () that used in many ways (receiver, parameter, return value, function
calls, grouping, etc).
Current https://go2goplay.golang.org/p/zBO9K4-yXck
package main
import (
"fmt"
)
type Stack(type T) struct {
list []T
}
type Pair(type K, V) struct {
Key K
Val V
}
func New(type T)() Stack(T) {
return Stack(T){list: []T{}}
}
func (s *Stack(T)) Push(v T) {
s.list = append(s.list, v)
}
func main() {
a := New(int)()
fmt.Printf("%#v\n",a)
b := Stack(Stack(int)){}
fmt.Printf("%#v\n",b)
c := Pair(string,int){}
fmt.Printf("%#v\n",c)
}
Probably more readable syntax:
- F:T for single generic declaration and usage, eg. Stack:int,
BinaryTree:string, Vector:Person
- F:[T1,T2] for multiple generic declaration and usage or when having
constraint or array/slice, eg. Pair:[string,int], HashTable:[string,int],
Stack:[T Stringer], Stack:[[3]int]
- F:[T1:T2] for nested generic usage, eg. Stack:[Queue:int]
So for example, if we want to use Stack that stores string-int Pair, we
could use: Stack:[Pair:[string,int]], if we want to use Pair with string
key and integer Stack value, we could use: Pair:[string,Stack:int]
The pros:
- we could always differentiate between function calls (that returns
function) and generics by : or :[] symbol, other than just checking
whether passed parameter is a datatype or variable/constant identifier. =
unambiguous
- consistent syntax between generic declaration and usage
type Stack:T struct {
list []T
}
type Pair:[K,V] struct {
Key K
Val V
}
func New:T() Stack:T {
return Stack:T{list: []T{}}
}
func (s *Stack:T) Push(v T) {
s.list = append(s.list, v)
}
func main() {
a := New:int()
fmt.Prinf("%#v\n",a)
b := Stack:[Stack:int]{}
fmt.Printf("%#v\n",b)
c := Pair:[string,int]{}
fmt.Printf("%#v\n",c)
}
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/d0cd52bc-b33d-4256-83e3-40a0a24ddc3do%40googlegroups.com.
