Автор Тема: Функции против процедур  (Прочитано 84130 раз)

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Функции против процедур
« Ответ #30 : Февраль 28, 2011, 01:31:15 pm »
Причем тут Хаскелль -это судя по вашему описанию  менеджер типов, что то на подобие  менеджера кучи - кусок исполняемого  кода который шлепается автоматически к программе. Вопрос - Решает введение его проблему или нет?
У Хаскеля статическая типизация. При статической типизации соответствие типов проверяются на этапе компиляции. Контроль побочных эффектов в хаскеле сведен к проверке типов так как описал я. Гм… Что-нибудь не ясно?
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

DIzer

  • Гость
Re:Функции против процедур
« Ответ #31 : Февраль 28, 2011, 02:13:24 pm »
Причем тут Хаскелль -это судя по вашему описанию  менеджер типов, что то на подобие  менеджера кучи - кусок исполняемого  кода который шлепается автоматически к программе. Вопрос - Решает введение его проблему или нет?
У Хаскеля статическая типизация. При статической типизации соответствие типов проверяются на этапе компиляции. Контроль побочных эффектов в хаскеле сведен к проверке типов так как описал я. Гм… Что-нибудь не ясно?
Ладно, господа давайте , подождем реакции Игоря-мне лично не очень понятно что он имел ввиду...  на эту мысль наводят его определения....функций и процедур. В этой каше боюсь что мы просто будем не понимать друг друга. а когда договоримся окажется, что Игорем имелось ввиду нечто другое...
Предлагаю обменяться мнениями по сообщению Vlada.

DIzer

  • Гость
Re:Функции против процедур
« Ответ #32 : Февраль 28, 2011, 02:29:23 pm »

По поводу пункта 1 у меня никаких возражений нет - да, хочется контролировать побочные эффекты. И такое разделение иметь полезно, пока мы имеем некий компромиссный ЯП (не хаскель ;)
По поводу пункта 2 - вообще непонятно зачем такое ограничение. Пусть возвращает нормальный результат. Зачем кому-то нужны OUT-параметры?
По поводу 1. Тоже как не  странно   :) Как я понял речь идет именно о разделении чистый -грязный (об устранении побочного эффекта речь не идет). Но зачем Ф и П  -может хватит модификатора PURE в заголовке? Это по внешнему виду. Возникает вопрос как обеспечить это ?
По поводу 2. Cогласен.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Функции против процедур
« Ответ #33 : Февраль 28, 2011, 02:39:01 pm »
По поводу 1. Тоже как не  странно   :) Как я понял речь идет именно о разделении чистый -грязный (об устранении побочного эффекта речь не идет). Но зачем Ф и П  -может хватит модификатора PURE в заголовке? Это по внешнему виду. Возникает вопрос как обеспечить это ?
Посмотрите как это сделано в D :  http://verypositive.com/files/d2.pdf
В статье найдите раздел "Функциональное программирование".
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

DIzer

  • Гость
Re:Функции против процедур
« Ответ #34 : Февраль 28, 2011, 03:03:36 pm »
По поводу 1. Тоже как не  странно   :) Как я понял речь идет именно о разделении чистый -грязный (об устранении побочного эффекта речь не идет). Но зачем Ф и П  -может хватит модификатора PURE в заголовке? Это по внешнему виду. Возникает вопрос как обеспечить это ?
Посмотрите как это сделано в D :  http://verypositive.com/files/d2.pdf
В статье найдите раздел "Функциональное программирование".
Vlad- Вы про это говорили? В этой статье речь идет о формальном контороле на этапе компиляции отсутствия в тексте реализации глобальных сущностей (не передаваемых через интерфейс), Если используются внешние функции внутри реализации то  возможность компиляции кода определяется  сигнатурой вызова этой функции (если она помечена как чистая компиляция идет успешно). Вас такое решение устроит?  :)

DIzer

  • Гость
Re:Функции против процедур
« Ответ #35 : Февраль 28, 2011, 03:33:07 pm »
Вас такое решение устроит?  :)
Простейший гемор - вы определяете набор совершенно чистых функций = которые прекрасно компилируются = но делаете из них DLL - и компилятор перестает считать их таковыми (Хотя они ими ОСТАЛИСЬ)  ;)

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Функции против процедур
« Ответ #36 : Февраль 28, 2011, 03:36:10 pm »
не перестает, если у нас сохранился интерфейс к этим функциям.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

DIzer

  • Гость
Re:Функции против процедур
« Ответ #37 : Февраль 28, 2011, 03:39:28 pm »
не перестает, если у нас сохранился интерфейс к этим функциям.
То есть вы предлагаете реализовать это в виде скрытого параметра?

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Функции против процедур
« Ответ #38 : Февраль 28, 2011, 03:45:46 pm »
Vlad- Вы про это говорили? В этой статье речь идет о формальном контороле на этапе компиляции отсутствия в тексте реализации глобальных сущностей (не передаваемых через интерфейс), Если используются внешние функции внутри реализации то  возможность компиляции кода определяется  сигнатурой вызова этой функции (если она помечена как чистая компиляция идет успешно). Вас такое решение устроит?  :)

