Ответ на »сообщение 2689« (Jack Of Shadows)
___________________________

Ответ на »сообщение 2688« (Jack Of Shadows)
___________________________
А ведь я обшибся :)) Как раз в обероне при смешивании integer и Real произойдет неявное преобразование типов.

Только от целого к вещественному, без потерь.
Простое правило: BYTE <= SHORTINT <= INTEGER <= SHORTREAL <= REAL.
В сторону от меньшему к большему преоборазование автоматическое.
Мне больше нравится подход Ады - вообще без неявных преоборазований.
Однако надо понимать, что здесь просто разные уровни типизации атомарных данных.
В Обероне четко и полностью воплощен уровень математической типизации ("тип данных = множество значений + допустимые операции"), более низкий уровень технической типизации ("тип данных - представление данных в память") полностью скрыт.
В Аде для атомарных данных воплощен следующий уровень типизации - асбтрактный или прикладной ("тип данных = содержательная роль данных в программе"), поддерживается расширение атомарных типов, субтипизация, явное определение того, что с чем совместимо и т.п.
Однако Ада не поддерживает компонентное программирование, и ввести эту поддержку сложно - не только из-за перечислений, а в целом из-за механизма атомарной абстрактной типизации. В Обероне абстрактная типизация и расширение типов воплощено последовательно для записей.
В общем, за все приходится платить, выбирать компромиссы.

Интересно, а какой уровень типизации в Хаскелле? Для атомарных данных и для структур? Где математическая, а где - абстрактная?

Наткнулся только что в Блэкбоксе на модуль Integers и пример его использования для вычисления факториала с произвольной точностью ObxFact...

MODULE ObxFact;
(**
  project  = "BlackBox"
  organization  = "www.oberon.ch"
  contributors  = "Oberon microsystems"
  version  = "System/Rsrc/About"
  copyright  = "System/Rsrc/About"
  license  = "Docu/BB-License"
  changes  = ""
  issues  = ""
**)
  IMPORT
      Stores, Models, TextModels, TextControllers, Integers;

  PROCEDURE Read(r: TextModels.Reader; VAR x: Integers.Integer);
      VAR i, len, beg: INTEGER; ch: CHAR; buf: POINTER TO ARRAY OF CHAR;
  BEGIN
      r.ReadChar(ch);
      WHILE ~r.eot & (ch <= " ") DO r.ReadChar(ch) END;
      ASSERT(~r.eot & (((ch >= "0") & (ch <= "9")) OR (ch = "-")));
      beg := r.Pos() - 1; len := 0;
      REPEAT INC(len); r.ReadChar(ch) UNTIL r.eot OR (ch < "0") OR (ch > "9");
      NEW(buf, len + 1);
      i := 0; r.SetPos(beg);
      REPEAT r.ReadChar(buf[i]); INC(i) UNTIL i = len;
      buf[i] := 0X;
      Integers.ConvertFromString(buf^, x)
  END Read;

  PROCEDURE Write(w: TextModels.Writer; x: Integers.Integer);
      VAR i: INTEGER;
  BEGIN
      IF Integers.Sign(x) < 0 THEN w.WriteChar("-") END;
      i := Integers.Digits10Of(x);
      IF i # 0 THEN
        REPEAT DEC(i); w.WriteChar(Integers.ThisDigit10(x, i)) UNTIL i = 0
      ELSE w.WriteChar("0")
      END
  END Write;

  PROCEDURE Compute*;
      VAR beg, end, i, n: INTEGER; ch: CHAR;
        s: Stores.Operation;
        r: TextModels.Reader; w: TextModels.Writer; attr: TextModels.Attributes;
        c: TextControllers.Controller;
        x: Integers.Integer;
  BEGIN
      c := TextControllers.Focus();
      IF (c # NIL) & c.HasSelection() THEN
        c.GetSelection(beg, end);
        r := c.text.NewReader(NIL); r.SetPos(beg); r.ReadChar(ch);
        WHILE ~r.eot & (beg < end) & (ch <= " ") DO r.ReadChar(ch); INC(beg) END;
        IF ~r.eot & (beg < end) THEN
            r.ReadPrev; Read(r, x);
            end := r.Pos(); r.ReadPrev; attr :=r.attr;
            IF (Integers.Sign(x) > 0) & (Integers.Compare(x, Integers.Long(MAX(LONGINT))) <= 0) THEN
              n := SHORT(Integers.Short(x)); i := 2; x := Integers.Long(1);
              WHILE i <= n DO x := Integers.Product(x, Integers.Long(i)); INC(i) END;
              Models.BeginScript(c.text, "computation", s);
              c.text.Delete(beg, end);
              w := c.text.NewWriter(NIL); w.SetPos(beg); w.SetAttr(attr);
              Write(w, x);
              Models.EndScript(c.text, s)
            END
        END
      END
  END Compute;

END ObxFact.

Люди! Оберонщики! Неужели для вас такие портянки - это нормально??? :о))

