Hacker News new | ask | show | jobs
by wowoc 3563 days ago
> How do you declare methods on non-struct types? Or are you disallowing defining your own non-struct types?

It will be allowed, through type opening (which isn't implemented yet). It's mentioned in the intro, I called it "structure opening" but actually it will work on any non-builtin named type.

I'm not sure how the syntax will look like yet, but say that you have a struct:

  struct A:
    func MethodA():
      pass
Then you will be able to open it and add new methods to it, it could look like this:

  open A:
    func MethodB():
      pass
> How are the generics implemented? The general tone seems to suggest that you do naive template expansion, but the section about when makes it seem that you are using interface{} and type-assertions in the generated code.

No, it's closer to template expansion, "when" is "executed" (for lack of a better word) during compilation. Inactive "when" branches are ignored by the code generator (and type checker, thus they can contain code that's invalid for given instantiation). There's no type-switch in the resulting Go code.

> How is the overloading of make handled (assuming it's actually just implemented with the existing generic mechanisms)?

Right now it's not handled at all. I don't want to add default argument values to the language, so, unless I come up with something better, I'm afraid that there will need to be more than one "make" function, each named differently.

Thanks for your feedback! I'm well aware that the chances of Have becoming popular are tiny, but I'm having lots of fun working on it anyway.
4 comments
Merovius 3562 days ago
> No, it's closer to template expansion, "when" is "executed" (for lack of a better word) during compilation. Inactive "when" branches are ignored by the code generator (and type checker, thus they can contain code that's invalid for given instantiation). There's no type-switch in the resulting Go code.

As I've now understood better what you mean, let me suggest a possible solution to your default-case conundrum: What about, if I don't want to allow the default-case, I just leave out the default case? And the compiler erroring out, if you pass in a type to a when-statement that doesn't have a valid case defined?

link
cbHXBY1D 3562 days ago
> No, it's closer to template expansion, "when" is "executed" (for lack of a better word) during compilation. Inactive "when" branches are ignored by the code generator (and type checker, thus they can contain code that's invalid for given instantiation). There's no type-switch in the resulting Go code.

I'm not sure I understand. Could you point to where you do this on Github?

link
wowoc 3562 days ago
Sure, the AST node for "when" is here: https://github.com/vrok/have/blob/master/have/ast.go#L159

Type checker checks the condition before every branch in "when" statements, and sets the "True" flag if it evaluated to true.

Then the code generator just skips over branches that don't have the "True" flag set: https://github.com/vrok/have/blob/master/have/generator.go#L...

link
NateDad 3562 days ago
Not quite sure why this isn't just

  type foo int:
      func MethodA():
          pass
Analagous to this:

  type foo int
  func (foo) MethodA(){}
Why opening and all that? Or is that a way to add methods to types outside the current package? If so, you're opening up a whole new can of worms.
link
wowoc 3562 days ago
Your example looks good as well. Opening gives more flexibility with how the code can be structured, say that you have two interfaces:

  type I interface {
    A()
  }

  type J interface {
    B()
  }
And you have two structs that implement them, you can then group methods from the same interface together:

  type X struct{}
  type Y struct{}

  func (x X) A() {}
  func (y Y) A() {}

  func (x X) B() {}
  func (y Y) B() {}
I've seen that used in the Golang codebase, and sometimes it does seem useful.
link
wnoise 3562 days ago
Why the exception for built-in types?
link
perfmode 3562 days ago
I think it might be because you can't define methods on built-in types.

func (s *[]string) Foo() is not valid.

func (m map[int]string) Bar() is not valid.

link
wowoc 3562 days ago
That too, but I rather meant predeclared named types. According to Go specification, types that you define with "type Name OldName" are named, but "int", "string" and the rest are named too. Go disallows declaring methods on predeclared types.

https://golang.org/ref/spec#Types

link