Здравствуйте, seregaa, Вы писали:
ANS>>найн. меня интересует этап выполнения макросов. то что в run-time можно использовать механизмы нижележащей платформы плюс рукописные "метки" и так понятно.
S>К сожалению, в рантайме область использования макросов сильно ограничена возможностями платформы. Тут ни тип расширить, ни метод переписать.
S>Если принять эти ограничения, то можно написать макроатрибут, превращающий такие ограниченные макросы из компайлтайм макросов в рантайм макросы. Будет проблема с доступностью апи компилятора, но для райнтайма можно сэмулировать его ограниченное подмножество.
Любая достаточно сложная программа /.../ содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.
ANS>Любая достаточно сложная программа /.../ содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Кстати, а почему? Как на счет применения патерна "Интерпретатор"?
Потому что можно поспорить с определением реализации как "неспецифированой, глючной и медленной".
Кстати, о какой программе мы говорим? О компиляторе Немерле? Или о гипотетической программе, написанной на Немерле?
Если первый случай, то возможно что CL больше подошел бы на роль языка реализации компилятора (кстати, как у него обстоят дела с интеропом с .net?), но это было бы стратегически неправильно — писать компилятор на языке, отличном от компилируемого. Тем более никто не гооворит о том, что немерле — самый подходщий кандидат для этого. И тем более неправильно распространять "недостатки" компилятора немерле на саму идею языка и все программы, на нем написанные.
А если речь о гипотетической программе, то причем здесь интерпретатор?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Вывод я огласил — есть фатальный недостаток, который Влад продаёт как фатальное преимущество.
Этот "фатальный недостаток" обусловлен ограничениями платформы, а не "десятым правилом". Если тебе не нравится платформа, так и скажи, что на язык то наезжать ))
Здравствуйте, seregaa, Вы писали:
ANS>>Вывод я огласил — есть фатальный недостаток, который Влад продаёт как фатальное преимущество. S>Этот "фатальный недостаток" обусловлен ограничениями платформы
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, seregaa, Вы писали:
ANS>>>Вывод я огласил — есть фатальный недостаток, который Влад продаёт как фатальное преимущество. S>>Этот "фатальный недостаток" обусловлен ограничениями платформы
ANS>нет!
Здравствуйте, FR, Вы писали:
V>>Языкам с легкой организацией REP-loop вроде как IDE не особо нужна, в отличие от статически типизируемых с выводом типов. FR>Языки OCaml и Haskell очень жестко статически типизированы и с выводом типов, при этом у обоих вполне нормальный REPL.
Забыл более похожий на Nemerle Scala — он тоже статически типизированный с выводом типов, и та-дам! с REPL-ом.
Re[5]: [Голосование] Почему я не использую Nemerle
Здравствуйте, VladD2, Вы писали:
FR>>Языки OCaml и Haskell очень жестко статически типизированы и с выводом типов, при этом у обоих вполне нормальный REPL. VD>... и IDE качества ниже плинтуса. Собственно популярность этих языков тоже не блещет. А возраст у них куда старше.
А вот для Scala есть IDE выше плинтуса — и Eclipse и IDEA его поддерживают, а я пишу в vim-е. Есть мнение, что потребность в IDE возникает у определенных коммьюнити. Т.е. дело не в языке. Могу предположить, что если народ повалит с Java на Haskell, то создаст замечательную IDE на базе Eclipse.
Re[5]: [Голосование] Почему я не использую Nemerle
Здравствуйте, vdimas, Вы писали:
V>Не знаю насчет OCaml, но у т.н. "интерпретатора" Haskell никакой он не нормальный. В окне непосредственного исполнения ты можешь использовать ограниченное подмножество языка. Все остальное надо оформлять в файл и вскармливать среде.
В REPL можно запускать только выражения. Задавать, скажем, типы нельзя
Re[6]: [Голосование] Почему я не использую Nemerle
Здравствуйте, lomeo, Вы писали:
L>А вот для Scala есть IDE выше плинтуса — и Eclipse и IDEA его поддерживают, а я пишу в vim-е. Есть мнение, что потребность в IDE возникает у определенных коммьюнити. Т.е. дело не в языке. Могу предположить, что если народ повалит с Java на Haskell, то создаст замечательную IDE на базе Eclipse.
Возможно. Осталось дождаться этого счастливого момента.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [Голосование] Почему я не использую Nemerle
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Что касается Nemerle, то, как я уже когда-то упоминал, у него фатальный недостаток — вся его машинерия работает только в compile-time.
А как иначе в строго-статически-типизируемом языке? Ты хоть понял что сказал?
ANS>Кстати, рефлексия хоть какая-то по макросам возможна? Или потребности и в такой колбасе нет?
ЗАЧЕМ? Буде нужен скриптовый язык (а твои намеки исключительно в эту сторону, даже если ты сам этого не осознаешь) — бери себе и спокойно хости в своей программе тот же JScript (.Net), и делай в рантайме чего хошь.
Re[6]: [Голосование] Почему я не использую Nemerle
L>В REPL можно запускать только выражения. Задавать, скажем, типы нельзя
Именно что... Обобщенное программирование в repl — это сложновато в реализации, потому как плохо понятно, что делать с уже инстанциированными типами при изменении их шаблонов.
Re[7]: [Голосование] Почему я не использую Nemerle
Здравствуйте, vdimas, Вы писали:
L>>В REPL можно запускать только выражения. Задавать, скажем, типы нельзя
V>Именно что... Обобщенное программирование в repl — это сложновато в реализации, потому как плохо понятно, что делать с уже инстанциированными типами при изменении их шаблонов.
Инстанциированных типов в Haskell нет, это не С++. Шаблонов тоже нет по той же причине. Или ты что-то другое имеешь в виду? Поясни, пожалуйста. На шаблоны в С++ скорее похожи typeclasses, хотя по сути это сахар для тех же алгебраических типов.
Re[8]: [Голосование] Почему я не использую Nemerle
Здравствуйте, vdimas, Вы писали:
V>List — обычный обобщенный тип, шаблон в терминах С++, где a — тип-параметр.
Я давно не писал на С++. Поправь, если что не так. Для меня шаблон и инстанциирование шаблона — это скорее макрос и его применение, из которого рожаются типы. Недаром, шаблон в С++ должен подключаться исходником.
Тип "List a" в Haskell — не шаблон. Вот, например, у нас есть функция List a -> a -> a, которая возвращает, скажем, первый элемент списка или значение по умолчанию, представленное вторым параметром. В С++ да — нарожается куча функций. В Haskell — нет. Соответственно, говорить об инстанциировании нет смысла, так как его нет. А значит оно не может являться препятствием к заданию типов в GHCi.
В Haskell есть конкретизация типа (List Int), но она работает только в компайл-тайме, ничего не генерит, в отличие от инстанциирования шаблона, и нужна только для тайпчекера. Или ты думаешь, что для каждого конкретного использования генерится cвой объектный код?
Ну, или приведи пример, как можно чинить препятствия REPL-у в случае параметризованных типов. В Scala вон REPL есть, и параметризованные типы задавать там можно. И дальше посмотрим на что больше похож Haskell — на Scala или C++.
L>>На шаблоны в С++ скорее похожи typeclasses, хотя по сути это сахар для тех же алгебраических типов. V>Не в ту степь.
Единственное, что нашёл схожего с шаблонами. Могу и подробнее.
V>Неожиданно от хаскелиста такое "мягко говоря"... Ты бы представлением библиотек Хаскеля поинтересовался.
Что такое "представление библиотек Хаскеля"?
Re[10]: [Голосование] Почему я не использую Nemerle
Здравствуйте, lomeo, Вы писали:
V>>List — обычный обобщенный тип, шаблон в терминах С++, где a — тип-параметр.
L>Я давно не писал на С++. Поправь, если что не так. Для меня шаблон и инстанциирование шаблона — это скорее макрос и его применение, из которого рожаются типы. Недаром, шаблон в С++ должен подключаться исходником.
Я ведь сказал посмотреть в сторону библиотек Хаскеля — они представляют из себя предобработанный исходник, а не бинарник (сравни с либами того же дотнета).
L>Тип "List a" в Haskell — не шаблон. Вот, например, у нас есть функция List a -> a -> a, которая возвращает, скажем, первый элемент списка или значение по умолчанию, представленное вторым параметром. В С++ да — нарожается куча функций. В Haskell — нет. Соответственно, говорить об инстанциировании нет смысла, так как его нет. А значит оно не может являться препятствием к заданию типов в GHCi.
Мде... Вообще-то именно порождается функция для конкретного параметра a.
L>В Haskell есть конкретизация типа (List Int), но она работает только в компайл-тайме, ничего не генерит, в отличие от инстанциирования шаблона, и нужна только для тайпчекера.
Инстанциирование типов из шаблонов C++ тоже ничего не генерит, кроме случаев явного указания такой генерации. Код генерится в месте использования шаблона.
L>Или ты думаешь, что для каждого конкретного использования генерится cвой объектный код?
Конечно, а если он в какой-то реализации совпадает, то лишь по той же причине, почему генерится одинаковый код для генериков или почему шаблонный код в С++ для разных типов "схлопывается" в один и тот же, если бинарные представления типов совпадают. Просто хочу сказать, что переиспользование или генерение идентичного бинарного кода — это внутренности реализации/оптимизации, а ты, как программист, должен считать, что имеешь каждый раз с независимо порожденным кодом из шаблона/обощенного типа/генерика для каждой конкретной комбинации типов-параметров.
L>Ну, или приведи пример, как можно чинить препятствия REPL-у в случае параметризованных типов. В Scala вон REPL есть, и параметризованные типы задавать там можно. И дальше посмотрим на что больше похож Haskell — на Scala или C++.
Ну или покажи мне хоть один интерпретатор Хаскеля, где можно определять типы в REPL. Мало ли кто на что похож...
L>>>На шаблоны в С++ скорее похожи typeclasses, хотя по сути это сахар для тех же алгебраических типов. V>>Не в ту степь.
L>Единственное, что нашёл схожего с шаблонами. Могу и подробнее.
Это ближе к контрактам, что ортогонально обсуждаемому, хотя интересная фича сама по себе.
V>>Неожиданно от хаскелиста такое "мягко говоря"... Ты бы представлением библиотек Хаскеля поинтересовался.
L>Что такое "представление библиотек Хаскеля"?
Ну открой их каким-нить текстовым редактором да посмотри.
Re[11]: [Голосование] Почему я не использую Nemerle
L>>Ну, или приведи пример, как можно чинить препятствия REPL-у в случае параметризованных типов. В Scala вон REPL есть, и параметризованные типы задавать там можно. И дальше посмотрим на что больше похож Haskell — на Scala или C++.
V>Ну или покажи мне хоть один интерпретатор Хаскеля, где можно определять типы в REPL. Мало ли кто на что похож...
У OCaml конечно система типов послабее Хаскельной, но те же параметризованные типы присутствуют, при этом в REPL можно спокойно задавать типы, и в библиотеках не текст а байт или нативный код.
Re[11]: [Голосование] Почему я не использую Nemerle
Здравствуйте, vdimas, Вы писали:
V>Конечно, а если он в какой-то реализации совпадает, то лишь по той же причине, почему генерится одинаковый код для генериков или почему шаблонный код в С++ для разных типов "схлопывается" в один и тот же, если бинарные представления типов совпадают. Просто хочу сказать, что переиспользование или генерение идентичного бинарного кода — это внутренности реализации/оптимизации, а ты, как программист, должен считать, что имеешь каждый раз с независимо порожденным кодом из шаблона/обощенного типа/генерика для каждой конкретной комбинации типов-параметров.
Сколько вариантов бинарного кода порождается для такой функции (как должен считать я, как программист) ?
