[go-nuts] Workaround for No parameterized methods in go generics draft
Regarding the the section of No parameterized methods in go generics draft:
package p1 // S is a type with a parameterized method Identity. type S
struct{} // Identity is a simple identity method that works for any type.
func (S) Identity[T any](v T) T { return v } package p2 // HasIdentity is
an interface that matches any type with a // parameterized Identity method.
type HasIdentity interface { Identity[T any](T) T } package p3 import "p2"
// CheckIdentity checks the Identity method if it exists. // Note that
although this function calls a parameterized method, // this function is
not itself parameterized. func CheckIdentity(v interface{}) { if vi, ok :=
v.(p2.HasIdentity); ok { if got := vi.Identity[int](0); got != 0 {
panic(got) } } } package p4 import ( "p1" "p3" ) // CheckSIdentity passes
an S value to CheckIdentity. func CheckSIdentity() { p3.CheckIden
But package p3 does not know anything about the type p1.S. There may be no
other call to p1.S.Identity elsewhere in the program. We need to
instantiate p1.S.Identity[int] somewhere, but how?
The natural way would be to fetch instance sets (sets containing method
implementations for any specified interface, here HasIdentity) as a matter
of reflection.
However, solving instance resolution over reflection alludes to the
following questions:
- Does reflection support generic instantiation?
- Are generic types/functions are part of the runtime type information
selectable for runtime reflection?
- Are type to interface conformance relationships are part of the
runtime type information?
If all these questions can be answered by yes, then the case highlighted
above is solvable.
Alternatively, modulating the "CheckIdentity" function by the compiler to:
func CheckIdentity(v interface{},
hiddenHasIdentityInstanceContainingPointerToIdentityMethod) { if vi, ok :=
v.(p2.HasIdentity); ok { if got := vi.Identity[int](0); got != 0 {
panic(got) } } }
serves providing an instance automatically by calling "CheckIdentity"
function. This hidden parameter needs to be up-propagated to all callers
passing p1.S down the caller-callee hierarchy.
--
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/420e8a74-d9f8-4df9-9d7b-efffb642fbe8n%40googlegroups.com.
Re: [go-nuts] Workaround for No parameterized methods in go generics draft
On Wed, Jan 13, 2021 at 12:39 PM Marcus Manning wrote: > > Does reflection support generic instantiation? No. In the current proposal, generic functions and types are not visible at run time. Only instantiated functions and types are visible. So there is no way to even name a generic function/type that should be instantiated. > Are generic types/functions are part of the runtime type information > selectable for runtime reflection? No. > Are type to interface conformance relationships are part of the runtime type > information? Yes, using reflect.Type.Implements. 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/CAOyqgcWqW7ACWxOWt6hp9Rz7DgJTV9UXcnP%2Bcj3-voVxuRNGGw%40mail.gmail.com.
Re: [go-nuts] Workaround for No parameterized methods in go generics draft
On 1/13/21 11:37 PM, Ian Lance Taylor wrote:
On Wed, Jan 13, 2021 at 12:39 PM Marcus Manning wrote:
Does reflection support generic instantiation?
No. In the current proposal, generic functions and types are not
visible at run time. Only instantiated functions and types are
visible. So there is no way to even name a generic function/type that
should be instantiated.
Are generic types/functions are part of the runtime type information selectable
for runtime reflection?
No.
Are type to interface conformance relationships are part of the runtime type
information?
Yes, using reflect.Type.Implements.
Ian
Hmm..., then we should appreciate the alternative to generate a hidden
instance parameter for each instantiated type in the function body. The
hidden parameters might need to be up-propagated. Further, using
reflection, these hidden parameters have to be optionals or include nil
as we don't know if instances for a type parameter are available:
```
func CheckIdentity(v interface{})
{
if vi, ok := v.(p2.HasIdentity); ok {
if got := vi.Identity[int](0); got != 0 {
panic(got)
}
}
}
package p4 import ( "p1" "p3" )
p3.CheckIdentity(p1.s,
hiddenParameterIdentityInt?=p1.InterfaceInstanceOfSForInt)
p3.CheckIdentity(p1.someOtherStructNotHavingIdentityInstanceForInt,hiddenParameterIdentityInt?=nil)
```
--
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/28ec2495-18c3-8162-dc5e-9aae2fcce79b%40gmail.com.
Re: [go-nuts] Workaround for No parameterized methods in go generics draft
On Wed, 13 Jan 2021 at 20:38, Marcus Manning wrote:
>
> Regarding the the section of No parameterized methods in go generics
> draft:
>
> package p1 // S is a type with a parameterized method Identity. type S
> struct{} // Identity is a simple identity method that works for any type.
> func (S) Identity[T any](v T) T { return v } package p2 // HasIdentity is
> an interface that matches any type with a // parameterized Identity method.
> type HasIdentity interface { Identity[T any](T) T } package p3 import "p2"
> // CheckIdentity checks the Identity method if it exists. // Note that
> although this function calls a parameterized method, // this function is
> not itself parameterized. func CheckIdentity(v interface{}) { if vi, ok :=
> v.(p2.HasIdentity); ok { if got := vi.Identity[int](0); got != 0 {
> panic(got) } } } package p4 import ( "p1" "p3" ) // CheckSIdentity passes
> an S value to CheckIdentity. func CheckSIdentity() { p3.CheckIden
>
This code seems corrupted (no newlines) and incomplete. It's hard to
understand what your question is about without seeing the motivational 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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAJhgacg%2B3epUowNnpRHB_b89qXc%3Ded%2BSiHQLjaPahMUns%2BivZA%40mail.gmail.com.
Re: [go-nuts] Workaround for No parameterized methods in go generics draft
On 1/14/21 1:49 PM, roger peppe wrote:
This code seems corrupted (no newlines) and incomplete. It's hard to
understand what your question is about without seeing the motivational
code.
I hate mailing lists for exactly this reason.
Here is the code again:
```
package p1
// S is a type with a parameterized method Identity.
type S struct{}
// Identity is a simple identity method that works for any type.
func (S) Identity[T any](v T) T { return v }
package p2
// HasIdentity is an interface that matches any type with a
// parameterized Identity method.
type HasIdentity interface {
Identity[T any](T) T
}
package p3
import "p2"
// CheckIdentity checks the Identity method if it exists.
// Note that although this function calls a parameterized method,
// this function is not itself parameterized.
func CheckIdentity(v interface{}) {
if vi, ok := v.(p2.HasIdentity); ok {
if got := vi.Identity[int](0); got != 0 {
panic(got)
}
}
}
package p4
import (
"p1"
"p3"
)
// CheckSIdentity passes an S value to CheckIdentity.
func CheckSIdentity() {
p3.CheckIdentity(p1.S{})
}
```
Is there any option to highlight code here?
--
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/e6a9e9df-45d3-f4db-5e36-e37ffe7f08e8%40gmail.com.
Re: [go-nuts] Workaround for No parameterized methods in go generics draft
On Thu, Jan 14, 2021 at 4:33 AM Marcus Manning wrote: > > Hmm..., then we should appreciate the alternative to generate a hidden > instance parameter for each instantiated type in the function body. The > hidden parameters might need to be up-propagated. Further, using > reflection, these hidden parameters have to be optionals or include nil > as we don't know if instances for a type parameter are available: The current proposal tries pretty hard to avoid requiring a specific implementation strategy. 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/CAOyqgcUNQo2KOhSF98%3DPtXJLnMz4jTFG2n7iMBBqQmoc5u8VrQ%40mail.gmail.com.
Re: [go-nuts] Workaround for No parameterized methods in go generics draft
On Thu, Jan 14, 2021 at 12:07 PM Marcus Manning wrote: > > On 1/14/21 7:59 PM, Ian Lance Taylor wrote: > > On Thu, Jan 14, 2021 at 4:33 AM Marcus Manning wrote: > >> Hmm..., then we should appreciate the alternative to generate a hidden > >> instance parameter for each instantiated type in the function body. The > >> hidden parameters might need to be up-propagated. Further, using > >> reflection, these hidden parameters have to be optionals or include nil > >> as we don't know if instances for a type parameter are available: > > The current proposal tries pretty hard to avoid requiring a specific > > implementation strategy. > > > > Ian > > I don't know if this is really specific as it doesn't require that much > to a backend. Usually, this is how things work with generic > typeclasses/interfaces/traits/concepts/, you are required to provide > witness tables along with. > > But because the example uses reflection, it may be more valuable just to > store reified conformances like triples as RTTI: > > (type: p1.S,witness: p1.Identity[Int],interface: p2.HasIdentity[Int]) > //in a global table? > > Then we ask for example: reflection give me the witness for S regarding > HasIdentity //that would be idiomatic, I think. > > In think, if we could add such a functionality later without to break > existing code we're fine to implement generics without this feature, > otherwise we can't introduce the proposed functionality later. What you are describing is basically how Go implements interface types. I don't understand how to tie this back to generics. In the current proposal, type parameters are a purely compile-time concept. A valid implementation would be full monomorphization aka stenciling of all type arguments, similar to the way that C++ templates work. 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/CAOyqgcVaNMdu38fAmUbQWhSXhYLgeKMNgTt9_fmaTxGQQqrUgw%40mail.gmail.com.
Re: [go-nuts] Workaround for No parameterized methods in go generics draft
On 1/14/21 7:59 PM, Ian Lance Taylor wrote: On Thu, Jan 14, 2021 at 4:33 AM Marcus Manning wrote: Hmm..., then we should appreciate the alternative to generate a hidden instance parameter for each instantiated type in the function body. The hidden parameters might need to be up-propagated. Further, using reflection, these hidden parameters have to be optionals or include nil as we don't know if instances for a type parameter are available: The current proposal tries pretty hard to avoid requiring a specific implementation strategy. Ian I don't know if this is really specific as it doesn't require that much to a backend. Usually, this is how things work with generic typeclasses/interfaces/traits/concepts/, you are required to provide witness tables along with. But because the example uses reflection, it may be more valuable just to store reified conformances like triples as RTTI: (type: p1.S,witness: p1.Identity[Int],interface: p2.HasIdentity[Int]) //in a global table? Then we ask for example: reflection give me the witness for S regarding HasIdentity //that would be idiomatic, I think. In think, if we could add such a functionality later without to break existing code we're fine to implement generics without this feature, otherwise we can't introduce the proposed functionality later. -- 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/bd88f3b7-7d7f-1c94-db77-d0e87d252935%40gmail.com.
Re: [go-nuts] Workaround for No parameterized methods in go generics draft
FWIW I think that one possible approach to allowing methods (and
potentially function values) with type parameters might be to allow
instantiating them only with a limited set of "shapes" of data (for
example, only pointer-like types). Then I think there's the possibility
that the method or function could be compiled once for each allowed shape
but still allow instantiation with an arbitrary number of types, without
the necessity to statically enumerate all the possible types for that
function.
We need to instantiate p1.S.Identity[int] somewhere, but how?
If one did something like the above, I guess you'd look up the
implementation by shape (8 bytes, non pointer) from the type info in the
interface value, then call the compiled function with the appropriate meta
information based on that. Details left as an exercise for the reader :)
I don't see that reflection per se would need to be involved, any more than
reflection is involved when doing a dynamic type conversion.
cheers,
rog.
On Wed, 13 Jan 2021 at 20:38, Marcus Manning wrote:
>
> Regarding the the section of No parameterized methods in go generics
> draft:
>
> package p1 // S is a type with a parameterized method Identity. type S
> struct{} // Identity is a simple identity method that works for any type.
> func (S) Identity[T any](v T) T { return v } package p2 // HasIdentity is
> an interface that matches any type with a // parameterized Identity method.
> type HasIdentity interface { Identity[T any](T) T } package p3 import "p2"
> // CheckIdentity checks the Identity method if it exists. // Note that
> although this function calls a parameterized method, // this function is
> not itself parameterized. func CheckIdentity(v interface{}) { if vi, ok :=
> v.(p2.HasIdentity); ok { if got := vi.Identity[int](0); got != 0 {
> panic(got) } } } package p4 import ( "p1" "p3" ) // CheckSIdentity passes
> an S value to CheckIdentity. func CheckSIdentity() { p3.CheckIden
>
> But package p3 does not know anything about the type p1.S. There may be no
> other call to p1.S.Identity elsewhere in the program. We need to
> instantiate p1.S.Identity[int] somewhere, but how?
>
> The natural way would be to fetch instance sets (sets containing method
> implementations for any specified interface, here HasIdentity) as a matter
> of reflection.
>
> However, solving instance resolution over reflection alludes to the
> following questions:
>
>- Does reflection support generic instantiation?
>- Are generic types/functions are part of the runtime type information
>selectable for runtime reflection?
>- Are type to interface conformance relationships are part of the
>runtime type information?
>
> If all these questions can be answered by yes, then the case highlighted
> above is solvable.
>
> Alternatively, modulating the "CheckIdentity" function by the compiler to:
> func CheckIdentity(v interface{},
> hiddenHasIdentityInstanceContainingPointerToIdentityMethod) { if vi, ok :=
> v.(p2.HasIdentity); ok { if got := vi.Identity[int](0); got != 0 {
> panic(got) } } }
>
> serves providing an instance automatically by calling "CheckIdentity"
> function. This hidden parameter needs to be up-propagated to all callers
> passing p1.S down the caller-callee hierarchy.
>
> --
> 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/420e8a74-d9f8-4df9-9d7b-efffb642fbe8n%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/CAJhgaci2EutMD9dxpeiW%3DrKapyHUad7mSL7VxMjLVFt7NQXamA%40mail.gmail.com.
Re: [go-nuts] Workaround for No parameterized methods in go generics draft
On Thu, Jan 14, 2021 at 3:07 PM roger peppe wrote: > > FWIW I think that one possible approach to allowing methods (and potentially > function values) with type parameters might be to allow instantiating them > only with a limited set of "shapes" of data (for example, only pointer-like > types). Then I think there's the possibility that the method or function > could be compiled once for each allowed shape but still allow instantiation > with an arbitrary number of types, without the necessity to statically > enumerate all the possible types for that function. > >> We need to instantiate p1.S.Identity[int] somewhere, but how? > > > If one did something like the above, I guess you'd look up the implementation > by shape (8 bytes, non pointer) from the type info in the interface value, > then call the compiled function with the appropriate meta information based > on that. Details left as an exercise for the reader :) > > I don't see that reflection per se would need to be involved, any more than > reflection is involved when doing a dynamic type conversion. I don't think that approach would work for an implementation that re-compiles the generic function for each set of type arguments. There would be no implementation to select. And, of course, the specific GC shape required might be missing. I think that any choice we make here has to always work reliably. 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/CAOyqgcVo4LtwJYwFsxhsAODW5Rrcd7aSRtMR-uENFRF%3DBC0wvA%40mail.gmail.com.
