Не совсем понял: 1. В предыдущих лекциях, когда разбиралась нормальная/аппликативная стратегия редукции терма - то было сказано, что хаскелль редуцирует нормально. 2. Сказано, что сопоставление с образцом форсирует вычисление => имеем аппликативную стратегию. Противоречие?
Зачем нужно было все это творить с PointDouble? Нельзя было написать так f :: (Double, Double) -> (Double, Double) -> (Double, Double) f (x1, y1) (x2, y2) = ((x1 + x2)/2, (y1 + y2)/2) Или это просто для того, чтобы показать пример работы?
+Корыто Можно, тип гомогенной пары эквивалентен нашему PointDouble. Однако использовать кортежи повсюду не очень рекомендуется - пользовательские типы данных с "говорящими" именами конструкторов в большинстве случаев повышают читабельность кода и обеспечивают более жесткий контроль типов.
Ой, всё
Не совсем понял:
1. В предыдущих лекциях, когда разбиралась нормальная/аппликативная стратегия редукции терма - то было сказано, что хаскелль редуцирует нормально.
2. Сказано, что сопоставление с образцом форсирует вычисление => имеем аппликативную стратегию.
Противоречие?
Это исключение, чтобы pattern matching (он же "сопоставление с образцом") работало хоть как то. Там же так и объясняется.
Зачем нужно было все это творить с PointDouble? Нельзя было написать так
f :: (Double, Double) -> (Double, Double) -> (Double, Double)
f (x1, y1) (x2, y2) = ((x1 + x2)/2, (y1 + y2)/2)
Или это просто для того, чтобы показать пример работы?
+Корыто Можно, тип гомогенной пары эквивалентен нашему PointDouble. Однако использовать кортежи повсюду не очень рекомендуется - пользовательские типы данных с "говорящими" именами конструкторов в большинстве случаев повышают читабельность кода и обеспечивают более жесткий контроль типов.
+Denis Moskvin аа хорошо. Спасибо))
Хаха, ленивый образец