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

Show HN: I implemented generics in my programming language

axe-docs.pages.dev

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Show HN: I implemented generics in my programming language

#11

Post by mikepurvis »

p0w3n3d wrote: post #2

This are merely instanceof switches. Generics mean that you write fun(a,b): return a+b and if the a + b is doable, it will be done. You don't need to specify the list of types that accepts this syntax. The difference between this and duck typing is that you can also specify interfaces (or traits in c++) that will say that this type is quackable so fun(a ): a.quack() is reusable. What is the difference between this an…

At least in C++ there's also the matter that the type switching happens at compile time, not runtime. You get a new instance of the function for each type that it's called with.

That's why C++ libraries with generic interfaces need to have their full implementations in the header or else have explicit instantiations for known supported types. If you compile the library first and the project later, there's no way of knowing at library-compile-time which instantiations of the generic will later be needed, and like, the types might not even exist yet at that point.

Re: Show HN: I implemented generics in my programming language

#12

Post by noelwelsh »

Someone wrote: post #8
one-punch wrote: post #4

You have implemented a form of ‘ad-hoc polymorphism’. This is different from ‘parametric polymorphism’, which is what people call generics.

I somewhat disagree. FTA: “If the callsite is some_function(2);, the compiler resolves T as i32 and selects the corresponding branch, returning the value incremented by one. […] The important point is that the decision is driven entirely by type information, not by runtime inspection” Given that, this isn’t that different from C generics ( https://en.cppreference.com/w/c/language/generic.html ), and people call that…

The key concept in "parametric polymorphism", which is what programming language nerds mean by generics, is "parametricity" [1]. This is basically the idea that all calls to a generic function should act in the same way regardless of the type of the actual concrete calls. The very first example breaks parametricity, as it multiplies for float, adds for i32, and isn't defined for other types.

It's implementation has the same issues as generics in Zig, which is also not parametric.

It's ok to explore other points in the design space, but the language designer should be aware of what they're doing and the tradeoffs involved. In the case of adhoc (non-parametric) polymorphism, there is a lot of work on type classes to draw on.

[1]: https://en.wikipedia.org/wiki/Parametricity

Re: Show HN: I implemented generics in my programming language

#14

Post by dragonwriter »

Towaway69 wrote: post #9

If I understand correctly, generics here are “type agnostic” functions in a strongly typed language? Why not just use a weakly typed language and add type checking were needed? It seems strange to put in so much effort for type checking then only to throw it overboard by implementing something that ignores type.

> If I understand correctly, generics here are “type agnostic” functions in a strongly typed language?

They are not.

They are applicable to a well-defined range of sets of input types, instead of a single specific type combination, and produce a well-defined output type for each input type combination.

> It seems strange to put in so much effort for type checking then only to throw it overboard by implementing something that ignores type.

Generics do not ignore types. That's kind of the whole point.

Re: Show HN: I implemented generics in my programming language

#15

Post by Someone »

noelwelsh wrote: post #12
Someone wrote: post #8

Earlier quoted context omitted.

I somewhat disagree. FTA: “If the callsite is some_function(2);, the compiler resolves T as i32 and selects the corresponding branch, returning the value incremented by one. […] The important point is that the decision is driven entirely by type information, not by runtime inspection” Given that, this isn’t that different from C generics ( https://en.cppreference.com/w/c/language/generic.html ), and people call that…

The key concept in "parametric polymorphism", which is what programming language nerds mean by generics, is "parametricity" [1]. This is basically the idea that all calls to a generic function should act in the same way regardless of the type of the actual concrete calls. The very first example breaks parametricity, as it multiplies for float, adds for i32, and isn't defined for other types. It's implementation has t…

I don’t see how that Wikipedia page supports your claim “The key concept in "parametric polymorphism", which is what programming language nerds mean by generics, is "parametricity"”. That page doesn’t even contain the character sequence “generic”.

IMO, https://en.wikipedia.org/wiki/Generic_programming is more appropriate. It talks of “data types to-be-specified-later”, something that this and C generic lack. That’s one of the reasons that I wrote “I _somewhat_ disagree”.

Also, I don’t see how one would define “act in the same way”. A function that fully acts in the same way regardless of the types of its arguments cannot do much with its arguments.

For example, a function “/” doesn’t act in exactly the same way on floats and integers in many languages (5.0/2.0 may return 2,5 while 5/2 returns 2; if you say it should return 2,5 instead you’re having a function from T×T to T for floats but a function from T×T to U for ints; why would you call that “act in the same way”?), “+” may or may not wrap around depending on actual type, etc.

Re: Show HN: I implemented generics in my programming language

#17

Post by tetha »

Towaway69 wrote: post #9

If I understand correctly, generics here are “type agnostic” functions in a strongly typed language? Why not just use a weakly typed language and add type checking were needed? It seems strange to put in so much effort for type checking then only to throw it overboard by implementing something that ignores type.

I'm assuming you meant statically/dynamically type checked languages.

Generic functions to not ignore types. An `inThere::a list -> a -> bool` very much enforces that the list passed in, as well as the element have the same type. With a sufficiently powerful type system, this allows for statically checked code that's not much less flexible than dynamically checked code.

Observing current developments in Python, but also Rust gives me the impression that dynamically typed languages were more a reaction to the very weak type systems languages like C or Java provided back in the day. A lot of Python code has very concrete or rather simple generic types for example - Protocols, Unions, First-class functions and Type parameters handle a lot. The tools to express these types better existed in e.g. Caml or Haskell, but weren't mainstream yet.

Re: Show HN: I implemented generics in my programming language

#18

Post by b33j0r »

You implemented type-checking. For a project this ambitious, I am surprised here.

“Generics” should mean that the compiler or interpreter will generate new code paths for a function or structure based on usage in the calling code.

If I call tragmorgify(int), tragmorgify(float), or tragmorgify(CustomNumberType), the expectation is that tragmorgify(T: IsANumber) tragmorgifies things that are number-like in the same way.

For a compiled language this usually means monomorphization, or generating a function for each occurring tuple of args types. For an interpreted language it usually means duck-typing.

This is not a bad language feature per se, but also not what engineers want from generics. I would never write code like your example. The pattern of explicit type-checking itself is a well-known codesmell.

There is not a good usecase for adding 2.0 to a float input but 1 to an integer input. That makes your function, which should advertise a contract about what it does, a liar ;)

Re: Show HN: I implemented generics in my programming language

#19

Post by p0w3n3d »

mikepurvis wrote: post #11
p0w3n3d wrote: post #2

This are merely instanceof switches. Generics mean that you write fun(a,b): return a+b and if the a + b is doable, it will be done. You don't need to specify the list of types that accepts this syntax. The difference between this and duck typing is that you can also specify interfaces (or traits in c++) that will say that this type is quackable so fun(a ): a.quack() is reusable. What is the difference between this an…

At least in C++ there's also the matter that the type switching happens at compile time, not runtime. You get a new instance of the function for each type that it's called with. That's why C++ libraries with generic interfaces need to have their full implementations in the header or else have explicit instantiations for known supported types. If you compile the library first and the project later, there's no way of k…

You're right, C++ generic implementation is different than Java for example. That's why it was hard for me to nail the features the generic should have in general... C++ is more like duck typing with precompiled checking i.e. If you have no traits you still get integers summed for example because the generated code from the headers is compilable. On Java it's different: all the generics have types erased and there is typecasting later, unless they are inherited by other types

Re: Show HN: I implemented generics in my programming language

#20

Post by mikepurvis »

p0w3n3d wrote: post #19
mikepurvis wrote: post #11

Earlier quoted context omitted.

At least in C++ there's also the matter that the type switching happens at compile time, not runtime. You get a new instance of the function for each type that it's called with. That's why C++ libraries with generic interfaces need to have their full implementations in the header or else have explicit instantiations for known supported types. If you compile the library first and the project later, there's no way of k…

You're right, C++ generic implementation is different than Java for example. That's why it was hard for me to nail the features the generic should have in general... C++ is more like duck typing with precompiled checking i.e. If you have no traits you still get integers summed for example because the generated code from the headers is compilable. On Java it's different: all the generics have types erased and there is…

I'm not a Java person, but my understanding is that in Java everything is boxed anyway, so the implementation of the "generic" logic is always just dealing with a pointer-sized entity and it's a matter of whether the dereferenced object on the other end of that has the required fields/methods.
Post reply on HN