Здравствуйте, Gajdalager, Вы писали:
G>Мозг хаскелем почти не насиловал, посмотрел только из интереса. Прочитал так, как нужно. Понимаю, конечно, что я не обычный человек, а программист, но все же
Я посморю на тебя когда ты что-то немного сложнее попробуешь почитать.
VD>>Вот знаешь как отличить кота от кошки?
G>Пинка дать? Если побежал — то кот, а если побежала — кошка?
Примерно, но не так жестоко.
Так вот, в этой шутке почти нет шутки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
WH>Он хочет спросить: Почему вывод типов работает только для локальных функций?
Ну, тогда он очень плохо формулирует свои мысли.
WH>Отвечаю: Иначе компилироваться будет ну очень долго.
Вообще-то официальная точка зрения заключается в том, что на публичном уровне фукнции лучше документировать явно. Это повзоляет проще ловить ошибки типизации и не допускать ошибок в публичных интерфейсах.
Хотя лично мне четко ясно, что большая программа с глабальным выводом типов уйдет в аут.
ЗЫ
Кстати, в Хаскеле и Окамле тоже обычно описывают типы фунций.
Там это не обязательно. Но это действительно позволяет упрощать выявление ошибок и конечно же повышает скорость компиляции.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Ограничение заключается в том, что для нелокальной функции это использоваться не может. Впрочем, мне уже ответили, так что забей.
Какое это ограничение? Вон в C# вообще нет выода типов ни для каких функций и никто об ограничении не говорит. Это дизайнерское решение языка. Вывод типов только логально. Так же вываод типов используется при инциализации по месту полей типов. Но там вывод не глобальный, а из выражения.
Целей у этого решения несколько. Причем быстродействие — это как раз наши догадки. Официально быстродействие не звучит. Официльная точка зрения "упрощение выявления ошибок и документирование".
Но как человек немного в этом разбирающийся скажу честно. Алгоритм очень вычислительно сложный. Так что если не отсекать это дело на уровне методов, то тормозить будет не щадно.
Одако решение оказалось просто удивительно грамотным. Так оно позволило реализовать реалтайное редактирование тел методов в IDE (инкрементальную их компиляцию).
Сейчас мы делаем так. Сначала сканируем все файлы и сроим дерево типов. При этом тела не парсятся и не типизируются. Далее когда открывается конкретный файл в фоновом режиме компилирются тела только тех методов, что находятся в этом файле. При изменени метода происходит только его перекомпиляция. В итоге имеем практически реалтаймное редактирование языка значительно более лсожного чем С++. При этом поддерживаются раскрытие макросов и т.п.
Я даже не знаю как делать интеграцию с IDE если будет решено выводить типы глобальном уровне.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Это ты какие-то свои представления вываливашь. А теперь представь, что мы имеем некий фрэймворк где как в Сингулярити группы объектов крутятся в отдельном потоке. Для каждого потока одтельная очередь сообщений. Она разргребается и выполняется некая работа.
В сингулярити не так.
Там у потока может быть сколько угодно очередей сообщений.
Болие того эти очереди двунаправленные.
VD>Все что синхронизируется — это доступ к очереди. Орканизуется это примитивно на интерлокедах. Все объекты в очереди доступны только для чтения.
На словах. Я тут гдето реализацию lock-free очереди видел
К тому же учти что интерлокед на многопроцессорной тачке весьма не дешев.
VD>Ну, и в чем, сажи мне на милость, проблема реализовать подобный механизм?
ГЦ один на всех. Он всех тормозить будет когда нужно мусор собрать.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>В сингулярити не так. WH>Там у потока может быть сколько угодно очередей сообщений. WH>Болие того эти очереди двунаправленные.
Это детали реализации. Они в данном случае не важны.
VD>>Все что синхронизируется — это доступ к очереди. Орканизуется это примитивно на интерлокедах. Все объекты в очереди доступны только для чтения. WH>На словах. Я тут гдето реализацию lock-free очереди видел WH>К тому же учти что интерлокед на многопроцессорной тачке весьма не дешев.
Ничего. Дешевле все равно ничего не бывает. Один интерлок на обработку сообщения не будет даже в микроскоп заметно.
WH>ГЦ один на всех. Он всех тормозить будет когда нужно мусор собрать.
GC уже рассчитан на пногопоточность. У них там все хитро устроено. Плюс есть специальный серверный ЖЦ.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > WH>ГЦ один на всех. Он всех тормозить будет когда нужно мусор собрать. > GC уже рассчитан на пногопоточность. У них там все хитро устроено. Плюс > есть специальный серверный ЖЦ.
Даже параллельный конкуррентный GC вынужден на определенное время
останавливать всех мутаторов. Оно достаточно короткое, но вполне
существенное для многих целей.
Нормальный полный конкуррентный GC невозможен без аппаратной поддержки
Здравствуйте, VladD2, Вы писали:
L>>Ограничение заключается в том, что для нелокальной функции это использоваться не может. Впрочем, мне уже ответили, так что забей.
VD>Какое это ограничение?
Область действия вывода типов ограничена локальными функциями. А что — разве не было бы лучше пользователям языка, если бы он снимал данное ограничение?
За остальное спасибо, было интересно почитать.
VD>Я даже не знаю как делать интеграцию с IDE если будет решено выводить типы глобальном уровне.
Полагаю, не это было причиной отказа от глобального вывода типов
Здравствуйте, VladD2, Вы писали:
WH>>Он хочет спросить: Почему вывод типов работает только для локальных функций?
VD>Ну, тогда он очень плохо формулирует свои мысли.
Я, напротив, удивлён твоему непониманию такой простой мысли.
VD>Вообще-то официальная точка зрения заключается в том, что на публичном уровне фукнции лучше документировать явно. Это повзоляет проще ловить ошибки типизации и не допускать ошибок в публичных интерфейсах.
Это несерьёзно. Вроде как вывод типа был призван объединить всё то лучшее, что есть в статических и динамических подходах.
VD>Кстати, в Хаскеле и Окамле тоже обычно описывают типы фунций. VD>Там это не обязательно. Но это действительно позволяет упрощать выявление ошибок и конечно же повышает скорость компиляции.
Позволяет упрощать выявление ошибок, может быть, но связано это не с этим. Причины совершенно другие. Если я пишу функцию, реализация которой мне изначально понятна, я записываю её без типа. Если я пишу функцию, которую сходу написать не могу, то часто пользуюсь методом — "писать от типа". Это очень удобно, потому что тип более-менее ясен, так как я представляю что должна делать функция, а уж из типа вывожу реализацию. Если я пишу код, который предполагаю обработать haddock'ом, то, конечно, пишу типы, чтобы проставить к ним комментарии. Если мне нужен не общий тип для этой функции, а более специфичный (например, это связано с целью оптимизации), то я пишу нужный тип. С целью повышения скорости компиляции типы может и пишут, но я про такое не слышал.
Здравствуйте, Disappear, Вы писали:
EC>>Это особенно заметно на legacy C++ code — тогда люди делали массу отпимизаций, которые сейчас просто потеряли смысл и просто сбивают с толку компилятор, т.к. информация, что именно должен делать компилятор слишком детализированная и ему негде развернуться.
D>Не совсем так. Современные С++ компиляторы такие вещи как inline, register, volatile в большинстве случаев просто пропускают. Поэтому ваш аргумент — не более чем выдумка.
Эти слова — не единственный способ оптимизации.
Часто люди для оптимизации разбивают циклы на несколько, выделяют локальыне переменные где не надо, неправильно разбивают код на функции, делают побитовые операции, где стоило делать обычные арифметические. При этом компилятор все равно многое может собрать обратно и нормально соптимизировать код, а что-то уже и не может...
Человеческий разум непобедим, особенно в неразумных поступках
Здравствуйте, VladD2, Вы писали:
IT>>Я о том, что пока всё просто, такая запись выглядит неплохо. Но, боюсь, что в реальном коде перегрузка метода не только по типу, но ещё и по значению не добавит простоты и понятности.
VD>В Хаскеле нет перегрузки методов. Только паттерн-матчинг.
Я говорю не о хаскеле, а о стиле.
VD>Да и "перегрузка метода по значению" — это какая-то фигня.
Ну назови это как тебе больше нравится.
VD>В общем, что-то ты не допонимаешь.
И похоже я не одинок.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, ironwit, Вы писали:
I>>Влад. тут мы почитали внимательно...
VD>Кто, мы?
я и стая товарищей (с)
I>>Такое ощущение что тебе нужен не специалиированный язык. типа универсального бойца. Верно? или это обманчивое впечатление?
VD>Мне нравится идея универсального инструмента который можно тоноко заточить под конкретную задачу/предметную область. Потому собственно я и обращаю внимание на метапрограммирование.
VD>Вот это не правда. Никакого математического назначения туту нет и в помине. Это чистые проблемы Хасклеля с приоритетами. Такие проблем есть толко ML-подобных языках.
Я, конечно, не знаю все 200 с хвостиком существующих языков, но по-моему "проблема с приоритетами" операторов есть в любом из них (кроме Lisp-подобных, где всё префиксно)
Выражение типа
1+2*3
во всех языках где есть инфиксная нотация операторов вернёт 7, а не 9, именно из соображений приоритета. Хаскелл не требует использования скобок вокруг аргумента(-ов) функции, поэтому просто добавляется ещё один (высший) уровень приоритета — применение функции, то есть в выражении типа
1 + sin x * 2
сначала sin x, а потом всё остальное. Я, главное, не вижу здесь ровно никаких проблем. Просто нужно понять, что в Хаскелле любой идентификатор — функция и
1 + a b * 2
это ровно то же самое, что и в примере с sin: применение функции a к b и затем умножение и сложение — в порядке приоритетов.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, deniok, Вы писали:
D>>Внутренние-то почему лишние? Возможно моя интуиция слишком "математизирована", но в
D>>x * sin x — 1 D>>vs. D>>x * sin (x — 1)
D>> по-моему всё однозначно и понятно
VD>Что тебе понятно?
Как вычислить эти выражения, попадись они мне в школьном учебнике алгебры Хаскель сохраняет для функций одной переменной стандартный математический синтаксис.
Здравствуйте, deniok, Вы писали:
D>Здравствуйте, VladD2, Вы писали:
D>Я, конечно, не знаю все 200 с хвостиком существующих языков, но по-моему "проблема с приоритетами" операторов есть в любом из них (кроме Lisp-подобных, где всё префиксно) D>Выражение типа
D>
D>1+2*3
D>
D>во всех языках где есть инфиксная нотация операторов вернёт 7, а не 9, именно из соображений приоритета.
Здравствуйте, VladD2, Вы писали:
VD>Ну, и опять же лично мне Эрлэнг не интересен. Слишком узок его область применения. А получить аналогичный фрэймворк в универсальном языке очень даже интересно. Уверен, что он в любом случае будет полезен и даст выигрыш на некоторых задачах.
Вопрос был как раз в том, что аналогичный фреймворк на "обычном" универсальном языке получить невозможно. Да, похожие варианты реализации могут быть (Scala.Actors как пример), но в целом модель Эрланга требует поддержки ВМ. И тут далеко не играют роль факторы, приводимые тобой про динамическуют типизацию и т.д. Вот здесь
всё расписано, повторяться не вижу смысла.
Если ты считаешь, что эту задачу можно решить библиотекой — ради бога, но правдой это не станет.
Я всё сказал.
Если нам не помогут, то мы тоже никого не пощадим.
Возможно моя интуиция слишком "математизирована", но в
