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

DIzer

  • Гость
Re:Функции против процедур
« Ответ #15 : Февраль 28, 2011, 08:57:54 am »
2. Пусть Вы вводите это разделение просто для того, чтобы разделить "Чистые" и "Грязные" действия- насколько предложенная Вами форма адекватна цели... и вообще насколько это реализуемо на практике в компилляторах (т.е. проверка чистоты на низком уровне для проекта произвольной сложности). всегда ли она возможна?
Однако трансляторы Хаскелла показывают, что это вполне возможно и реализуемо.
Я говорю про проекты ПОЛНОСТЬЮ реализованные на ЯП. Есть ли примеры создания на хаскеле очень сложных систем (БД, ОС) - без сторонних костылей (модулей написанных ДЛЯ ЭТОЙ задачи но на сторонних языках)? Пример,  Вирт показал, что с помощью Оберона МОЖНО построить ОС.

DIzer

  • Гость
Re:Функции против процедур
« Ответ #16 : Февраль 28, 2011, 09:08:34 am »
Эта проверка вообще делается не на уровне компилятора, а посредством системы типов. Система типов естественно нужна сильнее нежели в обероне, или даже Аде. Ну и естественно побочные эффекты должны быть возможны только через стандартную библиотеку (где уже все это типизировано как надо).


Что вы имеете ввиду- RTTI? Но тип то всего лишь схема по которой создается реальный обьект (или связывается внешний обьект) у нас не меняется... меняется под воздействием факторов (обычно внешних по программе) сам обьект.

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re:Функции против процедур
« Ответ #17 : Февраль 28, 2011, 09:22:22 am »
Есть ли примеры создания на хаскеле очень сложных систем (БД, ОС) - без сторонних костылей (модулей написанных ДЛЯ ЭТОЙ задачи но на сторонних языках)? Пример,  Вирт показал, что с помощью Оберона МОЖНО построить ОС.
Очень сложные системы не делаются только на одном языке.
Виртовскую систему вряд ли можно назвать очень сложной системой, и то без вставок машинного кода даже Вирт в Обероне не обошёлся. Это не костыль разве?

На Хаскелле тоже делали операционки, House, например. http://en.wikipedia.org/wiki/House_(operating_system)
http://ogi.altocumulus.org/~hallgren/ICFP2005/
Исходников не видел, так что не могу сказать, что там кроме Хаскелла использовалось.

Был ещё пример, но щас так не попадается на глаза. Там микроядро ОС было написано на Хаскелле, но бут-загрузчик на ассемблере.
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Функции против процедур
« Ответ #18 : Февраль 28, 2011, 09:24:31 am »
2. Пусть Вы вводите это разделение просто для того, чтобы разделить "Чистые" и "Грязные" действия- насколько предложенная Вами форма адекватна цели... и вообще насколько это реализуемо на практике в компилляторах (т.е. проверка чистоты на низком уровне для проекта произвольной сложности). всегда ли она возможна?
Однако трансляторы Хаскелла показывают, что это вполне возможно и реализуемо.
Я говорю про проекты ПОЛНОСТЬЮ реализованные на ЯП. Есть ли примеры создания на хаскеле очень сложных систем (БД, ОС) - без сторонних костылей (модулей написанных ДЛЯ ЭТОЙ задачи но на сторонних языках)? Пример,  Вирт показал, что с помощью Оберона МОЖНО построить ОС.
Да. См. например http://en.wikipedia.org/wiki/House_(operating_system)
Есть распределенная система контроля версий Darcs. Есть веб-фреймворки и так далее.
Софта на хаскеле писано больше чем на обероне, и он реально используется.

Кстати, Оберон-система была не полностью на Обероне – там был и асм тоже.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Функции против процедур
« Ответ #19 : Февраль 28, 2011, 09:26:02 am »
Что вы имеете ввиду- RTTI? Но тип то всего лишь схема по которой создается реальный обьект (или связывается внешний обьект) у нас не меняется... меняется под воздействием факторов (обычно внешних по программе) сам обьект.
Нет. RTTI тут никаким боком (ибо RTTI это не система типов, а всего лишь информация о типах в рантайме).
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

