reflect-based go interpreter

[Sebastien Binet]

hi there,

I (think I) attentively read CLs:
https://codereview.appspot.com/6572043
https://codereview.appspot.com/7716048

which basically introduce functions to create arrays, channels, maps
and slices from already existing reflect.Type values.
(although ArrayOf won't be exposed for go-1.1, btw: why? it's not
clear from the 2 above CLs)

I strongly suspect this won't happen for go-1.1 but is having a:

func StructOf(fields []StructField) Type

method in the roadmap ?

that would definitely opens up the possibility to create a
reflect-based go interpreter (which would be more in-sync' with the
underlying go implementation than what go-eval is - always lagging and
all)

-s

[Dan Kortschak]

On Wed, 2013-03-27 at 11:52 +0100, Sebastien Binet wrote:
> (although ArrayOf won't be exposed for go-1.1, btw: why? it's not
> clear from the 2 above CLs)

I think this is the reason (reflect/type.go) - proper garbage
collection:

1475 // TODO(rsc): Unexported for now. Export once the alg field is set correctly
1476 // for the type. This may require significant work.

[Ian Lance Taylor]

On Wed, Mar 27, 2013 at 3:52 AM, Sebastien Binet <seb....@gmail.com> wrote:
>
> I (think I) attentively read CLs:
> https://codereview.appspot.com/6572043
> https://codereview.appspot.com/7716048
>
> which basically introduce functions to create arrays, channels, maps
> and slices from already existing reflect.Type values.
> (although ArrayOf won't be exposed for go-1.1, btw: why? it's not
> clear from the 2 above CLs)

As Dan noted, this is because we haven't yet implemented the correct
garbage collection algorithm for an array type generated at runtime.
For channels, maps, and slices this is easy as the garbage collection
algorithm is always basically the same. For array types we need to
actually do some work. It's feasible but hasn't been done yet.

> I strongly suspect this won't happen for go-1.1 but is having a:
>
> func StructOf(fields []StructField) Type
>
> method in the roadmap ?
>
> that would definitely opens up the possibility to create a
> reflect-based go interpreter (which would be more in-sync' with the
> underlying go implementation than what go-eval is - always lagging and
> all)

I think we will get there eventually but not for Go 1.1. The issue is
that the runtime currently requires that two identical types use the
same pointer for the type descriptor, hence all the typelinks stuff.
We have to ensure that if the program defines a struct, and somebody
calls reflect.StructOf with the same field names and types, that we
wind up with the same pointer. Maybe the typelinks mechanism will
also work for structs; I'm not sure. Plus of course we will need to
implement the correct gc algorithm.

Ian

[Sebastien Binet]

Dan, Ian,

thanks for the infos.

-s