4 ms·

Yeah I like a lot of what I see. The compile-time metaprogramming looks nice and it would be good if I had a project to try it out for :) Zig Programming Lang

by chubot 8y ago

Yeah I like a lot of what I see. The compile-time metaprogramming looks nice and it would be good if I had a project to try it out for :) Zig Programming Language Blurs the Line Between Compile-Time and Run-Time https://andrewkelley.me/post/zig-programming-language-blurs-line-compile-time-run-time.html https://andrewkelley.me/post/zig-programming-language-blurs-... Now that I think of it, I wonder if Go could take the approach of Zig for generics, or at least for containers. Look at how they express List(i32) there. It seems like a much more Go-like approach than say what Swift or Rust do for containers and generics. Like Go, Zig seems to have no classes, only functions and structs. It does seem like many newer languages have complicated type systems and long compile times. I think Zig has an interesting alternative approach, although I would have to use it more to really make an judgement.

lifthrasiir 8y ago
It should be mentioned that Zig's approach is not really generics (at least in the PL sense); one cannot determine the characteristics (or even validity) of `List(i64)` from `List(i32)`, much like that one cannot predict the behavior `f(3)` from `f(2)` for an arbitrary function `f`. This approach, technically termed ad hoc polymorphism (i.e. polymorphism without type system support), is not necessarily bad---as C++ had been fine for decades---but can have some disadvantages w.r.t. compile time (yes, you heard right) or binary bloat.
- bjz_ 8y ago
  > This approach, technically termed ad hoc polymorphism (i.e. polymorphism without type system support) Note that Haskell and Rust (and other languages) have adhoc polymorphism _with_ type system support via type classes/traits. I would class this more as 'duck-typed templates'. > or binary bloat. This is an orthogonal issue, to do with whether instantiations of parameterized types/functions are monomorphised or not. I would say the big issue with templates is that they are slow and produce hard-to decipher compile-time stack traces, because they are not checked at the instantiation site.
  - lifthrasiir 8y ago
    > I would class this more as 'duck-typed templates'. Or parametrically polymorphic type variables! > This is an orthogonal issue, to do with whether instantiations of parameterized types/functions are monomorphised or not. I stand corrected, as monomorphization is optional for parametric polymorphism but mandatory for ad hoc polymorphism. It is still technically possible to deduplicate similar enough functions, either at the source level or at the binary level, but that is orthogonal to this issue :-) > I would say the big issue with templates is that they are slow and produce hard-to decipher compile-time stack traces, because they are not checked at the instantiation site. You are right for the status quo of C++ templates, but I'm not sure for general cases. It might be possible to keep error information down to the instantiation site for better error messages... or not.
    - coldtea 8y ago
      >I stand corrected, as monomorphization is optional for parametric polymorphism but mandatory for ad hoc polymorphism. It is still technically possible to deduplicate similar enough functions, either at the source level or at the binary level, but that is orthogonal to this issue :-) Regarding this bloat thing, are monomorphized functions ever generated for types/signatures that are not actually _used_ in the program? If not, it's not really bloat, is it? It's what one would do themselves without generics, if they wanted to be able to use them with full speed.
      - lifthrasiir 8y ago
        > It's what one would do themselves without generics, if they wanted to be able to use them with full speed. Right, but in many cases they can be combined without much speed penalty. For example you can combine monomorphized functions when you only rely on methods that are expected to be costly and inlining has a negligible effect. With actual, not ad hoc, generics you may (hopefully) have a control over monomorphization---I think Rust's trait object is a good design for this reason.
    - bjz_ 8y ago
      > I stand corrected, as monomorphization is optional for parametric polymorphism but mandatory for ad hoc polymorphism. It's not mandatory for ad-hoc polymorphism. Haskell desugars ah-hoc polymorphism to dictionary passing (although it often does inlining to reduce the overhead of this).

by chubot 8y ago

lifthrasiir 8y ago

It should be mentioned that Zig's approach is not really generics (at least in the PL sense); one cannot determine the characteristics (or even validity) of `List(i64)` from `List(i32)`, much like that one cannot predict the behavior `f(3)` from `f(2)` for an arbitrary function `f`. This approach, technically termed ad hoc polymorphism (i.e. polymorphism without type system support), is not necessarily bad---as C++ had been fine for decades---but can have some disadvantages w.r.t. compile time (yes, you heard right) or binary bloat.

bjz_ 8y ago
> This approach, technically termed ad hoc polymorphism (i.e. polymorphism without type system support) Note that Haskell and Rust (and other languages) have adhoc polymorphism _with_ type system support via type classes/traits. I would class this more as 'duck-typed templates'. > or binary bloat. This is an orthogonal issue, to do with whether instantiations of parameterized types/functions are monomorphised or not. I would say the big issue with templates is that they are slow and produce hard-to decipher compile-time stack traces, because they are not checked at the instantiation site.
- lifthrasiir 8y ago
  > I would class this more as 'duck-typed templates'. Or parametrically polymorphic type variables! > This is an orthogonal issue, to do with whether instantiations of parameterized types/functions are monomorphised or not. I stand corrected, as monomorphization is optional for parametric polymorphism but mandatory for ad hoc polymorphism. It is still technically possible to deduplicate similar enough functions, either at the source level or at the binary level, but that is orthogonal to this issue :-) > I would say the big issue with templates is that they are slow and produce hard-to decipher compile-time stack traces, because they are not checked at the instantiation site. You are right for the status quo of C++ templates, but I'm not sure for general cases. It might be possible to keep error information down to the instantiation site for better error messages... or not.
  - coldtea 8y ago
    >I stand corrected, as monomorphization is optional for parametric polymorphism but mandatory for ad hoc polymorphism. It is still technically possible to deduplicate similar enough functions, either at the source level or at the binary level, but that is orthogonal to this issue :-) Regarding this bloat thing, are monomorphized functions ever generated for types/signatures that are not actually _used_ in the program? If not, it's not really bloat, is it? It's what one would do themselves without generics, if they wanted to be able to use them with full speed.
    - lifthrasiir 8y ago
      > It's what one would do themselves without generics, if they wanted to be able to use them with full speed. Right, but in many cases they can be combined without much speed penalty. For example you can combine monomorphized functions when you only rely on methods that are expected to be costly and inlining has a negligible effect. With actual, not ad hoc, generics you may (hopefully) have a control over monomorphization---I think Rust's trait object is a good design for this reason.
  - bjz_ 8y ago
    > I stand corrected, as monomorphization is optional for parametric polymorphism but mandatory for ad hoc polymorphism. It's not mandatory for ad-hoc polymorphism. Haskell desugars ah-hoc polymorphism to dictionary passing (although it often does inlining to reduce the overhead of this).