Устроит, как только я пойму как будет работать такое:
struct X
{
    virtual void do() = 0;
};

void f(X &x) // pure или не pure?
{
    x.do();
}

Еще раз хочу заметить: по моему убеждению мы не можем пометить X::do как pure, потому что мы не знаем заранее - сможет ли ее наследник реализовать как pure.
Почти тоже самое в другой формулировке (без ООП):
void f(F prediacte); // f может быть pure только если F - тоже pure
Что делать, если нам нужно вызвать f, а на руках у нас не-pure predicate?

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Функции против процедур
« Ответ #39 : Февраль 28, 2011, 03:47:59 pm »
не перестает, если у нас сохранился интерфейс к этим функциям.
То есть вы предлагаете реализовать это в виде скрытого параметра?


Я так понимаю - просто в имени DLL-функции будет зашифровано pure она или нет. Как сейчас шифруются типы параметров для С++ функций.

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Функции против процедур
« Ответ #40 : Февраль 28, 2011, 03:54:08 pm »
не перестает, если у нас сохранился интерфейс к этим функциям.
То есть вы предлагаете реализовать это в виде скрытого параметра?
Во-первых в dll хранятся только имена функций, про параметры (скрытые или нет) там ничего нет.
Во-вторых в виде скрытого параметра если передавать, то у нас контроль опять будет в рантайме, а нам нужно по возможности в компайл-тайме.

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

DIzer

  • Гость
Re:Функции против процедур
« Ответ #41 : Февраль 28, 2011, 03:59:03 pm »
Vlad- Вы про это говорили? В этой статье речь идет о формальном контороле на этапе компиляции отсутствия в тексте реализации глобальных сущностей (не передаваемых через интерфейс), Если используются внешние функции внутри реализации то  возможность компиляции кода определяется  сигнатурой вызова этой функции (если она помечена как чистая компиляция идет успешно). Вас такое решение устроит?  :)

Устроит, как только я пойму как будет работать такое:
struct X
{
    virtual void do() = 0;
};

void f(X &x) // pure или не pure?
{
    x.do();
}

Еще раз хочу заметить: по моему убеждению мы не можем пометить X::do как pure, потому что мы не знаем заранее - сможет ли ее наследник реализовать как pure.
Почти тоже самое в другой формулировке (без ООП):
void f(F prediacte); // f может быть pure только если F - тоже pure
Что делать, если нам нужно вызвать f, а на руках у нас не-pure predicate?
1. Не чистая - просто потому что она (Do) обьявлена без модификатора
2.Просто f не обьявлять как чистую

DIzer

  • Гость
Re:Функции против процедур
« Ответ #42 : Февраль 28, 2011, 04:06:23 pm »
То есть полиморфизм плюсовый действительно накрывается медным тазиком- но и без него ведь люди живут  ;)

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Функции против процедур
« Ответ #43 : Февраль 28, 2011, 04:07:05 pm »
Vlad- Вы про это говорили? В этой статье речь идет о формальном контороле на этапе компиляции отсутствия в тексте реализации глобальных сущностей (не передаваемых через интерфейс), Если используются внешние функции внутри реализации то  возможность компиляции кода определяется  сигнатурой вызова этой функции (если она помечена как чистая компиляция идет успешно). Вас такое решение устроит?  :)

Устроит, как только я пойму как будет работать такое:
struct X
{
    virtual void do() = 0;
};

void f(X &x) // pure или не pure?
{
    x.do();
}

Еще раз хочу заметить: по моему убеждению мы не можем пометить X::do как pure, потому что мы не знаем заранее - сможет ли ее наследник реализовать как pure.
Почти тоже самое в другой формулировке (без ООП):
void f(F prediacte); // f может быть pure только если F - тоже pure
Что делать, если нам нужно вызвать f, а на руках у нас не-pure predicate?
1. Не чистая - просто потому что она (Do) обьявлена без модификатора

Если я f() объявлю как pure, то что будет:
1. Не скомпилится (вызов x.do() - не-pure)
2. Ошибка в рантайме, если конкретная реализация x.do является не-pure
Если 1 - то это то, о чем я говорил в самом начале (мало для чего можно использовать такие pure функции).
Если 2 - то мне такое принципиально не нравится

Цитировать
2.Просто f не обьявлять как чистую

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

DIzer

  • Гость
Re:Функции против процедур
« Ответ #44 : Февраль 28, 2011, 04:20:37 pm »

Еще раз хочу заметить: по моему убеждению мы не можем пометить X::do как pure, потому что мы не знаем заранее - сможет ли ее наследник реализовать как pure.

А что нам мешает ТРЕБОВАТЬ  от наследника PURE реализации?