Product Launch
anonymous
31 points
15 comments
Posted19 days agoActive10 days ago
Generics
axe-docs.pages.devmvplibrarydevelopers
Key Features
generic functions
Tech Stack
Axe programming language
programming languagesgenerics
Key Features
Tech Stack
fun(a,b): return a+b
fun(a <? implements Quackable>): a.quack()
class <T has trait Number> Complex(a T, b T):
Complex<T> operator+(Complex<T> other): return new Complex(this.a + other.a, this.b+other.b)
Complex<T> operator-(Complex<T> other): return new Complex(this.a - other.a, this.b-other.b)
Complex<T> operator*(Complex<T> other):
return Complex(this.a * other.a - this.b * other.b, this.a * other.b + this.b * other.a)
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.
Not true, there's int and Integer.
This is different from ‘parametric polymorphism’, which is what people call generics.
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.
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.
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.
One of my pet-hates is fellow developers who call an implementation 'generic', but when you peek inside, there's just if-statements that (at best) cover the already-known input types.
Usually I point to Generics as an example of what "generic" actually means: You peek inside List<T>, it doesn't know about your type, it does the right thing anyway.
Your list_contains function should be able to just do a == comparison regardless of whether it's an int or a string.
This is effectively no different than adding a parameter to one of your non-"generic" functions and just swapping behaviour based on that?
“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 ;)
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.