[haskell] проблемы с типизацией
Чтобы не вышло как с эллипсами на воде, сначала расскажу, что хотел получить. Нужно реализовать конфигурацию со скриптовыми элементами. То есть возможность считать из конфигурационного файла последовательность операций для получения некоторого результата, применённого к стандартному элементу.Ну так напиши свой простой скриптовый язык и не парься. Если хочешь, можешь как в xmonad конфиги сделать
Int -> (a -> bкоторая согласно идентификатору продуцирует функцию преобразования. Проблема только в том, что типы a и b заранее неизвестны.По сути это функция типа
1. Копроизведение и произведение - это String, вложение в копроизведение реализуется функцией show, проекция произведения - функцией read.
2. Копроизведение и произведение - это обычные типы A1 a1| A2 a2 | ... | An an и (b1, b2, ... , bn).
Можно реализовывал первый вариант, но вместо String взять свои, более удобные, типы и написать два класса, преобразующие туда и обратно. Собстенно, если хочется расширяемости, то этот путь более правильный.
Можно реализовывал первый вариант, но вместо String взять свои, более удобные, типы и написать два класса, преобразующие туда и обратно. Собстенно, если хочется расширяемости, то этот путь более правильный.и получится второй вариант
Те умные значки, которые ты ввёл, я не знаю, но на интуитивном уровне было понятно сразу, и связь между обоими вариантами видна хорошо. Первый вариант - готовый, но кривой, второй - более прямой, но нужно всё делать с самого начала.
Я вот что ещё подумал. Хаскелл развивается не только за счёт языковых средств, но и за счёт библиотек. Есть ли такое место в инете, где можно просмотреть все более-менее важные опубликованные библиотеки хаскелла? Хорошо бы там ещё можно было ориентироваться и не было бы нужды просматривать все библиотеки подряд, чтобы найти нужную. А то мне кажется, что кто-нибудь уже мог успеть написать библиотеку динамической типизации
и получится второй вариантНе обязательно, если у типов есть некоторые общие части. Но в общем да.
Можешь еще Data.Dynamic посмотреть в GHC, но, кажется, это немного не то.
Я вот что ещё подумал. Хаскелл развивается не только за счёт языковых средств, но и за счёт библиотек. Есть ли такое место в инете, где можно просмотреть все более-менее важные опубликованные библиотеки хаскелла? Хорошо бы там ещё можно было ориентироваться и не было бы нужды просматривать все библиотеки подряд, чтобы найти нужную. А то мне кажется, что кто-нибудь уже мог успеть написать библиотеку динамической типизацииТы не знаешь про Hackage? Оо
Те умные значки, которые ты ввёл, я не знаю,Я просто недавно начитался всякой фигни на эту тему, не обращай внимания
[тупой пост]
Template haskell не поможет?
[/тупой пост]
Template haskell не поможет?
[/тупой пост]
Template haskell не поможет?Я с Template Haskell не разбирался, у меня при беглом взгляде возникла мысль, что его прикрутить можно почти куда угодно, но не факт, что получится проще, чем с помощью менее джедайских средств.
Просмотр prelude выявил следующие библиотеки: Data.Typeable, Data.Dynamic, GHC.Dynamic, Data.Generics. Где бы ещё найти руководство по использованию их.
Просмотр prelude выявил следующие библиотеки: Data.Typeable, Data.Dynamic, GHC.Dynamic, Data.Generics. Где бы ещё найти руководство по использованию их.Scrap Your Boilerplate
Я, кстати, хотел спросить, что у тебя за проект, если не секрет?
Я, кстати, хотел спросить, что у тебя за проект, если не секрет?Мне уже тоже интересно)
Оставить комментарий
yroslavasako
Чтобы не вышло как с эллипсами на воде, сначала расскажу, что хотел получить. Нужно реализовать конфигурацию со скриптовыми элементами. То есть возможность считать из конфигурационного файла последовательность операций для получения некоторого результата, применённого к стандартному элементу. Типы результата и начального элемента известны, типы промежуточных функций преобразования - нет. Никакой сложной техники для решения этой задачи у меня составить не удалось, но это не показатель: до монад состояния и континуаций я тоже не своим умом дошёл, а в справочнике прочёл. В простом случае всё упирается в некоторую функцию вида:Int -> (a -> b
которая согласно идентификатору продуцирует функцию преобразования. Проблема только в том, что типы a и b заранее неизвестны. Они должны подходить одновременно под множество типов, то есть приводиться к ним некоторой функцией. Я вижу два способа осуществления такого приведения, оба не идеальные.
1) Всем необходимым типам пишем наследование классов Read и Show. После этого для инкапсуляции данных используем строку. Приведение типов осуществляется соответствующими функциями.
2) Объявляем рекурсивный алгебраический тип, в который записываем через | все возможные элементарные типы и способы их комбинаций. Пишем функции приведения, которые вытаскивают приводимые типы, либо генерят ошибку.
Первый вариант мне нравится тем, что он почти готовый и не требует изобретения велосипеда и не нравится тем, что при этом осуществляется множество лишних действий, данные хранятся неэффективно и вообще всё это выглядит как через жопу.
Второй вариант мне нравится только тем, что он работает, и не нравится необходимостью изобретать велосипед, вторично описывая систему типов, так же не нравится идея писать для него функции приведения.
Существует ли у проблемы в корне другое решение, можно ли в противном случае придумать ещё какой вариант универсально приводимого типа, и какой из них лучше?