Show HN: Fo: An experimental language which adds generics on top of Go

Post by ereyes01 » Tue, Jun 12, 2018, 10:41 PM UTC

anonymoushn wrote: post #91

ereyes01 wrote: post #88

Earlier quoted context omitted.

After only a quick glance at your code, I'd try to tackle it by wrapping my own interface around the different image types (which you could argue the image standard lib should've already done for you). The interface will define CreateWeights and Resize operations. Each implementing type will consist of a struct with an embedded field of each image type you're handling, and passthrough calls to the underlying function…

Image allows you to do this more or less. The problem to be solved here is that if you write the resize logic just once, you are accessing pixels from the image via the interface in a tight loop, and most of the time taken by your image resizer is the overhead of that access.

Post by jstimpfle » Tue, Jun 12, 2018, 11:07 PM UTC

ben509 wrote: post #79

jstimpfle wrote: post #55

Nice work. But, serious question - When going with parameterized types I know from Haskell how you always end up needing one more language extension and always end up banging your head against the wall that separates types and values a little more. At least if you're not a math genius, but probably even then. And from Java I know that there's a pretty trivial example that showcases how its Generics implementation is…

Haskell is a proving ground, so it's picked up a number of ideas that never quite panned out. I think you can identify a core set of features that are pretty reasonable. I think that'd be type classes, constraints, and functional dependencies. If they made a handful of extensions standard (GADTs, etc.) it would mostly Do What You Want without a lot of prodding. > And from Java I know that there's a pretty trivial exa…

    const int **pp2;
    int *p1;
    const int n = 13;
 
    pp2 = &p1; /* not allowed, but suppose it were */
    *pp2 = &n; /** valid, both const, but sets p1 to point at n */
    *p1 = 10;  /* valid, but changes const n */

Post by bakul » Tue, Jun 12, 2018, 11:26 PM UTC

marcrosoft wrote: post #81

bakul wrote: post #75

Earlier quoted context omitted.

Try implementing a shared map type where access is protected by a mutex and otherwise works just like Go's builtin map type (which is a generic map type).

Why would I need to re-implement what is already there?

  x := reduce(func(a, b int)int{return a*b}, []int[1,2,3])
  y := reduce(func(a, b string)string{return a+b}, []string{"a", "b", "c"})

Post by skj » Tue, Jun 12, 2018, 11:34 PM UTC

jimbokun wrote: post #72

marcrosoft wrote: post #69

Earlier quoted context omitted.

I've been working full time in Go since 2012. I've never had a use for generics.

And I've read about many people using Go and wishing for generics from day one.

Post by burntsushi » Wed, Jun 13, 2018, 1:12 AM UTC

ereyes01 wrote: post #92

anonymoushn wrote: post #91

Earlier quoted context omitted.

Image allows you to do this more or less. The problem to be solved here is that if you write the resize logic just once, you are accessing pixels from the image via the interface in a tight loop, and most of the time taken by your image resizer is the overhead of that access.

Interesting, you have a point actually. I would have thought that the performance cost of calling through an interface would be negligible, but I'm wrong about that: https://github.com/golang/go/issues/20116 The issues linked at the end there are interesting reads, and maybe they'll do something about this by Go 1.11. Having said all that, will an implementation of your code with generics be all that much faster? Or…