fromList?

А, там есть перегрузка

и она уже прямо в либе есть

👍

Бро

🌚

Это ж конструктор

Полностью согласен

оба - конструктор

один и тот же

Ну, так-то да

это синоним шаблона, притворяющийся конструктором

(:=) — инфиксный,
(,) — пре-ин-пост-фиксный

есть вариант
[ (,) k1 v1
, (,) k2 v2
]
но это ещё хуже

тут ещё скобки нужны будут, если они выражения

Доброго времени суток.
Написал простой сервис для манипуляций с изображениями: изменение размера + поворот в соответствии с exif-ориентацией. Сделал простой DSL на основе Free Monad так, чтобы можно было на уровне интерпретатора DSL использовать разные графические библиотеки. Поскольку каждая библиотека имеет своё внутреннее представление изображения, то нужно было как-то его упаковать в некий тип картинки для DSL. Первое, что попробовал, это

import Data.Dynamic
type Img = Dynamic

Все хорошо заработало. Но подумал, что слишком много получается преобразований в/из Dynamic. Решил переделать на

newtype Img a = Img a

Соответственно пришлось добавить параметр типа a к тайпклассу абстрактного интерпретатора. Так тоже заработало, количество кода сократилось, так как преобразования из Dynamic заменились простым паттерн-матчингом. Но самое интересное в том, что при тестировании производительности на одной и той же картинке скорость работы сервиса оказалась в разы лучше при использовании Dynamic. И даже программирование "в лоб" без DSL дало хуже результат, чем реализация через DSL с Dynamic. Мне казалось, что использования newtype должно наоборот сократить время доступа к содержимому картинки. Но практика показало обратное. Кто-нибудь может объяснить такое поведение? Может тайпклассы с несколькими параметрами тормозят? Или такое поведение вполне правильное, просто я чего-то не знаю/не понимаю?

Это довольно странно. А что профайлинг говорит?

Ну, вообще Data.Dynamic не то чтобы дорогой, но быстрее от него становиться не должно было бы

Я не знаю, что такое профайлинг. Как это посмотртеть?

как запускаете приложение? cabal build, cabal run, иное?