Re: [go-nuts] How to cast a multi-value?
Assigning string values to string values or byte[] to byte[] does not require additional memory allocation. But conversion between string and byte[] does so most of the time, because the underlying array of a string is immutable, versus the mutable of a byte[]. Encapsulating the type cast encapsulates exactly this potentially costly operation. Whether this has a negativ or positive impact on potential compiler optimisation in respect to the need of a copy in this special case, is hard to determine. Amnon schrieb am Dienstag, 18. Mai 2021 um 22:09:18 UTC+2: > My understanding was that a string had a pointer and a length, > whereas a slice had a pointer and a length and a capacity. > > https://golang.org/src/reflect/value.go?s=59515:59567#L1973 > > > On Tuesday, 18 May 2021 at 20:32:39 UTC+1 Brian Candler wrote: > >> Assigning a string value to another variable doesn't double the memory >> usage. >> >> A value of type string consists of a pointer, a length, and a capacity, >> and only these are copied - so you get another copy of the pointer, >> pointing to the same data buffer. >> >>> -- 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/188a70df-4dff-40d7-a2d2-4ea64902aa28n%40googlegroups.com.
Re: [go-nuts] Type parameters syntax... Can it be improved?
Ian Lance Taylor schrieb am Dienstag, 23. März 2021 um 23:22:51 UTC+1:
> On Tue, Mar 23, 2021 at 3:19 PM atd...@gmail.com
> wrote:
> >
> > Since, we also know the type of v, It would be infered from it.
> >
> > There is no variance, no dependent type... Meaning that the type of a Go
> variable does not change.
> > So the constraints do not change midway through the program, including
> type names/definitions.
> >
> > It does however require to have something that resemble a type
> definition beforehand.
> > A type parameter definition.
>
> In some cases it can be inferred.
But even if it can be inferred it should be possible to annotate the type I
do expect,
to improve local readiblity and compile time error message quality:
I assume that "x" is later used in a context requiring the type to be "int":
x := Min(someFunc(foo), someFunc(bar))
Here i can use:
var x int = Min(someFunc(foo), someFunc(bar)))
but using
x := Min[int]( someFunc(foo), someFunc(bar)))
The three version yield different error message, if the called function
"someFunc()" return a float instead of the expected int.
But what about cases where it
> can't? And what if I want to write
>
> // IntMin is a function with type func(int, int) int.
> var IntMin = Min[int]
>
?
>
> The constraints don't change midway through a program, but in your
> example the meaning of T does change.
>
>
hmmm... if all I need throughout my whole package is one binding e.g. to
"int",
or to the type parameter "MyParameterType" my function use for themselves
it may get teadious to
repeat the [MyParameter] all over the place.
Type inferences helps, but weakens the quality of error messages.
So please always allow for a explicit type parameter annotation even if
inference is possible.
(And doing so in a more global location may improve simplicity a lot;-)
Martin
> Ian
>
>
> > On Tuesday, March 23, 2021 at 10:41:15 PM UTC+1 Ian Lance Taylor wrote:
> >>
> >> On Tue, Mar 23, 2021 at 2:17 PM atd...@gmail.com
> wrote:
> >> >
> >> > Quick question...
> >> >
> >> > Why do we need brackets to define a parametered function, struct
> etc...?
> >> >
> >> > Why not change Go kinds to accept either a type (would produce a
> regular, function, structs, etc) or a new type parameter object that would
> implement the constraints (would produce a generic function definition)
> >> >
> >> > for instance,
> >> >
> >> > type parameter T
> >> >
> >> > // [...] some way to add constraint to T
> >> >
> >> > func Max(v T) T{...}
> >> >
> >> > What are the brackets for? Just an idea.
> >>
> >> Each call to Max can use a different value for T. We can call
> >> Max[int] and Max[string]. How would we do that with this notation?
> >>
> >> A type parameter really is a parameter to the function. Making it
> >> syntactically similar to other non-type parameters seems like a good
> >> idea to me.
> >>
> >> Ian
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to golang-nuts...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/5713130f-20c7-4b70-ba8f-2e9be22cb9c9n%40googlegroups.com.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/ba6f07e2-f89f-4d59-9f10-e0e2fcea004en%40googlegroups.com.
Re: [go-nuts] No Generics - Type Binding on Imports
Am 22.03.2021 um 10:10 schrieb Martin Leiser:
Am 21. März 2021 22:01:38 MEZ schrieb Ian Lance Taylor :
On Sun, Mar 21, 2021 at 1:02 PM Martin Leiser
wrote:
...
import "container/list" stringlist type ElementType = string
What if I want to have a list of lists of strings?
That is a no brainer. The type "list of strings" in the example is:
"stringlist.Element". So you add the following line:
import "container/list" liststringlist type ElementType = stringlist.Element
The really tricky question is in my opinion:
What if the binding type is a parameter type itself?
type MyElement interface{ String() string }
and this is bound to
import "container/list" myelementlist type ElementType = MyElement
I.e my container type build on the list type for its implementation.
This really adds complexity to the implementation, because every import
binding "MyElement" also binds the list package parameter type.
What if I want to have a list of some unexported type that I defined
in this package?
That is the "Complicated" part of the proposal. It can be solved and it is not
that tricky:
- All the compiler really needs to know about the bound type is specified by
the bound interface type, plus the storage size.
- You have to outrule cyclic definitions, but they are impossible, because it
is the implementaion which introduces the cycle.
- You may even fall back to the normal implementation of "interface types"
behind the scenes when appropriate.
Semantically all is solved by the following three program transformations
chained together:
1. Make the private Type exported (does not change behaviour as long as you
avoid name clashes by consistent renaming)
2. Add an import to the Package defining the binding type in a renamed copy of
the generic package
3. replace the definition of the bind type by a type alias with the binding
type in the copy of step 2
So steps 2 and 3 have to take place in the proper order and recursively
across separate packages in case of parameter types used as binding types.
Every binding of "MyElement" type adds another binding to list.ElementType.
Complicated but solvable, but perhaps only if cyclic imports our
outruled for type binding imports in the first place.
Thanks again.
Ian
Thanks for your quick response.
Martin
Martin
--
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/26262f4f-41ad-3b4c-5682-17946174cc3a%40gmail.com.
Re: [go-nuts] No Generics - Type Binding on Imports
Am 21. März 2021 22:01:38 MEZ schrieb Ian Lance Taylor : >On Sun, Mar 21, 2021 at 1:02 PM Martin Leiser >wrote: >> >> I think so. But How? Remember we need to do two things: >> >> - A way to define type parameters. >> >> - A way to bind the type parameters to concrete types at compile >time > >Thanks for the note. > >I think that a generics proposal needs to do three things. The third >is that it needs to describe which operations are permitted for a type >parameter. Absolutely correct. Especially if you think about the kind of things you may do with type parameters and type inference in languages like Haskell or ML. The only thing you aktually want to do with binding types of type parameters is: use them as parameters of your package. No difference to the accepted proposal here. The key difference here is the way to define and bind the parameters. All else should be as equal as possible, because the accepted proposal is good. > > >> But after we named it "ElementType" we can get a hold of it and bind >it in the package we intend to use e.G. a "list of strings": >> >> import "container/list" type ElementType string > >This general kind of idea has been suggested quite a few times before. >Here are a few examples: > >https://gist.github.com/PeterRK/41d4d3f54b8db55cd616403fd5a389f3 >https://github.com/dotaheor/unify-Go-builtin-and-custom-generics/blob/master/use-package-as-gen.md >https://groups.google.com/g/golang-nuts/c/xKYXZpsWHus/m/SS4FKMBEAQAJ > >There are others. > yes I know about eg. even older ones like genny https://github.com/cheekybits/genny > >> Last features. If you need two different bindings in one package, say >a list of string and a list of int you may use: >> >> import "container/list" intlist type ElementType = int >> >> import "container/list" stringlist type ElementType = string > >What if I want to have a list of lists of strings? That is a no brainer. The type "list of strings" in the example is: "stringlist.Element". So you add the following line: import "container/list" liststringlist type ElementType = stringlist.Element > >What if I want to have a list of some unexported type that I defined >in this package? That is the "Complicated" part of the proposal. It can be solved and it is not that tricky: - All the compiler really needs to know about the bound type is specified by the bound interface type, plus the storage size. - You have to outrule cyclic definitions, but they are impossible, because it is the implementaion which introduces the cycle. - You may even fall back to the normal implementation of "interface types" behind the scenes when appropriate. Semantically all is solved by the following three program transformations chained together: 1. Make the private Type exported (does not change behaviour as long as you avoid name clashes by consistent renaming) 2. Add an import to the Package defining the binding type in a renamed copy of the generic package 3. replace the definition of the bind type by a type alias with the binding type in the copy of step 2 In my posting I only named the 3. transformation to keep things simple. Steps 2 and 3 have to be done at most once for any binding type in the whole program. All this may be implemented as "source to source" transformations, as you may know from the compiler construction class talking about generics (mine was >30 years age full of examples from LIS and Ada, I am a bit rusty here). And it gets way more complicated when you actually start to do it in reality. But it is this simple to describe here, because I choose to bind on the package level. That is part of the trick. The price are global variables. But can You always apply this transformation? Are there additional limitations required? I do not know yet. I believe you must outrule a import cycle for the type binding import. Which should be of no practical impact. > That seems to require interweaving type definitions >and imports in ways that the language does not currently support. Hmm, do not think so, see above. The result of the program transformation above should be a valid Go 1 program. For every type binding you have to have a way to "instantiate" a copy of the whole package with this binding. And the "stringlist" must only have one instantiation for all packages using the same type binding imports. Doing this efficient and effective, that is the complicated part. Did I mention that there is no big difference in complexity in the implementation of my proposal and the accepted one? Sorry for ommiting that. I actually see an additional risk, when talking about global variables involving the parameter
[go-nuts] No Generics - Type Binding on Imports
the package.
I tried to give a semantic description in my definition in Binding
interface types on import
<https://github.com/leiser1960/importbinding/blob/master/README.md> but
it is not as elaborate as the accepted proposal.
The semantics is defined by a set of program transformations back to a
Go 1 program.
Is this *simplicty*?
I think so, ok not as simple as inheritance, because I have to add a
syntactic element: The type binding on Import.
But definitely a simpler than the accepted proposal.
Last features. If you need two different bindings in one package, say a
list of string and a list of int you may use:
import "container/list" intlist type ElementType = int
import "container/list" stringlist type ElementType = string
And then simply pick either the package name: "intlist" or "stringlist" e.g.
myintlist := intlist.New()
mystringlist := stringlist.New()
This makes myintlist.Value of type int, whereas mystringlist.Value is of
type string.
And if you think of the type "Map" in "sync.go
<https://golang.org/pkg/sync/#Map>": You need a way to bind more than
one type on a single import: sync.Key and sync.Value:
import "sync.go" type Key string; Map mySyncdata
But now we have all of the syntax by example. Simple to use.
You may not bind all "named interface types" on the import, the above
does not bind the Type "Locker <https://golang.org/pkg/sync/#Locker>",
so the "Cond <https://golang.org/pkg/sync/#Cond>" type remains polymorphic.
The definition of a generic package is go 1 compatible.
You only have to "name" the parameter types for use by type binding
imports. Which improves the documentation as well.
Not convinced? Lets move from Go 1 polymorphic generics to Go 2
monomorphic use, again using the "container/list.go" example.
It requires two sorts of changes:
1. Add the required type binding to the import clause, see above
2. delete the type casts needed for accessing the "Value" Attribute
of the "Element" struct:
if "" = (string)mystringlist.Value {
has to be changed to:
if "" = mystringlist.Value {
Try the same with the accepted proposal.
But a last word:
Simplicity is Complicated <https://www.youtube.com/watch?v=rFejpH_tAHM>
So behind the scenes there is more to it:
- there is an additional restriction for "named interface types"
necessary in order to allow them to be used as type parameters.
- there are new semantic hurdles because of the type parameters
being on the package level.
- I did not describe any "type inference rules" yet, but it should
be possible to add this for typical functional libraries such as
"sort.go <https://golang.org/pkg/sort/>".
- type bindings my even be transitive, if the binding type is itself
a exported interface type.
So the a full fledged proposal may end up as long as the accepted
proposal. That is the complicated part anyway.
But it is this the kind of *simplicity *I want to see when talking about
monomorphic generic types. Perhaps someone can do even better?
Yours Martin Leiser
--
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/6d48e04e-eade-6dc5-fb05-f1c6a7151a43%40gmail.com.
Re: [go-nuts] [generics] notes on adding generics to a package
while *you* consider it not a
goal to be able to write a generic Max function using `<`, the Go
project does.
Agree with that, but the solution suggested in the proposal would nicely
fit here too, because it adds an new form of "interface{}" type
definition, for this purpose. Which may be used to define named
parameters as well. So the "Comparable" of the golang draft may well be
used in my proposal unchanged.
But I wanted to keep things simple and concentrate on the important
pieces, which is the syntax without need for a new brackets discussion.
And while, personally, I wouldn't consider it a non-starter if your
design can't accommodate that, it's certainly a significant drawback
over the type-parameter proposal. Similarly, there is no way to
express that a type must be comparable, which means either a) a
generic function can't use it as a key-type for `map` or b) the result
won't be type-safe. Hashmaps are at the core of many of the
algorithms, people would like to implement generically.
You should also probably be aware, that the type-parameter proposal is
currently in the "likely accept" phase
<https://github.com/golang/go/issues/43651#issuecomment-772744198>.
I know. I am way too late. Sorry for stealing your time. I only have one
strong argument: it is a way simpler solution.
While this doesn't mean it's a done deal, it does mean the odds of
declining it in favor of a completely new, as of yet undiscussed
proposal, are relatively slim, IMO - especially in light of point 6 above.
Point 6 may be solved easily, see above, I think point 5 the breaks the
neck here.
Personally I think in praxis generic collections are the far more
important aspect than functional libraries containing "Min" and "Max"
functions.
And your writing was all about collections too.
Thank a lot for Your suggestions!
Martin Leiser
On Sun, Feb 7, 2021 at 9:20 PM Martin Leiser <mailto:leiser.1...@gmail.com>> wrote:
I follow the discussion about go generics for some time now, but
never tried using them.
Your conclusion
> I struggled to grasp generics at the outset of this experiment.
They are complex in a way that I haven’t encountered in a while
with Go: I wasn’t sure when to reach for them and when to use
another feature of Go.
is no surprise for me.
Adopting the "c++" or "java" style of generics, which dates back
to Ada and experimentell languages before that is no good fit for
golang in my opinion. I am working on a different approach not yet
published. You may have a look in:
https://github.com/leiser1960/importbinding/blob/master/README.md
<https://github.com/leiser1960/importbinding/blob/master/README.md>
I do not have a "go2go" implementation for it yet. It is way
simpler, and there is no doubt when to reach for it.
The basic idea is: golang already has generic types: interface
types. Simply constrain them to the types you actually want to use
with them with. It is a simple "opt in" approach. You add a type
binding on import, that's it. For the "generic" type in the
package: Give a name to your types, which helps for readability
anyway.
And big thanks for your good writeup of the experiment.
Martin Leiser
Ian Lance Taylor schrieb am Freitag, 29. Januar 2021 um 23:13:21
UTC+1:
On Fri, Jan 29, 2021 at 1:09 PM Ben Burkert
wrote:
>
> I wrote a blog post on my experience updating a package to
use the
> latest proposed generics feature with the go2go tool. My
overall
> impression is quite good as it was able to solve some existing
> problems with the package. Thanks to Go team & gopher
community for
> all your work making generics happen!
>
> https://benburkert.com/posts/on-go2-generics/
<https://benburkert.com/posts/on-go2-generics/>
Thanks for the write-up!
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
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/1f8db11d-56a7-4f16-b6b9-7c7b0b2fe822n%40googlegroups.com
<https://groups.google.com/d/msgid/golang-nuts/1f8db11d-56a7-4f16-b6b9-7c7b0b2fe822n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to a topic in the
Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topi
Re: [go-nuts] [generics] notes on adding generics to a package
I follow the discussion about go generics for some time now, but never tried using them. Your conclusion > I struggled to grasp generics at the outset of this experiment. They are complex in a way that I haven’t encountered in a while with Go: I wasn’t sure when to reach for them and when to use another feature of Go. is no surprise for me. Adopting the "c++" or "java" style of generics, which dates back to Ada and experimentell languages before that is no good fit for golang in my opinion. I am working on a different approach not yet published. You may have a look in: https://github.com/leiser1960/importbinding/blob/master/README.md I do not have a "go2go" implementation for it yet. It is way simpler, and there is no doubt when to reach for it. The basic idea is: golang already has generic types: interface types. Simply constrain them to the types you actually want to use with them with. It is a simple "opt in" approach. You add a type binding on import, that's it. For the "generic" type in the package: Give a name to your types, which helps for readability anyway. And big thanks for your good writeup of the experiment. Martin Leiser Ian Lance Taylor schrieb am Freitag, 29. Januar 2021 um 23:13:21 UTC+1: > On Fri, Jan 29, 2021 at 1:09 PM Ben Burkert wrote: > > > > I wrote a blog post on my experience updating a package to use the > > latest proposed generics feature with the go2go tool. My overall > > impression is quite good as it was able to solve some existing > > problems with the package. Thanks to Go team & gopher community for > > all your work making generics happen! > > > > https://benburkert.com/posts/on-go2-generics/ > > Thanks for the write-up! > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1f8db11d-56a7-4f16-b6b9-7c7b0b2fe822n%40googlegroups.com.
