Здравствуйте, Klapaucius, Вы писали:

T>>Я не поленился и перепёр haskell в шаблоны один в один:
K>Ох. Лучше бы вы не поленились читать то, что писал МигМит в том треде и что сейчас пишу я.
K>Вот смотрите:

K>Видите, этот код принимает число как аргумент командной строки. Он компилируется. НЕ интерпретируется.



Неправда, он интерпретируется в этом месте:

ScalarProduct a => ScalarProduct (Cons a) where

В отличие от Haskel, подобное преобразование типов (распаковка) для кода Tonal- выполняется в compile-time.


K>И типы проверяет статически.

Тоже неправда. Для АлгТД статически проверяется только м-но допустимых запакованных типов, то бишь статически проверяется лишь некое ограничение на возможный тип, но не сам запакованный тип. Конкретный тип распаковывается исключительно в рантайм, а сама техника распаковки тождественна технике dynamic_cast (с точностью до деталей, то бишь с точностью до способа кодирования/представления токена типа для целей рантайма).


K>Закомментированная строчка вызовет ошибку. Потому, что проверяются не абсолютные размеры списков, а то, что списки одинакового размера. А это известно на этапе компиляции, завит только от написанного кода, а не входных данных.

И опять неправда и непонимание происходящего. Это зависит от реализованной системы типов. Там, где ML-яык работает с боксированными значениями в рантайм, там мы имеем классическую эмуляцию динамики/интерпретации, хоть и со статическими проверками допустимости мн-ва АлгТД в момент компиляции. А там, где ML-язык будет пытаться инстанциировать типы целиком, чтобы избежать лишней динамики в рантайм, без техники зависимых типов не обойтись.

K>И зависимые типы для этого не нужны

Они не нужны только для боксированной реализации рекурсивных типов и прочей динамической типизации.