Ценой медленной арифметики в корректных бранчах?

I am writing this because I care about Haskell community. I want GHC and Haskell to be widely used. Right now, the only thing I hear from all companies around our company is that impredicative performance, even when following rules "how to write efficient code" is the biggest pain people have. Haskell is gathering attention - pure functional programming, immutability etc - are great. But it will not become a popular choice unless we care about predictive performance. Such performance changes are unacceptable when thinking about Haskell and GHC as production ready systems. We need a clear way how to write high performance Haskell without the need to benchmark every part of our programs even when refactoring things. GHC has enough information to discover that we want high performance here and there (even by looking at INLINE pragmas) and should warn us about lack of optimization. We should also have a way to force GHC to apply optimizations in particular places - for example by explicit marking code to be always specialized during compilation, so GHC would never fall back to dict-passing in such places. Such possibility would solve MANY related problems and user fears.

0

15.11.2021

Max Avanov

Nutritional Rabbit
I am writing this because I care about Haskell com...

в зануда-mode я бы сказал, что мне в целом не важно какой там Num будет использовать компилятор под капотом, если он видит что хватит Int или даже Int32, то так тому и быть, но снаружи-то инварианты длины должны поддерживаться системой типов, разве нет?

0

15.11.2021

Max Avanov

Aleksei (astynax) Pirogov
Ну вон, корректные агды у вас есть

кто нанимает по Агде или Идрису?

0

15.11.2021

Aleksei (astynax) Pirogov Автор вопроса

Max Avanov
кто нанимает по Агде или Идрису?

Кто-то нанимает на "корректно вместо быстро"?

0

15.11.2021