Ответ на »сообщение 2685« (Geniepro)
___________________________

Я взялся за программирование всего около полугода назад, ...

Упс! Я имел в виду - за функциональное программирование... :о))

Ответ на »сообщение 2688« (Jack Of Shadows)
___________________________
в хаскеле работает точно также как и в обероне.
Попробуйте в одном выражении применить два типа Integer и Real - получите сообщение об ошибке, а не явное преобразование типов.


А ведь я обшибся :)) Как раз в обероне при смешивании integer и Real произойдет неявное преобразование типов.
Как там Руслан говорил ? "Зачем явно преобразовывать/приводить типы? Присвоил и ладно. Компилятор поймет, не осудит." :))

Ответ на »сообщение 2679« (Руслан Богатырев)
___________________________
Руслан, ваif просветительсякая работа по квалифицирующему импорту была дружно встречена в штыки не только функциональщиками но и многими императивщиками.
Нам не нужен ОБЯЗАТЕЛЬНЫЙ квалифицирующий импорт. Смиритесь с этим фактом, и давайте закруглять то что никого здесь не интересует.
Коментировать больше эту тему я не буду, но замечу некоторые передергивания которые к импорту не относятся:

Замечательно, когда для программиста разницы между языком программирования и "костылями" инструментальной среды (IDE) практически нет.

Передергивание, Для вас IDE костыль. Для нас полезный инструмент. Неважно что мы подразумеваем под IDE - VisualStudio или Emacs.



Кто-то написал некий модуль и переслал его коллеге (наш случай с Geniepro). Коллега может не иметь всех тех настроек среды (и той же среды), ему нужен аккуратно отчужденный исходник (со всеми буковками) в текстовом виде (особенно, ежели в дороге, что может быть и равносильно случаю, когда кто-то обращается к исходнику спустя, скажем, лет 5).


Так я и знал. Все печетесь о тех кто в notepad работает.
Руслан, мы уже вам один раз говорили. Можем повторить. Нам НАПЛЕВАТЬ не тех кто работает в notepad/ Это их проблемы. Пусть пользуются нормальной средой. Не могут - пусть плачут, или уходят в оберон. Никто вслед им плакать не будет.


Зачем явно преобразовывать/приводить типы? Присвоил и ладно. Компилятор поймет, не осудит.


Передергивание. Строгая типизация вообще никакого отношения к квалифицирующему импорту не имеет, и в хаскеле работает точно также как и в обероне.
Попробуйте в одном выражении применить два типа Integer и Real - получите сообщение об ошибке, а не явное преобразование типов.

За сим все. Нам не интересно. Про квалифицирующий импорт можете здесь дальше не продолжать.

Ответ на »сообщение 2664« (Руслан Богатырев)
___________________________

Ответ на »сообщение 2662« (Jack Of Shadows)
___________________________

По сравнению с тем какие возможности по анализу кода дает хаскель

Вполне допускаю, даже убежден, что может и должен. Было бы интересно узнать (здесь достаточно даже просто ссылок) о работах по доказательному программированию применительно к Хаскелю.
В истории Хаскелла упоминалось, что одной из задач комитета по Хаскеллу было создание полного формального описания Хаскелла. К сожалению, до этого так ни у кого руки и не дошли - все силы ушли на различные первоапрельские шутки над Хаскелл-сообществом... :о))

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

Некоторые элементы Хаскелла всё-таки были формализованы, например, система модулей Хаскелла:
I. Diatchki, M. Jones, T. Hallgren, "A Formal Specification of the Haskell 98 Module System"

А вот отчёт о формализации и верификации микроядра прототипа ОС, написанной на Хаскелле, а затем переведённой на Си (в целях максимального повышения производительности):
K. Elphinstone, G. Klein, R. Kolanski, "Formalising a High-Performance Microkernel"

Из проекта Programatica, где, в частности, сделали ОС House на Хаскелле:
Dick Kieburtz, "Strategies for Verification"
Richard B. Kieburtz, "P-logic: property verification for Haskell programs

