LINUX.ORG.RU

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

 ,


0

2

Правильно ли я понимаю, что наличие мутабельных переменных (set! и компания) позволяет отнести Scheme/Lisp к императивным языкам? Из-за мутабельности вызовы функций могут иметь сайд-эффекты, становится важен порядок вызовов, ну и далее вырастает весь комплекс проблем классических императивных процедурных языков. Если это рассуждение не правильно, то объясните пожалуйста в развернутой форме, что именно не так?

★★★★★

Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonimous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от shamaz

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

anonimous
()
Ответ на: комментарий от anonymous

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

Dark_SavanT ★★★★★
()
Ответ на: комментарий от anonymous

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

shamaz
()

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

anonimous
()
Ответ на: комментарий от Bad_ptr

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

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

anonymous
()
Ответ на: комментарий от aedeph_

unsafePerformIO

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

Bad_ptr ★★★★★
()
Последнее исправление: Bad_ptr (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

anonimous
()
Ответ на: комментарий от Bad_ptr

Ну сравни.

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

anonymous
()
Ответ на: комментарий от anonimous

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

shamaz
()
Ответ на: комментарий от anonymous

Ну сравни.

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

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

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

Bad_ptr ★★★★★
()
Ответ на: комментарий от Bad_ptr

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

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

Manhunt ★★★★★
() автор топика
Ответ на: комментарий от Manhunt

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

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

shamaz
()
Ответ на: комментарий от Bad_ptr

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

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

monk ★★★★★
()
Ответ на: комментарий от shamaz

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

anonimous
()
Последнее исправление: anonimous (всего исправлений: 1)

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

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

dave ★★★★★
()
Ответ на: комментарий от monk

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

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

Bad_ptr ★★★★★
()
Ответ на: комментарий от monk

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

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

Manhunt ★★★★★
() автор топика
Ответ на: комментарий от dave

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

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

shamaz
()
Ответ на: комментарий от anonimous

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

anonymous
()
Ответ на: комментарий от shamaz

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

dave ★★★★★
()
Ответ на: комментарий от anonimous

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

anonymous
()
Ответ на: комментарий от anonimous

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

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

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

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

anonymous
()
Ответ на: комментарий от dave

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

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

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

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

Manhunt ★★★★★
() автор топика
Ответ на: комментарий от anonymous

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

anonimous
()
Ответ на: комментарий от anonymous

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

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

anonimous
()
Ответ на: комментарий от anonimous

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

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

anonymous
()
Ответ на: комментарий от anonimous

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

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

shamaz
()
Ответ на: комментарий от anonimous

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

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

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

anonymous
()
Ответ на: комментарий от Manhunt

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

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

shamaz
()
Ответ на: комментарий от shamaz

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

anonymous
()
Ответ на: комментарий от shamaz

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

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

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

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

Manhunt ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.