Императивность Scheme

print - сайд-эффект. Код, содержащий print, по определению является императивным.

Скобкота вообще ни на что не годится. Лопатой можно копать, а скобкотой ничего нельзя хорошо делать.

Да это понятно, но я в смысле того, что на состояние какой либо части програмы это вроде не способно повлиять. В старых лиспах было просто (write (read (write 'foo)))-->foo. Это никак не связано? Приведите пример кода, где принт меняет состояние.

Опять одно и тоже. Сейчас тебе приведут примеры, на что скобкота годится, затем ты попросишь пруфов, тебе приведут пруфы, а ты скажешь «ты все наврал» и быстро удалишься.

Как тебя свет носит!!!111

Можно. Не должно

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

Если я могу запилить одну часть на си. вторую на пито^Wсхеме срастить их через FFI и при необходимости на схеме писать без сайд-эффектов, чем плохо?

Да тут тупых анонимусов тоже презирают и ничего, живут они

Принт двигает курсор на экране. Вуаля

Императивность Scheme (комментарий)

А ты-то сам мнишь себя большим спецом, конечно?

В sicp, при введение в вычисления с окружениями, есть примерно такая фраза: «мы вынуждены отказаться от подстановочной модели вычислений, в пользу менее теоретически привлекательной, но более практичной модели с окружениями». Там же вводится и оператор присваивания. Таким образом, авторы называют функциональным программированием именно подстановочную модель вычислений, а замыкания они как раз вводят из-за необходимости императивных вычислений. Явно, в современном программировании, под функциональщиной понимается что-то другое.

Я нуб, но то что ты буровишь, делает мое ЧСВ.

Ути-пути! Налей борща, друг

Зачем без необходимости писать на 2 языках?

И почему два разных вызова функции для получения даты/времени возвращают разный результат.

Два разных вызова функции для получения даты/времени в хаскеле возвращают один и тот же результат, имеющий тип IO Time

unsafePerformIO

Единственное применение unsafePerformIO, подразумевающееся в стандарте - FFI к чистым функциям.

Ты бредишь, болезный. Посмотри, болезный и скорбный, как на чистом Term Rewriting определяется семантика Сишечки: https://code.google.com/p/c-semantics/

Ну, вот тебе вырожденный случай, тоже без присваивания: (popen «shutdown» '("-h" «now»))

Два разных вызова функции для получения даты/времени в хаскеле возвращают один и тот же результат, имеющий тип IO Time

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

Ты бредишь? Где в сообщении на которое ты отвечал вопрос о семантике си?

Если же ты попутал сообщения, то я тебе напоминаю, что я просил привести код на scheme, где принт способен повлиять на состояние програмы.

Ну сравни.

В смысле, не сказал? Все устанавливающие дату/время функции будут иметь тип IO () (для конкретного Time); совершенно аналогично.

Ты редостно туп. print хотя бы двигает курсор (что блядь в схеме, что в C, что где-то ещё). Это и есть изменение состояния

Ну сравни.

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

будут иметь тип IO ()

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

Это что-то вроде (begin (foo) (exit) (bar))?

Ты про какой принт то речь ведешь, секретутка, здесь про вывод говорят, идиот.

В /dev/sda лол

Слушай, давай нормально поговорим, лады? Вот скажи, откуда ты такой тупой?

а вообще в чём проблема. Ты хочешь, чтобы кто-то взбугуртнул

Вообще-то я наделся, что скобчатые хорошенько схлестнутся со штангистами во славу монад. Ну или срача из-за еще каких-нибудь прячущих мутабельный state костылей. Пока довольно вяло идёт, увы )

Штангисты тягают штанги, скобочники... что там они делают?

ЛОР давно дискредитировал себя как технический ресурс, так-то

Ну и получается что эти функции меняют состояние.

Они не меняют состояние, а возвращают вычисление. Которое, будучи выполненным через unsafePerformIO или аналог, будет менять состояние.

Ты настолько туп, что ты не понимаешь, что не важно, что выплевывает программа, текст на stdout, или харкоту в твою наглую харю, это не способно повлиять на ее состояние.

Правильно. Питер Норвиг давно написал в своей книге PAIP, что Common Lisp вместе с setf является императивным языком, а без setf - функциональным языком программирования. Тоже самое можно сказать о схеме.

Фокус в том, что понятия «императивный» и «функциональный» (а также «декларативный») не противопоставляются друг другу. На самом деле, все не так просто, или, наоборот, очень просто, но многие слишком любят делить все на черное и белое ;)

а возвращают вычисление. Которое, будучи выполненным через unsafePerformIO или аналог, будет менять состояние

Ну так в конце концов-то состояние-то поменяется.

Они не меняют состояние, а возвращают вычисление. Которое, будучи выполненным через unsafePerformIO или аналог, будет менять состояние.

Как как быть с тем, что «единственное применение unsafePerformIO, подразумевающееся в стандарте - FFI к чистым функциям». Анонимус ошибся?

Фокус в том, что понятия «императивный» и «функциональный» (а также «декларативный») не противопоставляются друг другу. На самом деле, все не так просто, или, наоборот, очень просто, но многие слишком любят делить все на черное и белое ;)

Я тоже так написал. А потом побыстрее стер, потому что по википедии это, якобы, «контрастирующие» понятия. Но только кому какое дело до терминологии? Но на ЛОРе могут придраться, так как терминология - единственное, чем владеет современный лоровец.

Тебе слово «семантика» знакомо, прыщь? О каком таком «состоянии» ты вякаешь, если меняется СЕМАНТИКА при изменении порядка вычислений императивной программы.

Ну, и пусть себе контрастируют. Что-то в этом есть. Просто многие до абсурда часто доводят.

Что-то вроде, только еще более радикально, с рваными пердаками.

Ты бредишь? Где в сообщении на которое ты отвечал вопрос о семантике си?

Ты болен. Ты сослался на семантику переписывания в SICP и начал вонять какую-то несусветную чушь про замыкания. Тебе было показано, что на чистой семантике переписывания можно изобразить абсолютно императивный Си.

что я просил привести код на scheme, где принт способен повлиять на состояние програмы.

А тебе мягко намекнули, что ты не понимаешь, что такое «состояние програмы».

Фокус в том, что понятия «императивный» и «функциональный» (а также «декларативный») не противопоставляются друг другу. На самом деле, все не так просто, или, наоборот, очень просто, но многие слишком любят делить все на черное и белое ;)

