OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Среда, 17 Июль, 2019 19:23

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 169 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7, 8, 9  След.
Автор Сообщение
СообщениеДобавлено: Воскресенье, 04 Декабрь, 2011 17:22 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4489
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Вот мой вариант генерации и обработки исключений нового типа в процедуре Евгения Темиргалеева...
Код:
...
CALL SetFileTime (the_fname; the_date; the_time); (* вызов процедуры и обработка "исключений нового типа" *)
    CATCH(NotValidDate) …;
    CATCH(NotValidTime) …;
    CATCH(BadStat) …;
    CATCH(NotGotAttributes) …;
    CATCH(NotModTime) …;
    CATCH(BadNewTimes) …;
    CATCH(NotSetTime) …;

Ветки CATCH должны появляться автоматически при попытке указать вызов процедуры.
Сергей,
1) Зря Вы свалили предусловия, инварианты (ASSERT) и коды возврата в одну кучу. Эти ситуации должны обслуживаться разной логикой. Первые говорят о логической ошибке в программе/окружении и невозможности продолжать выполнение вообще. Отлавливать это дело во всех вызывающих процедурах не имеет смысла, т.к. результат они могут выдать только один --- тот же самый --- отказ. N раз выдавать отказ вместо одного --- загромождение. Что у Вас и вышло. Попробуйте оставить ASSERTы на месте.
2) Приведите пожалуйста, как будет выглядеть в Вашей схеме такая логика вызывающей процедуры:
Код:
            SetFileTime(fname, i.date, i.time, res);
            IF res # 0 THEN
               INCL(i.attrs, setTimeFailed)
            ELSE (* res = 0 *)
               (* Вычислить и создать целевую папку *)
               ...
            END
Вся процедура для понятности:
Код:
   PROCEDURE MoveFiles (IN loadPath, storagePath: ARRAY OF SHORTCHAR; list: List.Item);
      VAR
         res: INTEGER;
         i: List.Item;
         fname, dir, fnameNew: ARRAY 2048 OF SHORTCHAR;
   BEGIN
      i := list;
      WHILE i # NIL DO
         i.attrs := i.attrs - {setTimeFailed, makeDirFailed, moveFailed};
         IF ~(loadFailed IN i.attrs) THEN
            (* Установить дату/время *)
            MakeFileName(loadPath, i.name, fname);
            SetFileTime(fname, i.date, i.time, res);
            IF res # 0 THEN
               INCL(i.attrs, setTimeFailed)
            ELSE (* res = 0 *)
               (* Вычислить и создать целевую папку *)
               MakeDirs(storagePath, i.date, dir, res);
               IF res # 0 THEN
                  INCL(i.attrs, makeDirFailed)
               ELSE (* res = 0 *)
                  (* Переместить *)
                  MakeFileName(dir, i.name, fnameNew);
                  res := Libc.rename(fname, fnameNew); ASSERT((res = 0) OR (res = -1), 100);
                  IF res # 0 THEN
                     INCL(i.attrs, moveFailed)
                  END
               END
            END
         END;
         i := i.next
      END
   END MoveFiles;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 04 Декабрь, 2011 21:54 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Евгений Темиргалеев писал(а):
Сергей,
1) Зря Вы свалили предусловия, инварианты (ASSERT) и коды возврата в одну кучу. Эти ситуации должны обслуживаться разной логикой. Первые говорят о логической ошибке в программе/окружении и невозможности продолжать выполнение вообще. Отлавливать это дело во всех вызывающих процедурах не имеет смысла, т.к. результат они могут выдать только один --- тот же самый --- отказ. N раз выдавать отказ вместо одного --- загромождение. Что у Вас и вышло. Попробуйте оставить ASSERTы на месте.

Евгений,
Такая мысль мне тоже пришла в голову - уже после того, как я опубликовал свой вариант. И я чуть было с Вами не согласился. Но потом мне пришла в голову другая мысль. А с какой стати какая-нибудь второстепенная процедура будет обрушивать всю программу, если эта несчастная процедура не проходит ASSERTы?! Такое, может быть и допустимо, если вся программа создается одним программистом, который знает все подробности проекта. Но если мы говорим о сборочном программировании, об использовании библиотек, то каждая вызывающая процедура должна сама решать, как ей реагировать на крах вызываемой процедуры. Какой-то из запусков ракет-носителей потерпел неудачу именно из-за того, что управляющая программа слишком "остро" среагировала на второстепенный сбой и всё "вырубила".

