Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, Курилка, Вы писали:

К>>Ну скажи как твоя только одна монада будет (цитирую изначальную проблему, которую я высказал) "контролировать чистоту для языка"?

BZ>я гнева вашего никак не растолкую...

BZ>самое простое — запрет на вызов процедур (имеющих побочные эффекты) из функций. и всё. даже никаких спец. синт. конструкций не понадобится

Дак собственно к этому я и вёл, задавал-то я вопрос по поводу контроля, а не по поводу синтаксиса.
Ну логично, что если поделить функции на чистые/грязные, то проконтролировать несложно.

Здравствуйте, Курилка, Вы писали:

К>Чувствую полноценного ответа ожидать не приходится...
К>Ну скажи как твоя только одна монада будет (цитирую изначальную проблему, которую я высказал) "контролировать чистоту для языка"?

Можно ввести новый тип значений — действия.
При выполнении блока "do { x <- expr1; expr2(x) }" интерпретатор проверяет (в рантайме) что expr1 и expr2(x) возвращают действия, точно так же как при вычислении выражения "e1 + e2" он проверяет, что e1 и e2 возвращают числа, вполне в духе динамических языков. Этот вариант реализован в интерпретаторе в сообщении выше.

Можно было пойти чуть дальше и сделать так, что грязная программа будет просто синтаксически некорректной, в моем интерпретаторе для этого нужно ввести понятие процедуры с аргументами.

Здравствуйте, Курилка, Вы писали:

К>Клёва, только контроля нету
Ну почему же нету — есть, но он в рантайме. Есть важное различие между отсутствием контроля и контролем в рантайме — в первом случае ты можешь написать программу, которая будет использовать функции с побочными эффектами и делать что-то полезное, во втором случае программа будет падать, и программист буде вынужден ее переписать в чистом стиле.

К>Хотя прикрутить, конечно можно
Ну если к текущему варианту прикрутить контроль, это получится некая вырожденная система типов, и язык будет уже не совсем динамическим. Но, как я говорил, осталось сделать полшага, чтобы грязные программы обнаруживались парсером как синтаксические ошибки.

Здравствуйте, palm mute, Вы писали:

PM>Здравствуйте, Курилка, Вы писали:

К>>Чувствую полноценного ответа ожидать не приходится...
К>>Ну скажи как твоя только одна монада будет (цитирую изначальную проблему, которую я высказал) "контролировать чистоту для языка"?

PM>Можно ввести новый тип значений — действия.
PM>При выполнении блока "do { x <- expr1; expr2(x) }" интерпретатор проверяет (в рантайме) что expr1 и expr2(x) возвращают действия, точно так же как при вычислении выражения "e1 + e2" он проверяет, что e1 и e2 возвращают числа, вполне в духе динамических языков. Этот вариант реализован в интерпретаторе в сообщении выше.

PM>Можно было пойти чуть дальше и сделать так, что грязная программа будет просто синтаксически некорректной, в моем интерпретаторе для этого нужно ввести понятие процедуры с аргументами.

А в реальности не знаешь, кто-нибудь таким извратом занимался?
Я вот только недоделанный (вроде) fun вспомнил.

Здравствуйте, palm mute, Вы писали:

PM>Здравствуйте, Курилка, Вы писали:

К>>Клёва, только контроля нету
PM>Ну почему же нету — есть, но он в рантайме. Есть важное различие между отсутствием контроля и контролем в рантайме — в первом случае ты можешь написать программу, которая будет использовать функции с побочными эффектами и делать что-то полезное, во втором случае программа будет падать, и программист буде вынужден ее переписать в чистом стиле.

Наверное я слепой, покажи где именно твой контроль?
Плюс процедуры (они же грязные функции) определять разве можно?

К>>Хотя прикрутить, конечно можно
PM>Ну если к текущему варианту прикрутить контроль, это получится некая вырожденная система типов, и язык будет уже не совсем динамическим. Но, как я говорил, осталось сделать полшага, чтобы грязные программы обнаруживались парсером как синтаксические ошибки.
Я про контроль в рантайме имел в виду, конечно же.

Здравствуйте, palm mute, Вы писали:

PM>Здравствуйте, Курилка, Вы писали:

К>>Клёва, только контроля нету
PM>Ну почему же нету — есть, но он в рантайме. Есть важное различие между отсутствием контроля и контролем в рантайме — в первом случае ты можешь написать программу, которая будет использовать функции с побочными эффектами и делать что-то полезное, во втором случае программа будет падать, и программист буде вынужден ее переписать в чистом стиле.

посылаю седеющую голову пеплом — просмотрел

Здравствуйте, Курилка, Вы писали:

К>Наверное я слепой, покажи где именно твой контроль?
К>Плюс процедуры (они же грязные функции) определять разве можно?
Ты "тесты" в конце видел? Там выражение print(action(42) + 5) падает с ошибкой.

Здравствуйте, palm mute, Вы писали:

PM>Здравствуйте, Курилка, Вы писали:

К>>Наверное я слепой, покажи где именно твой контроль?
К>>Плюс процедуры (они же грязные функции) определять разве можно?
PM>Ты "тесты" в конце видел? Там выражение print(action(42) + 5) падает с ошибкой.

Да уже нашёл, сссорри

Здравствуйте, Курилка, Вы писали:

К>А в реальности не знаешь, кто-нибудь таким извратом занимался?
Не знаю, не думаю, что это кому-нибудь нужно. Как я понимаю, "динамики" не признают статического контроля вообще (не считая проверки синтаксиса), потому зачем им такая вырожденная форма контроля — ума не приложу. С другой стороны, есть же динамически типизированные DSL вообще без ввода/вывода, там и контролировать ничего не надо.

PM>>>>Теоретически можно, если для операций с побочными эффектами ввести специальные синтаксические конструкции.
К>>>Т.е. есть какие-то примеры подобного?
T>>Haskell, do notation.
К>Это ответ на "как-то контролировать чистоту для языка с динамической типизацией"?

Да.

К>Или я что-то не понял или одно из двух...

Да.

Отложи проверку типов в Хаскеле до выполнения программы, получишь то, что нужно. "Ввод-вывод может производиться только в аргументах функции >>=, или в рамках do-выражения."

К>>Ну скажи как твоя только одна монада будет (цитирую изначальную проблему, которую я высказал) "контролировать чистоту для языка"?
BZ>самое простое — запрет на вызов процедур (имеющих побочные эффекты) из функций. и всё. даже никаких спец. синт. конструкций не понадобится

Да! Д-да! Р-рок! (С) B&B

Запретить! Вызов! Процедур!

Синтаксиса! Не НАДО!!!

Если серьёзно, то твоё запрещение и реализуется через синтаксическое ограничение.

К>А в реальности не знаешь, кто-нибудь таким извратом занимался?
К>Я вот только недоделанный (вроде) fun вспомнил.

Этот?

Только им мало, кто пользуется.

Адептам динамики он не нравится, слишком ограничивающий.

К>>Хотя прикрутить, конечно можно
PM>Ну если к текущему варианту прикрутить контроль, это получится некая вырожденная система типов, и язык будет уже не совсем динамическим. Но, как я говорил, осталось сделать полшага, чтобы грязные программы обнаруживались парсером как синтаксические ошибки.

Проверку типов можно реализовать в виде двухуровневых грамматик (они же грамматики ван Вийнгаардена). И встроить в разборщик.

Вроде, всего лишь разбор по синтаксису, а типы тоже проверяются.

Товарищи из динамического сообщества не скоро поймут, в чём их обманули.

Здравствуйте, thesz, Вы писали:

К>>А в реальности не знаешь, кто-нибудь таким извратом занимался?
К>>Я вот только недоделанный (вроде) fun вспомнил.

T>Этот?

Т. е. изобрели какой-то ключик, отключающий проверку типов в хаскеле до рантайма?
Если нет, то к чему твоя реплика, ибо речь шла о динамической типизации?

Здравствуйте, thesz, Вы писали:

T>Проверку типов можно реализовать в виде двухуровневых грамматик (они же грамматики ван Вийнгаардена). И встроить в разборщик.

вывод типов примерно так и выглядит. тот же q-lang — скриптовый язык, но основанный на inference вместо динамики. да и сам haskell хорош в качестве скриптового языка

Здравствуйте, thesz, Вы писали:

BZ>>самое простое — запрет на вызов процедур (имеющих побочные эффекты) из функций. и всё. даже никаких спец. синт. конструкций не понадобится

T>Если серьёзно, то твоё запрещение и реализуется через синтаксическое ограничение.

в конечном счёте ты прав, но как бы никакого нового синтаксиса не нужно

Здравствуйте, thesz, Вы писали:

T>Отложи проверку типов в Хаскеле до выполнения программы, получишь то, что нужно. "Ввод-вывод может производиться только в аргументах функции >>=, или в рамках do-выражения."

в хаскеле не проверка, а вывод типов. и тип результата, к примеру, может определять тип аргументов функции

Здравствуйте, BulatZiganshin, Вы писали:

BZ>в хаскеле не проверка
<буквоед mode>
не всегда, расширения GHC сплошь и рядом требуют аннотаций
</буквоед mode>

К>> Do нотация требует монаду
PM>Это в Хаскеле она требует монаду, т.к. рассахаривается в вызовы перегруженных функций (>>=) и return. Вполне можно представить себе язык, поддерживающий только одну монаду — IO — и транслирующий do-нотацию соответствующим образом.

В Helium — такой хаскеллоподобный язык — именно так и есть.

T>>Отложи проверку типов в Хаскеле до выполнения программы, получишь то, что нужно. "Ввод-вывод может производиться только в аргументах функции >>=, или в рамках do-выражения."
BZ>в хаскеле не проверка, а вывод типов. и тип результата, к примеру, может определять тип аргументов функции

Это то, что происходит в compile time.

Скажи, неужели ты не можешь вообразить алгоритм, что работает в run-time и производит проверку типов?