Здравствуйте, 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>да что-то не особо заметно прецендентов. ИМХО, специализированный тул во первых нагляднее (продолжения нифига не наглядны в коде), во вторых практически не оставляет шанса для неправильного использования, в отличие от.
"В отличии от" просто позволяет самому сделать специализированый тул, и (на пример той же схемы) не мешает одновременно иметь и его.