Еще один вопрос: а что делать с многочисленными ASSERTами после того, как программа отлажена? Оставить? Но тогда редкое стечение обстоятельств может привести к тому, что в "боевом" режиме программа потерпит крах на каком-то ASSERTе. Отключить компилятором? Но тогда есть риск в "боевом" режиме проворонить недопустимое значение параметров.

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

Евгений Темиргалеев писал(а):
2) Приведите пожалуйста, как будет выглядеть в Вашей схеме такая логика вызывающей процедуры:

Отличный вопрос!!! :D
Код:
SetFileTime(fname, i.date, i.time);
    CATCH(res_not_0)
        INCL(i.attrs, setTimeFailed)
    ELSE
        (* Вычислить и создать целевую папку *)
        ...
    END;


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ключевое слово CATCH
СообщениеДобавлено: Понедельник, 05 Декабрь, 2011 05:56 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Сергей Прохоренко писал(а):
Код:
    CATCH(res_not_0)
Не касаясь самой дискуссии, скажу, что ключевое слово CATCH в данном контексте я нахожу очень удачным. В связи с этим вопрос. Сергей, это ключевое слово Вы ввели самостоятельно, или позаимствовали где-то? Если позаимствовали, то откуда?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ключевое слово CATCH
СообщениеДобавлено: Понедельник, 05 Декабрь, 2011 09:49 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
igor писал(а):
Сергей Прохоренко писал(а):
Код:
    CATCH(res_not_0)
Не касаясь самой дискуссии, скажу, что ключевое слово CATCH в данном контексте я нахожу очень удачным. В связи с этим вопрос. Сергей, это ключевое слово Вы ввели самостоятельно, или позаимствовали где-то? Если позаимствовали, то откуда?


Я позаимствовал слово CATCH из исключений, которые есть в .NET (нечаянный каламбур)

Кстати, теперь я решил обойтись без CATCH :D и каких бы то ни было других ключевых слов при вызове процедур, порождающих исключения. Ключевые слова слишком сковывают свободу программиста, которому приходится правильно размещать их в программе. Коды ошибок как раз давали программисту необходимую свободу, хотя при этом были корявой самоделкой.

Теперь в вызывающей процедуре программист сможет произвольно использовать исключения - переменные логического типа, автоматически объявляемые при использовании в операторе ESCAPE() в вызываемой процедуре, - в сколь угодно сложных условных операторах, в том числе вложенных, и даже в заголовках циклов! Аналогично может использоваться логическая функция EXCEPTION(имя_вызываемой_процедуры).

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

Отличие ESCAPE() от EXIT не только в том, что ESCAPE() порождает исключение, но и в том, что после этого все данные из вызываемой процедуры считаются скомпрометированными и становятся недоступными в вызывающей процедуре. Поэтому исключения нового типа невозможно использовать для моделирования нормальной логики (нарушая при этом принципы структурного программирования), а можно использовать только для случаев аварийного завершения вызываемой процедуры.


Последний раз редактировалось Сергей Прохоренко Понедельник, 05 Декабрь, 2011 10:07, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Декабрь, 2011 09:59 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4489
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Евгений Темиргалеев писал(а):
2) Приведите пожалуйста, как будет выглядеть в Вашей схеме такая логика вызывающей процедуры:

Отличный вопрос!!! :D
Код:
SetFileTime(fname, i.date, i.time);
    CATCH(res_not_0)
        INCL(i.attrs, setTimeFailed)
    ELSE
        (* Вычислить и создать целевую папку *)
        ...
    END;
Это дело как-то не вяжется с приведённым Вами изначально телом процедуры. У Вас никакого res нету. Пока для меня всё запутано. У Вас уже есть общая схема или пока просто отдельные идеи?

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Декабрь, 2011 10:10 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Евгений Темиргалеев писал(а):
Это дело как-то не вяжется с приведённым Вами изначально телом процедуры. У Вас никакого res нету. Пока для меня всё запутано. У Вас уже есть общая схема или пока просто отдельные идеи?

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


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


Последний раз редактировалось Сергей Прохоренко Понедельник, 05 Декабрь, 2011 10:14, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ключевое слово CATCH
СообщениеДобавлено: Понедельник, 05 Декабрь, 2011 10:13 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Сергей Прохоренко писал(а):
igor писал(а):
Если позаимствовали, то откуда?

Я позаимствовал слово CATCH из исключений, которые есть в .NET (нечаянный каламбур)
Ясно. Спасибо.
Я далёк от .NET, и потому не в курсе.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Декабрь, 2011 14:55 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Обработка сигналов отказа процедуры/функции

