"Контролируемый" в том смысле, что компилятор может проконтролировать, что все варианты охвачены в операторе ПМ (или списке функций). Например, в Скале по умолчаню создаются открытые к расширению АлгТД, что ведет к тому, что компилятор не может контролировать полноту охвата ПМ. Но в Скале можно объявить АлгТД как запечатанные (не расширяемые), что приводит к тому, что компилятор может проконтролировать полноту охвата.
К>Если под ним подразумевается ПМ по неизменяемым данным
Нет. Изменяемость тут не причем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
T>Вроде, получил данные, а они рраз! и изменились. Рассуждения о программе идут лесом. Преобразовать сравнение с образцом в вызов функции уже нельзя.
В монгопоточных приложениях доступ к данным обычно осуществляется как один писатель, много читателей, или на обычных блокировках, не зависимо просто ли это чтение или сравнения с образцом.
Для однопоточных этого и не нужно.
и солнце б утром не вставало, когда бы не было меня
T>>Вот поэтому этим никто и не пользуется. В Nemerle, F# и некоторых диалектах Лиспа. Ну, про F# я ради красного словца, конечно. Но теперь вообще прекращу его рекомендовать. VD>У тебя мания величия. Можно подумать, что твоих рекомендаций кто-то ждет.
Если кто-нибудь попросит, то не буду.
T>>Вроде, получил данные, а они рраз! и изменились. Рассуждения о программе идут лесом. VD>На практике это не проблема. Если человек сделал структуру данных изменяемой, значит он понимает что тварит. Обычно это оптимизация. Например, в AST немерла есть поле Location определяющее местоположение соответствующего кода в файле. Само поле ни на что не влияет, использовать в ПМ его практически бесполезно. Однако очень важно, чтоб было можно менять это поле не пересоздавая объекты. Например, при редактировании файла нужно обеспечить корректировку ветвей АСТ которые располагаются ниже области редактирования. Иначе прийдется каждый раз перепарсивать весь файл.
Не вижу, зачем снова разбирать оставшуюся часть файла заново и твою "оптимизацию" можно сделать и функционально.
T>>Преобразовать сравнение с образцом в вызов функции уже нельзя. VD>А оно надо? В прочем, думаю, что ты и тут ошибаешься. Это только в хаскеле функции не могут иметь замканий на изменяемые данные. А в гибридных языках — это нормальная практика. Так что преобразовывать можно. Вопрос только зачем.
Оно надо для рассуждения о программах.
VD>>>Скорее тут нужно говорить о наличии АлгТД, так как классический ПМ на них рассчитан. T>>Узнай, же, о смертный, что классическое сравнение с образцом переводится в вызов функций-селекторов. VD>Блин, бессмертный .
Почему, тоже смертный. Только знаю.
VD>Во что там преобразуется ПМ — это вопрос реализации. В классическом алгоритме МЛ-я он преобразуется в банальные управляющие конструкции. Иначе это было бы дико не эффективно.
Посмотри на эффективность Хаскеля. Там сделано именно так, как я сказал.
Получилось не так и плохо.
VD>>>Но это тоже так только в следствии недоработанности темы. В принципе ПМ можно делать по произвольному объекту. Разве что контроля будет только по меньше. T>>Практически никакого. Контроля. Не будет. VD>Да и фиг бы с ним. Выбор то каков? Тосячи if-ов и switch-ей или одно выражение ПМ. Оно и без контроля позволит поднять уровень программ во много раз.
Да, этого не отнять.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Вроде, получил данные, а они рраз! и изменились. Рассуждения о программе идут лесом. Преобразовать сравнение с образцом в вызов функции уже нельзя. S> В монгопоточных приложениях доступ к данным обычно осуществляется как один писатель, много читателей, или на обычных блокировках, не зависимо просто ли это чтение или сравнения с образцом.
S>Для однопоточных этого и не нужно.
f q xx@(x:xs) = g xx (q x)
f [] = что-то
p xs = f (изменяющее xs функция, как параметр q) xs
Мы не можем рассчитывать, что g получит не пустой список, если q x вычислится первым.
Функциональное программирование сильно меняет взгляд на вещи.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, thesz, Вы писали:
T>>Функциональное программирование сильно меняет взгляд на вещи.
E>Ну да, в почти случайной последовательности символов
f q xx@(x:xs) = g xx (q x)
вдруг обнаруживается какой-то смысл.
E>
Всё ж не Перл.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Не вижу, зачем снова разбирать оставшуюся часть файла заново
Поле изменения текста в одном методе, все остальное АСТ начинает содержать неверные локешоны. Их сдвижка на требуемую дельту восстанавливает их актуальность. Иначе пришлось бы все парсить и типизировать за нова.
T>и твою "оптимизацию" можно сделать и функционально.
Языком все можно сделать. А на практике...
T>Оно надо для рассуждения о программах.
И часто ты о ней рассуждаешь?
VD>>Во что там преобразуется ПМ — это вопрос реализации. В классическом алгоритме МЛ-я он преобразуется в банальные управляющие конструкции. Иначе это было бы дико не эффективно.
T>Посмотри на эффективность Хаскеля. Там сделано именно так, как я сказал.
Дык смотрел не раз. Тормоз он еще тот. Иногда ничего вроде бы, а иногда просто ужас. И самое обидное, что когда надо нельзя сделать тупо как тебе хочется. Приходится только надеяться на то, что компилятор поможет.
T>Получилось не так и плохо.
Смотря для чего. Ты вот сам рассказывал, что используешь С или С++ для написания вычислительной части. Уверен, что если бы Хаскель позволял, то ты бы все на нем писал бы.
VD>>Да и фиг бы с ним. Выбор то каков? Тосячи if-ов и switch-ей или одно выражение ПМ. Оно и без контроля позволит поднять уровень программ во много раз.
T>Да, этого не отнять.
Ну, дык речь то идет о добавлении ПМ в Шарп, а не о замене шарпа хаскелем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, thesz, Вы писали: T>Функциональное программирование сильно меняет взгляд на вещи.
Менять меняет, но возьмем базы данных там тоже есть версионность (то есть чтение в разрезе транзакции, так и для откатов транзакций), но и экслюзивный доступ к данным.
Разные подходы нужны.
и солнце б утром не вставало, когда бы не было меня
T>>Не вижу, зачем снова разбирать оставшуюся часть файла заново VD>Поле изменения текста в одном методе, все остальное АСТ начинает содержать неверные локешоны. Их сдвижка на требуемую дельту восстанавливает их актуальность. Иначе пришлось бы все парсить и типизировать за нова.
Я не вижу, зачем здесь изменяемые значения.
T>>и твою "оптимизацию" можно сделать и функционально. VD>Языком все можно сделать. А на практике...
Так я на практике так и делаю.
T>>Оно надо для рассуждения о программах. VD>И часто ты о ней рассуждаешь?
Практически над каждой строкой. Да не по одному разу.
Как и ты, впрочем.
VD>>>Во что там преобразуется ПМ — это вопрос реализации. В классическом алгоритме МЛ-я он преобразуется в банальные управляющие конструкции. Иначе это было бы дико не эффективно. T>>Посмотри на эффективность Хаскеля. Там сделано именно так, как я сказал. VD>Дык смотрел не раз. Тормоз он еще тот. Иногда ничего вроде бы, а иногда просто ужас. И самое обидное, что когда надо нельзя сделать тупо как тебе хочется. Приходится только надеяться на то, что компилятор поможет.
Это ты опять преждевременно оптимизируешь.
T>>Получилось не так и плохо. VD>Смотря для чего. Ты вот сам рассказывал, что используешь С или С++ для написания вычислительной части. Уверен, что если бы Хаскель позволял, то ты бы все на нем писал бы.
Вычислительная часть и сравнение с образцом дружат редко. Хотя, символьная оптимизация на Хаскеле обычно получается работающей быстрее (во всех смыслах — и быстрее написать, и быстрее работает), чем на других языках.
Для моделирования я использую Джаву, поскольку JIT.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
VD>>Поле изменения текста в одном методе, все остальное АСТ начинает содержать неверные локешоны. Их сдвижка на требуемую дельту восстанавливает их актуальность. Иначе пришлось бы все парсить и типизировать за нова.
T>Я не вижу, зачем здесь изменяемые значения.
Бывает. Но я тут тебе уже не помогу. Это к другим специалистам .
Если серьезно, то с удовольствием послушаю то как здесь обойтись без изменяемых данных и при этом не получить оверхэда.
T>>>и твою "оптимизацию" можно сделать и функционально. VD>>Языком все можно сделать. А на практике...
T>Так я на практике так и делаю.
Языком?
T>>>Оно надо для рассуждения о программах. VD>>И часто ты о ней рассуждаешь?
T>Практически над каждой строкой. Да не по одному разу.
И каждый раз в функции переводишь чтобы порассуждать?
T>Как и ты, впрочем.
Я код пишу и читаю. Мне его в функции переводить нужды нет.
VD>>Дык смотрел не раз. Тормоз он еще тот. Иногда ничего вроде бы, а иногда просто ужас. И самое обидное, что когда надо нельзя сделать тупо как тебе хочется. Приходится только надеяться на то, что компилятор поможет.
T>Это ты опять преждевременно оптимизируешь.
Опять? Сможешь привести хотя бы один пример?
Оптимизировать тут нечего. Просто язык на сегодня не гарантирует высокую производительность в нужных местах.
T>>>Получилось не так и плохо. VD>>Смотря для чего. Ты вот сам рассказывал, что используешь С или С++ для написания вычислительной части. Уверен, что если бы Хаскель позволял, то ты бы все на нем писал бы.
T>Вычислительная часть и сравнение с образцом дружат редко.
Да, ну? Это очень сильно зависит от того как этот самый ПМ реализован. Если эффективно, то почему бы его не использовать и в вычислительных алгоритмах?
T>Для моделирования я использую Джаву, поскольку JIT.
Моделирования чего? Или в каком смысле?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>>Поле изменения текста в одном методе, все остальное АСТ начинает содержать неверные локешоны. Их сдвижка на требуемую дельту восстанавливает их актуальность. Иначе пришлось бы все парсить и типизировать за нова. T>>Я не вижу, зачем здесь изменяемые значения. VD>Бывает. Но я тут тебе уже не помогу. Это к другим специалистам . VD>Если серьезно, то с удовольствием послушаю то как здесь обойтись без изменяемых данных и при этом не получить оверхэда.
(осторожно) Ленивые вычисления?..
T>>>>и твою "оптимизацию" можно сделать и функционально. VD>>>Языком все можно сделать. А на практике... T>>Так я на практике так и делаю. VD>Языком?
Программирования, ага.
T>>>>Оно надо для рассуждения о программах. VD>>>И часто ты о ней рассуждаешь? T>>Практически над каждой строкой. Да не по одному разу. VD>И каждый раз в функции переводишь чтобы порассуждать?
Возможностью перевода (прозрачностью по ссылкам или функциональной чистотой) — каждый раз.
T>>Как и ты, впрочем. VD>Я код пишу и читаю. Мне его в функции переводить нужды нет.
Ты рассуждаешь. А уж умеешь ли ты использовать перевод в функции, или не умеешь, это дело третье.
Если умеешь — ты сильнее, как программист.
T>>>>Получилось не так и плохо. VD>>>Смотря для чего. Ты вот сам рассказывал, что используешь С или С++ для написания вычислительной части. Уверен, что если бы Хаскель позволял, то ты бы все на нем писал бы. T>>Вычислительная часть и сравнение с образцом дружат редко. VD>Да, ну? Это очень сильно зависит от того как этот самый ПМ реализован. Если эффективно, то почему бы его не использовать и в вычислительных алгоритмах?
Мало смысла.
Хотя кое-где очень полезно — например, k-d Или quad tree.
T>>Для моделирования я использую Джаву, поскольку JIT. VD>Моделирования чего? Или в каком смысле?
Аппаратуры. Моделирование аппаратуры и есть та самая вычислительная часть.
Это у Булата сжатие написано на C++.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
VD>>Если серьезно, то с удовольствием послушаю то как здесь обойтись без изменяемых данных и при этом не получить оверхэда.
T>(осторожно) Ленивые вычисления?..
И что с них толку? Еще раз повторяю, что значения должны меняться. Вбил символ — изменились. Вбил еще 3, снова изменились.
T>>>>>и твою "оптимизацию" можно сделать и функционально. VD>>>>Языком все можно сделать. А на практике... T>>>Так я на практике так и делаю. VD>>Языком?
T>Программирования, ага.
А со стороны видно, что обычным.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>>Если серьезно, то с удовольствием послушаю то как здесь обойтись без изменяемых данных и при этом не получить оверхэда. T>>(осторожно) Ленивые вычисления?.. VD>И что с них толку? Еще раз повторяю, что значения должны меняться. Вбил символ — изменились. Вбил еще 3, снова изменились.
Как так "должны меняться"?
Они должны читаться новыми, но чтобы меняться...
T>>>>>>и твою "оптимизацию" можно сделать и функционально. VD>>>>>Языком все можно сделать. А на практике... T>>>>Так я на практике так и делаю. VD>>>Языком? T>>Программирования, ага. VD>А со стороны видно, что обычным.
Одна твоя точка не даёт статистики.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, VladD2, Вы писали:
VD>>>Если серьезно, то с удовольствием послушаю то как здесь обойтись без изменяемых данных и при этом не получить оверхэда.
T>>(осторожно) Ленивые вычисления?..
VD>И что с них толку? Еще раз повторяю, что значения должны меняться. Вбил символ — изменились. Вбил еще 3, снова изменились.
Толк, однако, с них есть. Релятивистские эффекты в программах возникают, и их можно полезно использовать.
Изменяющиеся _видимые_ значения — никак не противоречат ленивости. Противоречие кажущееся. Ленивость — сложное явление, и надо потратить время, чтобы понять фишку. Вот тебе пример.
Потактовая модель процессора — это вполне императивная штука. Кадлая стадия конвейра имеет мутабельное состояние. Прикинь, именно ленивость позволяет компактно и прикольно его, процессор, описать. А именно — ленивые списки являются "проводами", которые связывают блоки — стадии конвейра, друг с другом.
Да, интересное наблюдение. Модели процов на Хаскеле дают более высокую производительность (такты в секунду), чем аналогичные модели на С++ (с применением библиотеки SystemC, что есть индустриальный стандарт). Это — наблюдавшийся на опыте в нашей работе (мы, если ты не знаешь, моделировали суперскалярный MIPS) парадокс, который сложно объяснить, но это — экспериментальный факт. Кстати — не только мы применяли Хаскель для моделирования аппаратуры. Еще это делает одна известная компания. ARM.
T>>>>>>и твою "оптимизацию" можно сделать и функционально. VD>>>>>Языком все можно сделать. А на практике... T>>>>Так я на практике так и делаю. VD>>>Языком?
T>>Программирования, ага.
VD>А со стороны видно, что обычным.
Да ладно тебе. У Зефирова реально очень большая практика применения Хаскеля в продакшне. Сейчас он делает это уже на другой работе, разрабатывая САПР для микроэлектроники. И вполне успешно. Это, как минимум, интересно, согласись?
Здравствуйте, Gaperton, Вы писали:
VD>>И что с них толку? Еще раз повторяю, что значения должны меняться. Вбил символ — изменились. Вбил еще 3, снова изменились.
G>Толк, однако, с них есть. Релятивистские эффекты в программах возникают, и их можно полезно использовать.
G>Изменяющиеся _видимые_ значения — никак не противоречат ленивости. Противоречие кажущееся. Ленивость — сложное явление, и надо потратить время, чтобы понять фишку. Вот тебе пример...
Я ничего не имею против ленивости. Я хочу понять как она поможет мне избавиться от императивного изменения значений и при этом оставить код эффективным в конкретном случае.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
G>>Изменяющиеся _видимые_ значения — никак не противоречат ленивости. Противоречие кажущееся. Ленивость — сложное явление, и надо потратить время, чтобы понять фишку. Вот тебе пример... VD>Я ничего не имею против ленивости. Я хочу понять как она поможет мне избавиться от императивного изменения значений и при этом оставить код эффективным в конкретном случае.
Ты ещё скажи, что ты не преждевременно оптимизируешь.
Но это я так, к слову.
Мы можем сделать промежуточную структуру, которая будет содержать в себе дерево и изменения позиции. ChangedTree PosDelta Tree.
При изменении позиции мы накапливаем её в ChangedTree. Когда нам надо получить изменённое дерево, мы применяем updateWithDelta posDelta к tree. Поскольку мы применяем лениво, то ничего лишнего не изменяется.
Это один из вариантов.
Второй вариант — ты разбираешь всё лениво. Тогда у тебя вообще ничего лишнего не запускается.
Такой вариант вполне подойдёт для указания места определения идентификатора, например. Для code completion также можно придумать какой-либо финт ушами.
В твоём энергичном случае ты работаешь с O(N) (N — число лексем или поддеревьев в файле) обновлений на каждый чих. В ленивом случае можно обойтись меньшим числом работы.
И на всякий случай — на stream processors сделать разбор в стиле Yi очень просто. Разбор на них строится таким образом, что текст подаётся в разборщик посимвольно и на каждый символ видимого текста ты можешь хранить своё продолжение работы.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Можно подумать, что твоих рекомендаций кто-то ждет.
