Хорошая статья о том, что нас больше всего волновало-бы, если бы первой закончилась
та часть закона Мура, которая о количестве транзисторов.
То есть его формулировали — каждые два года кол-во (читай — плотность) транзисторов
удваивается, а каждые полтора года удваивается скорость (частота).
Первой перестала действовать экспонента по увеличению частоты, экспонента по
увеличению плотности всё ещё действует (лет 5-10 ещё будет действовать).
Из-за увеличения числа транзисторов — сейчас индустрия озабочена больше
переходом на многоядерные CPU. А проблему разницы скорости процессора и
памяти решают увеличением кэша, сложными предвыборками и пр. Хотя и тут
некоторые приложения могут выиграть в скорости работы в разы (при правильной
организации данных в памяти), всё-же эта проблема пока отступает перед
проблемой — что делать со всеми этими транзисторами. В ядро уже влепили
несколько блоков ALU, FP, добавили блоки для векторной арифметики,
удвоили это всё большим количеством регистров (для каждой стадии конвеера),
оптимистичным исполнением и т.п. и т.д. Добавили гигантские кэши
(увеличение которых уже почти не даёт ускорения). А транзисторов всё прибывает,
и как их эффективно использовать — непонятно. Разве только переходом на
многоядерность, интегрированием разнородных ядер и пр. Отсюда и основное
движение в софтостроении — распарраллелить, приготовится к приходу 8-16-32
ядерных процессоров...
А если бы первой закончилась та часть закона Мура, которая о кол-ве транзисторов,
а частота продолжала-бы расти экспоненциально? Вот тогда-бы все говорили
только об этом — как быстрее добраться до памяти. Потому как проходило-бы не
200, а 2000 тактов при доступе к памяти, транзисторов для безмерного кэша просто
не было-бы, и так далее. Архитектура процессоров бы менялась именно в этом направлении.
Но вы не переживайте, это всё временные акценты. Вот когда закончится и вторая
часть, и транзисторов не будет прибавляться, и скорость не будет расти, вот тогда
акценты выровняются, и сегодняшние проблемы нам покажутся цветочками, по сравнению
с грядущими ягодками. Архитектуру надо будем менять и для быстрого доступа к
памяти (и другим устройствам, включая CPU), и для условий нехватки транзисторов,
и для работы с узко-специализированными чипами странной архитектуры, и для
оптимальной работы и настройки адаптируемых чипов (с изменяемой системой
комманд, архитектурой, функциональностью).
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, mkizub, Вы писали:
M>>Весёлое будет время. WH>И тут придет твоя сумаде и всех спасет? WH>Угадал? WH>
Не знаю. Зависит от того, что ты понимаешь под спасением.
Если некую панацею — нет, SymADE не панацея.
Просто эта технология позволяет перейти на новый уровень сложности программ
(за счёт повышения уровня адаптивности, в том числе и адаптивности к
новым аппаратным архитектурам), как раньше OOP позволил перейти на новый уровень
сложности программ.
WH>Вот только ты так и не сказал как.
Сказал, но ты не там искал
WH>Давай без речей типа ньюВасюки. WH>Все хотят видить техническое обоснование.
WH>Отказ от текста обоснованием не является.
Речь идёт от отказе от того уровня стандартизации языков программирования,
которые мы сейчас имеем. Отказ от текстового представления является
необходимым условием для этого (альтернативно прийдётся использовать
примитивный синтаксис а-ля Lisp/Forth).
Здравствуйте, mkizub, Вы писали:
M>Отказ от текстового представления является M>необходимым условием для этого (альтернативно прийдётся использовать M>примитивный синтаксис а-ля Lisp/Forth).
А это почему? И в пользу чего? Текст — это, наверное, одно из самых компактных представлений информации, в том смысле, что на единицу площади, например листа, можно уложить больше всего, и при этом (самое главное) — такое представление будет понятно человеку.
Еще раз подчеркну, что теоритическая возможность нарисовать какой-нибудь прямоугольник, весь испещренный мелкими точечками различных цветов, не интересует, так как, хоть это и позволит упаковать больше информации, но прочесть (декодировать) ее обычному человеку будет вряд ли возможно.
Здравствуйте, mkizub, Вы писали:
M>Если некую панацею — нет, SymADE не панацея.
Если верить твоим речам то таки панацея.
M>Просто эта технология позволяет перейти на новый уровень сложности программ
За счет чего?
M>(за счёт повышения уровня адаптивности, в том числе и адаптивности к новым аппаратным архитектурам),
На сколько новым?
Вернее насколько разнам?
Если в приделах вариаций на тему фон Неймоновской архитектуры то это не интересно.
В этих приделах может адаптироваться практически все.
WH>>Вот только ты так и не сказал как. M>Сказал, но ты не там искал
Я искал базис на котором все будет работать.
Но что-то не вижу.
M>Речь идёт от отказе от того уровня стандартизации языков программирования, которые мы сейчас имеем.
Предлагаешь жить без стандартов?
Или как?
M>Отказ от текстового представления является необходимым условием для этого
Ну этого ты пока не показал.
Пока что вся аргументация сводилась к чемуто типа: "Бедные индусы не поймут что написано на языке высокого уровня."
Проблема в том что реализацию распределенных транзакций они не поймут по любому.
M>(альтернативно прийдётся использовать примитивный синтаксис а-ля Lisp/Forth).
Те ты изобрел что-то типа лиспа или форта?
Замечательно.
Значит у этого чегото должна быть очень простая вычислительная модель которую можно подробно описать за пару часов максимум.
И это вложение окупится ибо такие как я смогут понять что к чему.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Стэн, Вы писали:
С>Здравствуйте, mkizub, Вы писали:
M>>Отказ от текстового представления является M>>необходимым условием для этого (альтернативно прийдётся использовать M>>примитивный синтаксис а-ля Lisp/Forth).
С>А это почему? И в пользу чего? Текст — это, наверное, одно из самых компактных представлений информации, в том смысле, что на единицу площади, например листа, можно уложить больше всего, и при этом (самое главное) — такое представление будет понятно человеку.
С>Еще раз подчеркну, что теоритическая возможность нарисовать какой-нибудь прямоугольник, весь испещренный мелкими точечками различных цветов, не интересует, так как, хоть это и позволит упаковать больше информации, но прочесть (декодировать) ее обычному человеку будет вряд ли возможно.
Речь не идёт об (полном) отказе от текстового отображения.
Что удобно — будет отображаться в виде текста. Но. Те-же функциональные языки жутко хвастаются
возможностью выведения типов. Но фактически, всё, чем это помогает человеку — более компактное
отображение текста программы. Так вот, имея программу в виде дерева, можно отображать в любой
удобной форме — например, показывая типы (в декларациях) или не показывая их. Но это самый мизер
из предоставляющихся возможностей гибкого отображения (и редактирования) кода программ.
Здравствуйте, mkizub, Вы писали:
M>Так вот, имея программу в виде дерева, можно отображать в любой M>удобной форме — например, показывая типы (в декларациях) или не показывая их. Но это самый мизер M>из предоставляющихся возможностей гибкого отображения (и редактирования) кода программ.
Ну, гибкость в отображении — это хорошо, а вот поможет ли это в редактировании, пока не очеидно.
Вот, например, при представлении кода в виде простого текстового файла я могу сохранить его даже, если в нем есть ошибки (хоть лексические, хоть грамматические). А вот в случае баз данных так не получится, так как данные должны быть согласованны, и промежуточные результаты хоть на салфетке записывай...
Так вот, что представляет собой описание программы в виде дерева, в свете этих двух альтернатив? Как учитывается временная несогласованность частей? И каков формат хранения данных — бинарный или текстовый?
Здравствуйте, Стэн, Вы писали:
С>Здравствуйте, mkizub, Вы писали:
M>>Так вот, имея программу в виде дерева, можно отображать в любой M>>удобной форме — например, показывая типы (в декларациях) или не показывая их. Но это самый мизер M>>из предоставляющихся возможностей гибкого отображения (и редактирования) кода программ.
С>Ну, гибкость в отображении — это хорошо, а вот поможет ли это в редактировании, пока не очеидно. С>Вот, например, при представлении кода в виде простого текстового файла я могу сохранить его даже, если в нем есть ошибки (хоть лексические, хоть грамматические). А вот в случае баз данных так не получится, так как данные должны быть согласованны, и промежуточные результаты хоть на салфетке записывай... С>Так вот, что представляет собой описание программы в виде дерева, в свете этих двух альтернатив? Как учитывается временная несогласованность частей? И каков формат хранения данных — бинарный или текстовый?
Лексических и грамматических ошибок в дереве быть не может, по определению. Там лексики нет, и парсера нет.
Все ошибки в них могут быть только семантические. Конечно, ты можешь сохранить файл с ошибками. Пофиг что сохранять — просто дерево дампится в файл.
В текстовом или бинароном виде — тоже пофиг. Сейчас я дамплю в xml-е. Конечно, можно написать имя класса "this$is_a`тип", а вот правильное оно или нет — определится только когда ты выберешь конкретный backend — в некоторых $_` можно использовать в именах, а в других нет. В некоторых имена типов должны начинаться с большой буквы. А в других можно использовать только ascii, уникод нельзя.
Каждый узел дерева — это просто:
а) имя узла (в смысле — тип, то есть "Var" или "PrefixExpression")
б) набор примитивных аттрибутов (int, string, и т.п.)
в) набор под-узлов
г) символьные ссылки на другие узлы (само имя + uuid)
В отличие от, скажем, Lisp-а — у узла есть тип (имя типа), и слоты под аттрибуты/под-узлы именованные (а не по индексу в списке).
Конечно, можно использовать примитивный синтаксис, вроде
(PrefixExpression operator="!" expr=(BoolConst value="true"))
но это будет ещё менее удобно, чем лисп, а смысла практически никакого. Если уж так надо сохранить текст, можно использовать разработку языка вроде XL.
Конечно, этого слишком мало для нормальной работы. Просто это минимум, после определения которого узел будет опознаваться в системе.
А потом на него навешивается дополнительная информация — как отображать/редактировать, как проверять семантическую правильность, как трансформировать в конкретный backend или делать "нормализацию"%, навесить control-flow информацию (если будет использоваться в языке с выводом типов), навесить проверку типов, навесить резолвинг имён и т.п. и т.д. Всего этого в Lisp-е за задать.
Отличие от современных средств разработки в том, что эта информация задаётся централизованно, единожды заданная она используется всеми средствами.
Скажем, если я задал правила резолвинга имён — это используется и в компиляторе, и в редакторе для авто-комплита.
Дерево версионное, можно открывать транзакции, в которые будут автоматом записываться все изменения — и версионность используется и редактором
для undo, и компилятором для отката ненужных трансформаций и т.п.
Конечно, синтаксис никуда не делся. Просто это не текстовый синтаксис, это описание формата узла (имени, имён и типов аттрибутов) и формата дополнительной информации.
Здравствуйте, WolfHound, Вы писали:
M>>Отказ от текстового представления является необходимым условием для этого WH>Ну этого ты пока не показал.
Сам смотри, если есть чем. WH>Пока что вся аргументация сводилась к чемуто типа: "Бедные индусы не поймут что написано на языке высокого уровня."
Этой аргументации ты от меня услышать не мог, потому как не было её. WH>Проблема в том что реализацию распределенных транзакций они не поймут по любому.
Проблема в языке, на котром эти транзакции излагаются.
M>>(альтернативно прийдётся использовать примитивный синтаксис а-ля Lisp/Forth). WH>Те ты изобрел что-то типа лиспа или форта? WH>Замечательно. WH>Значит у этого чегото должна быть очень простая вычислительная модель которую можно подробно описать за пару часов максимум. WH>И это вложение окупится ибо такие как я смогут понять что к чему.
Ты умеешь просто фантастически неправильно понять. Выдёргиваешь знакомое слово, и у тебя несётся туева хуча ассоциаций,
никак к делу не относящихся.
SymADE — это не язык программирования и не процессор. Это среда разработки. У неё нет вычислительной модели.
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, Стэн, Вы писали:
С>>Здравствуйте, mkizub, Вы писали:
M>>>Так вот, имея программу в виде дерева, можно ...
M>Конечно, этого слишком мало для нормальной работы. Просто это минимум, после определения которого узел будет опознаваться в системе. M>А потом на него навешивается дополнительная информация — как отображать/редактировать, как проверять семантическую правильность, как трансформировать в конкретный backend или делать "нормализацию"%, навесить control-flow информацию (если будет использоваться в языке с выводом типов), навесить проверку типов, навесить резолвинг имён и т.п. и т.д. ...
Забавно, но именно под таким соусом мне подают сейчас лисп
Вопрос — сколько имеющихся backends имеют понятие о cache-conscious data structures ? Или это по принципу "это все оставлено как упражнение для читателя".
Здравствуйте, SleepyDrago, Вы писали:
SD>Здравствуйте, mkizub, Вы писали:
M>>Здравствуйте, Стэн, Вы писали:
С>>>Здравствуйте, mkizub, Вы писали:
M>>>>Так вот, имея программу в виде дерева, можно ...
M>>Конечно, этого слишком мало для нормальной работы. Просто это минимум, после определения которого узел будет опознаваться в системе. M>>А потом на него навешивается дополнительная информация — как отображать/редактировать, как проверять семантическую правильность, как трансформировать в конкретный backend или делать "нормализацию"%, навесить control-flow информацию (если будет использоваться в языке с выводом типов), навесить проверку типов, навесить резолвинг имён и т.п. и т.д. ...
SD>Забавно, но именно под таким соусом мне подают сейчас лисп
Да? Про отображение/редактирование попродробней, плиз. Кто, где, что делает.
SD>Вопрос — сколько имеющихся backends имеют понятие о cache-conscious data structures ? Или это по принципу "это все оставлено как упражнение для читателя".
Это оставлено как упражнение для производителей железа и компиляторов. А SymADE решает задачу возможности расширения языков соответствующими
семантическими понятиями. А равно и семантическими понятиями для всех остальных целей. И начинал этот разговор я с того, что
проблемы латентности памяти или многотредовости — это достаточно мелкие проблемы, по сравнению с теми, что ожидают нас в недалёком
будущем. И вот SymADE — это технология, парадигма решения этих проблем. А не само решение. Так же, как, скажем, OOP или FP — это
парадигма, технология решения определённых проблем, а не конкретные программы и не конкретные языки программирования для
конкретных backend-ов.
Здравствуйте, mkizub, Вы писали:
M>>>>>Так вот, имея программу в виде дерева, можно ... SD>>Забавно, но именно под таким соусом мне подают сейчас лисп M>Да? Про отображение/редактирование попродробней, плиз. Кто, где, что делает.
Отображением и редактированием занимается текстовый редактор
SD>>Вопрос — сколько имеющихся backends имеют понятие о cache-conscious data structures ? Или это по принципу "это все оставлено как упражнение для читателя".
M>Это оставлено как упражнение для производителей железа и компиляторов. А SymADE решает задачу возможности расширения языков соответствующими M>семантическими понятиями. А равно и семантическими понятиями для всех остальных целей. И начинал этот разговор я с того, что M>проблемы латентности памяти или многотредовости — это достаточно мелкие проблемы, по сравнению с теми, что ожидают нас в недалёком M>будущем. И вот SymADE — это технология, парадигма решения этих проблем. А не само решение. Так же, как, скажем, OOP или FP — это M>парадигма, технология решения определённых проблем, а не конкретные программы и не конкретные языки программирования для M>конкретных backend-ов.
Пока вы не решили 1 конкретную задачу, то парадигма — пустой звук. Вот например cache-conscious. Это проблема тк любое высокоуровневое описание этому делу в лучшем случае не помогает. предлагаемая идея в стиле "давайте все засунем в xml/lisp/ast" это не решение ни одной из задач. это в лучшем случае декларация намерений ее решить. Потому как эта форма описания не работает, а та которая работает — не высокоуровневая. И по сравнению с обычным boilterplate нужно иметь проблему например с деталями xml и инструментами отладки.
То есть утверждение что "эта задача не такая важная" это не конструктивно.
Меня кстати очень интересует набор инструментов, который бы позволял такие вещи как cache-conscious манипуляции с си в качестве target platform. Можете продемонстрировать пример ?
Здравствуйте, mkizub, Вы писали:
WH>>Ну этого ты пока не показал. M>Сам смотри, если есть чем.
Есть чем. Но не на что.
WH>>Проблема в том что реализацию распределенных транзакций они не поймут по любому. M>Проблема в языке, на котром эти транзакции излагаются.
Нет. Проблема в алгоритмах.
Ты сам то пробовал делать распределенные транзакции?
Или хотябы локальные?
M>Ты умеешь просто фантастически неправильно понять. Выдёргиваешь знакомое слово, и у тебя несётся туева хуча ассоциаций, никак к делу не относящихся.
Где уж нам уж.
M>SymADE — это не язык программирования и не процессор. Это среда разработки. У неё нет вычислительной модели.
Ты же пишешь в этой среде программы. Так?
Далие эта среда переводит эти программы в некий другой вид (например байткод JVM).
Следовательно просто обязан быть нейкий базис относительно которого будут происходить трансформации.
Его просто не может не быть физически.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
M>>SymADE — это не язык программирования и не процессор. Это среда разработки. У неё нет вычислительной модели. WH>Ты же пишешь в этой среде программы. Так? WH>Далие эта среда переводит эти программы в некий другой вид (например байткод JVM). WH>Следовательно просто обязан быть нейкий базис относительно которого будут происходить трансформации. WH>Его просто не может не быть физически.
Ну нету его. Какая вычислительная модель у Eclipse? Никакой. Есть плагины к Eclipse, в которых
и реализуется компиляция кода, отдельный плагин для Java, отдельный для C++ и так далее.
Eclipse предоставляет платформу — редакторы, средства сохранения настроек, GUI и т.п.
Так же и SymADE — это платформа для компиляторов.
Отличия SymADE от Eclipse в том, что Eclipse вообще никак не стандартизирует внутреннее представление
програм на разных языках, а в SymADE это внутренее представление стандартизировано. В SymADE есть
набор "заготовок" общих для разных языков программирования, но он не требует, чтоб эти "заготовки"
использовались конкретным компилятором (плагином). Заготовки — это типа "Var", "Class", "Method",
"BinaryExpr" и т.д. Скажем, единственный реализованный у меня сейчас компилятор (в java bytecode)
берёт эти заготовки и трансформирует дерево в соответствии со своим представлением. Например, берёт
"заготовку" AccessExpr, у которого есть два аттрибута (под-узла) — accessor и lvalue-decl.
Если accessor — ThisExpr или просто другое выражение, то он заменяет этот узел на явовский
узел InstanceFieldAccessExpr. А если это TypeReference, то заменяет на StaticFieldAccessExpr.
И так далее. В конце трансформации получается набор из семантических узлов непосредственно
соответствующих понятиям JVM. У меня два backend-а, один дампит это дерево как явовский source
code, а другой дампит это-же дерево в java bytecode.
Практически все расширения к яве у меня реализованы как эти плагины, трансформирующие дерево.
Собственно, и сами добавления к яве в версиях больше 1.0 тоже реализованы как плагины. Плагин
и семантические узлы для enum-ов, плагин и семантические узлы для assert-ов и т.д.
Скажем, моё расширение для generic types позволяет в рантайме получать тип аргументов у контейнера.
Для этого он вставляет во все NewExpr и во все аргументы Constructor-ов этих контейнеров
специально генерируемые данные, потом модифицирует InstanceOfExpr, CastExpr, NewExpr, NewArrayExpr
и другие явовские узлы так, что они используют эти сгенерированные данные в рантайме. А для
.NET подобное не нужно генерировать, он это сам поддерживает, такой трансформер дерева
можно не использовать.
Но сам SymADE ничего не вычисляет. Точнее, если у узла заданы сведения о том, как резолвить в нём
имена, как получить его тип, какой у него data/control flow — они вычисляются. А трансформации
производятся плагинами и backend-ами (которые, собственно говоря, тоже плагины).
Здравствуйте, mkizub, Вы писали:
M>Отличия SymADE от Eclipse в том, что Eclipse вообще никак не стандартизирует внутреннее представление програм на разных языках, а в SymADE это внутренее представление стандартизировано.
Очень интересно.
Каким образом?
M>В SymADE есть набор "заготовок" общих для разных языков программирования, но он не требует, чтоб эти "заготовки" использовались конкретным компилятором (плагином).
Что будет если в дереве есть некие узлы которые не понимает бекенд?
Например комуто захочется использовать континюэйшены. Как ты код с континюэйшенами превратишь в жабовский байткод?
M>Заготовки — это типа "Var", "Class", "Method", "BinaryExpr" и т.д.
Те все языки ограничиваются жабой и C#ом?
M>Скажем, единственный реализованный у меня сейчас компилятор (в java bytecode) берёт эти заготовки и трансформирует дерево в соответствии со своим представлением. Например, берёт "заготовку" AccessExpr, у которого есть два аттрибута (под-узла) — accessor и lvalue-decl. M>Если accessor — ThisExpr или просто другое выражение, то он заменяет этот узел на явовский узел InstanceFieldAccessExpr. А если это TypeReference, то заменяет на StaticFieldAccessExpr.
А что делать с хаскелем?
M>И так далее. В конце трансформации получается набор из семантических узлов непосредственно соответствующих понятиям JVM. У меня два backend-а, один дампит это дерево как явовский source code, а другой дампит это-же дерево в java bytecode.
Короче из того что я вижу тебе нужно срочно менять позиционирование своей сумаде как мегатул для жабы.
Но не для решения вобще всех проблем человечества.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, mkizub, Вы писали:
M>>Отличия SymADE от Eclipse в том, что Eclipse вообще никак не стандартизирует внутреннее представление програм на разных языках, а в SymADE это внутренее представление стандартизировано. WH>Очень интересно. WH>Каким образом?
Метаданными, данными и операциями которые можно производить над узлами дерева/графа.
Чуть выше я об этом писал (не тебе).
M>>В SymADE есть набор "заготовок" общих для разных языков программирования, но он не требует, чтоб эти "заготовки" использовались конкретным компилятором (плагином). WH>Что будет если в дереве есть некие узлы которые не понимает бекенд?
В этот бэкэнд скомпилировать код использующий эти узлы — будет нельзя.
WH>Например комуто захочется использовать континюэйшены. Как ты код с континюэйшенами превратишь в жабовский байткод?
В ПРЫНЦЫПЕ это можно сделать. Только это будет настолько неэффективно, что никто даже заморачиваться не будет.
Но если кому-то нужно — то можно сделать. Не continuation в полном виде, а некий урезанный вариант, который
покроет его нужды. Что-то подобное я и сделал для своего логического движка — мне нужен был backtracking,
yield, и я их сделал — для конкретного типа методов.
M>>Заготовки — это типа "Var", "Class", "Method", "BinaryExpr" и т.д. WH>Те все языки ограничиваются жабой и C#ом?
Языков в твоём понимании там вообще нет. Есть семантические понятия, можно создавать (чисто для удобства) онтологии
оных, которые будут являтся аналогом языка программирования. Но в коде программы можно легко смешивать любые
семантические узлы. Если backend тебя не поймёт — это не проблемы SymADEа. Это проблемы того кто писал код
и кто писал backend. Кому надо Var в хаскеле (неком гипотетическом хаскелевском backend-е) — тот и через
IO сделает генерацию кода для них.
M>>Скажем, единственный реализованный у меня сейчас компилятор (в java bytecode) берёт эти заготовки и трансформирует дерево в соответствии со своим представлением. Например, берёт "заготовку" AccessExpr, у которого есть два аттрибута (под-узла) — accessor и lvalue-decl. M>>Если accessor — ThisExpr или просто другое выражение, то он заменяет этот узел на явовский узел InstanceFieldAccessExpr. А если это TypeReference, то заменяет на StaticFieldAccessExpr. WH>А что делать с хаскелем?
Подумай.
M>>И так далее. В конце трансформации получается набор из семантических узлов непосредственно соответствующих понятиям JVM. У меня два backend-а, один дампит это дерево как явовский source code, а другой дампит это-же дерево в java bytecode. WH>Короче из того что я вижу тебе нужно срочно менять позиционирование своей сумаде как мегатул для жабы.
Спасибо, я пешком постою.
WH>Но не для решения вобще всех проблем человечества.
Да что тебе неймётся с панацеями. У тебя очень ограниченный набор терминов, в которых ты можешь размышлять.
Я тебе уже десять раз сказал — это не решение всех проблем человечества, и даже не решение всех проблем
программирования. Но ты никак не можешь сойти с колеи которую сам себе в мозгу протоптал.
Здравствуйте, mkizub, Вы писали:
M>Метаданными, данными и операциями которые можно производить над узлами дерева/графа.
Ясно. Святым духом.
M>В этот бэкэнд скомпилировать код использующий эти узлы — будет нельзя.
Ясно.
Будет весьма ограниченное колличество узлов которые будут отображатся в весьма ограниченное колличество очень похожих бекендов.
Видимо только шарп и жаба.
Ну может что-то еще сильно похожее на первые 2.
M>В ПРЫНЦЫПЕ это можно сделать.
Ну очень в принципе ибо жаба полна по Тьюрингу.
Проблема в том что придется натгивать на жабу другую вычислительную модель.
M>Только это будет настолько неэффективно, что никто даже заморачиваться не будет.
Во-во.
M>Но если кому-то нужно — то можно сделать. Не continuation в полном виде, а некий урезанный вариант, который покроет его нужды.
Любители континьейшенов очень любят call/cc. Так что захотят именно его.
Еще они любят shift/reset тоже не подарок.
M>Языков в твоём понимании там вообще нет.
А тебе что извесно мое понимаение языков?
Не думаю.
Ибо твое семантическое дерево в моем понимании это тоже язык.
Бессмысленный язык без четкой модели, допускающий кучу неопределенного поведения.
M>Есть семантические понятия, можно создавать (чисто для удобства) онтологии оных, которые будут являтся аналогом языка программирования. Но в коде программы можно легко смешивать любые семантические узлы.
Не любые, а только те что понимает бекенд.
Также нужно понимать что некоторые узлы просто физически не совместимы друг с другом.
Например call/cc и конструкторы/деструкторы из С++.
Ты просто не сможешь написать бекенд который превратит дерево с этими узлами во что-то осмысленное.
M>Если backend тебя не поймёт — это не проблемы SymADEа. M>Это проблемы того кто писал код и кто писал backend.
Нет это проблемы сумаде.
Ибо код написанный под один бекенд не будет работать на другом бекенде.
Те вся переносимость идет в топку.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
M>>Есть семантические понятия, можно создавать (чисто для удобства) онтологии оных, которые будут являтся аналогом языка программирования. Но в коде программы можно легко смешивать любые семантические узлы. WH>Не любые, а только те что понимает бекенд.
WH>Также нужно понимать что некоторые узлы просто физически не совместимы друг с другом. WH>Например call/cc и конструкторы/деструкторы из С++. WH>Ты просто не сможешь написать бекенд который превратит дерево с этими узлами во что-то осмысленное.
M>>Если backend тебя не поймёт — это не проблемы SymADEа. M>>Это проблемы того кто писал код и кто писал backend. WH>Нет это проблемы сумаде. WH>Ибо код написанный под один бекенд не будет работать на другом бекенде. WH>Те вся переносимость идет в топку.
Ты так уверенно писал, что тебе всё ясно, что я просто в растерянности от последовавших неверных выводов.
Чего же ты проигнорировал реализацию Var в хаскеле через IO? Наверное, она мешала стройности твоего
понимания. Потому как этот пример чётко показывает, что вставлять можно любые узлы, и эти узлы могут
быть трансформированны так, чтоб их понял backend.
Кроме того, где ты видел обещание переносимости? Я такого не обещал.
Переносимо писать в SymADE можно, но для этого надо выполнить некоторые условия.
Главное — надо писать семантику, а не реализацию. То есть, надо писать log INFO "Cannot do this",
где log — это семантическое понятие, имеющий атрибут для severity и атрибут для текста сообщения.
А не getLogger().logInfo("Cannot do this"), потому как этот код использует конкретную библиотеку
и конкретный язык. На платформе, где нет backend-а для этого языка или нет реализации этой библиотеки —
программа и не скопилится. А некий абстрактный log можно скомилировать практически во что угодно,
на какой угодно платформе и используя кучу разных средств. А можно вообще выкинуть, если копилируется
с настройками не выводить логгинга. Вот поэтому и назвал Чарльз Симони похожую технологию — intentional
programming. Потому как она предполагает кодировать намерения программиста, а не конкретный код
под конкретную платформу. А компьютер по возможности автоматизирует компиляцию в конкретный код под
конкретную платформу.
Ты всё ищешь в SymADE панацею. Хоть я тебе уже не раз говорил — это не она. Но это хороший
инструмент для автоматизации работы программиста, чтоб компьютер думал вместо него. А если
ты будешь этот инструмент использовать как просто среду для набивания кода в старом языке
программирования — много ты с него не получишь. Точно так-же, как используя компилятор C++
для компиляции C-шных исходников — никакого эффекта от ООП компилера ты не заметишь. ООП
виноват будет?
Здравствуйте, mkizub, Вы писали:
M>Ты так уверенно писал, что тебе всё ясно, что я просто в растерянности от последовавших неверных выводов.
Не верных или не укладывающихся в твою картинку мира?
M>Чего же ты проигнорировал реализацию Var в хаскеле через IO?
А что на него реагировать?
Меня другое интересует: Почему ты проигнорировал невозможность укатать в одно дерево call/cc и деструкторы С++?
Наверное, она мешала стройности твоего понимания.
(С)Ты
Ы?
M>Потому как этот пример чётко показывает, что вставлять можно любые узлы, и эти узлы могут быть трансформированны так, чтоб их понял backend.
IO в хаскеле показывает что можно выкрутится в одном частном случае.
Причем данный частный случай не содержит противоречий внутри дерева.
А может и не повести... см про call/cc и деструкторы.
M>Кроме того, где ты видел обещание переносимости?
А в чем смысл без переносимости?
M>Переносимо писать в SymADE можно, но для этого надо выполнить некоторые условия. M>Главное — надо писать семантику, а не реализацию. То есть, надо писать log INFO "Cannot do this", где log — это семантическое понятие, имеющий атрибут для severity и атрибут для текста сообщения. А не getLogger().logInfo("Cannot do this"), потому как этот код использует конкретную библиотеку и конкретный язык.
Да пойми ты наконец что это твое семантическое дерево и есть язык и log INFO "Cannot do this" часть программы на этом языке.
M>На платформе, где нет backend-а для этого языка или нет реализации этой библиотеки — программа и не скопилится.
Те будет еще хуже чем с С++.
Чтобы программа компилировалась на разных платформах придется жить с очень не большим колличеством узлов которые понимют наиболие распространенные бекенды.
M>А некий абстрактный log можно скомилировать практически во что угодно, на какой угодно платформе и используя кучу разных средств. M>А можно вообще выкинуть, если копилируется с настройками не выводить логгинга.
Ты просто не предстваляешь в какой геморой при деплойменте выльются такие выкрутасы.
M>Ты всё ищешь в SymADE панацею. Хоть я тебе уже не раз говорил — это не она.
Это несколько расходится с твоими речами про то что всем кто не будет использовать сумаде будет ой как плохо.
M>Но это хороший инструмент для автоматизации работы программиста, чтоб компьютер думал вместо него.
Компьютер думать не умеет.
Вобще.
Он может только проводить преобразования по некоторым правилам.
Проблема твоего семантического дерева в том что есть семантические поянтия которые при появлении в дереве приводят систему в состояние в котором просто невозможно сформулировать осмысленные правила.
M>А если ты будешь этот инструмент использовать как просто среду для набивания кода в старом языке программирования — много ты с него не получишь.
И я о томже... ибо от языков ты никуда не ушол.
Семантическое дерево это язык.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
M>>Но если кому-то нужно — то можно сделать. Не continuation в полном виде, а некий урезанный вариант, который покроет его нужды. WH>Любители континьейшенов очень любят call/cc. Так что захотят именно его. WH>Еще они любят shift/reset тоже не подарок.
Ты неправильно ставишь вопрос, т.к. это вообще спорная технология. Она используется не как самоцель, а как подпорка ввиду отсутствия другого, более детерминированного инструментария (типа иерархии ексепшенов в других языках).
Здравствуйте, vdimas, Вы писали:
V>Ты неправильно ставишь вопрос, т.к. это вообще спорная технология. Она используется не как самоцель, а как подпорка ввиду отсутствия другого, более детерминированного инструментария (типа иерархии ексепшенов в других языках).
Можно развернуть?
Ещё: в схеме есть и исключения и продолжения, т.е. "ввиду отсутствия" здесь вроде как не проходит.
Здравствуйте, WolfHound, Вы писали:
WH>Меня другое интересует: Почему ты проигнорировал невозможность укатать в одно дерево call/cc и деструкторы С++? WH>
Наверное, она мешала стройности твоего понимания.
WH>(С)Ты WH>Ы?
Я на более общий вопрос уже отвечал. Ну хорошо, отвечу на этот конкретный, но всё равно скажу то-же самое.
В одно дерево укатать call/cc и С++ можно. Только ты врядли найдёшь backend который это поддержит.
И врядли сможешь написать трансформатор для такого дерева. По вполне очевидным причинам — не предусмотрено
в С++, что по стеку будут откатываться несколько раз. И даже если это будет Java, и память не будет
руками выделяться, и повторные close() для ресурсов не будут убивать программу — всё равно call/cc
в ней не нужен. Потому как это в лиспе и иже с ним, ветвление стека дешёвое. Потому как он и так в
хипе лежит, а то и в linked list заимплеменчен. Посему, C++/Java программист будет решать поставленную
задачу адекватными средствами. Создаст thread factory и передаст на него ссылку. И будут эти треды
создавать и вызывать сколько угодно раз, без всякого гемороя с реализацией continuation.
И я тебе писал, что я решал похожую задачу, только мне надо было yeild сделать. Не вообще сделать, а
с конкретной целью, обеспечить backtracking в logic методах. И я его сделал, простой генерацией
кода, когда фрейм (локальные переменные) методов закатывался в отдельный класс, там же сохранялась
точка в которой мы вышли из метода в последний раз, там-же хранилась информация для backtrack-а.
И всё замечательно работает до сих пор.
ПОТОМУ, ЧТО Я РЕШАЛ НЕ ЗАДАЧУ _ВООБЩЕ_, А РЕШАЛ _КОНКРЕТНУЮ_ ПРОБЛЕМУ.
Это ключевое для SymADE. Он позволяет решать конкретные проблемы.
Потому как всякое решение, общее или частное, имеет свой trade-off, свои компромисы.
В лиспе continuation — это удобно, но цена за это — невозможность иметь аппаратный,
быстрый стек в виде массива, immutable данные в стеке и т.п.
Когда человек желает некую фичу — он должен ясно себе представлять ту цену, в которую
она ему обойдётся. И решить для себя — платит он эту цену или нет.
Очевидно, что если человек пишет на C++, то он выбрал быструю работу программы, низкоуровневую
оптимизацию и т.п. Цена — невозможность многих вещей, вроде precision GC, call/cc
и огромного количества других полезностей. Видимо, эти полезности в его текущей задаче не
настолько нужны, насколько нужна скорость исполнения и минимальные требования к ресурсам.
А для другой задачи он выберет другой backend, где на скорость работы он расчитывать
не сможет, но зато сделает прогармму быстро, надёжно, дёшево.
Но сейчас у программиста есть выбор между несколькими фиксированными платформами,
у каждой из которых эти компромисы, эти trade-offы уже выбраны и зафиксированы.
А SymADE позволяет эти trade-offы выбирать намного более гибко.
Если в Java нет closures — то сегодня это всё, нету их. Может появятся лет
через 5. А мне для проекта их хочется, и я их активно использую. Вот я добавляю
семантический узел для closures, пишу простой tree transformer, который их
конвертит в inner anonymouse class, и они у меня уже есть. Пока это только
синтаксический сахар. Но я всегда могу идти дальше, добавить то, чего нет
в Java как языке, но есть в JVM — те-же goto, например. Их использование
ускорило код для backtrack-инга в два раза. Правда, в java source code
уже не выдашь goto, но можно написать два трансформера (или конфигурировать
один) — для конвертации в набор узлов имеющихся в java language и в набор
узлов имеющихся в JVM. Можно идти и дальше, и добавлять новые возможности
в JVM — благо она сейчас open-source. Можно идти и дальше, и добавлять
новые возможности в железо, и SymADE позволит их использовать.
M>>Потому как этот пример чётко показывает, что вставлять можно любые узлы, и эти узлы могут быть трансформированны так, чтоб их понял backend. WH>IO в хаскеле показывает что можно выкрутится в одном частном случае. WH>Причем данный частный случай не содержит противоречий внутри дерева. WH>А может и не повести... см про call/cc и деструкторы.
Когда человек решает конкретную проблему, а не общую — как правило везёт.
M>>Кроме того, где ты видел обещание переносимости? WH>А в чем смысл без переносимости?
Выше написал.
M>>Переносимо писать в SymADE можно, но для этого надо выполнить некоторые условия. M>>Главное — надо писать семантику, а не реализацию. То есть, надо писать log INFO "Cannot do this", где log — это семантическое понятие, имеющий атрибут для severity и атрибут для текста сообщения. А не getLogger().logInfo("Cannot do this"), потому как этот код использует конкретную библиотеку и конкретный язык. WH>Да пойми ты наконец что это твое семантическое дерево и есть язык и log INFO "Cannot do this" часть программы на этом языке.
Я это отлично понимаю.
Я писал, дословно, — "языки, в современном понимании этого слова".
В современно понимании — язык это фиксированный набор семантических понятий.
А у меня — изменяемый набор семантических понятий.
M>>На платформе, где нет backend-а для этого языка или нет реализации этой библиотеки — программа и не скопилится. WH>Те будет еще хуже чем с С++. WH>Чтобы программа компилировалась на разных платформах придется жить с очень не большим колличеством узлов которые понимют наиболие распространенные бекенды.
Ну, а как-же возможности трансформации дерева?
Если для тебя ценным является переносимость — то да, живи с небольшим набором. Это такой выбор в trade-offах,
твоя цена за переносимость. А другой программист пишет для конкретной платформы, иногда даже для конкретной
железяки. Он сделает совсем другой выбор в этом-же trade-offе.
Ценность SymADE в том, что он позволяет делать эти выборы.
Как известно, наши достоинства — это продолжения наших недостатков
Вот в SymADE выбор в trade-offe между стандартизированностью и гибкостью сделан в пользу гибкости.
Что не делает его лучше "вообще". Он будет лучше в частной, конкретной ситуации, которая нас
вскорости настигнет — разнообразие и гибкость аппаратных средств, всё более сложные задачи,
которые будут решать программисты.
M>>А некий абстрактный log можно скомилировать практически во что угодно, на какой угодно платформе и используя кучу разных средств. M>>А можно вообще выкинуть, если копилируется с настройками не выводить логгинга. WH>Ты просто не предстваляешь в какой геморой при деплойменте выльются такие выкрутасы.
Например?
Ты, кстати, учитываешь, что деплоить можно как программу содержащую семантический узел log
(на платформу, которая его динамически скомпилирует во что ей надо), так и уже скомпилированную
в нечто (в printf, в getLogger(), в (void) и т.п.)?
M>>Ты всё ищешь в SymADE панацею. Хоть я тебе уже не раз говорил — это не она. WH>Это несколько расходится с твоими речами про то что всем кто не будет использовать сумаде будет ой как плохо.
Я вообще стараюсь не употреблять слова высшего уровня абстрактности, такие как "все", "никто", "всегда"
и т.п. Так что маловероятно, чтоб я писал такое.
M>>Но это хороший инструмент для автоматизации работы программиста, чтоб компьютер думал вместо него. WH>Компьютер думать не умеет. WH>Вобще. WH>Он может только проводить преобразования по некоторым правилам. WH>Проблема твоего семантического дерева в том что есть семантические поянтия которые при появлении в дереве приводят систему в состояние в котором просто невозможно сформулировать осмысленные правила.
Да. Я так и написла с самого начала — это путь к отказу от стандартов (не полному отказу, конечно), что
позволит сделать программирование более гибким. Конечно, отказ от стандартов и большая гибкость это и
предполагают — бОльшие проблемы при сведении разных семантических понятий в одном коде.
Ты сейчас не имеешь этих проблем, потому как у тебя и выбора такого нету. Тебе никто, никакой
стандарт, если это целостный стандарт, не даст свести в одном языке конфликтные фичи, конфликтные
семантические понятия. А в SymADE ты это можешь сделать. Но, хотя и не обязан этого делать, не пользуясь
этой возможностью ты себя слишком ограничиваешь, будешь использовать его в четверть силы.
Тогда уж лучше оставаться на старых средствах программирования (то есть на сегодняшний день — современных).
Как я уже писал выше, по моему мнению, задач, в которых можно будет использовать эти "современные"
средства — со временем будет всё меньше.
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, vdimas, Вы писали:
V>>Ты неправильно ставишь вопрос, т.к. это вообще спорная технология. Она используется не как самоцель, а как подпорка ввиду отсутствия другого, более детерминированного инструментария (типа иерархии ексепшенов в других языках).
L>Можно развернуть? L>Ещё: в схеме есть и исключения и продолжения, т.е. "ввиду отсутствия" здесь вроде как не проходит.
M>Exceptions in SISC are a simple wrapper around an error record and an associated error continuation.
Вроде как это всего лишь одна из реализаций схемы.
В стандарте и srfi не прописана обязательная имплементация исключений через продолжения.
Да и это имеет совсем небольшое отношение к моему вопросу.
Здравствуйте, vdimas, Вы писали:
V>Ты неправильно ставишь вопрос, т.к. это вообще спорная технология. Она используется не как самоцель, а как подпорка ввиду отсутствия другого, более детерминированного инструментария (типа иерархии ексепшенов в других языках).
Как раз продолжения это вполне фундаментальная вещь, а иерархии исключений и т. п. больше похожи на костыли и подпорки.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, vdimas, Вы писали:
V>>Ты неправильно ставишь вопрос, т.к. это вообще спорная технология. Она используется не как самоцель, а как подпорка ввиду отсутствия другого, более детерминированного инструментария (типа иерархии ексепшенов в других языках).
FR>Как раз продолжения это вполне фундаментальная вещь, а иерархии исключений и т. п. больше похожи на костыли и подпорки.
Фундаментальная вещь — это которую на кривой кобыли не объедешь. Закон сохранения энергии, например.
А программировать без продолжений — вполне можно. Настолько можно, что все мэйнстрим языки без этой возможности совершенно не страдают.
Здравствуйте, FR, Вы писали:
FR>Как раз продолжения это вполне фундаментальная вещь, а иерархии исключений и т. п. больше похожи на костыли и подпорки.
У продолжений есть очень серьезная проблема: Они не совместимы с детерминированным освобождением ресурсов.
Короче в практически приминимых языках придется обойтись исключениями и корутинами.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>Ты неправильно ставишь вопрос, т.к. это вообще спорная технология. Она используется не как самоцель, а как подпорка ввиду отсутствия другого, более детерминированного инструментария (типа иерархии ексепшенов в других языках).
Это мягко говоря не так.
Продолжения можно использовать и для построения логики.
Причем иногда с ними все получается проще.
С другой стороны мы теряем возможность анализа программы ибо потоки исполнения становятся совершенно произвольными и могут очень сильно меняться со временем.
Так же пропадает возможность детерминированной финализации.
Тут по любому приходится выберать что нам важнее.
Лично мой выбор не в пользу продолжений ибо помогают они редко, а пакостят всегда.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, mkizub, Вы писали:
M>Я на более общий вопрос уже отвечал.
Где?
M>Ну хорошо, отвечу на этот конкретный, но всё равно скажу то-же самое. M>В одно дерево укатать call/cc и С++ можно. Только ты врядли найдёшь backend который это поддержит. M>И врядли сможешь написать трансформатор для такого дерева.
Значит нельзя.
Если программу нельзя исполнить все остальное бла-бла-бла.
M>По вполне очевидным причинам — не предусмотрено в С++, что по стеку будут откатываться несколько раз.
Не верная диагностика.
Продолжения несовместимы с любой детерминированной финализацией.
M>И даже если это будет Java, и память не будет руками выделяться, и повторные close() для ресурсов не будут убивать программу — всё равно call/cc в ней не нужен.
А конкретному разработчику нужен.
Он хочет call/cc.
А ты заявляешь что можно засунуть в дерево любые узлы и все будет работать.
M>Потому как это в лиспе и иже с ним, ветвление стека дешёвое. Потому как он и так в хипе лежит, а то и в linked list заимплеменчен.
Это называется спагетти стек.
M>Посему, C++/Java программист будет решать поставленную задачу адекватными средствами. M>Создаст thread factory и передаст на него ссылку. И будут эти треды создавать и вызывать сколько угодно раз, без всякого гемороя с реализацией continuation.
Те мы таки приходим к тому что твое сумаде весьма огриничено жабообразными язычками?
M>Это ключевое для SymADE. Он позволяет решать конкретные проблемы.
Если бекенд позволит.
M>Потому как всякое решение, общее или частное, имеет свой trade-off, свои компромисы. M>В лиспе continuation — это удобно, но цена за это — невозможность иметь аппаратный, быстрый стек в виде массива, immutable данные в стеке и т.п.
Фигня это, а не цена.
Цена это невозможность детерминированной финализации.
M>А для другой задачи он выберет другой backend, где на скорость работы он расчитывать не сможет, но зато сделает прогармму быстро, надёжно, дёшево.
Те по факту другой язык и другой компилятор.
M>Но сейчас у программиста есть выбор между несколькими фиксированными платформами, у каждой из которых эти компромисы, эти trade-offы уже выбраны и зафиксированы. M>А SymADE позволяет эти trade-offы выбирать намного более гибко.
Как мы выяснили не позволяет.
M>Если в Java нет closures — то сегодня это всё, нету их. Может появятся лет через 5. А мне для проекта их хочется, и я их активно использую. Вот я добавляю семантический узел для closures, пишу простой tree transformer, который их конвертит в inner anonymouse class, и они у меня уже есть. Пока это только синтаксический сахар. Но я всегда могу идти дальше, добавить то, чего нет в Java как языке, но есть в JVM — те-же goto, например. Их использование ускорило код для backtrack-инга в два раза. Правда, в java source code уже не выдашь goto, но можно написать два трансформера (или конфигурировать один) — для конвертации в набор узлов имеющихся в java language и в набор узлов имеющихся в JVM. Можно идти и дальше, и добавлять новые возможности в JVM — благо она сейчас open-source. Можно идти и дальше, и добавлять новые возможности в железо, и SymADE позволит их использовать.
Ты вобще представляешь сколько человек на такое способны?
У тебя будут теже проблемы что и у лиспа (только в еще болие запущенной форме ибо в лиспе нет зоопарка бекендов)... прежде чем написать на лиспе программу нужно написать для нее язык.
M>Когда человек решает конкретную проблему, а не общую — как правило везёт.
Проблема в том что всегда можно найти понятия которые несвместимы.
И особенно весело получится если попытаться использовать чужой код.
WH>>А в чем смысл без переносимости? M>Выше написал.
Нет.
M>Я это отлично понимаю. M>Я писал, дословно, — "языки, в современном понимании этого слова". M>В современно понимании — язык это фиксированный набор семантических понятий. M>А у меня — изменяемый набор семантических понятий.
Библиотеки в языках вполне себе наборы семантических понятий под задачу.
Итвои наборы узлов не болие чем библиотеки для твоей сумаде.
M>Ну, а как-же возможности трансформации дерева?
А всеравно дальше бекенда не уйдешь.
M>Если для тебя ценным является переносимость — то да, живи с небольшим набором.
Она ценна всегда.
Иначе так бы и писали на макроассемблере.
M>Ценность SymADE в том, что он позволяет делать эти выборы.
Да ничерта он не позволяет.
M>Как известно, наши достоинства — это продолжения наших недостатков M>Вот в SymADE выбор в trade-offe между стандартизированностью и гибкостью сделан в пользу гибкости.
Баз стандартизации в индустрии ничего выжить не может.
M>Что не делает его лучше "вообще". Он будет лучше в частной, конкретной ситуации, которая нас вскорости настигнет — разнообразие и гибкость аппаратных средств, всё более сложные задачи, которые будут решать программисты.
Начал с частностей, а закончил глобальными вещами...
WH>>Ты просто не предстваляешь в какой геморой при деплойменте выльются такие выкрутасы. M>Например?
Ну ты эта... подеплой чтонибудь годик под хатя бы 3 разных линуха...
M>Ты, кстати, учитываешь, что деплоить можно как программу содержащую семантический узел log (на платформу, которая его динамически скомпилирует во что ей надо), так и уже скомпилированную в нечто (в printf, в getLogger(), в (void) и т.п.)?
Без разници.
Всеравно гемор жутчайший.
Программа будет везде неработать по разному.
M>Я вообще стараюсь не употреблять слова высшего уровня абстрактности, такие как "все", "никто", "всегда" и т.п. Так что маловероятно, чтоб я писал такое.
А толку если твои частные конкретные ситуации описывают глобальные вещи?
M>Да. Я так и написла с самого начала — это путь к отказу от стандартов (не полному отказу, конечно), что позволит сделать программирование более гибким.
Этот отказ позволит окончательно все сломать.
Отказ от стандартов может позволить себе мега контора "3 веселых столяра" строгающие не стандартные табуретки.
Индустрия без стандартов сдохнет на раз.
Ибо всем придется писать гигатонны кода самим.
Это кстати очень больная тема для С/С++... библиотеки имеют кучу разных интерфейсов и хрен совместишь одну с дргой.
M>Конечно, отказ от стандартов и большая гибкость это и предполагают — бОльшие проблемы при сведении разных семантических понятий в одном коде. M>Ты сейчас не имеешь этих проблем, потому как у тебя и выбора такого нету.
А что он мне даст то?
M>Тебе никто, никакой стандарт, если это целостный стандарт, не даст свести в одном языке конфликтные фичи, конфликтные семантические понятия.
И правильно сделает.
Индустрии не нужны конфликты компонент.
Индустрии нужна возможно повторно использовать компоненты.
M>А в SymADE ты это можешь сделать.
И словить тАкой гемор себе на ж... что просто жуть.
M>Но, хотя и не обязан этого делать, не пользуясь этой возможностью ты себя слишком ограничиваешь, будешь использовать его в четверть силы.
Представляю индуса с сумаде.
Ой билн
А сотня индусов с сумаде...
M>Тогда уж лучше оставаться на старых средствах программирования (то есть на сегодняшний день — современных). M>Как я уже писал выше, по моему мнению, задач, в которых можно будет использовать эти "современные" средства — со временем будет всё меньше.
Задач в которых можно использовать сумаде вобще не будет.
Ибо это генератор гемороя.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, mkizub, Вы писали:
FR>>Как раз продолжения это вполне фундаментальная вещь, а иерархии исключений и т. п. больше похожи на костыли и подпорки.
M>Фундаментальная вещь — это которую на кривой кобыли не объедешь. Закон сохранения энергии, например. M>А программировать без продолжений — вполне можно. Настолько можно, что все мэйнстрим языки без этой возможности совершенно не страдают.
Опять кривые аналогии, путаем физику и IT
Под фундаментальным тут имеется в виду, что продолжения это самый мощный и одновременно простой и достаточно безопасный способ работы с потоком управления, и через него можно выразить все другие (не локальные переходы, исключения, сопрограммы, генераторы и т. п.)
Здравствуйте, FR, Вы писали:
WH>>У продолжений есть очень серьезная проблема: Они не совместимы с детерминированным освобождением ресурсов. FR>Хочешь новый виток RAI vs GC
Детерминированная финализация это не обязательно RAII.
WH>>Короче в практически приминимых языках придется обойтись исключениями и корутинами. FR>Не обязательно.
Без детерминрованной финализации жизни нет.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
V>>Ты неправильно ставишь вопрос, т.к. это вообще спорная технология. Она используется не как самоцель, а как подпорка ввиду отсутствия другого, более детерминированного инструментария (типа иерархии ексепшенов в других языках).
FR>Как раз продолжения это вполне фундаментальная вещь, а иерархии исключений и т. п. больше похожи на костыли и подпорки.
goto тоже фундаментальная вещь, как и продолжения, которые можно использовать для чего угодно. Для обработки ошибок — это нецелевое использование. Я акцентировал именно на иерархии исключений по типу, которая распределяет по уровням вложенности обработку ошибок.
FR>Под фундаментальным тут имеется в виду, что продолжения это самый мощный и одновременно простой и достаточно безопасный способ работы с потоком управления, и через него можно выразить все другие (не локальные переходы, исключения, сопрограммы, генераторы и т. п.)
Вот именно, ибо продолжения — это всего лишь разновидность замыканий. При чём тут кокретно обработка ошибок? Таким точно макаром при желании можно и на современном C# писать (обрабатывать ошибки с помощью эмуляции продолжений), да что-то не особо заметно прецендентов. ИМХО, специализированный тул во первых нагляднее (продолжения нифига не наглядны в коде), во вторых практически не оставляет шанса для неправильного использования, в отличие от.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, FR, Вы писали:
FR>>Как раз продолжения это вполне фундаментальная вещь, а иерархии исключений и т. п. больше похожи на костыли и подпорки. WH>У продолжений есть очень серьезная проблема: Они не совместимы с детерминированным освобождением ресурсов.
Ну как бы при определённых танцах с бубнами и жесткими правилами их применения — добиться можно. Да вот только это будет всего лишь декларация на уровне name and code style convention, вот в чём проблема, компилятор тут самоустраняется. В то время как мощь исключений (помимо иерархии по типам) — именно в блоке finally или же в тех же С++ деструкторах, которые не требуют доп. плясок для гарантированного вызова.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, vdimas, Вы писали:
V>>Ты неправильно ставишь вопрос, т.к. это вообще спорная технология. Она используется не как самоцель, а как подпорка ввиду отсутствия другого, более детерминированного инструментария (типа иерархии ексепшенов в других языках). WH>Это мягко говоря не так. WH>Продолжения можно использовать и для построения логики.
Вот я и говорю, что продолжения — это нецелевое использование ср-в, т.е. в отсутствии специального инструмента приспособили имеющийся.
WH>Причем иногда с ними все получается проще.
Это если причина ошибки по-боку, то проще. Если ты имел ввиду проще вообще, т.е. общее построение логики, то это и так известно, я высказывался лишь в плане применения их к обработке ошибок.
WH>С другой стороны мы теряем возможность анализа программы ибо потоки исполнения становятся совершенно произвольными и могут очень сильно меняться со временем.
Более того, можем нарваться на потоконебезопасность совершенно не очевидным образом, в то время как достигнуть потокобезопасными объекты исключения — очень просто (напр. каждый объект исключения создавать заново, или распостранять по значению).
Здравствуйте, vdimas, Вы писали:
V>Ну как бы при определённых танцах с бубнами и жесткими правилами их применения — добиться можно.
Как бы с этим никто не спорит ибо исключения и корутины вполне реализуются через продолжения.
V>Да вот только это будет всего лишь декларация на уровне name and code style convention, вот в чём проблема, компилятор тут самоустраняется.
В этом то и проблема.
V>В то время как мощь исключений (помимо иерархии по типам) — именно в блоке finally или же в тех же С++ деструкторах, которые не требуют доп. плясок для гарантированного вызова.
Бяка и то и другое.
Убивают замыкания и оптимизацию хвостовой рекурсии на корню.
Есть варианты без этих проблем.
Я их сечас думаю.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>У тебя будут теже проблемы что и у лиспа (только в еще болие запущенной форме ибо в лиспе нет зоопарка бекендов)... прежде чем написать на лиспе программу нужно написать для нее язык.
Здравствуйте, lomeo, Вы писали:
WH>>У тебя будут теже проблемы что и у лиспа (только в еще болие запущенной форме ибо в лиспе нет зоопарка бекендов)... прежде чем написать на лиспе программу нужно написать для нее язык. L>Опа. Обычно это ставят в премимущества лиспу
Его адепты.
Тем не мение это одна из главных причин почему лиспу в индустрии ничего не светит.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
V>Вот именно, ибо продолжения — это всего лишь разновидность замыканий.
Угу "всего лишь" замыкания потока управления.
V>При чём тут кокретно обработка ошибок?
При том что позволяет реализовать в том числе и обработку ошибок, притом реализовать те же исключения один в один как встроенные исключения.
V>Таким точно макаром при желании можно и на современном C# писать (обрабатывать ошибки с помощью эмуляции продолжений),
Интересно бы посмотреть на такую эмуляцию, по моему это невозможно.
V>да что-то не особо заметно прецендентов. ИМХО, специализированный тул во первых нагляднее (продолжения нифига не наглядны в коде), во вторых практически не оставляет шанса для неправильного использования, в отличие от.
"В отличии от" просто позволяет самому сделать специализированый тул, и (на пример той же схемы) не мешает одновременно иметь и его.
Здравствуйте, FR, Вы писали:
FR>Интересно бы посмотреть на такую эмуляцию, по моему это невозможно.
Можно частично проэмулировать на итераторах (нужно дописать клонирование итераторов через рефлекшен/кодогенерацию). Как сделать на замыканиях — без понятия.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
FR>>Интересно бы посмотреть на такую эмуляцию, по моему это невозможно.
AVK>Можно частично проэмулировать на итераторах (нужно дописать клонирование итераторов через рефлекшен/кодогенерацию). Как сделать на замыканиях — без понятия.
Можно еще писать например в CPS стиле, но на шарпе это будет очень коряво, и вообще любая такая эмуляция будет напоминать ООП в турбо ассемблере
Здравствуйте, WolfHound, Вы писали:
WH>>>У тебя будут теже проблемы что и у лиспа (только в еще болие запущенной форме ибо в лиспе нет зоопарка бекендов)... прежде чем написать на лиспе программу нужно написать для нее язык. L>>Опа. Обычно это ставят в премимущества лиспу WH>Его адепты. WH>Тем не мение это одна из главных причин почему лиспу в индустрии ничего не светит.
Здравствуйте, lomeo, Вы писали:
L>Так вроде, наоборот, все кричат DSL! DSL!
Одно дело макра другая в клиничиских случаях.
Другое дело когда 100% кода это макры.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
L>>Так вроде, наоборот, все кричат DSL! DSL! WH>Одно дело макра другая в клиничиских случаях. WH>Другое дело когда 100% кода это макры.
Это заблуждение, посмотри штуки 5 крупных CL проектов, посмотри, сколько там процентов кода состоит из макров. По моим сугубо личным наблюдениям, сначала создаются DSL (это процентов 20-30% от всего проекта), а потом на базе них пишется собственно остальная часть проекта.
Мне например в CL очень редко приходится писать макры, почти все что нужно, уже есть. Опять же, только в клинических случаях.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, yumi, Вы писали:
Y>По моим сугубо личным наблюдениям, сначала создаются DSL (это процентов 20-30% от всего проекта), а потом на базе них пишется собственно остальная часть проекта.
Всеравно много.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Идеи в вобщем то правильные, но надо работать над их реализацией, а не на форуме лясы точить. И совершенно не ясно чем твой проект лучше чем IP, например.
V>>При чём тут кокретно обработка ошибок?
FR>При том что позволяет реализовать в том числе и обработку ошибок, притом реализовать те же исключения один в один как встроенные исключения.
И перехват на разных уровнях вложенности в зависимости от иерархии типов исключений? Т.е. в том ж мейнстриме я где хочу перехватываю более низкие по иерархии исключения (более подробные), на более высоком уровне — вышестоящие.
Здравствуйте, vdimas, Вы писали:
FR>>При том что позволяет реализовать в том числе и обработку ошибок, притом реализовать те же исключения один в один как встроенные исключения.
V>И перехват на разных уровнях вложенности в зависимости от иерархии типов исключений? Т.е. в том ж мейнстриме я где хочу перехватываю более низкие по иерархии исключения (более подробные), на более высоком уровне — вышестоящие.
Обычные исключения (как в Java), грубо говоря, выполняют 2 функции:
1) нелокальная передача управления
2) "паттерн-матчинг" на объекте исключения для выбора нужного обработчика.
Продолжения выполняют только первую функцию, потому они и являются более общим механизмом. Для реализации настоящих исключений все остальное — стек продолжений (обработчиков) и поиск в нем — нужно реализовать программисту.
FR>Можно еще писать например в CPS стиле, но на шарпе это будет очень коряво, и вообще любая такая эмуляция будет напоминать ООП в турбо ассемблере
А использование продолжений в Схеме убивает компиляцию участка кода в бинарный вид и всякую оптимизацию (рекурсий в т.ч.), в результате участок кода выполняется в лисповской интерпретируемой манере.
PM>Обычные исключения (как в Java), грубо говоря, выполняют 2 функции: PM>1) нелокальная передача управления PM>2) "паттерн-матчинг" на объекте исключения для выбора нужного обработчика.
PM>Продолжения выполняют только первую функцию, потому они и являются более общим механизмом. Для реализации настоящих исключений все остальное — стек продолжений (обработчиков) и поиск в нем — нужно реализовать программисту.
И как в схеме сделать _иерархию_ объектов-исключений? Без этой иерархии сам механизм исключений теряет львиную долю своей полезности, т.к. без этого сложно обобщать/уточнять реакцию на ошибки.
Здравствуйте, vdimas, Вы писали:
V>А использование продолжений в Схеме убивает компиляцию участка кода в бинарный вид и всякую оптимизацию (рекурсий в т.ч.), в результате участок кода выполняется в лисповской интерпретируемой манере.
Это особенность конкретной реализации и ничего больше.
Здравствуйте, vdimas, Вы писали:
V>И как в схеме сделать _иерархию_ объектов-исключений? Без этой иерархии сам механизм исключений теряет львиную долю своей полезности, т.к. без этого сложно обобщать/уточнять реакцию на ошибки.
Как угодно. Повторюсь, "иерархия исключений" мало относится к использованию продолжений для обработки ошибок, это ортогональная задача.
Можно обойтись предикатами вида
Можно использовать какую-либо реализацию паттерн-матчинга, которых предостаточно. Например, конструкция define-struct в PLT Scheme поддерживает подтипы, и паттерн-матчинг, идущий в комплекте (модуль "match.ss"), об этом знает.
Proof of concept:
;; собственно, иерархия исключений
(define-struct Error ())
(define-struct (IO-Error Error) ())
(define-struct (Logic-Error Error) ())
(define (println s)
(display s)
(newline))
(define (test)
(try-catch
;; внешний try-блок
(lambda ()
(begin
(println "Entering inner block")
(try-catch
;; внутренний try-блок
(lambda ()
(begin
(println "About to throw exception")
(throw (make-Logic-Error))
(println "Unreachable code")))
;; внутренние обработчики
(match-lambda
(($ IO-Error) (println "IO error handled"))
;; маленькое неудобство - неопознанные "исключения" нужно перебрасывать наверх,
;; но это можно спрятать в макросе (а заодно заменить слово match-lambda на что-то
;; более подходящее
(e (throw e))))))
;; внешний обработчик
(match-lambda
(($ Error)(println "Top-level handler caught exception")))))
PM> ;; маленькое неудобство — неопознанные "исключения" нужно перебрасывать наверх, PM> ;; но это можно спрятать в макросе (а заодно заменить слово match-lambda на что-то PM> ;; более подходящее
Дабы не быть голословным, пользовательский код может выглядеть так:
Здравствуйте, Andrei F., Вы писали:
AF>Идеи в вобщем то правильные, но надо работать над их реализацией, а не на форуме лясы точить.
А я работаю. Просто пока в текстовом редакторе, и сырцы собираются только целиком.
Компилится полторы минуты. В это время я и точу лясы
Где-то через пол-года уже доделаю, чтоб можно было работать в своей IDE, так веселее пойдёт.
AF>И совершенно не ясно чем твой проект лучше чем IP, например.
Так про IP почти ничего не известно. Из того, что я нашёл — вроде не лучше и не хуже,
просто подход несколько другой. Наверняка у них степень проработанности (завершённости
проекта) намного лучше. Но из того, что я сумел найти у них — вроде у меня степень
продуманности самой идеи много глубже. Кроме того, SymADE может выиграть за счёт open-source.
Короче, когда IP выйдет, там и посмотрим.
Здравствуйте, mkizub, Вы писали:
M>Так про IP почти ничего не известно. Из того, что я нашёл — вроде не лучше и не хуже, M>просто подход несколько другой. Наверняка у них степень проработанности (завершённости M>проекта) намного лучше. Но из того, что я сумел найти у них — вроде у меня степень M>продуманности самой идеи много глубже. Кроме того, SymADE может выиграть за счёт open-source. M>Короче, когда IP выйдет, там и посмотрим.
Читал книгу — Чарнецки и другие, "Порождающее программирование"? Там кое-что есть.
А выигрыш за счет open source — я бы на это не рассчитывал, намного больше шансов на обратный эффект. За счет эффекта рака, лебедя и щуки.
V>>А использование продолжений в Схеме убивает компиляцию участка кода в бинарный вид и всякую оптимизацию (рекурсий в т.ч.), в результате участок кода выполняется в лисповской интерпретируемой манере.
FR>Это особенность конкретной реализации и ничего больше.
Это принципиальное ограничение. Сами продолжения изначально появились из-за возможности "вручную"/пошагово выполнять ф-ии в Лиспе, путём банального apply.
Здравствуйте, Andrei F., Вы писали:
AF>Здравствуйте, mkizub, Вы писали:
M>>Так про IP почти ничего не известно. Из того, что я нашёл — вроде не лучше и не хуже, M>>просто подход несколько другой. Наверняка у них степень проработанности (завершённости M>>проекта) намного лучше. Но из того, что я сумел найти у них — вроде у меня степень M>>продуманности самой идеи много глубже. Кроме того, SymADE может выиграть за счёт open-source. M>>Короче, когда IP выйдет, там и посмотрим.
AF>Читал книгу — Чарнецки и другие, "Порождающее программирование"? Там кое-что есть.
Не читал. В электронном виде вроде нету, попробую купить на рынке...
AF>А выигрыш за счет open source — я бы на это не рассчитывал, намного больше шансов на обратный эффект. За счет эффекта рака, лебедя и щуки.
Дело не в этом. Дело в том, что закрытый продукт труднее сделать расширяемым.
А главное преимущество этой технологии — в расширяемости, в настраиваемости инструмента (среды
разработки и исполнения) под конкретный проект или технологию.
Делая изменения (в языке, в среде) под конкретный проект — ты учитываешь только требования
своего проекта. А делая изменения в стандарте (даже если это некий плагин к компилятору) —
ты должен учитывать все остальные фичи языка программирования или инструмента программирования.
А это в 9 случаев из 10 приводит к конфликту фич.
Закрытые платформы мета-программирования неизбежно проиграют в качестве.
Другое дело, если это некий открытый код поддерживаемый известной фирмой или группой фирм.
Вроде Eclipse, GCC и т.п.
Здравствуйте, vdimas, Вы писали:
V>Это принципиальное ограничение. Сами продолжения изначально появились из-за возможности "вручную"/пошагово выполнять ф-ии в Лиспе, путём банального apply.
Я не совсем понимаю, о чем вы говорите, но на всякий случай, официальная история рождения понятия "continuation": The Discoveries of Continuations, John Reynolds.
In the early history of continuations, basic concepts were independently
discovered an extraordinary number of times. This was due less to poor
communication among computer scientists than to the rich variety of set-
tings in which continuations were found useful: They underlie a method
of program transformation (into continuation-passing style), a style of def-
initional interpreter (defining one language by an interpreter written in
another language), and a style of denotational semantics (in the sense of
Scott and Strachey). In each of these settings, by representing “the mean-
ing of the rest of the program” as a function or procedure, continuations
provide an elegant description of a variety of language constructs, including
call by value and goto statements.
Continuations появились в первую очередь как теоретический инструмент. С его помощью удалось формально описать семантику языков программирования с goto, обработкой ошибок, недетерминизмом и т.п. С монадами, кстати, та же история — изначально они были просто теоретическим построением для описания семантики языков. На мой взгляд, наличие продолжений в Схеме, SML и монад в Хаскеле объясняется просто: целевая аудитория этих языков ценит возможность создания DSL и, так сложилось исторически, ориентируется в теории ЯП, а монады или continuations позволяют описать семантику любых мыслимых управляющих операторов. В промышленных языках, наверно, им не место из-за чрезмерной мощности/сложности понимания.
В вопросе эффективной реализации continuations я почти ничего не понимаю, но все же замечу, что невозможность поддержки continuations в компилируемых языках — заблуждение. Есть несколько компиляторов Схемы; один из них, Chez Scheme, использует сегментированный стек для эффективной поддержки как продолжений, так и обычных функций; два оптимизирующих компилятора SML — SML/NJ и MLton — поддерживают callcc.
Здравствуйте, palm mute, Вы писали:
V>>Это принципиальное ограничение. Сами продолжения изначально появились из-за возможности "вручную"/пошагово выполнять ф-ии в Лиспе, путём банального apply.
PM>Я не совсем понимаю, о чем вы говорите,
Курить классический apply в Lisp, что такое контекст/окружение (environment), call by name, call by value. (В Схеме всё тоже самое)
PM>но на всякий случай, официальная история рождения понятия "continuation":
Просто когда пишешь интерпретатор Лиспа, то замечаешь, что работающая программа (целиком) в каждый момент времени представляет из себя экземпляр continuation, любое состояние интерпретатора (представляющее из себя простой указатель на позицию в списке), можно запомнить и многократно "продолжать" затем код с запомненной позиции. В условиях глобального статического контекста в большинстве реализаций Лиспов это более чем просто делалось, ибо контекст исполнения — это такой же список, и текущий контекст "сфотографировать" было более чем просто, опять же простым запоминанием текущей головы контекста на момент lambda-захвата. (Контекст растёт со стороны головы)
PM>Continuations появились в первую очередь как теоретический инструмент.
Конечно-конечно
Впервые они появились во второй реализации Лиспа, и остались без названия. "Теоретики" заметили, обмусолили и дали термин несколько позже, одновременно с разработкой Схемы. Собсно, Схема — это и есть строго формально причёсанный Лисп по-сути. Понимаешь, в бинарном виде создать снапшот программы в некоторой точке — это практически снимок стека создать, вместе со всей вложенностью (в оптимизированном варианте параметры ф-ий идут через стек, а не как указатель на список), а такое на каждом шаге не сделаешь — весьма накладно будет, что сделает саму идею бесполезной с практической т.з.
PM>С его помощью удалось формально описать семантику языков программирования с goto, обработкой ошибок, недетерминизмом и т.п. С монадами, кстати, та же история — изначально они были просто теоретическим построением для описания семантики языков. На мой взгляд, наличие продолжений в Схеме, SML и монад в Хаскеле объясняется просто: целевая аудитория этих языков ценит возможность создания DSL и, так сложилось исторически, ориентируется в теории ЯП, а монады или continuations позволяют описать семантику любых мыслимых управляющих операторов. В промышленных языках, наверно, им не место из-за чрезмерной мощности/сложности понимания.
Чуть не подавился (насчёт сложности).
In computing, a continuation represents the rest of the computation given a point in the computation. Another word for "rest of the computation" is control state, meaning the data structures and code needed to complete a computation.
Укажи на сложность, плиз.
PM>В вопросе эффективной реализации continuations я почти ничего не понимаю, но все же замечу, что невозможность поддержки continuations в компилируемых языках — заблуждение. Есть несколько компиляторов Схемы; один из них, Chez Scheme, использует сегментированный стек для эффективной поддержки как продолжений, так и обычных функций; два оптимизирующих компилятора SML — SML/NJ и MLton — поддерживают callcc.
Я же не сказал, что невозможно, я сказал, что этот участок кода должен выполнятся стандартной Лисп-машиной, вместо компиляции в бинарный код (вернее, участки кода от call/cc к call/cc могут быть бинарными в итоге, но сам их поочерёдный вызов как ни крути — в интерпретируемой манере). Все-равно в бинарник сама лисп-машина тоже зашивается, благо она миниатюрная, да и обязательные eval и apply как раз через нее работают (или она через них )
Здравствуйте, vdimas, Вы писали:
V>>>Это принципиальное ограничение. Сами продолжения изначально появились из-за возможности "вручную"/пошагово выполнять ф-ии в Лиспе, путём банального apply. PM>>Я не совсем понимаю, о чем вы говорите, V>Курить классический apply в Lisp, что такое контекст/окружение (environment), call by name, call by value. (В Схеме всё тоже самое)
Спасибо, я это все уже курил. У меня хобби такое — курить академические статьи по теории языков программирования. Я просто не понимаю, каким образом "путем банального apply" возникают продолжения.
PM>>но на всякий случай, официальная история рождения понятия "continuation": V>Просто когда пишешь интерпретатор Лиспа, то замечаешь, что работающая программа (целиком) в каждый момент времени представляет из себя экземпляр continuation...
Еще проще было бы просто написать интерпретатор в CPS.
PM>>Continuations появились в первую очередь как теоретический инструмент. V>Конечно-конечно V>Впервые они появились во второй реализации Лиспа, и остались без названия. "Теоретики" заметили, обмусолили и дали термин несколько позже, одновременно с разработкой Схемы.
Ссылкой не подкрепите свое утверждение? Я с классическим Лиспом практически не знаком, беглый просмотр истории Лиспа, а также описаний Лиспов 1.5 и 2 ничего похожего не подтверждает, хотя я мог что-то пропустить.
Обидно, что вы не потрудились открыть ссылку из предыдущего сообщения, там масса интересных фактов. Например, автором преобразования, очень похожего на CPS, является A. Wijngaarden; об этом преобразовании он докладывал в 1964 году, причем на докладе присутствовал Джон Маккарти, автор Лиспа. Также на докладе присутствовали Ландин, Дейкстра, Хоар и прочие видные деятели, которых вы, как мне показалось, несколько пренебрежительно назвали "теоретиками". Из той же статьи можно узнать, что Ландин в том же 1964 г. опубликовал "Mechanical Evaluation of Expressions" с описанием SECD-машины, состояние которой содержало параметр D — фактически, явное представление continuation, хотя тогда этого термина еще не было. Предшественник оператора call/cc — J operator, — был введен тем же Ландином в 1965 г. (A Generalization of Jumps and Labels. Интересный факт, не имеющий прямого отношения к дискуссии — именно упомянутый доклад спровоцировал Дейкстру на его знаменитый манифест "Goto considered harmful".
Все перечисленные граждане в тот период занимались вовсе не Схемой (которая появится только в 1975 г), они работали над Алголом. А собственно термин "continuation" придумал Wadsworth в 1970 г., и опять же, занимался он вовсе не Схемой, а денотационной семантикой. И последнее, сам Маккарти, а также практически все участники событий эту статью читали и комментировали, и серьезных возражений вроде не было. Возражения есть только у вас.
V> Собсно, Схема — это и есть строго формально причёсанный Лисп по-сути.
Спасибо, буду знать.
V> Понимаешь, в бинарном виде создать снапшот программы в некоторой точке — это практически снимок стека создать, вместе со всей вложенностью (в оптимизированном варианте параметры ф-ий идут через стек, а не как указатель на список), а такое на каждом шаге не сделаешь — весьма накладно будет, что сделает саму идею бесполезной с практической т.з.
Понимаешь, я нигде не утверждал, что first class continuations — очень дешевая конструкция, и их очень просто реализовать эффективно. Тем не менее, в компилируемых Схемах и в SML так и делают — либо копируют стек, либо представляют стек в виде связанного списка фреймов в куче, либо усложняют сам стек. Более интересные с практической точки зрения delimited continuations (см. shift/reset, control/prompt и др.) несколько упрощают ситуацию, т.к. для их эффективной реализации нужно скопировать только фрагмент стека до ближайшего control delimiter'а. Но не будем уклоняться от темы — где здесь интерпретация, и что это за "интерпретируемая манера", о которой вы все время говорите?
V>Чуть не подавился (насчёт сложности). V>
V>In computing, a continuation represents the rest of the computation given a point in the computation. Another word for "rest of the computation" is control state, meaning the data structures and code needed to complete a computation.
V>Укажи на сложность, плиз.
Не стоит давиться. Дело в том, что, например, у оператора goto еще более простое определение, но при его недисциплинированном применении программы становятся несколько запутанными, согласно доминирующему сегодня мнению. Я встречал матерых джавистов, утверждавших, что применение оператора yield в C# очень затрудняет чтение программ . У тех же монад тоже очень простое определение — конструктор типов m, для которого определены 2 операции, return и bind, удовлетворяющие трем простым законам. Это не мешает народу шарахаться от Haskell и не останавливает поток многостраничных туториалов. Всем известно, что желательно минимизировать применение побочных эффектов, т.к. они усложняют понимание программ. Так вот continuations — это квинтэссенция побочных эффектов, все остальные разновидности побочных эффектов можно эмулировать черех них. В конце концов, достаточно взглянуть на неполный список литературы, посвященной вопросу, чтобы понять, что тема не такая уж простая.
PM>>В вопросе эффективной реализации continuations я почти ничего не понимаю, но все же замечу, что невозможность поддержки continuations в компилируемых языках — заблуждение. Есть несколько компиляторов Схемы; один из них, Chez Scheme, использует сегментированный стек для эффективной поддержки как продолжений, так и обычных функций; два оптимизирующих компилятора SML — SML/NJ и MLton — поддерживают callcc.
V>Я же не сказал, что невозможно, я сказал, что этот участок кода должен выполнятся стандартной Лисп-машиной, вместо компиляции в бинарный код (вернее, участки кода от call/cc к call/cc могут быть бинарными в итоге, но сам их поочерёдный вызов как ни крути — в интерпретируемой манере). Все-равно в бинарник сама лисп-машина тоже зашивается, благо она миниатюрная, да и обязательные eval и apply как раз через нее работают (или она через них )
Было бы очень здорово, если бы вы показали, в каком конкретно месте в бинарники, генерируемые MLton, зашивается лисп-машина. Еще интереснее, куда она зашивается в при компиляции Окамла в байт-код. Дело в том, что официально Окамл не поддерживает продолжения, но Олег Киселев в своей библиотеке Delimcc их реализовал копированием фрагментов стека (реализация на C, заточена под знание структуры стековых фреймов в Окамле, да, хак, не слишком эффективно, но работает). Это "интерпретируемая манера" или нет? И как определяются границы "участка кода", который невозможно скомпилировать? И вы уверены, что для поддержки first-class continuations совершенно необходимо явное представление окружений в виде списков и примитив "apply"?
Здравствуйте, vdimas, Вы писали:
V>Я же не сказал, что невозможно, я сказал, что этот участок кода должен выполнятся стандартной Лисп-машиной, вместо компиляции в бинарный код
Посмотри как в шарпе реализованы итераторы. А это, фактически, 2/3 пути к продолжениям — клонирование итераторов, в отличие от клонирования стека — тривиальная операция.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1090 on Windows Vista 6.0.6001.65536>>
Здравствуйте, vdimas, Вы писали:
V>Просто когда пишешь интерпретатор Лиспа, то замечаешь, что работающая программа (целиком) в каждый момент времени представляет из себя экземпляр continuation, любое состояние интерпретатора (представляющее из себя простой указатель на позицию в списке), можно запомнить и многократно "продолжать" затем код с запомненной позиции. В условиях глобального статического контекста в большинстве реализаций Лиспов это более чем просто делалось, ибо контекст исполнения — это такой же список, и текущий контекст "сфотографировать" было более чем просто, опять же простым запоминанием текущей головы контекста на момент lambda-захвата. (Контекст растёт со стороны головы)
На данном этапе имеется программа, преобразованная в CPS, к которой применены правила преобразования в замыкания. То есть существует набор замыканий, переход между которыми может осуществляться простым прыжком на тело очередного замыкания. Такая форма программы называется closure-passing style. При вызове следующего замыкания, мы должны передать ему параметры и совершить переход на его тело.
Такое представление без проблем компилируется, и не требует никаких интерпретаторов во время работы скомпилированного кода. По этой схеме работает Gambit-C http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Main_Page вот небольшая цитата из описания:
Thanks to an efficient implementation of continuations, the thread system is very efficient and can support millions of concurrent threads
Почитал... Общее впечатление — м-да, чудес не бывает.
Код, конечно, скомпилирован, но стек мы держим в хипе.
Стек immutable, поэтому копировать там нечего, и продолжения могут быть реализованы эффективно.
Каждая операция скомпилирована в отдельную функцию. Между ними мы ходим по jump, а не по
call, поскольку фреймы для функций в аппаратном стеке нам создавать (аппаратно) не надо — мы их ручками создаём.
С чего начали, тем и закончили. На хардварном стеке лежит большой болт. Спасибо навороченной железке
под названием пеньтюх, с навороченным предсказателем исполнения кода, который делает наши jump-ы почти
бесплатными. Впрочем, на фоне отказа от аппаратного стека и отказа от локальных оптимизаций с использованием
регистров (какие регистры, мля, мы каждый add выполняем через jump), это "почти" даже не видно.
PS Особенно порадовало
Thanks to an efficient implementation of continuations, the thread system is very efficient and can support millions of concurrent threads.
в сочетании с
Gambit supports the execution of multiple Scheme threads. These threads are managed entirely by Gambit's runtime and are not related to the host operating system's threads. Gambit's runtime does not currently take advantage of multiprocessors (i.e. at most one thread is running).
Интересно, чё это они так? Синхронизация будет стоить дороже, чем выигрыш от многопроцессорности?
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, FR, Вы писали:
M>Почитал... Общее впечатление — м-да, чудес не бывает. M>Код, конечно, скомпилирован, но стек мы держим в хипе. M>Стек immutable, поэтому копировать там нечего, и продолжения могут быть реализованы эффективно. M>Каждая операция скомпилирована в отдельную функцию. Между ними мы ходим по jump, а не по M>call, поскольку фреймы для функций в аппаратном стеке нам создавать (аппаратно) не надо — мы их ручками создаём. M>С чего начали, тем и закончили. На хардварном стеке лежит большой болт. Спасибо навороченной железке M>под названием пеньтюх, с навороченным предсказателем исполнения кода, который делает наши jump-ы почти M>бесплатными. Впрочем, на фоне отказа от аппаратного стека и отказа от локальных оптимизаций с использованием M>регистров (какие регистры, мля, мы каждый add выполняем через jump), это "почти" даже не видно.
Для полностью динамического языка по моему очень даже неплохо.
И еще не думаю что отказ от аппаратного стека так уж и сильно просадит производительность. Тем более есть эксперементальные реализации типа stalin scheme которые делают код близкий по производительности к си.
Использование регистров и не делание мы каждый add выполняем через jump зависит только от ресурсов вложенных в разработку компилятора, ничего принципиално ограничивающего оптимизации нет.
M>Интересно, чё это они так? Синхронизация будет стоить дороже, чем выигрыш от многопроцессорности?
Ну ты сделал открытие, на современных даже SMP процессорах, в случае когда нужно много (и очень много) потоков легкие потоки гораздо эффективнее аппаратных, на которых основное время уходит на сохранение контекста. Так что никакого отношения к особенностям Схемы это не имеет.
AVK>Посмотри как в шарпе реализованы итераторы. А это, фактически, 2/3 пути к продолжениям — клонирование итераторов, в отличие от клонирования стека — тривиальная операция.
Тогда уж ты посмотри, как работает классическая Лисп-машина (ибо как работают итераторы я смотрел многократно). Намёк на то, что обобщённый итератор как раз впервые в Лиспе и встречается, не зря там были впервые реализованы продолжения.
Это примерно то же, о чём я говорил, что куски кода м/у call/cc могут быть бинарными (скомпиллированные замыкания), но ходить м/у ними надо путём простого итерирования, как это делает безстековая Лисп-машина (на которой те самые продолжения реализуются естественным образом), что убивает всякую локальную оптимизацию. Прогресс я вижу только в том, что вместо итератора зашит непосредственный jump, но это экономия буквально одной-двух машинных инструкций на переход, и никаких изменений по-сути.
Здравствуйте, vdimas, Вы писали:
V>Это примерно то же, о чём я говорил, что куски кода м/у call/cc могут быть бинарными (скомпиллированные замыкания), но ходить м/у ними надо путём простого итерирования, как это делает безстековая Лисп-машина (на которой те самые продолжения реализуются естественным образом), что убивает всякую локальную оптимизацию. Прогресс я вижу только в том, что вместо итератора зашит непосредственный jump, но это экономия буквально одной-двух машинных инструкций на переход, и никаких изменений по-сути.
По сути получается, практически нормальная компиляция только без аппаратного стека. Если бы язык был не динамический, то и оптимизации были бы более доступны. Позже посмотрю как все это дело в mlton реализованно там наверняка доступно больше оптимизаций
Здравствуйте, palm mute, Вы писали:
PM>Я просто не понимаю, каким образом "путем банального apply" возникают продолжения.
Потому как код программы по-сути итерируется через apply, и оказалось возможным скопировать/запомнить состояние итератора. И зря ты не обратил внимание на особенность контекста в Лисп. Понимаешь, если программа оперирует глобальными переменными (составляющими часть контекста всей программы), то повторный вызов продолжений может оперировать в непредсказуемом окружении, в отличие от "правильных" реализаций Лиспа и Схемы (далеко не все правильные, кстати), в которых замыкание фиксирует именно текущий контекст программы, а не ссылку на будущие непредсказуемые данные.
PM>>>Continuations появились в первую очередь как теоретический инструмент. V>>Конечно-конечно V>>Впервые они появились во второй реализации Лиспа, и остались без названия. "Теоретики" заметили, обмусолили и дали термин несколько позже, одновременно с разработкой Схемы. PM>Ссылкой не подкрепите свое утверждение? Я с классическим Лиспом практически не знаком, беглый просмотр истории Лиспа, а также описаний Лиспов 1.5 и 2 ничего похожего не подтверждает, хотя я мог что-то пропустить.
Реализация для IBM 704.
PM>Обидно, что вы не потрудились открыть ссылку из предыдущего сообщения, там масса интересных фактов. Например, автором преобразования, очень похожего на CPS, является A. Wijngaarden; об этом преобразовании он докладывал в 1964 году, причем на докладе присутствовал Джон Маккарти, автор Лиспа. Также на докладе присутствовали Ландин, Дейкстра, Хоар и прочие видные деятели, которых вы, как мне показалось, несколько пренебрежительно назвали "теоретиками". Из той же статьи можно узнать, что Ландин в том же 1964 г. опубликовал "Mechanical Evaluation of Expressions" с описанием SECD-машины, состояние которой содержало параметр D — фактически, явное представление continuation, хотя тогда этого термина еще не было. Предшественник оператора call/cc — J operator, — был введен тем же Ландином в 1965 г. (A Generalization of Jumps and Labels. Интересный факт, не имеющий прямого отношения к дискуссии — именно упомянутый доклад спровоцировал Дейкстру на его знаменитый манифест "Goto considered harmful". PM>Все перечисленные граждане в тот период занимались вовсе не Схемой (которая появится только в 1975 г), они работали над Алголом. А собственно термин "continuation" придумал Wadsworth в 1970 г., и опять же, занимался он вовсе не Схемой, а денотационной семантикой. И последнее, сам Маккарти, а также практически все участники событий эту статью читали и комментировали, и серьезных возражений вроде не было. Возражения есть только у вас.
И где у меня возражения?
Я лишь говорю о том, что на продолжения впервые наткнулись практически (IBM 704 — это середина 50-х), и лишь спустя десяток или больше лет они были описаны теоретически и им было дано текущее название. Впрочем, это характерно для большинства аспектов нашей IT-области.
V>>Чуть не подавился (насчёт сложности). V>>
V>>In computing, a continuation represents the rest of the computation given a point in the computation. Another word for "rest of the computation" is control state, meaning the data structures and code needed to complete a computation.
V>>Укажи на сложность, плиз.
PM>Не стоит давиться. Дело в том, что, например, у оператора goto еще более простое определение, но при его недисциплинированном применении программы становятся несколько запутанными, согласно доминирующему сегодня мнению.
Не надо наседать на несчастный goto. Проблема goto в ранних языках была от возможности нелокального перехода, т.е. когда можно было передать управление на участок программы, который должен выполнятся на некоей другой вложенности стека. Именно эту ситуацию и промоделировали на продолжениях. В локальном же goto ничего зазорного нет, и он прекрасно описывается автоматной моделью (собсно, программа на каждом определённом уровне стека представляет из себя конечный автомат, и goto — суть переход к некоторому состоянию) Так же, современный мейнстрим использует языки-наследники структурных, в которых этот goto ограничен для применения только локально, и для пущего удобства "завёрнут" в структурные операторы: операторы цикла, вложенности условных, всякие break и continue.
PM>Я встречал матерых джавистов, утверждавших, что применение оператора yield в C# очень затрудняет чтение программ . У тех же монад тоже очень простое определение — конструктор типов m, для которого определены 2 операции, return и bind, удовлетворяющие трем простым законам. Это не мешает народу шарахаться от Haskell и не останавливает поток многостраничных туториалов. Всем известно, что желательно минимизировать применение побочных эффектов, т.к. они усложняют понимание программ. Так вот continuations — это квинтэссенция побочных эффектов, все остальные разновидности побочных эффектов можно эмулировать черех них.
Ну вот есть такой побочный эффект в функциональных программах, как изменение глобального состояние программы (языки с такими возможностями не считаются чисто-функциональными), и каким боком тут продолжения для эмуляции подобных побочных эффектов?
PM>В конце концов, достаточно взглянуть на неполный список литературы, посвященной вопросу, чтобы понять, что тема не такая уж простая.
И что с того? Замыканиям посвящено на пару порядков больше литературы, а суть их с т.з. программиста еще более простая. Что это доказывает и о чём спор?
PM>Было бы очень здорово, если бы вы показали, в каком конкретно месте в бинарники, генерируемые MLton, зашивается лисп-машина.
В обязательные ф-ии apply и eval, однако. В тех местах, где вывод типов на момент компиляции не возможен, работают они, родимые. Если язык компиллируемый, это еще не значит, что он потерял свою динамическую сущность.
PM>Еще интереснее, куда она зашивается в при компиляции Окамла в байт-код.
В данном споре — неинтересно.
PM>Дело в том, что официально Окамл не поддерживает продолжения, но Олег Киселев в своей библиотеке Delimcc их реализовал копированием фрагментов стека (реализация на C, заточена под знание структуры стековых фреймов в Окамле, да, хак, не слишком эффективно, но работает).
Такой хак и для языков С/С++ сделать можно, опять же, к чему это здесь? Есть еще технология фиберов — близкая по смыслу вещь.
PM>Это "интерпретируемая манера" или нет? И как определяются границы "участка кода", который невозможно скомпилировать? И вы уверены, что для поддержки first-class continuations совершенно необходимо явное представление окружений в виде списков и примитив "apply"?
Не обязательно в виде списков, но для правильной реализации замыканий в Лиспе надо оперировать значениями из контекста (и для всех вложенных вызовов внутри замыкания тоже), а не сылками на оные. Просто в виде растущего с головы списка это проще всего реализуется. Я, например, реализовывал в виде списка хеш-таблиц, не суть, семантика должна оставаться согласно описанному, и там не все так просто. Например, работающее замыкание порождает свой контекст, который никаким образом не трогает глобальный, но стыкуется с ним в точке создания замыкания. Для правильной реализации продолжений (а не поделки с одноимённым названием), необходимы именно такие качества реализованных замыканий, иначе действительно, кол-во побочных эффектов будет просто зашкаливать, и устремлять полезность от call/cc к 0-лю. Там где продолжения ограничиваются только копированием стека — это вообще жалкие поделки. Почитай внимательнее всю свою литературу о продолжениях еще раз, и обрати внимание теперь на такую штуку как контекст.
PM>P.S. Извините за резкость, не мог сдержаться.
Та ради бога, я просто как бы реализовывал мини-интерпретатор Схемы для внутренних нужд в своё время (по 4-му стандарту, за исключением внутренней реализации целых чисел через неограниченный big-int за ненадобностью), просмотрел и подробно разобрал _десятки_ исходников схем и лиспов (более половины из них не соответствуют заявленным реализациям стандартов, в плане замыканий — в первую очередь), так что мне даже интересно сравнить свою практику с чьим-то теоретическим опытом.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, vdimas, Вы писали:
V>>Это примерно то же, о чём я говорил, что куски кода м/у call/cc могут быть бинарными (скомпиллированные замыкания), но ходить м/у ними надо путём простого итерирования, как это делает безстековая Лисп-машина (на которой те самые продолжения реализуются естественным образом), что убивает всякую локальную оптимизацию. Прогресс я вижу только в том, что вместо итератора зашит непосредственный jump, но это экономия буквально одной-двух машинных инструкций на переход, и никаких изменений по-сути.
FR>По сути получается, практически нормальная компиляция только без аппаратного стека. Если бы язык был не динамический, то и оптимизации были бы более доступны.
Дык, я вообще не до конца склонен считать Лисп и Схему (а так же Forth) интерпретаторами, ибо там код переводится во внутреннее представление, а затем исполняется. Если это внутреннее представление предсохранить, и удалить из программы возможность интерпретированного исполнения каких либо новых кусков кода, то сохраним работоспособность всей программы (если её логика не заключается в обработке новых кусков поступающего кода, например), но интерпретатором это уже не будет, такой казус. Далее, без использования аппаратного стека исполнение программы "внешнее", т.к. это внешнее исполнение должно обслуживать аналог стека, ну и тут правильно заметили, что банальная ф-ия "+" вызывается как подпрограмма. Так же рядом я уже указывал, что там, где вывод типов в момент компиляции невозможен, способ исполнения кода мало отличается от интерпретируемого варианта.
FR>Позже посмотрю как все это дело в mlton реализованно там наверняка доступно больше оптимизаций
В местах, где вывод типов не возможен, макимум можно хвостовую рекурсию раскрутить.
PM>>Было бы очень здорово, если бы вы показали, в каком конкретно месте в бинарники, генерируемые MLton, зашивается лисп-машина.
V>В обязательные ф-ии apply и eval, однако. В тех местах, где вывод типов на момент компиляции не возможен, работают они, родимые. Если язык компиллируемый, это еще не значит, что он потерял свою динамическую сущность.
С какого перепугу в жестко статически типизированном Standard ML будут eval и apple?
Здравствуйте, vdimas, Вы писали:
V>Дык, я вообще не до конца склонен считать Лисп и Схему (а так же Forth) интерпретаторами, ибо там код переводится во внутреннее представление, а затем исполняется. Если это внутреннее представление предсохранить, и удалить из программы возможность интерпретированного исполнения каких либо новых кусков кода, то сохраним работоспособность всей программы (если её логика не заключается в обработке новых кусков поступающего кода, например), но интерпретатором это уже не будет, такой казус. Далее, без использования аппаратного стека исполнение программы "внешнее", т.к. это внешнее исполнение должно обслуживать аналог стека, ну и тут правильно заметили, что банальная ф-ия "+" вызывается как подпрограмма. Так же рядом я уже указывал, что там, где вывод типов в момент компиляции невозможен, способ исполнения кода мало отличается от интерпретируемого варианта.
Угу, недостаточная оптимизация связанно именно с тем что схема динамический язык, продолжения тут практически мало что меняют. Хотя та же Stalin Scheme показывает что можно оптимизировать существенно лучше, близко к статически типизированным языкам.
FR>>Позже посмотрю как все это дело в mlton реализованно там наверняка доступно больше оптимизаций
V>В местах, где вывод типов не возможен, макимум можно хвостовую рекурсию раскрутить.
Так в Standard ML реализацией которого является mlton если вывод типов невозможен будет ошибка компиляции
Здравствуйте, vdimas, Вы писали:
V>Ну вот есть такой побочный эффект в функциональных программах, как изменение глобального состояние программы (языки с такими возможностями не считаются чисто-функциональными), и каким боком тут продолжения для эмуляции подобных побочных эффектов?
Языки, допускающие любые побочные эффекты, по определению не являются чисто функциональными, деструктивные присваивания не имеют исключительного статуса в этом отношении.
Эмулировать изменяемое состояние с помощью continuations (а именно, multi-prompt delimited continuations) очень просто. В том смысле, что мы можем создать некий объект v, поддерживающий операции (read-var v) и (write-var v 42) с ожидаемым поведением, не пользуясь примитивом set!.
Для примера возьмем функцию суммирования интервала чисел:
(define (sum-up-to n)
(let ((i 0)
(sum 0))
(define (loop)
(when (not (>; i n))
(begin
(set! sum (+ sum i))
(set! i (+ i 1))
(loop))))
(begin
(loop)
sum)))
С использованием наших примитивов эта функция будет выглядеть так:
(require (lib "control.ss"))
(define (read-var v)
(shift-at v k (lambda (val) ((k val) val))))
(define (write-var v new-val)
(shift-at v k (lambda (val) ((k `()) new-val))))
(define (with-mutable-var init-val func)
(let ((v (new-prompt)))
((reset-at v (let ((result (func v)))
(lambda (val) result)))
init-val)))
К сожалению, у меня сейчас нет времени на подробное объяснение, что здесь происходит; скажу только, что это вариация на тему реализации монады State в терминах shift/reset, о которой я уже писал
Здравствуйте, palm mute, Вы писали:
PM>К сожалению, у меня сейчас нет времени на подробное объяснение, что здесь происходит; скажу только, что это вариация на тему реализации монады State в терминах shift/reset, о которой я уже писал
В той статье ты упорно называешь контекстом вычисления только захваченный стек, в то время как контекст или окружение (environment) в Лиспе и Схеме — это видимые из замыкания "глобальные" (они же локальные для замыкания) переменные. Т.е. я про то, что реализация продолжений на самом деле сильно зависит от реализации замыканий. По-сути, основной водораздел совместимости разных реализаций Схемы проходит по их способу реализации замыканий.
