Re: [go-nuts] Re: Algorithm Club

2017-04-06 Thread Jesper Louis Andersen
On Fri, Mar 31, 2017 at 6:19 PM Michael Jones wrote: > There is part of the topic that has always been slightly beyond my grasp. > (Maybe I do understand...but just lack absolute certainty.) Maybe others > know the answer... > > In a template system (which is what I

Re: [go-nuts] Re: Algorithm Club

2017-04-06 Thread Will Faught
On Sat, Apr 1, 2017 at 12:11 AM, Egon Elbre wrote: > On Sat, Apr 1, 2017 at 1:42 AM, Will Faught wrote: > >> >>> For example []GenericElement could be boxed as: >>> >>> struct{ itab ptr; ... data []struct{elem ptr} } >>> or >>> []struct{itab, elem

Re: [go-nuts] Re: Algorithm Club

2017-03-31 Thread David Collier-Brown
In a previous life, this was one of the problems we had with generate-and-execute. In lisp, you could almost always create correct code and run it. With C, I could generate library interposers by the ton, but they only *usually* worked, so I had to generate unit tests, too. Fortunately I had

Re: [go-nuts] Re: Algorithm Club

2017-03-31 Thread Egon
On Friday, 31 March 2017 19:20:26 UTC+3, Michael Jones wrote: > > There is part of the topic that has always been slightly beyond my grasp. > (Maybe I do understand...but just lack absolute certainty.) Maybe others > know the answer... > > In a template system (which is what I prefer but that's

Re: [go-nuts] Re: Algorithm Club

2017-03-31 Thread Jan Mercl
On Fri, Mar 31, 2017 at 6:20 PM Michael Jones wrote: > I recalled it i the sort case because I wanted to kinds of typed clients for "<", the kind where !Less(a,b)&&!Less(b,a) === Equal(a,b), and the kind where that is not the case--and ideally--a way to have

Re: [go-nuts] Re: Algorithm Club

2017-03-31 Thread Michael Jones
There is part of the topic that has always been slightly beyond my grasp. (Maybe I do understand...but just lack absolute certainty.) Maybe others know the answer... In a template system (which is what I prefer but that's not the point of this email) we have the notion of the TYPE(s) being a

Re: [go-nuts] Re: Algorithm Club

2017-03-31 Thread Egon
On Friday, 31 March 2017 09:02:09 UTC+3, Will Faught wrote: > > >Because it can also be implemented in other ways. > > Do you mean interface{} can be implemented in other ways? I couldn't make > out your meaning. > There are multiple ways of implementing "boxing generics" and "interface{}".

Re: [go-nuts] Re: Algorithm Club

2017-03-31 Thread Will Faught
>Because it can also be implemented in other ways. Do you mean interface{} can be implemented in other ways? I couldn't make out your meaning. >As said... there is a performance upside for some other approaches. The other approaches have downsides, or at least generation does. Compared to

Re: [go-nuts] Re: Algorithm Club

2017-03-29 Thread Egon
On Thursday, 30 March 2017 03:15:33 UTC+3, Will Faught wrote: > > Egon: > > >See > https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#heading=h.j8r1gvdb6qg9 > > I don't see the Implicit Boxing section point out that this is what > happens now when you shoehorn

Re: [go-nuts] Re: Algorithm Club

2017-03-29 Thread Will Faught
Egon: >See https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi- HnNjkMEgyAHX4N4/edit#heading=h.j8r1gvdb6qg9 I don't see the Implicit Boxing section point out that this is what happens now when you shoehorn everything into interface{}. In this sense, I don't see a performance downside

[go-nuts] Re: Algorithm Club

2017-03-28 Thread Egon
On Tuesday, 28 March 2017 07:56:57 UTC+3, Will Faught wrote: > > Something I've never seen addressed in the generics tradeoffs debate (not > saying it hasn't been, but I haven't see it personally) > See

[go-nuts] Re: Algorithm Club

2017-03-27 Thread Will Faught
Something I've never seen addressed in the generics tradeoffs debate (not saying it hasn't been, but I haven't see it personally) is that without generics, you're forced to use interface{}, which just boxes the values anyway. So you're already paying a performance cost for type-agnostic code

Re: [go-nuts] Re: Algorithm Club

2017-03-27 Thread Jesper Louis Andersen
In addition, there are also the notion of "staging meta-compilation" as witnessed in e.g., BER-MetaOCaml. The idea is that if you want the best program efficiency, no compiler is able to carry out the needed optimizations. So you start meta-compiling by staging the compiler and generating code at

Re: [go-nuts] Re: Algorithm Club

2017-03-27 Thread David Collier-Brown
Folks, is this something that we should do with a template processor? More topically, is this a set of somethings that we should prototype each of, using templates? I'd love to see actual experiments in computer "science" (;-)) and a debate about the tradeoffs based on code. --dave On

Re: [go-nuts] Re: Algorithm Club

2017-03-27 Thread Michael Jones
Another dimension is "intellectual complexity." Where that is smaller, everything else is better for coding, documenting, debugging, testing, reading, using, and maintaining. It is a critical measure for maintaining the 'Go' of Go. On Sun, Mar 26, 2017 at 11:40 PM Egon

Re: [go-nuts] Re: Algorithm Club

2017-03-27 Thread Egon
On Monday, 27 March 2017 04:06:17 UTC+3, Mandolyte wrote: > > I agree that it makes the suitable trade-offs. And Linq is doing pretty > well without generics (https://github.com/ahmetb/go-linq); not familiar > with Rx. > > When I consider the dilemma, the two things I don't want are slow >

Re: [go-nuts] Re: Algorithm Club

2017-03-26 Thread Egon
On Sunday, 26 March 2017 05:15:10 UTC+3, Bakul Shah wrote: > > The simplest design I can think of (that does what you seem to > want) is to add parameterized packages. Here's a > stereotypical example: > > > package stack(T)// parameterized on stack element type > import

Re: [go-nuts] Re: Algorithm Club

2017-03-25 Thread Bakul Shah
The simplest design I can think of (that does what you seem to want) is to add parameterized packages. Here's a stereotypical example: package stack(T)// parameterized on stack element type import "fmt" type Type struct { rep []T func New() *Type { {} } func (stk *Type)Push(t

Re: [go-nuts] Re: Algorithm Club

2017-03-25 Thread David Collier-Brown
Hmmn, we may be thinking different things... I *think* I'm looking for a way to say "an X of Y", and see composition as a possible approach. I just don't know if it will be a, the, or not the answer (;-)) --dave On 24/03/17 11:21 PM, Michael Jones wrote: I think I was saying that what I seem

Re: [go-nuts] Re: Algorithm Club

2017-03-24 Thread Michael Jones
I think I was saying that what I seem to want personally is the "simple, weak, slight" thing that you likely see as failure. The opposite end of that--where everything is a list and can be composed without special regard (lisp) or everything is an object that can receive any message (smalltalk)

[go-nuts] Re: Algorithm Club

2017-03-24 Thread David Collier-Brown
We still don't understand genrality: the current generics are unimpressive. The proposals for Go are typically "let's do something that has failed already, in hopes that trying it agin will have a different result". That, alas, is one of the definitions of insanity. Due caution is advised!