DIzer

  • Гость
Re:Функции против процедур
« Ответ #20 : Февраль 28, 2011, 09:28:27 am »
Что вы имеете ввиду- RTTI? Но тип то всего лишь схема по которой создается реальный обьект (или связывается внешний обьект) у нас не меняется... меняется под воздействием факторов (обычно внешних по программе) сам обьект.
Нет. RTTI тут никаким боком (ибо RTTI это не система типов, а всего лишь информация о типах в рантайме).
Тогда что ? (я говорил про использование этой информации).

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Функции против процедур
« Ответ #21 : Февраль 28, 2011, 09:31:54 am »
Все проверки на этапе компиляции. При чем тут rtti?
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

DIzer

  • Гость
Re:Функции против процедур
« Ответ #22 : Февраль 28, 2011, 09:37:55 am »

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

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re:Функции против процедур
« Ответ #23 : Февраль 28, 2011, 10:04:35 am »
Ну, собственно, в Хаскелле контроль за побочными эффектами возложен именно на систему типов, с минимальной поддержкой со стороны компилятора: компилятор позволяет создать грязное значение, но не позволяет вытащить из него данные в чистый мир (что в IO попало, то там и пропало).
Ну а для тех, кто уж совсем не может без того, что бы не выстрелить себе в ногу из верёвки, всё-таки предусмотрели функцию unsafePerformIO, нарушающую эту защиту.
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Функции против процедур
« Ответ #24 : Февраль 28, 2011, 10:09:20 am »
Алексей я прицепился к этой части фразы... - не понял о чем идет речь-и сделал предположение что оно может гипотетчески означать.. давайте не будем уподобляться Илье.. если хотим что бы обсуждение имело хоть какой то  смысл...
Конечно. Если вдруг опять начну уподобляться, бейте меня по носу.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

valexey

  • Administrator
  • Hero Member
  • *****
  • Сообщений: 1990
    • Просмотр профиля
Re:Функции против процедур
« Ответ #25 : Февраль 28, 2011, 10:29:10 am »
Разъясню для тех кто хаскелл в глаза не видел как оно там устроено (надеюсь знающие меня поправят, наверняка я где-то ошибусь):

В хаскеле по умолчанию нет побочных эффектов. Т.e. совсем нет. Все не изменно и так далее. Однако, очевидно что так жить нельзя :-) Поэтому в стандартной библиотеке есть множество функций позволяющих создавать изменяемые значения и менять их, лазить по памяти и что-то там ещё. Соответственно правило – из такой функции можно вызвать чистую функцию, из чистой функции вызвать такую функцию нельзя.

Теперь о том, как это правило реализуется: в хаскеле система типов, грубо говоря позволяет вешать тип на тип. То есть например функция у нас возвращает тип "A", мы можем написать функцию которая будет возвращать тип "B A". Причем если конструкторы типа B не экспортируются в модуле где определен B, то у тебя нет никакой возможности из значения типа "B A" получить нечто типа "A". При этом модуль где вводится тип B может иметь функцию преобразующая значение любого типа A (C,D,E… без разницы), в значение типа "B A".

Тип функций через которые возможны побочные эффекты имеют тип IO, конструкторы этого типа программисту не доступны. В хаскеле нет по сути statement'ов, соответственно там есть только выражения. Т.e. вызвать функцию с побочным эффектом и проигнорировать её тип не выйдет, её тип будет влиять на тип функции её вызвавшую. (всем очевидно, что в выражении a+b+c+d*z – типы переменных влияют на результат). Соответственно функция вызвавшая функцию с типом "IO что-то-там" также становится функцией типа "IO что-то-там' ".

Вот и всё. И никакой черной магии и поддержки со стороны компилятора конкретно этого. Просто система типов + отсутствие побочных эффектов в ЯЗЫКЕ (они в стандартной либе). Ну а автоматический вывод типов делает все это юзабельным (иначе потонули бы в ручной декларации типов). А монадный синтаксис делает это еще и читабельным.

