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
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
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
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
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
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
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{}".
>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
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
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
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
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
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
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
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
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
>
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
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
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
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)
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!
21 matches
Mail list logo