Здравствуйте, vdimas, Вы писали:
K>>Что есть нативная поддержка функциональной парадигмы языком? K>>Мой ответ — первоклассность функций в этом языке. K>>Вы хотели сказать, что функций как FCO недостаточно? K>>С моей точки зрения — вполне достаточно. K>>А чего еще не хватает? V>Функциональная парадигма в нынешнем виде — это не только первоклассность ф-ий и не столько.
Допустим.
V>Когда-то обсуждали сам термин "парадигма" и пришли к выводу, что парадигма (относительно к IT) — это совокупность подходов, практик, идей и соответствующего инструментария, определяющих способ решения некоей задачи (среди бесконечного множества других способов). В интуитивном плане парадигма формирует точку зрения на проблему.
Все вышеописанное это парадигма не только относительно к IT. Но я парадигмы обсуждать не буду, дабы не призывать.
V>Функциональная декомпозиция — это лишь один из кирпичиков этой парадигмы, как и первоклассность ф-ий.
Краеуголный кирпичик.
V>Считается, что в функциональной парадигме присутствует как минимум еще иммутабельность, и как следствие — инструментарий, типа туплов
Кортежи — не следствие иммутабельности, вообще говоря. Что касается иммутабельности — о чем собственно идет речь — об отсутствии присваивания? Иммутабельность это интересный вопрос, который не мешало бы развить.
V> и прилагающегося к ним паттерн-матчинга,
И паттерн-матчинг также не прилагается к кортежам. Паттерн матчинг это инструмент для диспетчеризации и, если есть сложные структуры — средство декомпозиции сложных структур (в частном случае — кортежей). Отношение к функциональному программированию он имеет, но весьма опосредованное. Есть языки с паттерн матчингом не являющиеся функциональными (Prolog) и функциональные языки без паттерн матчинга (Scheme)
V>раскрутки рекурсии
Это оптимизация, вообще говоря. Как здесь уже правильно было замечено, язык поддерживает общую рекурсию, а раскручивается ли хвостовая рекурсия — вопрос реализации. Да, я знаю, что это оптимизация включается в стандарты некоторых языков. Но теория раскрутки хвостовой рекурсии была выработана Хьюиттом в 1977 году. Все языки которые появились до этого счастливого момента были нефункциональными?
V> и встроенная возможность ленивости (не только при моделировании бесконечных списков, сам факт оперирования ф-иями как значениями предполагает отложенный вызов этих самых ф-ий).
Вот видите, вы же сами понимаете, что "возможность ленивости" есть во всех языках с первоклассными функциями, какой смысл в таком случае рассматривать эту характеристику отдельно?
Кстати, "возможность ленивости" есть вообще во всех тьюринг полных языках — просто без нормального порядка вычислений затруднительно что-то посчитать. Например, тернарный оператор ?: и вообще любой оператор ветвления во всех языках — "ленивые".
V> Т.е. вот минимальный "джентельменский" требований к инструментарию,
Минимальный? Да нет. Минимальный — первоклассность функций. Язык с паттерн-матчингом, кортежами и "раскруткой хвостовой рекурсии" но без первоклассных функций не является функциональным, а язык без всего этого, но с первоклассными функциями — является. Хотябы потому, что лямбда-исчисление это функциональный язык.
Ну и что у нас осталось от этого "джентельменского набора" кроме первоклассных функций и иммутабельности, с которой разберемся позже?
V>для полной поддержки современной функциональной парадигмы.
Давайте без современной. Мы классифицируем языки, так что неплохо было бы использовать для этого предикат для языка. А "язык был функциональным, а после 70ой годовщины отябрьской революции перестал быть функциональным" — никуда не годится. Это предикат для языка и года. Например "современный язык".
K>>Что есть "число строк необходимое для поддержки ООП" и на каком числе строк находится граница между OO и неОО языком? V>т.к. ось бесконечна, то интересует лишь ее отрезок — суть разность строк, применительно к какой-либо задаче.
Это не решает нашу проблему. С таким подходом можно сказать, что Траляля более функциональный, чем Блаблабла. А у нас все началось с того, что Траляля — функциональный, а Блаблабла — нет.
V>>>определение объекта в студию... K>>Допустим, АТД с состоянием. Годится?
V>без "А" годится,
А почему без А?
V>ибо под классическое определение объекта попадает любой конечный автомат, разработанный (или смоделированный, не суть) на любом ЯП, например на том же С.
Не понимаю этого возражения. В C нет сущности FSM. Точно также как и сущности "объект" там нет, но используя некоторые сущности существующие в этом языке можно и FSM написать и писать программы с применением объектной декомпозиции.
V>Ok, просто это как бы контрпример к тому, что наличие или отсутствие в инструменте какого-либо одного "кирпичика" не обязательно делает инструмент достаточно подходящим для использования в рамках какой-либо парадигмы, хотя и может сделать применение этой парадигмы с этим инструментом _возможным_. Дело, разумеется, лишь в количестве доп. приседаний, которые согласен делать применяющий, а так же в количестве _автоматически_ обнаруживаемых граблей, принадлежащих к парадигме генетически.
Зачем этот контрпример? Я и сам считаю,(и писал об этом прямо в этой теме), что можно писать программы с применением объектной декомпозиции на неООЯ и с применением функциональной на неФЯ.
V>>>почему ты отделяешь удобства от фич? K>>Фича — характеристика языка. Удобство — характеристика системы язык-программист. Синтаксис с отступами — фича. С точки зрения Васи — это удобство, с точки зрения Пети — неудобство. V>Что-то мне подсказывает, что фичи языков, да и сами ЯП высокого уровня появились в ответ на требование "удобства". Набор реализованных взаимодействующих фич в языке является, по-сути, реализацией неких требований удобства с т.з. авторов языка.
См. выделенное. Или это не возражение, а согласие с моими словами?
V>>>Ну на C# можно, и согласно твоей логике, он является ФЯП. K>>Это уже обсуждалось. Да, со второй версии он соответствует моему определению ФЯП. V>Тогда неудивительно, что вышел такой длинный спор.
Чувствуется ответственный подход к изучению дискуссии. Функциональность С# здесь еще никто не оспаривал, хотя это не может не удивлять.
На самом деле с ним не все просто и я об этом писал. Также я писал, что мы говорим не о позиционировании, а о классификации.
... << RSDN@Home 1.2.0 alpha rev. 774>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Также я писал, что мы говорим не о позиционировании, а о классификации.
Похоже, ты пытаешься классифицировать по фичам, хоть и краеугольным. (Кстати, классифицировать можно много по чему) Тогда в чём полезность дискуссии? Мы ведь инструменты обсуждаем, а каким-то разделом мозга, отвечающим за интуицию, мне кажется, что инструменты имеет смысл классифицировать только по их позиционированию. Например, отвертка классическая и с электроприводом могли бы по очень многим параметрам быть отнесены к разной классификации, но меня бы больше всех интересовала только классификация по назначению. Хотя, достаточно тяжелой отвёрткой можно и гвозди забивать, особенно если классифицировать, скажем, по наличию тяжёлой металлической детали в составе инструмента.
K>И паттерн-матчинг также не прилагается к кортежам. Паттерн матчинг это инструмент для диспетчеризации и, если есть сложные структуры — средство декомпозиции сложных структур (в частном случае — кортежей). Отношение к функциональному программированию он имеет, но весьма опосредованное. Есть языки с паттерн матчингом не являющиеся функциональными (Prolog) и функциональные языки без паттерн матчинга (Scheme)
Кстати, примеры неудачные привёл. Прологу паттерн-матчинг нужен именно для обработки кортежей.
А насчёт Схемы — вообще вопрос отдельный, согласно твоему же определению насчёт первоклассности Лисп/Схему нельзя отнести к функциональным языкам, ибо ф-ии представляются не "напрямую", как встроенная сущность, а с помощью доп. механизма — списка. В этом плане приведение ф-ий к делегатам в D кажется куда как более ближе к понятию первоклассности.
V>>раскрутки рекурсии
K>Это оптимизация, вообще говоря.
Если рассматривать языки ради языков, забыв, что это, в первую очередь — инструмент, то можно слишком на многое закрывать глаза. Мне же всё время хочется называть вещи своими именами, например, раскрутку рекурсии в языках, где это единственный способ организации цикла — условием существования языка в качестве применимого инструмента.
K>Как здесь уже правильно было замечено, язык поддерживает общую рекурсию, а раскручивается ли хвостовая рекурсия — вопрос реализации.
Да пофиг, поддерживает ли язык рекурсию как таковую в общем случае, речь о тех случаях, где только так и можно организовать цикл. В этих случаях отнести раскрутку к необязательной оптимизации просто невозможно.
K>Да, я знаю, что это оптимизация включается в стандарты некоторых языков.
Ну вот, сам же и написал всё правильно. Если раскрутка включена в стандарт, то, может быть, это не просто оптимизация.
K>Но теория раскрутки хвостовой рекурсии была выработана Хьюиттом в 1977 году. Все языки которые появились до этого счастливого момента были нефункциональными?
Они были малоприменимыми в качестве инструмента. Лисп — второй, после Фортрана ЯВУ в истории IT, а на практике применялся на несколько порядков меньше, оставаясь обучающим и исследовательским языком. Случайно ли?
K>Вот видите, вы же сами понимаете, что "возможность ленивости" есть во всех языках с первоклассными функциями, какой смысл в таком случае рассматривать эту характеристику отдельно?
Я, наверно, недостаточно раскрыл понятие "встроенной" ленивости. Я подразумевал "прозрачное" построение структурированных данных как цепочек ленивых вызовов. "Непрозрачно", т.е. явно это можно сделать много где, даже в отсутствии первоклассных ф-ий.
V>> Т.е. вот минимальный "джентельменский" требований к инструментарию,
K>Минимальный? Да нет. Минимальный — первоклассность функций. Язык с паттерн-матчингом, кортежами и "раскруткой хвостовой рекурсии" но без первоклассных функций не является функциональным, а язык без всего этого, но с первоклассными функциями — является. Хотябы потому, что лямбда-исчисление это функциональный язык.
И всё-таки, тот же Лисп и Схема не имет ф-ий как первоклассных отдельный сущностей, а паттерн-матчинг (или нечно похожее по сути) там может быть сделан в виде пользовательских ф-ий, ввиду однородности представления данных, т.е., хоть эта фича и не встроенна в язык, её легко получить ср-вами языка (напр. Лисп-надстройка Qi).
Так что, если уж минимизировать, то я бы оставил только одно минимальное требование — конструирование сущностей, аналогичным ф-иям, в процессе работы программы. (Более полные требования уже перечислял в прошлом посте.) Делегаты и замыкания в D очень даже удовлетворяют этому минимальному требованию, так же как и представление ф-ий в виде списков в Лиспе/Схеме.
Здравствуйте, vdimas, Вы писали:
V>>>раскрутки рекурсии
K>>Это оптимизация, вообще говоря.
V>Если рассматривать языки ради языков, забыв, что это, в первую очередь — инструмент, то можно слишком на многое закрывать глаза. Мне же всё время хочется называть вещи своими именами, например, раскрутку рекурсии в языках, где это единственный способ организации цикла — условием существования языка в качестве применимого инструмента.
K>>Как здесь уже правильно было замечено, язык поддерживает общую рекурсию, а раскручивается ли хвостовая рекурсия — вопрос реализации.
V>Да пофиг, поддерживает ли язык рекурсию как таковую в общем случае, речь о тех случаях, где только так и можно организовать цикл. В этих случаях отнести раскрутку к необязательной оптимизации просто невозможно.
Именно так и поступили для языка Scheme -- там требование поддержки хвостовой рекурсии описано непосредственно в стандарте языка.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
vdimas wrote:
> Кстати, примеры неудачные привёл. Прологу паттерн-матчинг нужен именно для > обработки кортежей. А насчёт Схемы — вообще вопрос отдельный, согласно > твоему же определению насчёт первоклассности Лисп/Схему нельзя отнести к > функциональным языкам, ибо ф-ии представляются не "напрямую", как > встроенная сущность, а с помощью доп. механизма — списка. В этом плане > приведение ф-ий к делегатам в D кажется куда как более ближе к понятию > первоклассности.
Погоди, а можно ссылочку. Просто на Scheme, пишу учебные задачки. Чисто
внешне функция FCO. В SICP даже пример приведён как с помощью функций можно
реализовать список.
> > V>>раскрутки рекурсии > > K>Это оптимизация, вообще говоря. > > Если рассматривать языки ради языков, забыв, что это, в первую очередь - > инструмент, то можно слишком на многое закрывать глаза. Мне же всё время > хочется называть вещи своими именами, например, раскрутку рекурсии в > языках, где это единственный способ организации цикла — условием > существования языка в качестве применимого инструмента.
В Nice или в D это разве единственный способ?
> K>Как здесь уже правильно было замечено, язык поддерживает общую рекурсию, > а раскручивается ли хвостовая рекурсия — вопрос реализации. > > Да пофиг, поддерживает ли язык рекурсию как таковую в общем случае, речь о > тех случаях, где только так и можно организовать цикл. В этих случаях > отнести раскрутку к необязательной оптимизации просто невозможно. > > > K>Да, я знаю, что это оптимизация включается в стандарты некоторых языков. > > Ну вот, сам же и написал всё правильно. Если раскрутка включена в > стандарт, то, может быть, это не просто оптимизация.
Для Scheme это важно, т.к. там циклы по другому не делаются, для Nice/D
просто оптимизация.
> V>> Т.е. вот минимальный "джентельменский" требований к инструментарию, > > K>Минимальный? Да нет. Минимальный — первоклассность функций. Язык с > паттерн-матчингом, кортежами и "раскруткой хвостовой рекурсии" но без > первоклассных функций не является функциональным, а язык без всего этого, > но с первоклассными функциями — является. Хотябы потому, что > лямбда-исчисление это функциональный язык.
[] > Так что, если уж минимизировать, то я бы оставил только одно минимальное > требование — конструирование сущностей, аналогичным ф-иям, в процессе > работы программы. (Более полные требования уже перечислял в прошлом > посте.) Делегаты и замыкания в D очень даже удовлетворяют этому > минимальному требованию, так же как и представление ф-ий в виде списков в > Лиспе/Схеме.
На D и Nice можно писать в функциональном стиле практически одинаково
просто. Но разница между Nice и D в дизайне этой фичи — насколько я
понимаю, автор Nice сразу заложил в язык функции как FCO, но в некоторых
местах вылазят ограничение платформы, которые он толи не смог, толи не стал
скрывать. В D же автор эту фичу внёс уже позже и пришлось городить делегаты
и прочее. И выходит разница между ними, с точки зрения практики, только в
этом. Поскольку оба языка гибридные, то ИМХО в Nice код в функциональном
стиле выглядит органичнее и естественнее, чем такой же на D. Особенно после
Scheme или Haskell.
Posted via RSDN NNTP Server 2.1 beta
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, dr.Chaos, Вы писали:
DC>>Погоди, а можно ссылочку. Просто на Scheme, пишу учебные задачки. Чисто DC>>внешне функция FCO.
V>Ну, полностью реализующих 5-й стандарт еще не видел. А для многих существующих реализаций-интерпретаторов ф-ия от списка мало чем отличается.
А функция от этого перестаёт быть FCO? Насколько я понимаю там список нужен для хранения замкнутых переменных.
Здравствуйте, dr.Chaos, Вы писали:
DC>>>Погоди, а можно ссылочку. Просто на Scheme, пишу учебные задачки. Чисто DC>>>внешне функция FCO.
V>>Ну, полностью реализующих 5-й стандарт еще не видел. А для многих существующих реализаций-интерпретаторов ф-ия от списка мало чем отличается.
DC>А функция от этого перестаёт быть FCO? Насколько я понимаю там список нужен для хранения замкнутых переменных.
Да нет, само тело ф-ии — это список, системный eval делает apply к членам списка (apply просто берет голову списка, и вызывает её с хвостом в кач-ве аргумента). Результат хранения замкнутых переменных — это новая ф-ия, которая содержит в своём теле вызов исходной.
DC>Что из этих действий я не могу делать с функциями в Scheme если они реализованы с помощью списков?
Спор изначально шёл не об этом. Я вот вполне считаю, что делегаты в D вполне могут всё тоже самое, т.е. являются первоклассными объектами, просто помимо них существует разновидность функциональных сущностей, которые не могут рассматриваться как данные ("обычные" ф-ии). Можно считать, что есть два типа функционалных сущностей в D.
А в классическом Лисп любые структуры данных организуются как списки, и тела ф-ий — в т.ч., т.е. нет отдельной сущности — функции. Сконструированный вручную список может представлять из себя ф-ию (речь о пользовательских ф-иях).
Здравствуйте, vdimas, Вы писали:
K>>И паттерн-матчинг также не прилагается к кортежам. Паттерн матчинг это инструмент для диспетчеризации и, если есть сложные структуры — средство декомпозиции сложных структур (в частном случае — кортежей). Отношение к функциональному программированию он имеет, но весьма опосредованное. Есть языки с паттерн матчингом не являющиеся функциональными (Prolog) и функциональные языки без паттерн матчинга (Scheme) V>Кстати, примеры неудачные привёл. Прологу паттерн-матчинг нужен именно для обработки кортежей.
Все-таки не кортежей, а структурных термов. Разве в Прологе кортежи отдельно от функторов бывают? Но это не важно. Пролог это пример языка с паттерн-матчингом, но в то же время не являющегося функциональным. В чем неудачность примера — непонятно.
V>А насчёт Схемы — вообще вопрос отдельный, согласно твоему же определению насчёт первоклассности Лисп/Схему нельзя отнести к функциональным языкам, ибо ф-ии представляются не "напрямую", как встроенная сущность, а с помощью доп. механизма — списка.
Почему "с помощью"? В Схеме — функция — это и есть список. Это не мешает функциям Схемы быть первоклассными, точно также как и то, что функции в Ницце являются объектами не мешает функциям быть первоклассными. Скорее это необходимо как раз для того, чтобы они были первоклассными.
V>В этом плане приведение ф-ий к делегатам в D кажется куда как более ближе к понятию первоклассности.
Проблема как раз в приведении. Но с первоклассностью делегатов я никогда и не спорил.
V>Если рассматривать языки ради языков, забыв, что это, в первую очередь — инструмент, то можно слишком на многое закрывать глаза. Мне же всё время хочется называть вещи своими именами, например, раскрутку рекурсии в языках, где это единственный способ организации цикла — условием существования языка в качестве применимого инструмента.
Безотносительно к тому является ли язык инструментом (а с моей точки зрения язык инструментом является) это все равно деталь реализации. Кроме того, для языков, в которых есть другие способы реализации цикла раскрутка хвостовой рекурсии "условием существования" (правильнее — условием существования реализации) не является.
K>>Но теория раскрутки хвостовой рекурсии была выработана Хьюиттом в 1977 году. Все языки которые появились до этого счастливого момента были нефункциональными? V>Они были малоприменимыми в качестве инструмента.
Если есть набор стандартных комбинаторов вроде map и fold (как они реализованы внутри — неважно) гарантированная раскрутка хвостовой рекурсии теряет решающее значение.
V>Лисп — второй, после Фортрана ЯВУ в истории IT, а на практике применялся на несколько порядков меньше, оставаясь обучающим и исследовательским языком. Случайно ли?
Не думаю, что тут все дело в раскрутке хвостовой рекурсии. Но это разговор отдельный.
K>>Вот видите, вы же сами понимаете, что "возможность ленивости" есть во всех языках с первоклассными функциями, какой смысл в таком случае рассматривать эту характеристику отдельно? V>Я, наверно, недостаточно раскрыл понятие "встроенной" ленивости. Я подразумевал "прозрачное" построение структурированных данных как цепочек ленивых вызовов.
Чтобы сэкономить время сразу говорю, что вы недостаточно раскрыли понятие "прозрачности" и т.д.
V>И всё-таки, тот же Лисп и Схема не имет ф-ий как первоклассных отдельный сущностей,
Думаю, что Схема — имеет.
V>а паттерн-матчинг (или нечно похожее по сути) там может быть сделан в виде пользовательских ф-ий, ввиду однородности представления данных,
А зачем? Благодаря однородности представления данных он там и не нужен.
V>Так что, если уж минимизировать, то я бы оставил только одно минимальное требование — конструирование сущностей, аналогичным ф-иям, в процессе работы программы.
Это необходимо, но недостаточно — эти "аналогичные функциям сущности" нужно еще и передавать в другие "аналогичные функциям сущности" и возвращать из них.
... << RSDN@Home 1.2.0 alpha 3 rev. 880>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, vdimas, Вы писали:
V>Это игра терминов. То, что в D называется делегатом, во многих ФЯ называется функцией. Просто напомню, что для нас (программистов) ЯП — лишь инструмент, и в этом смысле делегаты в D и ф-ии в ФЯ — это абсолютно один и тот же инструмент, хоть и называется по-разному в рамках разных языков.
Тем не менее, то, что в D называется функцией — первоклассным объектом не является. А то, что называется делегатом — является.
K>>В Nice никакие делегаты не нужны — как раз потому, что функции — первоклассные. V>Потому что других типов ф-ий нет, лишь те, что аналоги делегатов.
Вообще говоря, функции Nice не аналоги делегатов D потому, что функцию в Nice можно определить и на этапе компиляции, а делегат D только создать в рантайме. Но, по здравому размышлению это решающим при определении функциональности языка D не является.
В D есть четыре разновидности "аналогичных функциям сущностей" — два вида функций (статические+свободные и экземплярные методы) и два вида делегатов. Оба вида делегатов — первоклассные объекты.
Принимая во внимание, что "аналогичные функциям" первоклассные сущности в D есть (хотя то, что в D называется функцией — это не первоклассные сущности) можно считать, что современный D соответсвует моему определению функционального языка.
Спасибо за дельное замечание.
... << RSDN@Home 1.2.0 alpha 3 rev. 880>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