«Декларативный» и «императивный» — это ортогональные понятия: декларативное описывает результат (но не говорит о том, как его достигнуть), а императивное описывает последовательность шагов (но не говорит о том, каков будет результат).

На практике императивная часть практически никогда не встречается без декларативной (императивные программы оперируют понятиями инвариантов, контрактов, и тому подобного - то есть декларативными утверждениями относительно императивного кода).

Однако гораздо интереснее то, что на практике встречаются успешные примеры чисто-декларативных, без малейшего намека на императивщину, языков. И это позволяет прямо противопоставить друг другу императивное и декларативное.

Поясни, тогда, как изначально заложенная инструкция «записать туда-то», способна повлиять на порядок выполнения.

что на чистой семантике переписывания можно изобразить

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

Поясни, тогда, как изначально заложенная инструкция «записать туда-то», способна повлиять на порядок выполнения.

Ты идиот? Наоборот, порядок выполнения влияет на семантику императивной программы, и не влияет на семантику функциональной.

способна повлиять на порядок выполнения.

Причём тут порядок выполнения?

Ты, гомосек, сын гомосека и проститутки, писал следующее:

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

За это тебя и макают твоим тупым хлебалом в говнище.

что на практике встречаются успешные примеры чисто-декларативных, без малейшего намека на императивщину, языков.

В которых считают факториалы?

В которых ключевые слова вроде «SELECT», «FROM», «ORDER BY», и т.п.

что на практике встречаются успешные примеры чисто-декларативных, без малейшего намека на императивщину, языков.

В которых считают факториалы?

Не, гораздо более интересные штуки делают:

Императивность Scheme (комментарий)
Императивность Scheme (комментарий)
Императивность Scheme (комментарий)