Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, Mirrorer, Вы писали:
M>>Но это в том случае если принять, что указатель на функцию == функции.
K>Так в том и дело, что указатель на функцию != функции.
Это детали реализации. И вообще что значит функци?
Это ее код? Тогда ни один компилируемый язык не может поддерживать ФВП. Хотя... Как тогда расценивать эксперементы Рихтера по передачи кода функций из процесса в процесс?
Это некий идентификатор однозначно определяющий функцию? Тогд почему им не может быть указатель на фукнцию?
K>Собственно, в той же Википедии и об этом написано здесь
Читаем:
The modern, natively compiled programming languages support functions defined statically at compile time. Most of them, e.g. C and Pascal, additionally support function pointers, which can be stored in data structures and passed as arguments to other functions. Nevertheless, they are not considered to support first class functions, since, in general, functions cannot be created dynamically during the execution of a program.
То есть рассуждения с ФВП переходят на ФСО. Другими словами начинается подмена понятий.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Опять-т аки мой ответ адресуется обеим участникам, ответившим на мой вопрос, хотя и расположен вынужденно в неподобающем месте (что за скверный движок форума).
Ничего нового вы мне не сказали. Как совершенно правильно заметил Quintanar, в случае с ФП мы имеем дело с множеством локальных состояний вместо вполне определенных глобальных. В этом-то и состоит неестественность ФП, оторванность от реальности, именно поэтому на ФЯ тяжело реализуются соврмененные промышленные системы. Но вы ошибаетесь, считая, что я совсем свожу роль ФЯ на нет. Мне кажется, данная группа языков может быть оптимальной для решения очень узкой группы задач преимущественно вычислительного характера. В частности, ФЯ были бы очень к месту в CAD-системах в качестве внутренних языков. На них, быть может, легче решать небольшие, локальные задачи. Но для крупной разработки промышленного уровня применение данного подхода оптимальным назвать нельзя.
Мое мнение, возможно, незначительно изменится после ознакомления хотя бы с одним из этих языков (до этого у меня не было реального опыта применения).
Социализм — это власть трудящихся и централизованная плановая экономика.
В С и Паскале есть ФВП, но они не являются First-Class Values.
Точно в дырочку!
Кстати, такая путанница возникает даже у искушенных дядь. Мы тут как раз сейчас публикуем переводную статью по Хаскелю и в ней точно такая же путанница.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, fddima, Вы писали:
F> Реализовать можно всё, особенно если делать допущения. Но... то что можно реализовать — это хорошо, для языка. А "напрямую" оперировать понятиями — это уже другое. С теми же функциями... собственно мы в C можем их только вызывать, и на этом возможности заканчиваются. Речь ведь об этом?
Кто тебе сказал, что мы их можем только вызвать? Погляди, например, ради хохмы описание функции qsort() из стандартной библиотеки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > F> Реализовать можно всё, особенно если делать допущения. Но... то что > можно реализовать — это хорошо, для языка. А "напрямую" оперировать > понятиями — это уже другое. С теми же функциями... собственно мы в C > можем их только вызывать, и на этом возможности заканчиваются. Речь ведь > об этом? > > Кто тебе сказал, что мы их можем только вызвать? Погляди, например, ради > хохмы описание функции qsort() из стандартной библиотеки.
Это ещё не хохма.. Хохма — в VCL. Там где-то надо передать более-менее
делегат (procedure of object) в качестве callback в функцию WinAPI,
которая, увы, принимает только указатель на функцию, без лишнего
указателя. Ну так там просто-таки создаётся новая функция — результат
вырожденного частичного применения (остаётся процедура без
аргументов)... Но как это сделано... На стеке выделяется место и туда
пишутся машинные коды и в некотором месте в immediate data записывается
тот самый указатель, которого не хватает для счастья. Так как обычно
Executable Stack допустим, всё работает.
Здравствуйте, Sinclair, Вы писали:
S>Ее изобретали любители ФП. Реализация оказалась связана с проблемами с CAS: для работы CAS необходимо иметь доступ к неразрушенному стеку. В итоге, реализаторам пришлось эмулировать нормальный стек через технологическое отверстие, что оказалось медленнее, чем наивная реализация. Я не в курсе, существует ли решение для этой проблемы.
Хм. А goto почему проблем с CAS не вызывает?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, raskin, Вы писали:
R>Это ещё не хохма.. Хохма — в VCL. Там где-то надо передать более-менее R>делегат (procedure of object) в качестве callback в функцию WinAPI, R>которая, увы, принимает только указатель на функцию, без лишнего R>указателя. Ну так там просто-таки создаётся новая функция — результат R>вырожденного частичного применения (остаётся процедура без R>аргументов)... Но как это сделано... На стеке выделяется место и туда R>пишутся машинные коды и в некотором месте в immediate data записывается R>тот самый указатель, которого не хватает для счастья. Так как обычно R>Executable Stack допустим, всё работает.
Это как раз к языку отношения не имет. Это как раз эмуляция.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ну, хоть что-то новое в нашем болоте... воинт ООП — это радикально ново!
Что касается вопроса о естественности изменяемого состояния, то отвечу просто — бывает по разному. Бывают ситуации которые хорошо лучше эмулируются изменяемым состоянием, бывает наоборот.
Приведу в пример учет. Учет в широком финансовом смысле этого слова.
Вот предположим нам надо учитывать сколько денег осталось в кубышке. Мы создаем объект "деньги", объект "кубышка", а так же сообщения "добавить денег в кубышку" и "изьять деньги из кубышки". Оба сообщения хранят ссылаются на деньги помещаемые или изымаемые из кубышки.
Здорово? Похоже — да. Удобно? Для того чтобы сказать сколько денег сейчас в кубышке — вполне!
Но всегда ли это здорово?
Что если нам вдруг захочется узнать какой оборот был за определенный период? Или, скажем, сколько денег было в кубышке на конкретное число?
А ничего. Ничего хорошего. Наша модель не рассчитана на это. Ведь она всего лишь эмулирует реальный мир.
А что же далеть, чтобы наша модель позволяла решать поставленные задачи?
А очень просто! Надо всего лишь запрерить менять объекты, а вместо этого складывать сообщения в единое хранилище, откуда их можно будет извлечь и проанализировать.
Чувствуете куда я клоню? Правильно... к базам данных — шутка.
Я клоню к тому, что не всегда с точки зрения задачи изменение состояния — это благо.
Например, для большинства вычислительных задач функциональный стиль предпочтителен. ООП же изумительно подходит для задач симуляции и манипуляции. Ну, право, не глупо ли выражать онко Виндовс в виде фукнции?!
В общем, пусть цветут все цветы, главное чтобы они хорошо пахли. ООП никак не противоречит ФП и оба этих подхода никак не противоречат процедурному. На против они изумиетельно совмещаются. Главное уметь понять где какой предпочесть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, LaPerouse, Вы писали:
LP>Опять-т аки мой ответ адресуется обеим участникам, ответившим на мой вопрос, хотя и расположен вынужденно в неподобающем месте (что за скверный движок форума).
Интересно, почему люди увидя что-то новое и не успев привыкнуть к нему, сразу же начинают исать недостатки в этом новом и никогда не задумываются над тем, что недостаток в них (например, привычка к плохому)?
Вот, ты, например, увидил форум и начал возмущаться, что мол движок у него скверный. Меж тем достаточно понять, что в этом движке просто не надо отвечать сразу 10 человекам. Это и не конструктиво, так как они ведь не хором говорят. Отвечай себе конкретно на конкретные замечания и будет все ОК. Но привычка явно сильнее.
Та же ерунда и с взглядом на ФП. Увидил что-то, посчяитал его новым и пошел сразу искать недостатки. А надо ли с этого начинать? Может ради объективности сначала попробовать поглядеть и на достоинства?
Почему скажем наличие классов, библиотек коллекций, и других прибамбасов привычных для ООП — это нормально и даже наверно хорошо, а наличие:
синтаксических конструкций, помогающих объявлять вложенные конструкции функций, встроенные в сам язык возможности для обработки списков и т п — все это для дураков, чтобы дать им почувствовать всю “революционность” и крутизну “новейшего” подхода.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, LaPerouse, Вы писали:
LP>Все-таки основным критерием функционального подхода является то, о чем я говорил выше – отношение к хранению состояния. Вот он, постамент, на котором зиждется вся теория и практика функционального программирования, тот самый “пятый элемент”, придающий особый колорит этому стилю. Стоит только разрешить изменение переменных в любом “функциональном языке” и внешние ссылки на эти переменные (которое не нужно даже специальным образом вводить), и этот язык неуловимо для глаз превратится в стандартный процедурный язык. Все остальное – синтаксические конструкции, помогающие объявлять вложенные конструкции функций, встроенные в сам язык возможности для обработки списков и т п — все это для дураков, чтобы дать им почувствовать всю “революционность” и крутизну “новейшего” подхода. Да! Я утверждаю, что за роскошной вывеской прячется тухлятина, которой уже как минимум 50 лет. И готов это доказать любому, пусть и придется пожертвовать частью личного времени на восполнение пробелов в чужом образовании.
Все-таки основным критерием ОО подхода является то, о чем я говорил выше – отношение к хранению состояния. Вот он, постамент, на котором зиждется вся теория и практика ООП, тот самый “пятый элемент”, придающий особый колорит этому стилю. Стоит только запретить классы в любом “ОО-языке” и объявления методов в них, и этот язык неуловимо для глаз превратится в стандартный процедурный язык. Все остальное – синтаксические конструкции, помогающие объявлять интерфейсы, встроенные в сам язык возможности итирации по коллекция и т п — все это для дураков, чтобы дать им почувствовать всю “революционность” и крутизну “новейшего” подхода. Да! Я утверждаю, что за роскошной вывеской прячется тухлятина, которой уже как минимум 50 лет. И готов это доказать любому, пусть и придется пожертвовать частью личного времени на восполнение пробелов в чужом образовании.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
The modern, natively compiled programming languages support functions defined statically at compile time. Most of them, e.g. C and Pascal, additionally support function pointers, which can be stored in data structures and passed as arguments to other functions.
+1
Я ошибся — указатели конечно не являются функциями, но структуры данных могут содержать указатели, и можно построить структуру (скажем такая {указатель на функцию, список типов для параметров, тип для возвращаемого значения}), которую можно назвать "функцией". ФВП будут те процедуры, которые принимают/возвращают такие структуры.
В вики написано нормально (за исключением момента, что не очень понятно, что там понимается под "функцией").
Здравствуйте, VladD2, Вы писали:
VD>Все остальное – синтаксические конструкции, помогающие объявлять интерфейсы, встроенные в сам язык возможности итирации по коллекция и т п — все это для дураков
Всё же интерфейсы придуманы скорее не для дураков, а для поддержки КОП.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, raskin, Вы писали:
R>Но как это сделано... На стеке выделяется место и туда R>пишутся машинные коды и в некотором месте в immediate data записывается R>тот самый указатель, которого не хватает для счастья.
А вот в стандатном паскале можно просто передать локальную функцию.
Здравствуйте, gandalfgrey, Вы писали:
G>Я не понимаю, что такое время,
Судя по реакции на мое сообщение, ты в этом не одинок G>и признаю это открыто.
А вот это уже редкость.
Здравствуйте, LaPerouse, Вы писали:
LP>На основании ваших ответов можно заключить, что никто из вас не отвергает приближения ФЯ->Проц. язык. Таким образом, загвоздка заключается только в употребляемых терминах. Под функциональным языком вы имеете ввиду процедурный язык с явными ограничениями ввиде запрещений внешних ссылок, изменяемых переменных и т п. Прекрасно. В таком случае и доказывать-то мне ничего не остается — разве что недопустимость использования устаревшей парадигмы.в сегодняшних задачах. Но я хочу говорить не об этом.
Функциональная и императивная парадигмы появились приблизительно в одно время. Императивная раньше была воплощена в виде машины, которую уже можно было использовать.
Здравствуйте, Трурль, Вы писали:
G>>Я не понимаю, что такое время, Т>Судя по реакции на мое сообщение, ты в этом не одинок
Конечно, не одинок ! Нас — таких -много..."Имя нам — легион" (с)
Более того, существуют некоторые бытовые заморочки со временем, которые не понятны НИКОМУ из моих знакомых.
Пример :
Есть прибор, собирающий значения какого-то параметра раз в час. Как известно, 2 раза в год у нас происходит перевод времени.
То-есть один день в году имеет 23 часа и после 1 часу ночи наступает сразу 3 час. Другой день имеет 25 часов, и после 2 часов ночи наступает снова 2 часа ночи.
Как быть, куда бежать ? Никакого внятного, корректного и более-менее универсального способа обработать такую ситуацию пока не придумано.
Так что — такова се ля ва ! 8)
Трурль wrote: > R>Но как это сделано... На стеке выделяется место и туда > R>пишутся машинные коды и в некотором месте в immediate data записывается > R>тот самый указатель, которого не хватает для счастья. > > А вот в стандатном паскале можно просто передать локальную функцию.
А разве там можно её передать так, чтобы она ссылалась на переменные
функции на шаг выше?
VladD2 wrote: > R>Это ещё не хохма.. Хохма — в VCL. Там где-то надо передать более-менее > R>делегат (procedure of object) в качестве callback в функцию WinAPI, > R>которая, увы, принимает только указатель на функцию, без лишнего > R>указателя. Ну так там просто-таки создаётся новая функция — результат > R>вырожденного частичного применения (остаётся процедура без > R>аргументов)... Но как это сделано... На стеке выделяется место и туда > R>пишутся машинные коды и в некотором месте в immediate data записывается > R>тот самый указатель, которого не хватает для счастья. Так как обычно > R>Executable Stack допустим, всё работает. > > Это как раз к языку отношения не имет. Это как раз эмуляция.
К языку имеет отношение наличие делегатов. Которое в принципе позволяет
написать даже функцию, возвращающую сумму двух функций. А хохма связана,
действительно, не с языком, а с его взаимодействием с внешним миром,
когда даже такие зачатки приходится эмулировать.
M>>За возможность написать map(Fun, List) я бы продал Страуструпа с Виртом в рабство. Обоих
LCR>За эту фразу я бы поставил три балла! Если бы форум был КУ...
Я конечно понимаю, что это возможно и в С++ (а может и в Паскале), но вот такой ценой? Нее. Не надо Я лучше все в скрипты вынесу
— шутка.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Если нам не помогут, то мы тоже никого не пощадим.
