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

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

K>>>Детали реализации, на мой взгляд, — это детали реализации вне зависимости от того, существует одна реализация, две, или вообще ни одной.
E>>Если вообще нет ни одной реализации, то речь не может идти о языке программирования. Максимум -- о проекте языка.

K>C моей точки зрения, которая, насколько я знаю, не слишком отличается от общепринятой, язык программирования — это набор синтаксических и семантических правил. Наличие компилятора не обязательно.

Это как в науке -- теория должна подтверждаться практикой. Язык без реализации -- это теория. В данном конкретном случае теория мне не интересна.

E>>Только вот эта деталь показывает, что функции в Nice не копируются.

K>А это, как раз, не деталь реализации. Это семантика функциональных типов. Они в Nice — ссылочные.

Следовательно, конструкция:

f = () => { println( "Hello!" ); }

определяет f как ссылку на функцию. И в плане практического использования f не сильно-то отличается от делегатов в D и агентов в Eiffel.

E>>Программист от этого вряд ли сильно страдает, ведь в Eiffel он все равно может делать то же самое, что и в Nice.

K>Еще раз. Мы говорим не о каких-то гипотетических страданиях программистов на Eiffel, стонущих под гнетом отсутствия первоклассных функций в этом языке. Мы решаем проблему классификации и демаркации.

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

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

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

K>>>Странно. Если функцию все равно можно передать только по ссылке, зачем это указывать явным образом? Ситуация с объектами гораздо логичнее.
E>>Что явным образом указывать?

K>Явно указывать взятие ссылки на функцию.

Еще раз: чтобы явно различить вызов функции от получения ссылки на функцию.

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

VE>Кстати, с этой стороны тоже надо посмотреть на вопрос.

VE>eao197, Klapaucius, если взять язык типа C#, но без struct. Т.е. все пользовательские объекты будут иметь ссылочную семантику. Вопрос: объекты будут первоклассными сущностями? Передать их в функцию нельзя (только ссылку), вернуть нельзя (только ссылку), но можно создавать и удалять.
VE>Теперь возьмем работу с функцией как в C++, т.е. не обязательно указывать &foo, можно просто foo, и для вызова аналогично. Понятно, что это сахар, да еще, ЕМНИП, не стандартный, хотя тут не копался, не столь важный вопрос. Но все же — функции в данном случае первоклассны или нет?
VE>Если объекты в приведенном псевдо-C# не первоклассны, то вопросов нет.
VE>Если объекты первоклассны, а функции в Си++ — нет, тогда почему? Что еще нужно, создание и удаление?

VE>Хотелось бы услышать мнение обоих, спасибо

Извините, вряд ли я смогу дать вам интересный ответ, поскольку я не силен в теории и само понятие "первоклассный" для меня является не очень понятным. По мне, первоклассное -- это то, что поддерживается средствами языка. Например делегат в D -- это первоклассная сущность, которая связывает функцию/метод с неким контекстом. А вот в C++ делегат, в принципе, может быть создан через указатель на функцию + функтор, но это уже будет не первоклассная сущность, т.к. ее приходится создавать самому программисту.

Мне кажется, что в языках с сылочными типами объекты -- первоклассны. А вот ссылки на объекты -- нет. Здесь получается некий нонсенс для человека с C-ным прошлым: переменная ссылочного типа -- это ссылка, но сделать что-нибудь с самой переменной (например, взять указатель и заменить значение переменной через указатель) практически ничего нельзя. Хотя и есть один очень важный момент -- ссылку, в отличии от объекта, можно занулить. Т.е. объект либо есть, либо нет, объект не может быть null-ом. А вот переменная-ссылка может быть null-ом.