Сигналы отказа процедуры/функции в PureBuilder являются переменными логического типа и заменяют собой исключения и функции Assert и Exit в языках программирования, а также создаваемые программистом коды ошибок.

В вызывающей процедуре/функции программист может произвольным образом (обычно в условных операторах, в том числе вложенных, и даже в заголовках циклов) использовать сигналы отказа, которые считаются автоматически объявленными и имеют идентификатор вида:
  • имя_вызываемой_процедуры.имя_сигнала_отказа,
  • имя_вызываемой_процедуры.имя_прерывания_операционной_системы,
  • имя_вызываемой_процедуры.failure (для любого сигнала отказа или реально возможного прерывания операционной системы).

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

В вызываемой процедуре/функции сигналы отказа используются один раз – только в качестве параметра в операторе Escape() – и без указания имени вызываемой процедуры. Они не могут каким-либо ещё образом использоваться в вызываемой процедуре.

Как и оператор Exit в языках программирования, оператор Escape():
  • чаще всего используется в условном операторе;
  • прерывает исполнение процедуры/функции, в которой он встречается.

Но, в отличие от оператора Exit (отсутствующего в PureBuilder), оператор Escape():
  • объявляет сигнал отказа – переменную логического типа – и присваивает ей значение «истина»,
  • объявляет все данные из вызываемой процедуры скомпрометированными и делает их недоступными в вызывающей процедуре. Не происходит возврата параметров или возвращаемого значения в вызывающую функцию/процедуру. Поэтому сигналы отказа невозможно использовать для моделирования нормальной логики (нарушая при этом принципы структурного программирования), а можно использовать только для случаев аварийного завершения вызываемой процедур.

Опасные операторы и части программы, которые могут вызвать прерывания операционной системы (ошибка выделения памяти, ошибка оператора присваивания или ввода/вывода, деление на ноль, выход индекса за границу массива и т.д.) или иные сигналы отказа, следует выделять в отдельные процедуры/функции по следующим причинам:
  • для облегчения обработки прерываний операционной системы с помощью перехвата сигналов отказа,
  • для сохранения возможности воспользоваться выходными параметрами или возвращаемым значением в случае отказа опасной части программы.


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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Декабрь, 2011 15:24 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2308
Откуда: Россия, Санкт-Петербург
Сергей Прохоренко писал(а):
объявляет все данные из вызываемой процедуры скомпрометированными и делает их недоступными в вызывающей процедуре.
Как быть с содержимым объектов, переданных в процедуру по ссылке? В частности, как быть с полями объекта при сбое в вызове метода? Состояние объекта или данных может утратить целостность, но изъять их из обращения отовсюду вряд ли представляется возможным.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ключевое слово CATCH
СообщениеДобавлено: Понедельник, 05 Декабрь, 2011 16:29 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3059
Откуда: Астрахань
igor писал(а):
Сергей Прохоренко писал(а):
igor писал(а):
Если позаимствовали, то откуда?

Я позаимствовал слово CATCH из исключений, которые есть в .NET (нечаянный каламбур)
Ясно. Спасибо.
Я далёк от .NET, и потому не в курсе.

Дык catch - стандартное слово и в С++, и в Java.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 05 Декабрь, 2011 17:05 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Александр Ильин писал(а):
Сергей Прохоренко писал(а):
объявляет все данные из вызываемой процедуры скомпрометированными и делает их недоступными в вызывающей процедуре.
Как быть с содержимым объектов, переданных в процедуру по ссылке? В частности, как быть с полями объекта при сбое в вызове метода? Состояние объекта или данных может утратить целостность, но изъять их из обращения отовсюду вряд ли представляется возможным.


К этим объектам в любом случае есть доступ из вызывающей процедуры/функции, и эти объекты, конечно, скомпрометированы. Я не вижу способа, которым можно было бы элегантно решить эту проблему. Имеющиеся способы, которые приходят на ум:
1. молиться, чтобы скомпрометированным данным можно было доверять; :D
2. предусматривать в вызывающей процедуре такую обработку сигнала отказа, которая обезопасит программу при использовании скомпрометированных данных;
3. избегать заведомо рискованной передачи объектов по ссылке;
4. использовать по умолчанию передачу по значению;
5. запретить вообще передачу по ссылке;
6. объединить процедуры, передающие друг другу данные по ссылке, и отделить затем в другую процедуру все действия, не связанные с обработкой этих данных;
7. разбить данные на небольшие куски, передаваемые по значению;
8. предусмотреть возможность отката к исходным значениям данных, переданных по ссылке (аналогично транзакциям в СУБД);
9. предусмотреть последовательный доступ вызываемых процедур/функций к данным, чтобы можно было обойтись всего одной копией при передаче по значению.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Ключевое слово CATCH
СообщениеДобавлено: Понедельник, 05 Декабрь, 2011 17:33 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 1056
Валерий Лаптев писал(а):
Дык catch - стандартное слово и в С++, и в Java.
Ответил в личку.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Декабрь, 2011 10:02 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Александр Ильин писал(а):
Сергей Прохоренко писал(а):
объявляет все данные из вызываемой процедуры скомпрометированными и делает их недоступными в вызывающей процедуре.
Как быть с содержимым объектов, переданных в процедуру по ссылке? В частности, как быть с полями объекта при сбое в вызове метода? Состояние объекта или данных может утратить целостность, но изъять их из обращения отовсюду вряд ли представляется возможным.


