4 ms·

So, let me phrase my criticism as questions :) How do you declare methods on non-struct types? Or are you disallowing defining your own non-struct types? It se

So, let me phrase my criticism as questions :) How do you declare methods on non-struct types? Or are you disallowing defining your own non-struct types? It seems to me that the method-syntax you introduced will either be a step back, because it disallows non-struct types, or it will be a step back because it makes method declaration inconsistent. 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. How is the overloading of make handled (assuming it's actually just implemented with the existing generic mechanisms)? It can take between 1 and 3 arguments and does vastly different things to them depending on the type parameter. The latter part might be handled by your specialization mechanism (with considerable runtime overhead for a very central part of the language), but the former is not described. Overall, I admire implementing a language as a hobby project (I always wanted to do that myself). But I don't see anything that would compel a significant share of people to migrate over either from python or from go. It doesn't come close to python's expressiveness and it also lacks go's simple and orthogonal design. It seems to me, that you added a few things that are better addressed (and will be addressed) in an eventual go2 and then more or less arbitrarily changed a bunch of things for personal taste. The result feels a bit patchworky; your generics have even more overlap with interfaces than people have feared about a go addition (which is one of the major reasons it doesn't have them) due to the type-switchy-when and the syntax changes create a bunch of inconsistencies. Still. Plow forwards :) There can only come good of more stuff in the world :)

wowoc 10y 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.
- cbHXBY1D 10y 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?
  - wowoc 10y ago
    Sure, the AST node for "when" is here: https://github.com/vrok/have/blob/master/have/ast.go#L159 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#L728 https://github.com/vrok/have/blob/master/have/generator.go#L...
- NateDad 10y 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.
  - wowoc 10y 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.
- Merovius 10y 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?

wowoc 10y 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.

cbHXBY1D 10y 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?
- wowoc 10y ago
  Sure, the AST node for "when" is here: https://github.com/vrok/have/blob/master/have/ast.go#L159 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#L728 https://github.com/vrok/have/blob/master/have/generator.go#L...
NateDad 10y 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.
- wowoc 10y 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.
Merovius 10y 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?