Здравствуйте, WolfHound, Вы писали: WH>Ну давай раскажи как заставить try/finally bли любой другой способ детерминированной финализации работать в присутствии продолжений.
В языках, как ты говоришь, с "позорными" системами типов — так же, как и в присутствии yield в C# или в присутствии нескольких потоков. Если программист хочет бесконтрольно шарить ресурс между корутинами/потоками — программист должен сам определить, где надо освобождать ресурс.
WH>Простейшие uniqueness решают данную проблему на корню.
Что мешает uniqueness-типам решать ту же проблему на корню в коде с континуациями? Ты же сам сказал, что твой исходный бажный пример с call/cc uniqueness-типы не пропустят. Вот и замечательно — этого нам и было надо.
Здравствуйте, Mr.Cat, Вы писали:
WH>>Ну давай раскажи как заставить try/finally bли любой другой способ детерминированной финализации работать в присутствии продолжений.
Ответ на вопрос будет?
MC>В языках, как ты говоришь, с "позорными" системами типов — так же, как и в присутствии yield в C# или в присутствии нескольких потоков. Если программист хочет бесконтрольно шарить ресурс между корутинами/потоками — программист должен сам определить, где надо освобождать ресурс.
А давай ты расскажешь при решении какой задачи нужно бесконтрольно шарить ресурс?
MC>Что мешает uniqueness-типам решать ту же проблему на корню в коде с континуациями? Ты же сам сказал, что твой исходный бажный пример с call/cc uniqueness-типы не пропустят. Вот и замечательно — этого нам и было надо.
Так они и решают. Примерно как гильотина лечит головную боль.
При появлении хоть одного uniqueness типа программа с продолжениями компилироваться перестанет ибо у нее не будет шансов пройти проверку типов.
А если учесть что любой внешней ресурс это uniqueness тип и в программе есть хотя бы один внешней ресурс (иначе она не сможет оставить следов своей жизнедеятельности) то ни одна программа с продолжениями не скомпилируется.
Спрашивается: Если все равно ни одна программа с продолжениями не скомпилируется то нахрена их вообще добавлять?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, palm mute, Вы писали:
PM>Насколько я понимаю, Влад противопоставляет макросы и продолжения в качестве средств метапрограммирования. Опять же, в отношении детерминированной финализации они ничем не отличаются. Ничем не ограниченные трансформации AST в общем случае ничуть не безопаснее ничем не ограниченных манипуляций потоком управления.
А можно объяснить почему продолжения вообще относятся к средствам метапрограммирования?
Ну, и за одно хотелось бы услышать определение термина "метапрограммироваине". Может дело в трактовании?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, palm mute, Вы писали:
PM>oneof, guard, return кажутся ключевыми словами, но таковыми не являются.
Не знаю. Может у меня фантазия слабая? Они мне кажутся вызовами функций.
PM>Признаю, для данной задачи макросы подходят гораздо лучше.
Я что-то в этой задаче не углядел место где было метапрограммирование.
То что макросы подходят для МП — это и ёжику понятно, так как они и есть МП.
PM> А вот для веба, если мы хотим программировать серверную часть так, будто это обычный десктопный ГУЙ, показывающий модальные диалоги и дожидающийся ответа, все не так очевидно.
Все как раз очевидно. Макры == МП. Они позволяет реализовать тот синтаксис и ту семантику что нужно.
Что до примеров применения МП для Веба, то Вольфхаунд дал тебе отличный пример (твой же, если не ошибаюсь).
ЗЫ
И все же хотелось бы объяснений того каким боком продолжения относятся к МП.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, palm mute, Вы писали:
PM>Как это обошлось без продолжений? "сериализовали имя и аргументы функции в url" — это и есть продолжение. Думаю, если бы у функции counter были локальные переменные — их мы бы тоже увидели в url.
Не обязательно. Их примеры это хорошо демонстрируют.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mr.Cat, Вы писали:
VD>>Тут вообще какая-то подмена понятий. То что через одну фичу можно с горем пополам выразить другую не делает саму фичу метапрограммированием. MC>Не с горем пополам одно через другое, а реализовать на основе одного целый класс схожих механизмов.
Да по фигу с горем или без. Мой вопрос был — "Какое отношение имеет возможность реализации одной фичи через другую к метапрограммированию?".
MC>Так, гигиенические макросы позволяют создавать новые синтаксические конструкции, обладающие свойством лексической области видимости.
Макры позволяют определять синтаксис и семантику. Отсюда понятно почему они могут помогать менять язык. Но МП — это возможность написания программ пишущих программы. И причем тут продолжения? Макры == МП. Заметь, не макры позволяют релизовать МП, а макры сами являются МП. Как только ты их применил, так сразу у тебя появилось МП. Но разве с продолжениями будет тоже самое?
MC>А континуации — создавать механизмы нелокального перехода.
Ну, и что?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
вот для этого и существуют тесты — чтобы проталкивать мусор дуракам, которые не способны сами разобраться в предмете. ценность этих конкретных тестов — нулевая. одни из них говорят о том, что в c++ нет стандартной green threads библиотеки, а в ghc она есть. другие — о том, что и на хаскеле можно писать в assembler style.
там в одном тесте кажется php был на первом месте вообще, большая часть тех тестов зависела исключительно от библиотек, причём запрещалось использовать third-party ones, оставшиеся три теста были изрядно низкоуровнево оптимизированы любителями хаскела, дело дошло даже до включения в стандартные билиотеки ghc функции, необходимой для ускорения одного из них
VladD2 wrote:
> А> Я так понимаю — то, что нельзя взять текущий continuation, > сериализовать его в БД, а ключик послать клиенту. И потом по этому > ключику достать и исполнить. > > Ну, кое-где это наверно можно. Только не очень ясно зачем же в БД > пихать? Народ вон от вюстэйта избавляется, а тут... > Не проще ли держать в памяти, а тех что давнно не ворочаются выкидывать?
Я вот только что подумал тоже, что если параллельно с выполнением
сессии писать всё в БД с поддержко MVCC, в одной транзакции от
начала сессии, -- очень было бы удобно. Но я не понимаю тоже,
в чём там могли бы быть проблемы.
Здравствуйте, FR, Вы писали:
FR>В этом наверно тоже, но вот недавно в рассылке плач был на тему что французы ничего про OCaml не знают и пишут на вражеских языках.
Как-то странно. Ничего не знают, но в то же время что-то пишут.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
А>> Но вопрос не в этом. Вопрос простой — зачем вообще эти таймауты?!?
VD>Я вообще не понимаю о каких таймаутах речь. VD>Авторизация может тупо вернуть некий билет который можно хранить в куках. Сессия тут просто не нужна.
Здравствуйте, Lloyd, Вы писали:
VD>>Я вообще не понимаю о каких таймаутах речь. VD>>Авторизация может тупо вернуть некий билет который можно хранить в куках. Сессия тут просто не нужна.
L>Дык, сессия именно так и работает.
Тут кто-то хотел хранить состояние сессии в БД. И это точно был не я.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали: WH>>>Ну давай раскажи как заставить try/finally bли любой другой способ детерминированной финализации работать в присутствии продолжений. WH>Ответ на вопрос будет?
Уже, можно сказать, был. То, что try/finaly не является способом детерминированной финализации в присутствии лямбд, корутин и потоков — ты сам согласился. Из твоих доводов остались uniqueness-типы. Я не знаком с ними настолько, чтобы аргументированно спорить, но на мой взгляд их внесение в язык окажет не большее влияние, чем монада IO, а она, как видно, ничуть не мешает писать код в cps — для него в хаскеле даже хелпер в виде монады Cont есть. Т.е. максимум надо будет разделять чистый и нечистый код, и в чистом можно будет использовать в том числе и континуации. Что касаетсмя использования континуаций в коде с побочными эффектами — с ходу не могу сформировать мнение. Возможно, стоит полистать ветку, где ты расписывал прелести uniqueness-типов Ремарку, но пока я плохо знаком с их основами — не вижу для себя в этом смысла.
WH>При появлении хоть одного uniqueness типа программа с продолжениями компилироваться перестанет ибо у нее не будет шансов пройти проверку типов. WH>А если учесть что любой внешней ресурс это uniqueness тип и в программе есть хотя бы один внешней ресурс (иначе она не сможет оставить следов своей жизнедеятельности) то ни одна программа с продолжениями не скомпилируется. WH>Спрашивается: Если все равно ни одна программа с продолжениями не скомпилируется то нахрена их вообще добавлять?
Здравствуйте, Mr.Cat, Вы писали:
MC>Уже, можно сказать, был. То, что try/finaly не является способом детерминированной финализации в присутствии лямбд, корутин и потоков — ты сам согласился.
Ты что-то не так понял.
Цитату можно?
MC>Из твоих доводов остались uniqueness-типы. Я не знаком с ними настолько, чтобы аргументированно спорить, но на мой взгляд их внесение в язык окажет не большее влияние, чем монада IO, а она, как видно, ничуть не мешает писать код в cps — для него в хаскеле даже хелпер в виде монады Cont есть.
Тут вот в чем дело.
Если uniqueness-тип попадает в продолжение то программа не сможет пройти проверку типов.
Проблема в том что call/cc засовывает в продолжение весь стек на момент вызова call/cc.
И в ста процентах случаев мы будем иметь в стеке хоть один uniqueness-тип. Иначе программа просто не сможет ничего сказать внешнему миру.
В случае с ручным CPS мы сами контролируем содержание стека. И можем избежать попадание в стек чего не надо.
MC>Возможно, стоит полистать ветку, где ты расписывал прелести uniqueness-типов Ремарку, но пока я плохо знаком с их основами — не вижу для себя в этом смысла.
Задача простая: Гарантировать что на объект существует одна и только одна ссылка.
Решается тоже очень просто: в переменную uniqueness-типа можно записать и прочитать из нее ровно один раз.
Таким образом мы просто реализуем семантику передачи владения.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали: MC>>Уже, можно сказать, был. То, что try/finaly не является способом детерминированной финализации в присутствии лямбд, корутин и потоков — ты сам согласился. WH>Ты что-то не так понял. WH>Цитату можно?
Но в данном случае ты приводишь проблему которая есть только в конкретном языке с весьма позорной системой типов.
Простейшие uniqueness решают данную проблему на корню.
Я это понял как согласие с тем, что детерминированная финализация в языках без uniqueness-типов возможна только в самых простых случаях.
WH>Если uniqueness-тип попадает в продолжение то программа не сможет пройти проверку типов.
Тут ты пожалуй прав. Сами по себе континуации и сими по себе uniqueness плохо сочетаются. Но из этого только следует то, что компилятор должен знать о контунцациях. Например, можно встроить поддержку delimited continuations, которые позволяют ограничить захватываемую континуацию. Также, я полагаю, в некоторых случаях можно доказать, что континуация, захваченная с call/cc вызывается не более одного раза.
WH>Задача простая: Гарантировать что на объект существует одна и только одна ссылка. WH>Решается тоже очень просто: в переменную uniqueness-типа можно записать и прочитать из нее ровно один раз. WH>Таким образом мы просто реализуем семантику передачи владения.
Ну на концептуальном-то уровне все понятно. Просто я ни разу не писал на языках с uniqueness. А дьявол-то наверняка в деталях.
