Но там виртуальная машина.

А в GHC нет её?

Для GHC это означает что нужно тащить в рантайм сам GHC.

Почему он не может быть сбоку обеспечивая RPC?

Не «универсальный» тип T, а стирание типов у всего чего можно.

Нет, я имел ввиду вывод с обоих сторон.

Плюс специальные конструкции, типа «а вот тут у нас будут происходить фейлы типизации».

С точки зрения лиспа (как там сделано) - не фейлы типизации, а фейлы типа «ой, у нас сюда попало что-то совсем не того типа, давайте сделаем рестарт, пусть пользователь (языка) сам решает», а не «решим-ка за пользователя». Т.е. типы тоже можно использовать как данные (а не просто квантифицировать по ним в параллельном представлении), и делать выбор по typecase.

Просто работает. И еще работает Data.Generics. А то что приходится gfoldl определять, так это издержки.

Т.е. если я решил писать код в духе Data.Dynamic и использую ещё несколько библиотек в которых их авторы определили несколько типов данных, то мне нужно заниматься дописыванием инстансов к чужим библиотекам (при том что даже gfoldl неплохо деривайдится). Я просто как-то наткнулся на это «очевидное» поведение и понял, что я всё-таки не могу это использовать.

Считай это элементом дизайна.

Ну хорошо, я как раз думал - нет ли общепринятого способа это обойти. Видимо нет.

Дальше что? Зато в динамических языках полностью отсутствует требование чтобы все типы были к моменту рантайма худо-бедно опеределены.

Тоже верно, но это, ещё раз, на тему того что одни выводят типы снизу, другие распостраняют их сверху. В лиспе, например, нет проблем с тем чтобы добавить вывод снизу (есть проблемы в умельцах которые бы реализовали такую возможность правильно, и нет «покупателей» - кому нужны типы в лиспе? :))

Кстати, есть такое расширение как CLOS (+ MOP), там сделать унификацию времени компиляции не составляет особых проблем.

> Т.е. типы тоже можно использовать как данные (а не просто квантифицировать по ним в параллельном представлении), и делать выбор по typecase.

Если _компилятор_ не может дать гарантий, то вышесказанное - просто жалкое словоблудие^W^Wпопытка оправдания :)

Если _компилятор_ не может дать гарантий, то вышесказанное - просто жалкое словоблудие^W^Wпопытка оправдания :)

Ты поднимаешь социальный а не технический вопрос :) Надо спросить mv какие они гарантии дают в своём софте :) Компилятор-то легко расширяется - все over 30 примитивов в раз-макросенном CL не покроешь, но частичную унификацию можно делать.

Изначально (после вопроса «нафиг лисп?») речь пошла про «полезный REPL», типа если ты купил новый многоядерный процессор с новыми инструкциями, то в SBCL ты можешь научить компилятор работать с этими ядрами и инструкциями так же просто как определить в GHCi факториал :)

Теперь нужны гарантии от чего? От реализаций CL? Тогда приведи простой пример кода (точнее класс возможных кодов) относительно которогу нужны какие-то гарантии.

>> Если _компилятор_ не может дать гарантий, то вышесказанное - просто жалкое словоблудие^W^Wпопытка оправдания :)

Ты поднимаешь социальный а не технический вопрос :) Надо спросить mv какие они гарантии дают в своём софте :)

Вот как раз вопрос про софт mv - это социальный, а вопрос о гарантиях компилятора - технический.

Теперь нужны гарантии от чего? От реализаций CL?

От абстрактного сферического компилятора в вакууме. А от компилятора CL я их не жду, потому что CL - это динамический недоязычок.

take two

пример будет?

Пример чего тебе нужен?

>Почему он не может быть сбоку обеспечивая RPC?

Суть изменится мало, а проблемы безопасности возникнут. Нужен какой-то хитрый линкоровщик... Не обязательно же делать как в лиспе. Пусть хотя бы будет эрланговский подход: возможность замены модулей в рантайме. Но тогда придется использовать модули а-ля ML, как минимум, и хранить их сигнатуры в рантайме.

Нет, я имел ввиду вывод с обоих сторон.

Что ты имеешь в виду под «c обоих сторон»?

а не «решим-ка за пользователя»

Не совсем так. Скорее «я не могу доказать соответствующее высказывание». Но никто за пользователя ничего не решает.

в которых их авторы определили несколько типов данных

А если эти типы даннх — абстрактные? Придется делать обертку из своего типа, для него определять набор комбинаторов, чтобы можно было быстро преобразовывать из и в библиотечный тип. А уж для этого безобразия делать instance'ы.

Я конечно могу ошибаться, но Identity должно хватить.

В лиспе, например, нет проблем с тем чтобы добавить вывод снизу

Угу. Будет такой же «двумерный» подход: сначала описываем сам терм, затем описываем что этот терм делает, затем описываем что делает терм, который описывает... и т.д. пока не надоест. ИЧХ в лиспе это будет сделано _намного_ проще. Хотите тип как объект первого класса? Пожалуйста! Хотите генерить типы с помощью макросов? Вперед! Хотите генерить типы на основе статического анализа S-выражения? Кто ж мешает? Тип можно вытаскивать в рантайме по аналогии с документацией. Э-э-э-х. Только кому это нужно?

Пример чего тебе нужен?

Ну ты пишешь:

Если _компилятор_ не может дать гарантий, то вышесказанное - просто жалкое словоблудие^W^Wпопытка оправдания :)

Если -> То. Вот я и спрашиваю - какой компилятор не может дать гарантий (а то словоблудие получается) и каких (пример: «код - нужные гарантии»).

Но ты прав - CL в стандартной поставке не может дать никаких гарантий помимо использования неизвестных функций (точнее, все остальные гаранитии смещены за момент запуска программы). Это вопрос расширения языка - вопрос социальный (я исхожу из того, что такое расширение сделать не трудно технически, вопрос в потребности сообществом). Но анонимус сказал, что можно написать макрос ;)