Здравствуйте, deniok, Вы писали:
D>Как вычислить эти выражения, попадись они мне в школьном учебнике алгебры Хаскель сохраняет для функций одной переменной стандартный математический синтаксис.
Попадись тебе в учебнике запись вида "sin x — 1" ты бы подумал что sin — это имя переменной. Да и вычислять в неопределенных фукнциях в математике ничего нельзя. Это же формулы.
Та что не надо ничего притягивать за уши.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
VD>>Вообще-то официальная точка зрения заключается в том, что на публичном уровне фукнции лучше документировать явно. Это повзоляет проще ловить ошибки типизации и не допускать ошибок в публичных интерфейсах.
L>Это несерьёзно. Вроде как вывод типа был призван объединить всё то лучшее, что есть в статических и динамических подходах.
Несколько раз прочел твою фразу и не смог найти в ней ни грама смысла.
По крайней мере она точно не имеем никакого отношения к сказаному мной.
Прочти еще раз мои слова и попытайся объяснить какое отношение произнесенный тобой лозунг "был призван объединить всё то лучшее..." относится к банальной мысли, что обязаетельность декларации типов в публичном интерфейсе уберегает программиста от ошибок?
VD>>Кстати, в Хаскеле и Окамле тоже обычно описывают типы фунций. VD>>Там это не обязательно. Но это действительно позволяет упрощать выявление ошибок и конечно же повышает скорость компиляции.
L>Позволяет упрощать выявление ошибок, может быть, но связано это не с этим.
С чем "не с этим"?
L> Причины совершенно другие. Если я пишу функцию, реализация которой мне изначально понятна, я записываю её без типа. Если я пишу функцию, которую сходу написать не могу, то часто пользуюсь методом — "писать от типа".
Это очередная мантра. Поробуй разяснить что ты вкладываешь в это понятие и уверен, что окажется, что все в итоге упрется в контроль ошибок компилятором.
L> Это очень удобно, потому что тип более-менее ясен, так как я представляю что должна делать функция, а уж из типа вывожу реализацию.
Очередная мантра "выводу из типа".
L> Если я пишу код, который предполагаю обработать haddock'ом, то, конечно, пишу типы, чтобы проставить к ним комментарии. Если мне нужен не общий тип для этой функции, а более специфичный (например, это связано с целью оптимизации), то я пишу нужный тип. С целью повышения скорости компиляции типы может и пишут, но я про такое не слышал.
Дело в том, что ты почему-то ассацируешь себя с остальными. Ты можешь ухо через ногу чесать, что с того?
Я вообще не понял предмет обсуждения. Ты спросил, я тебе ответил. Что мне до твоего опыта? От твоих предочтений и привычек у людей исходные редпосылки не изменяются. Типы пишутся только по двум причинам. 1. Ускорение компиляции. 2. Чтобы компилятор внятно сообщил об ошибках если что не так.
В одном языке допускают опускать типы в публчном интерфейсе, а в другом считают это плохой практикой. Вот собственно и все.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Область действия вывода типов ограничена локальными функциями. А что — разве не было бы лучше пользователям языка, если бы он снимал данное ограничение?
Не было бы. Было бы значительно хуже. Вывод типов и так часто приводитк к ошибкам которые не так то просто понять. Стандартная ситуация когда компилятор показывает в одно место, а реальная ошибка в другом. Если все лакализовано в методе, то проблема решается относительно легко. Если нет, то можно ее искать очень долго. Плюс ошибки не проходят в другие типы и модули. В итое все выльется в то, что для поиска ошибко компиляции потрбуются гуру которые один хрен будут решать проблему рассавляя декларации типов.
Для IDE это тоже решение отличное, так как иначе при каждом чихе прийдется перекомпилировать всю программу.
L>Полагаю, не это было причиной отказа от глобального вывода типов
Пологаю одного раза должно быть достаточно, что бы запомнить, что отаказа не было. Был выбор на основе некоторых соображений. Лично я этот выбор поддерживю.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>А если выводить тип приватных методов?
Язык переживет. Тормозов только будет по больше. Для IDE — это будет полный кабждец. Прейдется перекомпилировать на каждый чих все приватные методы. Точнее все, так как их и выделить то нельзя.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>Вопрос был как раз в том, что аналогичный фреймворк на "обычном" универсальном языке получить невозможно. Да, похожие варианты реализации могут быть (Scala.Actors как пример),
Ну, значит могу? На том и порешим.
К> но в целом
А в целом — это домыслы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Даже параллельный конкуррентный GC вынужден на определенное время C>останавливать всех мутаторов. Оно достаточно короткое, но вполне C>существенное для многих целей.
И что?
C>Нормальный полный конкуррентный GC невозможен без аппаратной поддержки
Это вопрос терминологии. К тому же конкуррентный и хорошо параллелящийся — это две большие разницы.
Я не вижу причин по которым не реализовать удобное распараллеливание в универсальных языках. Возможно эффективность будет несколько ниже неже ли если бы интегрировать поддержку в VM, но все равно решение будет полезным. О изменениях VM пока что можно только мечтать. А сделать фрэймворк можно здесь и сейчас. И он удет полезен на прктике. Так что не вижу предмета обсуждения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ironwit, Вы писали:
VD>>Мне нравится идея универсального инструмента который можно тоноко заточить под конкретную задачу/предметную область. Потому собственно я и обращаю внимание на метапрограммирование.
I>понятно. спасибо. значит не показалось
Не показалось. Я вообще, во многом разделяю идеи Страуструпа. Просто я несколько иначе вижу их реализацию и приоритеты.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
К>>Вопрос был как раз в том, что аналогичный фреймворк на "обычном" универсальном языке получить невозможно. Да, похожие варианты реализации могут быть (Scala.Actors как пример),
VD>Ну, значит могу? На том и порешим.
Нет, в данном случае половина решения не есть целое решение.
Как пример, для того чтобы гарантировать переключаемость между потоками/процессами надо инструментировать дотнетный/джавовский код, чтобы избавиться, например, от бесконечных циклов, отъедающих всё время процессора и не дающих "воздуху" другим вычислениям.
Твоё предположение что ты можешь сделать параллельность аналогичную Эрлангу (до софтриэлтайм гарантий) на базе CLI — домыслы, на том и порешим.
Будет реально работающая библиотека или что-то подобное — будет смысл вернуться к обсуждению, а так, извиняйте.
Здравствуйте, VladD2, Вы писали:
VD>Дело в том, что ты почему-то ассацируешь себя с остальными. Ты можешь ухо через ногу чесать, что с того?
О нет Влад, что ты! Это только твоя прерогатива. Слова "практика показывает", "этого нет, значит это никому не нужно" и прочее — это слова из твоих постов. Копирайты за тобой.
VladD2 wrote: > C>Даже параллельный конкуррентный GC вынужден на определенное время > C>останавливать всех мутаторов. Оно достаточно короткое, но вполне > C>существенное для многих целей. > И что?
Не всегда это терпимо. Хороший пример — игры. Вряд ли тебе будет
приятно, если у тебя иногда игра будет на пару секунд зависать.
> C>Нормальный полный конкуррентный GC невозможен без аппаратной поддержки > Это вопрос терминологии. К тому же конкуррентный и хорошо параллелящийся > — это две большие разницы.
Это я прекрасно знаю, поэтому и пишу "параллельный конкуррентный".
> Я не вижу причин по которым не реализовать удобное распараллеливание в > универсальных языках.
Проблема в том, что для GC в том же .NET не существует
иммутабельных объектов. Так как через reflection ты можешь поменять даже
содержимое string. А значит, куча оптимизаций из Erlang GC идет лесом.
> О изменениях VM пока что можно только мечтать.
Я сейчас финансирование на CLR для LLVM провожу. Так что я могу и мечтать
Здравствуйте, Cyberax, Вы писали:
C>VladD2 wrote: >> О изменениях VM пока что можно только мечтать. C>Я сейчас финансирование на CLR для LLVM провожу. Так что я могу и мечтать
Здравствуйте, VladD2, Вы писали:
L>>Область действия вывода типов ограничена локальными функциями. А что — разве не было бы лучше пользователям языка, если бы он снимал данное ограничение?
VD>Не было бы. Было бы значительно хуже.
То, что ты написал дальше — это хуже для дизайнеров этого языка. Это не проблемы пользователя. Дизайнеры не могут решить эту проблему и говорят — ок, пусть вывод типов будет только локально, это связано с тем, что сделать то-то и то-то трудно/неэффективно/чтонибудьещё. От того, что у ограничения есть объяснение его существования оно не перестаёт быть ограничением. Как отсутствие перегрузки в Хаскеле. Его ведь тоже можно объяснить, нес па?
Что касается "был выбор" то вообще не понятно. Ну, выбрали наличие в языке этого ограничения, ну есть для этого причины, и что? От того, что выбор был оно перестаёт быть ограничением?
А может тебе не нужен глобальный вывод типов просто потому, что ты с ним не работал и не почувствовал его достоинств?
Курилка wrote: >> > О изменениях VM пока что можно только мечтать. > C>Я сейчас *финансирование на CLR для LLVM провожу*. Так что я могу и > мечтать > А можно расшифровать выделенное?
Собираюсь делать небольшой проект — портирование CLR на LLVM. Пока для
него финансирование делаю.
Здравствуйте, lomeo, Вы писали:
L>А может тебе не нужен глобальный вывод типов просто потому, что ты с ним не работал и не почувствовал его достоинств?
Может он не нужен, потому что у него больше недостатков чем достоинств?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
L>>А может тебе не нужен глобальный вывод типов просто потому, что ты с ним не работал и не почувствовал его достоинств?
IT>Может он не нужен, потому что у него больше недостатков чем достоинств?
Может, однако недостатки глобального вывода для пользователя языка озвучены не были.
Здравствуйте, lomeo, Вы писали:
IT>>Может он не нужен, потому что у него больше недостатков чем достоинств?
L>
L>Может, однако недостатки глобального вывода для пользователя языка озвучены не были.
Были буквально тремя постами выше, просто ты не внимательно читал.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
L>>Может, однако недостатки глобального вывода для пользователя языка озвучены не были.
IT>Были буквально тремя постами выше, просто ты не внимательно читал.
Здравствуйте, lomeo, Вы писали:
IT>>Были буквально тремя постами выше, просто ты не внимательно читал.
L>"упрощение выявления ошибок и документирование"?
С практической точки зрения особенно первое.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Хаскель сохраняет для функций одной переменной стандартный математический синтаксис.
Что за зверь?
Если нам не помогут, то мы тоже никого не пощадим.
