Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

111–120 of 125 posts

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

#111

Post by jhomedall »

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…

> I'd be curious to see that.

https://twitter.com/joshbloch/status/822948565433466881

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

#112

Post by tapirl »

cowboysauce wrote: post #41
awb wrote: post #31

Earlier quoted context omitted.

Isn't interface{} a generic?

No, interface {} is more like void pointers in C and C++ or Object in C# and Java. It can hold values of any type. One of the major selling points of actual generics is that they provide type safety, but interface {} doesn't provide that.

unsafe.Pointer is the equivalent of C void pointer. interface{} is Any of Object in some other languages.

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

#113

Post by tomp »

reificator wrote: post #37
nemo1618 wrote: post #27

Earlier quoted context omitted.

Well, it's not quite fair to say it's "plain Go." The compiler converts expressions like x, ok := m["foo"] into function calls. User-level code can't define syntax sugar like that. Also, the hashmap implementation imports some internal packages, so you can't just copy and paste it. (I would know, because I mostly did copy and paste it for one of my own projects: https://github.com/lukechampine/randmap )

When discussing whether go has generics, "plain go" is a reasonable thing to say. Besides it's a compiler. It's going to take an input in format X and translate it to an output in format Y. That's just what they do. Syntactic sugar debates aside there's still no generics in there.

"generics" is mostly a matter of type system, not of implementation - as Java and this Go implementation showcase. Indeed, "untyped" generics is trivially implementable in Go, via `interface {}`, you just loes all the type safety (and you have to write more verbose code).

My point is, Go type system DOES support generics, but only for "primitive" types, not for user-defined types.

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

#114

Post by polymathist »

nemo1618 wrote: post #26
polymathist wrote: post #2

Author here. I've been working on Fo part time for 4 months. Feel free to ask me anything.

Hi there! I worked on something similar a while ago: a compile-to-Go superset that adds some generic functions/methods. You may have come across it: https://github.com/lukechampine/ply My perspective was that when I find myself wishing for generics in Go, what I really want is not full-blown generic types and functions, but rather a few helper functions like map/filter/reduce, or converting a map to a slice, etc. Hav…

Ply looks really cool! I can certainly understand the appeal of that kind of approach in terms of simplicity, stability, and better interop.

Local types are an edge case I'll need to spend more time working on. The type-checker won't have any problems; the real question is how to generate the appropriate Go code. One solution might be to move the local type into a higher scope during code-generation. Another might be inlining the relevant generic types in the same scope as the local type. Finally, the best solution might just be to say this sort of thing isn't allowed and the compiler will return an error.

Imports aren't supported right now, but it's one of the most important things I need to work on next. It'll be pretty tricky, but I'm confident I can find a solution.

The fortunate thing about the approach I'm using with Fo is that I have complete control over the parser, type-checker, and code-generator. At the cost of having significantly more complexity, I have the flexibility to tackle these sorts of edge cases without relying solely on existing tooling.

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

#115

Post by polymathist »

bakul wrote: post #44
polymathist wrote: post #2

Author here. I've been working on Fo part time for 4 months. Feel free to ask me anything.

Did you consider parameterized packages? The idea is you can declare a set of related objects/types/methods as well as have concrete type specific initialization. E.g. package stack[t] type Type []t func New() Type { return Type{} } ... Then it can be used so: import s “stack”[int] var s1 = s.New()

Parameterized packages are interesting but they come with their own problems. It can get tedious if I want to use, e.g., a stack with multiple different types. They also lose some of the flexibility that comes with scoping type parameters to any function/method/data structure.

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

#116

Post by polymathist »

politician wrote: post #3
polymathist wrote: post #2

Author here. I've been working on Fo part time for 4 months. Feel free to ask me anything.

What does the implementation look like under the hood? What are the limitations of your approach (i.e. generic interfaces) and are they fundamental or just on the todo list?

The Fo compiler parses and type-checks Fo source code and then generates and outputs Go code. It generates a unique concrete type for each usage of a generic type. You can look at the examples directory of the repo to see what this output looks like: https://github.com/albrow/fo/tree/master/examples/box.

Generic interfaces are pretty fundamental IMO. It's something I plan to add to the language before the v1 release.

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

#117

Post by polymathist »

weberc2 wrote: post #20
polymathist wrote: post #2

Author here. I've been working on Fo part time for 4 months. Feel free to ask me anything.

Any plans to add formal sum types (as opposed to interface hacks)?

Definitely something I'm thinking about. It's one of a handful of features that I have in my head but haven't created an issue for.

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

#118

Post by tree_of_item »

gowld wrote: post #33
awb wrote: post #31

Earlier quoted context omitted.

Isn't interface{} a generic?

That's reflection not generics. It's mostly the same denotational semantics, but much less efficient performance.

It's not the same semantics at all. Using the top type is not even close to using a type parameter.

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

#119

Post by polymathist »

leshow wrote: post #61
polymathist wrote: post #2

Author here. I've been working on Fo part time for 4 months. Feel free to ask me anything.

Can you do ad-hoc or bounded polymorphism? What about recursive types?

Yes, I've already been thinking about constraining type parameters to an interface. Internally, the type-checker considers type parameters to have underlying type interface {}. A constraint on a type parameter should be as straightforward as changing it's underlying type to a specific named interface instead of an empty one. The only tricky bit I can see is thinking about how this would work with generic interfaces or whether we should allow other kinds of type constraints (e.g., union types).
Post reply on HN