On Mon, 5 Nov 2018 at 10:21, Axel Wagner
wrote:
> Even though all we did was save some references to values, the code has
>> radically changed (along with its runtime implications).
>>
>
> you'd choose a suitable small subset based on the type-constructors used
> in the signature.
>
For the
>
> Even though all we did was save some references to values, the code has
> radically changed (along with its runtime implications).
>
Because I am lazy and simply trying to illustrate how this can be done. I
was trying to achieve consensus, not to implement generics and I never
pretended that
On Mon, 5 Nov 2018 at 02:35, Axel Wagner
wrote:
> On Sun, Nov 4, 2018 at 10:14 PM roger peppe wrote:
>
>> This code, for example: https://play.golang.org/p/eaLHBbUJT-d
>> What might your generated code look like for that?
>>
>
> A bit ad-hoc, but WAI: https://play.golang.org/p/vuCHY2RRxIR
>
>
On Sun, Nov 4, 2018 at 10:14 PM roger peppe wrote:
> 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
On Sun, Nov 4, 2018 at 10:14 PM roger peppe wrote:
> This code, for example: https://play.golang.org/p/eaLHBbUJT-d
> What might your generated code look like for that?
>
A bit ad-hoc, but WAI: https://play.golang.org/p/vuCHY2RRxIR
In practice, of course, most of these wouldn't be actually
hOn Sun, 4 Nov 2018 at 12:09, Axel Wagner
wrote:
> On Sun, Nov 4, 2018 at 11:45 AM roger peppe 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
On Sun, Nov 4, 2018 at 11:45 AM roger peppe 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)
>}
>
>
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
Sorry, should've added what I consider the source:
https://play.golang.org/p/3_um7p3IxwK
On Thu, Oct 25, 2018 at 10:09 AM Axel Wagner
wrote:
> Sure: https://play.golang.org/p/W_ruqI22Vhv
> Seems a fairly straight-forward transformation to me - and again easy to
> devirtualize.
>
> On Thu, Oct
Sure: https://play.golang.org/p/W_ruqI22Vhv
Seems a fairly straight-forward transformation to me - and again easy to
devirtualize.
On Thu, Oct 25, 2018 at 8:56 AM roger peppe wrote:
>
> On Thu, 25 Oct 2018, 12:52 am Axel Wagner,
> wrote:
>
>> On Thu, Oct 25, 2018 at 12:39 AM roger peppe
On Thu, 25 Oct 2018, 12:52 am Axel Wagner,
wrote:
> On Thu, Oct 25, 2018 at 12:39 AM roger peppe wrote:
>
>> I understand this argument. By putting some smarts into the compiler, we
>> would hope that we can see benefits not just in our generated generic code,
>> but also in other code that
On Thu, Oct 25, 2018 at 12:39 AM roger peppe wrote:
> I understand this argument. By putting some smarts into the compiler, we
> would hope that we can see benefits not just in our generated generic code,
> but also in other code that we've already written that uses generics. This
> would be
On Sun, 21 Oct 2018 at 13:53, Axel Wagner
wrote:
> Last addition:
>
> On Sun, Oct 21, 2018 at 2:03 PM roger peppe wrote:
>
>> Ah, I *think* I see where you might be coming from now. You're thinking
>> that the compiler could do some kind of Go-to-Go transformation for generic
>> functions so
On Sun, 21 Oct 2018 at 13:40, Axel Wagner
wrote:
> On Sun, Oct 21, 2018 at 2:03 PM roger peppe wrote:
>
>> Yes. The draft proposal says "generic functions, rather than generic
>> types, can probably be compiled using an interface-based approach. That
>> will optimize compile time, in that the
Last addition:
On Sun, Oct 21, 2018 at 2:03 PM roger peppe wrote:
> Ah, I *think* I see where you might be coming from now. You're thinking
> that the compiler could do some kind of Go-to-Go transformation for generic
> functions so that they looked exactly as if they'd been written using
>
On Sun, Oct 21, 2018 at 2:03 PM roger peppe wrote:
> Yes. The draft proposal says "generic functions, rather than generic
> types, can probably be compiled using an interface-based approach. That
> will optimize compile time, in that the package is only compiled once, but
> there will be some
On Sat, 20 Oct 2018 at 11:37, Axel Wagner
wrote:
>
> Thank, I feel I can work with this :)
>
> On Sat, Oct 20, 2018 at 10:58 AM roger peppe wrote:
>
>> That transformation might be valid for the simple case you have there,
>> where there's a single parameter of exactly the interface type, but
Thank, I feel I can work with this :)
On Sat, Oct 20, 2018 at 10:58 AM roger peppe wrote:
> That transformation might be valid for the simple case you have there,
> where there's a single parameter of exactly the interface type, but generic
> functions allow much more than that. You can have
On Fri, 19 Oct 2018 at 22:41, Axel Wagner
wrote:
> As I said, I don't really understand why we disagree here - or what we are
> even disagreeing about. So let me make my claim as precise as possible, in
> the hope that it at least helps me understand which particular part you are
> disagreeing
As I said, I don't really understand why we disagree here - or what we are
even disagreeing about. So let me make my claim as precise as possible, in
the hope that it at least helps me understand which particular part you are
disagreeing with. I claim:
a) w.l.o.g. we can ignore operators
On Fri, 19 Oct 2018 at 12:04, roger peppe wrote:
> The algorithm to do it is quite straightforward:
> https://play.golang.org/p/subnLkSSxdI
>
On reflection, that ParamType hack won't work correctly with
types.Identical. This should work better:
https://play.golang.org/p/iswgf7mr8ht
>
--
You
On Thu, 18 Oct 2018 at 13:41, Axel Wagner
wrote:
> On Thu, Oct 18, 2018 at 2:06 PM roger peppe wrote:
>
>> For generics, that analysis is trivial - there is no need to do any
>> control flow analysis to determine the set of possible generic type
>> parameters to a type or function (with the
On Thu, Oct 18, 2018 at 2:06 PM roger peppe wrote:
> For generics, that analysis is trivial - there is no need to do any
> control flow analysis to determine the set of possible generic type
> parameters to a type or function (with the exception of recursive generic
> functions, which can be
On Thu, 18 Oct 2018 at 08:40, Axel Wagner
wrote:
> On Thu, Oct 18, 2018 at 9:16 AM roger peppe wrote:
>
>> The difference is that for generics, you *always* know the exact set of
>> possible types that a type parameter can be.
>>
>
> If and only if you choose to do that analysis. AFAIK it is
On Thu, Oct 18, 2018 at 9:16 AM roger peppe wrote:
> The difference is that for generics, you *always* know the exact set of
> possible types that a type parameter can be.
>
If and only if you choose to do that analysis. AFAIK it is not currently
planned to do that
On Thu, 18 Oct 2018 at 06:44, Axel Wagner
wrote:
> This is only tangentially related to your specific idea, but I've decided
> that for generics discussions this is the hill I'm dying on:
>
> On Wed, Oct 17, 2018 at 6:44 PM roger peppe wrote:
>
>> The method calls in question can be inlined
This is only tangentially related to your specific idea, but I've decided
that for generics discussions this is the hill I'm dying on:
On Wed, Oct 17, 2018 at 6:44 PM roger peppe wrote:
> The method calls in question can be inlined because everything is known
> statically, so there's
I don't think you even need contracts as such at this point; you can do
a cast without them, so you just need to be able to specify a method set
on type parameters. I would be interested to hear your thoughts on the
proposal I wrote up on how to do this:
While thinking about the draft generics proposal and the complexity of
contracts, it occured to me that if you relax some of the restrictions on
type conversion, it's possible to make data structures containing basic
types amenable to generic algorithms.
Once upon a time, the Go specification
29 matches
Mail list logo