Механизм общий, через него можно очень многое делать. Собственно управление побочными эффектами (IO) лишь малая толика того, что делают посредством этой системы типов.
"но сейчас, чтобы компенсировать растущую мощность компьютеров, программисты используют фреймворки"

Geniepro

  • Hero Member
  • *****
  • Сообщений: 1955
  • Знайте- истина в том, что повторено трижды подряд!
    • Просмотр профиля
Re:Функции против процедур
« Ответ #26 : Февраль 28, 2011, 10:39:42 am »
Остаётся только добавить, что нет каких-то принципиальных ограничений на размеры систем, которые можно создать, используя такую систему типов.
Где-то может быть больше кода в области IO, где-то меньше. Это уже зависит от задачи и программистов-архитекторов...
to iterate is human, to recurse, divine

Салат «рекурсия»: помидоры, огурцы, салат…

DIzer

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

Очень сложные системы не делаются только на одном языке.
Виртовскую систему вряд ли можно назвать очень сложной системой, и то без вставок машинного кода даже Вирт в Обероне не обошёлся. Это не костыль разве?

На Хаскелле тоже делали операционки, House, например. http://en.wikipedia.org/wiki/House_(operating_system)
http://ogi.altocumulus.org/~hallgren/ICFP2005/
Исходников не видел, так что не могу сказать, что там кроме Хаскелла использовалось.

Был ещё пример, но щас так не попадается на глаза. Там микроядро ОС было написано на Хаскелле, но бут-загрузчик на ассемблере.
Зависит от того что реализовано на нем  (стороннем языке)-если элементарные операции по взаимодействию с железом - то (на мой  взглят это приемлемо). Если диспетчер управления ресурсами - нет.

DIzer

  • Гость
Re:Функции против процедур
« Ответ #28 : Февраль 28, 2011, 01:21:13 pm »
Ну, собственно, в Хаскелле контроль за побочными эффектами возложен именно на систему типов, с минимальной поддержкой со стороны компилятора: компилятор позволяет создать грязное значение, но не позволяет вытащить из него данные в чистый мир (что в IO попало, то там и пропало).
Ну а для тех, кто уж совсем не может без того, что бы не выстрелить себе в ногу из верёвки, всё-таки предусмотрели функцию unsafePerformIO, нарушающую эту защиту.
Причем тут Хаскелль -это судя по вашему описанию  менеджер типов, что то на подобие  менеджера кучи - кусок исполняемого  кода который шлепается автоматически к программе. Вопрос - Решает введение его проблему или нет?

vlad

  • Hero Member
  • *****
  • Сообщений: 1391
    • Просмотр профиля
Re:Функции против процедур
« Ответ #29 : Февраль 28, 2011, 01:22:23 pm »
И чего полезного такие функции могут посчитать?
Вторичные данные. То есть те данные, которыми мы не располагали до вызова функции.
Вопросики какие-то детские пошли  :D

Вопросик немного шире :) Данные в немаленьких системах не лежат настолько открыто, чтобы функции могли "прочитать" все что нужно. Данные инкапсулированы и скрыты за абстракциями. Т.е., разделение на процедуры/функции должно распространятся и на методы (связанные процедуры/функции). Такое уже есть в C++ (const методы), поэтому я хорошо представляю, что это такое. Вы не можете заранее (в абстрактном интерфейсе) определить будет ли метод функцией (const), потому что вы ничего не можете предполагать о реализации этого метода. В С++ эта проблема нивелируется наличием явного приведения к не-const и наличием mutable-данных. Поэтому в С++ наличие const у методов носит сугубо логический характер. Помечая метод const вы позволяете его вызов для const объекта. Не более того. Т.е., вызывая const метод вы не имеете никакой гарантий, что не будет сайд эффектов.
Следствие же вашего предложение будет таким, что функции вообще ничего полезного выдать не смогут и расширяться тоже не будут. Ну факториал посчитают, да. Массив переколбасят по какому-то жесткому алгоритму (без использования абстракций). А вот в лог уже не запишут. Зачем такая штука (в таком ограниченном виде) в языке - не представляю.