Ситуация с функциями чуть сложнее, чем с объектами. Ведь в рассматривавшихся здесь языках (C#, Java, Nice, Eiffel, D, C/C++) заменить тело функции невозможно. Так же, как и скопировать тело функции в другое место. Поскольку функция -- это скомпилированный в некое машинное представление код. Следовательно, все, что может предоставить язык программисту в этом случае -- это взятие ссылки на функцию. И здесь возникает вопрос -- что из себя будет представлять ссылка на функцию -- некую прозрачную и несамостоятельную сущность, как ссылка на объект (в языках типа C#, Java, D), или же самостоятельную сущность с собственным типом (как указатель на функцию в C/C++, делегат в D или агент в Eiffel). Различия здесь могут быть достаточно серьезными -- например, в D можно взять указатель переменной-делегата и изменить эту переменную через указатель.

Языки D и Eiffel демонстрируют, что в языках с ссылочными типами для ссылки на функцию уровень косвенности получается достаточно большим: есть функция (код), есть некий дескриптор (делегат, агент) и есть ссылка на этот дескриптор. И, что важно, программист видит всю эту косвенность.

В Nice доступ к функции выполняется точно так же: есть функция (код), есть некий дескриптор и есть ссылка на этот дескриптор. Но данная косвенность не так очевидна, хотя и программист все равно ее видит (например, метод getClass() относится не к функции, а к дескриптору).

При этом в языках D, Eiffel и Nice есть встроенные в язык средства для работы с функциями (делегаты в D, агенты в Eiffel, функциональные типы в Nice). Т.е. для того, чтобы получить ссылку на функцию, программисту не нужно писать собственный код (как в случае с функторами в C++), достаточно просто воспользоваться языковыми конструкциями.

Следовательно, вопрос сводится к тому, являются ли средства Nice более "правильными" по сравнению со средствами D/Eiffel. И здесь всплывают такие различия как то, что в D и Nice дескрипторы функций видны пользователю, что ссылку на функцию нужно получать явно, что вызов идет как-то не так. Но, на мой взгляд, это не является определяющим фактором, поскольку программист все равно имеет в своем распоряжении одинаковые по мощности средства. HOF типа map или fold можно реализовать на каждом из этих языков. Причем, отличия будут разве что на уровне синтаксиса, но не смысла происходящего.

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

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

По мне, так для того, чтобы быть функциональным, языку нужно позволять программисту писать в функциональном стиле. А здесь оказывается, что ни D, ни Eiffel, ни Nice не являются конкурентами таких общепризнаных функциональных языков, как OCaml или Erlang. А здесь ведущую роль играют уже не столько функции, сколько иммутабельность данных и возможности выражения циклов через рекурсию. Да и паттерн-матчинг не на последнем месте.

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

E>Извините, вряд ли я смогу дать вам интересный ответ, поскольку я не силен в теории и само понятие "первоклассный" для меня является не очень понятным. По мне, первоклассное -- это то, что поддерживается средствами языка.

Первоклассный — это не то, что поддерживается средствами языка, а то, что может быть использовано, например в выражениях как атом. Т.е. никаких дополнительных ограничений на сущность не накладывается.

Например, в Ява нельзя взять метод и передать как параметр. Хотя методы средствами языка поддерживаются.

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

VE>если взять язык типа C#, но без struct. Т.е. все пользовательские объекты будут иметь ссылочную семантику. Вопрос: объекты будут первоклассными сущностями? Передать их в функцию нельзя (только ссылку), вернуть нельзя (только ссылку), но можно создавать и удалять.

Будут, ведь ссылки как отдельной сущности не существует — есть ссылочные типы.

VE>Теперь возьмем работу с функцией как в C++, т.е. не обязательно указывать &foo, можно просто foo, и для вызова аналогично. Понятно, что это сахар, да еще, ЕМНИП, не стандартный, хотя тут не копался, не столь важный вопрос. Но все же — функции в данном случае первоклассны или нет?

Нет, но по другой причине.

VE>Если объекты первоклассны, а функции в Си++ — нет, тогда почему? Что еще нужно, создание и удаление?

Да, создание экземпляра функционального типа в рантайме.

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

K>>C моей точки зрения, которая, насколько я знаю, не слишком отличается от общепринятой, язык программирования — это набор синтаксических и семантических правил. Наличие компилятора не обязательно.
E>Это как в науке -- теория должна подтверждаться практикой. Язык без реализации -- это теория. В данном конкретном случае теория мне не интересна.

Язык — это не "теория".
Теория это некие нетривиальные предположения, которые могут быть опровергнуты эспериментом. Язык сам по себе не содержит никаких нетривиальных фальсифицируемых предположений — поэтому теорией не является. Язык это средство выражения абстракций или инструмент коммуникации.
Язык программирования это язык, который может быть использован для написания программ и коммуникации программистов.
Любой псевдокод — язык программирования, с его помощью программист A может донести идею для программиста B. Или даже программист A(t1) может записать на этом псевдокоде идею, а позже восстановить ее в памяти, будучи программистом A(t2). Программа транслятор (и кол-во программ-трансляторов) с одного искуственного языка на другой никакого отношения к определению языка не имеет.

K>>А это, как раз, не деталь реализации. Это семантика функциональных типов. Они в Nice — ссылочные.
E>Следовательно, конструкция:
E>

E>f = () => { println( "Hello!" ); }
E>

E>определяет f как ссылку на функцию.

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

E>И в плане практического использования f не сильно-то отличается от делегатов в D и агентов в Eiffel.

Совершенно верно.

K>>Еще раз. Мы говорим не о каких-то гипотетических страданиях программистов на Eiffel, стонущих под гнетом отсутствия первоклассных функций в этом языке. Мы решаем проблему классификации и демаркации.
E>Мы решаем? Боюсь, что это не так. Я всего лишь пытаюсь понять, почему из трех языков, предоставляющих программисту одинаковые возможности в практической работе, один вы считаете функциональным, а два других нет.

Выделенное курсивом и означает, что вы пытаетесь решить проблему классификации и демаркации. Понятно?

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

K>>Явно указывать взятие ссылки на функцию.
E>Еще раз: чтобы явно различить вызов функции от получения ссылки на функцию.

А зачем это явно различать?
И если это так важно, почему вызов функции через делегат и возвращение делегата явно не различатся?
Или обернуть функцию без аргументов в делегат нельзя?

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

K>Теория это некие нетривиальные предположения, которые могут быть опровергнуты эспериментом. Язык сам по себе не содержит никаких нетривиальных фальсифицируемых предположений — поэтому теорией не является. Язык это средство выражения абстракций или инструмент коммуникации.
K>Язык программирования это язык, который может быть использован для написания программ и коммуникации программистов.
K>Любой псевдокод — язык программирования, с его помощью программист A может донести идею для программиста B. Или даже программист A(t1) может записать на этом псевдокоде идею, а позже восстановить ее в памяти, будучи программистом A(t2). Программа транслятор (и кол-во программ-трансляторов) с одного искуственного языка на другой никакого отношения к определению языка не имеет.

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

K>Определение "ссылка на функцию" в данном случае может ввести в заблуждение из-за ошибочных аналогий с ссылкой на функцию в C, например.

В C/C++ нет ссылки на функцию, есть указатели. А указатели и ссылки в C++ это разные вещи. Например, ссылку на int можно рассматривать как очень-очень прозрачный прокси к экземпляру int. И все операции над ссылкой будут прозрачным образом адресоваться к экземпляру. Например:

int a = 0, int b = 1;
int & ra = a;
int & rb = b;

ra = rb * 2; // В точности то же самое, что и a = b * 2;

Соответственно для объектов:

class functor_t {
  public: void operator() { ... }
};
functor_t a;
functor_t & ra = a;

ra(); // В точности то же самое, что и a().

Поэтому я и употребил термин "ссылка на функцию", т.к. это практически в точности соответствует ссылкам на объекты в C++.

E>>Мы решаем? Боюсь, что это не так. Я всего лишь пытаюсь понять, почему из трех языков, предоставляющих программисту одинаковые возможности в практической работе, один вы считаете функциональным, а два других нет.

K>Выделенное курсивом и означает, что вы пытаетесь решить проблему классификации и демаркации. Понятно?

Я не пытаюсь ее решить. Я пытаюсь понять, почему вы решили ее именно так.

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

K>>>Явно указывать взятие ссылки на функцию.
E>>Еще раз: чтобы явно различить вызов функции от получения ссылки на функцию.

K>А зачем это явно различать?

ИМХО, для повышения читабельности программы. Чтобы без дополнительных инструментов было видно, что к чему.

K>И если это так важно, почему вызов функции через делегат и возвращение делегата явно не различатся?

Вообще-то различается. Так, если есть:

int delegate() r = ...;
return r;

то здесь возвращается экземпляр делегата. А если написать так:

int delegate() r = ...;
return r();

то возвращается результат вызова делегата.

Почему сделано именно так -- не знаю. Возможно для того, чтобы избежать неоднозначности в подобных случаях: означает ли r само значение делегата или же результат вызова делегата.

K>Или обернуть функцию без аргументов в делегат нельзя?

Можно.

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

E>

E>int delegate() r = ...;
E>return r;
E>

E>то здесь возвращается экземпляр делегата. А если написать так:
E>

E>int delegate() r = ...;
E>return r();
E>

E>то возвращается результат вызова делегата.
E>Почему сделано именно так -- не знаю. Возможно для того, чтобы избежать неоднозначности в подобных случаях: означает ли r само значение делегата или же результат вызова делегата.

А для вызова функции без аргументов () — не используется, или это я с Eiffel путаю?

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

E>>

E>>int delegate() r = ...;
E>>return r;
E>>

E>>то здесь возвращается экземпляр делегата. А если написать так:
E>>

E>>int delegate() r = ...;
E>>return r();
E>>

E>>то возвращается результат вызова делегата.
E>>Почему сделано именно так -- не знаю. Возможно для того, чтобы избежать неоднозначности в подобных случаях: означает ли r само значение делегата или же результат вызова делегата.

K>А для вызова функции без аргументов () — не используется, или это я с Eiffel путаю?

И там, и там функция без аргументов может вызываться без скобочек.

Но ситуация в D похожа на аналогичную в Nice -- запись r в Nice обозначает саму функцию, а не ее вызов:

int endln() { println(""); return 0; }

void main( String[] args )
    {
        let r = endln;
        println( r.getClass.getName );
    }

и

int endln() { println(""); return 0; }

void main( String[] args )
    {
        let r = endln();
        println( r.getClass.getName );
    }

Приводят к совершенно разным результатам.

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

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

Этим "реальный" от "вымышленного" (хотя, конечно, все языки вымышленные) врятли отличается. Ошибки, которых не ждали могут быть в коде и на том и на другом.

K>>Определение "ссылка на функцию" в данном случае может ввести в заблуждение из-за ошибочных аналогий с ссылкой на функцию в C, например.
E>В C/C++ нет ссылки на функцию, есть указатели.

Действительно, какая-то у меня неправильная ассоциация.

E>Поэтому я и употребил термин "ссылка на функцию", т.к. это практически в точности соответствует ссылкам на объекты в C++.

По моему, аналогия со ссылкой a la C++ не лучше, чем аналогия с указателем на функцию.

K>>Выделенное курсивом и означает, что вы пытаетесь решить проблему классификации и демаркации. Понятно?
E>Я не пытаюсь ее решить. Я пытаюсь понять, почему вы решили ее именно так.

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

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

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

У меня нет проблемы классификации. Скорее у меня были трудности с пониманием вашей системы классификации языков. Ведь для проведения классификации нужно выбрать некую систему, относительно которой эта классификация будет производиться. И, очевидно, у нас эти системы слишком сильно различаются.

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

E>Но ситуация в D похожа на аналогичную в Nice -- запись r в Nice обозначает саму функцию, а не ее вызов

Это понятно.
Непонятно почему в D для функций неопределенность разрешается явным указанием foo и &foo, а для делегатов foo() и foo соответственно.
Это должно упрощать чтение? пока я никакого упрощения не вижу. Напротив, строгий вариант определения fco представляется мне все более и более обоснованным. Я даже начинаю усматривать связь с практикой. Функции в Nice достаточно понятны (для меня, во всяком случае), а незначительный опыт программирования на функциональных языках приходит на помощь в трудной ситуации. В то же время, странная двойная классификация функций и делегатов в D, требующая каких-то поясняющих указаний то так — то эдак для меня совершенно контринтуитивна
и не облегчает ни чтения, ни описания.
Я, конечно понимаю: все это субъективно и тем, на кого ориентирован D серьезно облегчает чтение, но должен с сожалением констатировать, что я не из их числа.

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

E>У меня нет проблемы классификации.

Рад за вас, но все еще не понимаю, почему вы не формулируете свое определение.

E>Скорее у меня были трудности с пониманием вашей системы классификации языков.

Что не перестает меня удивлять. Определение fco Кристофера Стрейчи широко известно и легко доступно. Насколько я помню, оно упоминалось в одной из первых глав SICP. Оно и в Википедии совершенно точно есть.
Помимо знания этого определения требуется только умение отделить синтаксис и семантику языка от деталей конкретной реализации, что, вообще говоря, не должно вызывать сложностей у программиста.

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

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

E>>Но ситуация в D похожа на аналогичную в Nice -- запись r в Nice обозначает саму функцию, а не ее вызов

K>Это понятно.
K>Непонятно почему в D для функций неопределенность разрешается явным указанием foo и &foo, а для делегатов foo() и foo соответственно.

Потому, что &foo для делегата будет означать указатель на делегата. Ведь делегат -- это первоклассный объект. А значит для него можно получить указаль в D, так же, как для объекта, экземпляра типа int и т.д.

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

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

E>>У меня нет проблемы классификации.

K>Рад за вас, но все еще не понимаю, почему вы не формулируете свое определение.

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

Свой критерий я уже давно высказал, он был мной позаимствован у Страуструпа: язык можно считать поддерживающим некую парадигму, если он позволяет писать с использованием этой парадигмы без особых усилий. Да, критерий настолько же субъективный, как и критерии оценки "полноты" людей. Но я и не ставил перед собой задачи создания периодической системы языков и занесения языка Nice в одну из ее ячеек.

E>>Скорее у меня были трудности с пониманием вашей системы классификации языков.

K>Что не перестает меня удивлять. Определение fco Кристофера Стрейчи широко известно и легко доступно. Насколько я помню, оно упоминалось в одной из первых глав SICP. Оно и в Википедии совершенно точно есть.
K>Помимо знания этого определения требуется только умение отделить синтаксис и семантику языка от деталей конкретной реализации, что, вообще говоря, не должно вызывать сложностей у программиста.

У каждого свои недостатки.

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

E>В C/C++ нет ссылки на функцию, есть указатели.

#include <iostream>

int f(int x) { return x + 1; }

int main()
{
  int (&my)(int) = f;
  std::cout << my(5);
}

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

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

E>>В C/C++ нет ссылки на функцию, есть указатели.


VE>

VE>#include <iostream>

VE>int f(int x) { return x + 1; }

VE>int main()
VE>{
VE>  int (&my)(int) = f;
VE>  std::cout << my(5);
VE>}
VE>

VE>

Ахринеть!

Но в С-то точно нет ссылки на функцию

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

K>>Непонятно почему в D для функций неопределенность разрешается явным указанием foo и &foo, а для делегатов foo() и foo соответственно.
E>Потому, что &foo для делегата будет означать указатель на делегата. Ведь делегат -- это первоклассный объект. А значит для него можно получить указаль в D, так же, как для объекта, экземпляра типа int и т.д.

C делегатом все ясно. Непонятно почему для функции нельзя сделать foo() и foo. Вообще неудобно, что функция непосредственно используется иначе, чем через делегат — т.е. одинаковые семантически вещи выглядят в коде различно, а разные вроде указателя и делегата похоже.
Впрочем, обсуждать дизайн D мне не особенно интересно.