Кажется, я нашел решение.

При разработке критических программ или отсутствии жестких ограничений по используемым программой ресурсам передача объектов в процедуру/метод по ссылке должна быть запрещена на уровне среды разработки, кроме доступа к базе данных с возможностью отката неудачной транзакции. Если в такой программе используются крупные объекты, то ее придется изменить:
  • Разбить каждый крупный объект на меньшие, передаваемые по значению.
  • Выделить обработку каждого объекта в одну или несколько независимых процедур/функций, чтобы объект не мог быть скомпрометирован отказами в других частях алгоритма.
  • Предусмотреть последовательный доступ вызываемых процедур/функций к объекту, чтобы в каждый момент времени можно было обойтись всего одной его копией при передаче по значению.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Декабрь, 2011 13:37 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Вот это, кстати, с позиции "предметника" интересным кажется...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Декабрь, 2011 13:57 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
А глобальные объекты модулей? Тоже запретить?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 06 Декабрь, 2011 21:10 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Александр Шостак писал(а):
А глобальные объекты модулей? Тоже запретить?


А что это такое? Можно пример?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 07 Декабрь, 2011 14:09 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9127
Откуда: Россия, Орёл
Сергей Прохоренко писал(а):
Александр Ильин писал(а):
Сергей Прохоренко писал(а):
объявляет все данные из вызываемой процедуры скомпрометированными и делает их недоступными в вызывающей процедуре.
Как быть с содержимым объектов, переданных в процедуру по ссылке? В частности, как быть с полями объекта при сбое в вызове метода? Состояние объекта или данных может утратить целостность, но изъять их из обращения отовсюду вряд ли представляется возможным.


Кажется, я нашел решение.

При разработке критических программ или отсутствии жестких ограничений по используемым программой ресурсам передача объектов в процедуру/метод по ссылке должна быть запрещена на уровне среды разработки, кроме доступа к базе данных с возможностью отката неудачной транзакции. Если в такой программе используются крупные объекты, то ее придется изменить:
  • Разбить каждый крупный объект на меньшие, передаваемые по значению.
  • Выделить обработку каждого объекта в одну или несколько независимых процедур/функций, чтобы объект не мог быть скомпрометирован отказами в других частях алгоритма.
  • Предусмотреть последовательный доступ вызываемых процедур/функций к объекту, чтобы в каждый момент времени можно было обойтись всего одной его копией при передаче по значению.



Это в точности подход функционального программирования.
Например, на Эрланге дело обстоит именно так. Всё по значению. Любой поток при ошибке просто убивается. Он не изменял данных, поэтому может быть перезапущен безболезненно.
Глобальные изменяемые данные хранятся только в СУБД - в рантайме Эрланга есть стандартная СУБД Mnesia.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 07 Декабрь, 2011 14:17 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Цитата:
А что это такое? Можно пример?

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

Код:
VAR
  MyObject*: SomeObject;

PROCEDURE Dangerous;
BEGIN
  ...
  (* работаем с MyObject напрямую *)
  ...
END Dangerous;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 07 Декабрь, 2011 22:57 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Александр Шостак писал(а):
Цитата:
А что это такое? Можно пример?

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

Код:
VAR
  MyObject*: SomeObject;

PROCEDURE Dangerous;
BEGIN
  ...
  (* работаем с MyObject напрямую *)
  ...
END Dangerous;


Цитата с сайта PureBuilder:
Цитата:
В соответствии с функциональной парадигмой программирования в PureBuilder не применяются глобальные и статические переменные.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 09 Декабрь, 2011 11:57 

Зарегистрирован: Четверг, 23 Апрель, 2009 18:01
Сообщения: 219
Как в такой парадигме простейшую функцию random реализовать? А любую другую, которая зависит от ранее рассчитанного результата?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 169 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7, 8, 9  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB