hOn Sun, 4 Nov 2018 at 12:09, Axel Wagner <axel.wagner...@googlemail.com>
wrote:
> On Sun, Nov 4, 2018 at 11:45 AM roger peppe <rogpe...@gmail.com> wrote:
>
>> One thing to consider: at any point in your program, someone might call
>> something like the following function with any value in scope:
>>
>> var vals []interface{}
>> func save(x interface{}) {
>> vals = append (vals, x)
>> }
>>
>> For the semantics of the generic program to be consistent, the values in
>> vals must have the exact concrete types of the instantiated generic values.
>>
>
>> I don't see that that is possible if a boxing approach is used like your
>> code snippets.
>>
>
>> For example, in your sum function, if save was called with the address of
>> x, the saved value would have type *interface{}, not *int.
>>
>
> I don't understand your point. The sum function doesn't contain anything
> like that and I'm not sure about the context you're implying.
>
This code, for example: https://play.golang.org/p/eaLHBbUJT-d
What might your generated code look like for that?
> If someone writes to the slice, you'd obviously pass more functions to it
> for those operations and the compiler can create appropriate closures to
> pass.
>
That's the problem I have with the solutions you're suggesting. The set of
required operation arguments is open ended and depends on all the generic
data structures that are used within the function and all generic functions
that that are called by it.
The code we've been using for an example is naively simple - any real code
would be much more complex. For example, your code is passing in a closure
that allows the code to get the index of one particular slice. But what if
the code creates another slice for itself? Presumably that would require
another operation function to be passed in. A slice of slices? That's
different and would require a different operation function, I think. What
if it defines a new type and puts a value in it? Another operation. Taking
the address of a value, calling a function value, putting a value into a
map, copying a value, ...? All different operations requiring their own
entry points. As the complexity of the generic code rises, so does the
number of closures that must be created to allow that code to do all the
things that it needs to do. I don't see that as a viable implementation
strategy.
Perhaps you might want to have a go at trying to translate a slightly more
substantial piece of generic code. For example, this generic implementation
of Dijkstra's algorithm: https://play.golang.org/p/BsktFSFVU0D. I'd be
interested to see what you end up with.
--
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.
For more options, visit https://groups.google.com/d/optout.