Довольно много подобных работ связано с языком Clean, весьма похожем на Хаскелл. Вот некоторые из них:
M. Tejfel, Z. Horvath, T. Kozsik, "Defining and Proving Invariants of Clean Programs" и Презентация к ней
M. Tejfel, Z. Horvath, T. Kozsik, "Proving Invariants of Functional Programs"
Z. Csornyei, Type Systems and Program Verification

Работа, связанная с Эрлангом:
Thomas Arts et al. "Testing Implementations of Formally Verified Algorithms"

Без ориентации на какой-то язык:
Nikolaj Popov, "Functional Program Verification in Theorema"

Немного не в тему, но всё-таки:
Майлингова О. Л., Манжелей С. Г., Соловская Л. Б. "Прототипирование программ на языке Scheme"

Ответ на »сообщение 2684« (Geniepro)
___________________________

Ответ на »сообщение 2670« (AVC)
Противоречие не между ФП и децентрализацией поведения, а между ФП и недетерменированностью поведения ООП и динамических компонентных систем.
А децентрализация состояния - так ли уж действительно она необходима в системах, где запрещён разгул изменений состояния?

Разгул изменений состояния был запрещен уже даже в строгой структурной парадигме в ИП... Нет "состояния вообще", есть строго локализованное состояние модулей, "микромодулях" - объектах и активациях процедур... В ИП есть понятие выражение и оператора. Первое не меняет состояния, второй как раз-таки предназначен для прямого переключения состояния. ФП исключает операторы, строит программы только на выражениях. Переключения состояния прячутся внутрь "автоматической коробки передач" - рантайма. Очень удобно и красиво для задач на обработку данных, в которых вся суть - в выражениях-соотношениях, а операторы - досадный "мусор", от которого хочется избавиться. Есть задачи, для которых вся суть сконцентрирована в операторах и переходах состояний, а вычисления встречаются "вкраплениями" и могут быть реализованы все теми же выражениями. Если я для своих задач откажусь от использования операторов, мне придется писать "выражения-намеки", которые заставляли бы "автоматическую коробку" совершать те же переходы состояний, которые я сейчас описываю напрямую.

По поводу недетерминированности - извините, ерунда какая-то. У автомата есть конечное множество состояний и переходов, входная цепочка данных дереминирует последовательность выполнения переходов...
В чем недетерминированность?

Ответ на »сообщение 2653« (Руслан Богатырев)
___________________________

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

Вы так часто это повторяете, что даже заинтриговали! :о))
Любопытно, что это за проблема и может ли она повториться в Хаскелле?


Что Вы могли бы сказать о ФП в отношении программирования в большом (в том числе для задач конструирования/моделирования/макетирования)? Желательно сразу не отсылать к источникам, а сформулировать видение/позицию своими словами.

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

Я не успел поучавствовать в крупных проектах на ФП или свои подобные провернуть, так что ничего в общем-то сказать не могу...
Вот только - разве макетирование относится к программированию в большом?

Ответ на »сообщение 2670« (AVC)
___________________________

Осталось только так сильно обжечься на подобной ситуации, что бы это стало действительно серьёзным доводом, и заставлять разработчиков использовать только квалифицированный импорт, что очень легко контролировать (по наличию только import qualified без простого import)... :о)

И получится как в Обероне? ;)

Не совсем. Одно отличие всё-таки останется - так называемый инвертированный импорт, о котором недавно рассказывали Вы с Ильёй Ермаковым. Если в Оберонах можно менять состояние импортированных модулей, то в Хаскелле нельзя (по крайней мере законными средствами языка).

Подобные действия могут быть полезны для быстрого макетирования программ с изменением (правкой) модулей на горячую. Но это вносит недетерменированность поведения, что несовместимо с принципами чистого функционального программирования, да ещё и ленивого...


Я неоднократно пытался поднять вопрос о противоречии между ФП и децентрализацией, присущей ООП и динамической модульности; ссылался на SICP и т.д.

Противоречие не между ФП и децентрализацией поведения, а между ФП и недетерменированностью поведения ООП и динамических компонентных систем.
А децентрализация состояния - так ли уж действительно она необходима в системах, где запрещён разгул изменений состояния?

(Напомню, что в разделе 3.1.2 книги SICP приводятся аргументы в пользу присваивания.)
Охотно допускаю, что я здесь ошибаюсь; но, как мне кажется, я ни разу не получил удовлетворительного ответа на свой вопрос.

Как, разве Вас не удовлетворил мой ответ, что при всём уважении к SICP эта книга не есть истина в последней инстанции? :о))

Поймал себя вот на какой мысли.

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