OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 16:56

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




Начать новую тему Ответить на тему  [ Сообщений: 43 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 03 Февраль, 2011 20:11 
Аватара пользователя

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


Не замахаюсь. :D В PureBuilder таблица с параметрами должна заполняться автоматически при выделении части программы в отдельную процедуру.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 20:28 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Боязнь побочных эффектов доводить до крайности - не совсем разумно.
Общий контекст для нескольких процедур - вполне нормально. В конце концов, ООП на этом построено.

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

А.А. Берс (ИСИ СО РАН) в одной из своих лекций даже подвёл некую общую классификацию для этих... контекстов всяких.
viewtopic.php?f=62&t=3031


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 21:34 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 710
Откуда: Псков
Для разнообразия немного сомнений. А стоит ли овчинка выделки?

1. Синтаксис с ограниченностью применения , а по сути директива компилятору.

2. В том виде как изложено для рекурсивных вызовов не пригодна.Будет зацикливание даже и без оптимизации. Вызов концевой процедуры в рекурсивных вариантах должен быть условным в составе IF,ELSE ... или в CASE . И вообще рекурсивные вызовы в моей практике всё больше внутри циклов. Да и без передачи параметров как-то о рекурсии говорить тяжело.

3.А есть реально нужда стек экономить. Обращаясь опять к своей практике (MUMPS), да, раньше надо было экономить несчастные несколько килобайт.Теперь у меня десятки и сотни килобайт (вам не смешны эти цифры). Но это MUMPS (много юзеров, процессов). А здесь, наверное речь будет идти мегабайтах как минимум.

Пока на сегодня всё.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 22:12 
Аватара пользователя

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


Когда меня толкают на компромисс, я хочу знать, а ради чего? Что взамен? И вижу, что ничего. И зачем тогда эти побочные эффекты плюс усложнение синтаксиса (не забудьте!)?

Что касается ООП, то это ГИГАНТСКИЙ КОМПРОМИСС ради такой маленькой вещи, как повторное использование кода. И я теперь должен благоговеть перед ООП? Не стоит его приводить в качестве положительного примера, хотя я не принципиальный противник ООП.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 03 Февраль, 2011 22:36 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
albobin писал(а):
2. В том виде как изложено для рекурсивных вызовов не пригодна.Будет зацикливание даже и без оптимизации. Вызов концевой процедуры в рекурсивных вариантах должен быть условным в составе IF,ELSE ... или в CASE .

Конечно же!!
Концевой - не значит синтаксически в конце!!
Если говорить об обычном вызове, то он считается концевым, если после возврата из него текущая процедура тоже закончит свою работу. Функциональные компиляторы это распознают и оптимизируют. В частности, ту же рекурсию - до цикла.
Я же просто предложил, чтобы не полагаться на такую несколько эфемерную вещь, как "понимание" компилятора, явную конструкцию. Она всегда "концевая", в каком бы месте не встретилась. Т.е. это как будто вызов функции, а потом сразу RETURN стоит. Разумеется, правила стиля те же, что и для RETURN - ставить на действительно концевом месте.

Цитата:
И вообще рекурсивные вызовы в моей практике всё больше внутри циклов. Да и без передачи параметров как-то о рекурсии говорить тяжело.

У вас переменные объемлющей процедуры - делайте рекурсию над ними! Концевая рекурсия реализуется в фиксированном объёме памяти. Фактически, такая рекурсия - сложный цикл. Логично, что есть вместо параметров просто переменные цикла.

Цитата:
3.А есть реально нужда стек экономить. Обращаясь опять к своей практике (MUMPS), да, раньше надо было экономить несчастные несколько килобайт.

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


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

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 710
Откуда: Псков
Тогда это возврат к теме множественный выход из процедуры.Хорошо это или плохо?
По мне так лучше один выход, хоть я и MUMPSист :)
И вообще, мне кажется, что пусть эту оптимизацию делает компилятор(опционально), тогда и синтаксис можно не менять(добавлять).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Февраль, 2011 08:26 

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 710
Откуда: Псков
Илья Ермаков писал(а):
А Вы представьте, что это логика какого-нибудь цикла обработки событий, автоматного, который крутится день и ночь. И реализован он на этих концевых вызовах вместо SWITCH. Функциональщики, кстати, именно так и реализуют.

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


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

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 710
Откуда: Псков
Илья Ермаков писал(а):
У вас переменные объемлющей процедуры - делайте рекурсию над ними! Концевая рекурсия реализуется в фиксированном объёме памяти. Фактически, такая рекурсия - сложный цикл. Логично, что есть вместо параметров просто переменные цикла.

Это когда концевая. Углубились - всплыли.
А если как челнок ( типа по дереву ползать) - то сразу встанет проблема восстановления контекста.
Если уж и ограничиваться переменными объемлющей процедуры, то тогда надо и от рекурсии избавляться, сводить к автоматному циклу(например)


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Так неконцевая-то как относится к обсуждаемому вопросу? Никак.

Речь в данной теме исключительно о концевой.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Февраль, 2011 13:16 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Поскольку ни одного куска кода ещё приведено не было, то приведу примитивный пример.
Вместо CONTINUE использовано NEXT.

Код:
PROCEDURE BootSystem (...);
  VAR ...

  PROCEDURE ^ Stage1;
  PROCEDURE ^ Stage2;
  PROCEDURE ^ Stage3;
  PROCEDURE ^ Fail;

  PROCEDURE Stage1;
  BEGIN
    ..
    IF all ok THEN
      NEXT Stage2
    ELSE
      NEXT Fail
    END
  END Stage1;

...
BEGIN

END BootSystem;


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


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

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Илья Ермаков писал(а):
Не знаю, видимо, кто-то так и делает, но обычно такой стиль как-то "выбивается" ещё у новичков, как "наивный".
Мне кажется, что в приведённом примере (возможно, я просто не вижу более общей картины) решение о продолжении работы должно приниматься не процедурой Stage1, а вызывающей стороной:
Код:
PROCEDURE BootSystem (...);
  VAR ...

  PROCEDURE ^ Stage1(): BOOLEAN;
  PROCEDURE ^ Stage2(): BOOLEAN;
  PROCEDURE ^ Stage3(): BOOLEAN;
  PROCEDURE ^ Fail;

  PROCEDURE Stage1(): BOOLEAN;
  BEGIN
    ..
    RETURN all ok
  END Stage1;

...
BEGIN
  IF Stage1() & Stage2() & Stage3() THEN
  ELSE
    Fail
  END
END BootSystem;
Как вам такой вариант? Я что-то упускаю из виду в данном обсуждении?


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

Зарегистрирован: Пятница, 20 Июль, 2007 17:26
Сообщения: 710
Откуда: Псков
Илья Ермаков писал(а):
Так неконцевая-то как относится к обсуждаемому вопросу? Никак.

Речь в данной теме исключительно о концевой.

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

P.S.
Это сообщение уже лишнее. Не заметил "stop"
Илья Ермаков писал(а):
Отсюда предложение: ...
:)


Последний раз редактировалось albobin Пятница, 04 Февраль, 2011 15:36, всего редактировалось 1 раз.

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

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


Александр, так я начал с этого: с того, что есть декомпозиция древовидная, а есть списочная - viewtopic.php?p=59493#p59493
Вы предлагаете решение в рамках древовидной, а всё обсуждение предлагаю подумать над списочной :)


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

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Илья Ермаков писал(а):
Александр, так я начал с этого: с того, что есть декомпозиция древовидная, а есть списочная - viewtopic.php?p=59493#p59493
Вы предлагаете решение в рамках древовидной, а всё обсуждение предлагаю подумать над списочной :)
Спасибо, кажется, понял. То есть, вы предлагаете языковой конструкт для следующего цикла:
Код:
PROCEDURE BootSystem (...);
  VAR NEXT: PROCEDURE;
  ...

  PROCEDURE ^ Stage1;
  PROCEDURE ^ Stage2;
  PROCEDURE ^ Stage3;
  PROCEDURE ^ Done;
  PROCEDURE ^ Fail;

  PROCEDURE Stage1;
  BEGIN
    ..
    IF all ok THEN
      NEXT := Stage2
    ELSE
      NEXT := Fail
    END
  END Stage1;

...
BEGIN
  NEXT := Stage1;
  REPEAT
    NEXT
  UNTIL (NEXT = Fail) OR (NEXT = Done);
  NEXT
END BootSystem;
Правильно я понял?

Кстати, действительно получается сильно похоже на конечный автомат, и при том без потери производительности на CASE.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Февраль, 2011 16:11 
Модератор
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 04 Февраль, 2011 18:40 

Зарегистрирован: Понедельник, 05 Июнь, 2006 09:49
Сообщения: 327
Откуда: Ленинград, Емельянов Алексей Николаевич
Илья Ермаков писал(а):
Да, Александр, Вы правильно поняли и привели интересный код, спасибо.
Более того, этот код похож как две капли воды на принцип моего диспетчера легкого параллелизма, который был у меня в одном проекте пару лет назад :)

Код Александра понятен и нагляден. В этой связи: а нужен ли специальный языковый конструкт ?


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

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Axcel писал(а):
Код Александра понятен и нагляден. В этой связи: а нужен ли специальный языковый конструкт ?
Мой код не будет работать в Oberon/CP: локальные процедуры не могут быть присвоены процедурным переменным, так как в языке нет замыканий. Этот метод сработает только если в качестве контекста (группы локальных переменных) использовать RECORD или глобальные переменные модуля.


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

Зарегистрирован: Понедельник, 05 Июнь, 2006 09:49
Сообщения: 327
Откуда: Ленинград, Емельянов Алексей Николаевич
Александр Ильин писал(а):
Axcel писал(а):
Код Александра понятен и нагляден. В этой связи: а нужен ли специальный языковый конструкт ?
Мой код не будет работать в Oberon/CP: локальные процедуры не могут быть присвоены процедурным переменным, так как в языке нет замыканий. Этот метод сработает только если в качестве контекста (группы локальных переменных) использовать RECORD или глобальные переменные модуля.

Ну да, а в ТМТ-Паскаль будет. Так в этом и вопрос, что лучше вводить новые конструкты, или универсализировать существующие. Лично я предпочитаю второе. Если ввели процедурные переменные, значит они должны работать с любыми процедурами.


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

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Axcel писал(а):
Ну да, а в ТМТ-Паскаль будет. Так в этом и вопрос, что лучше вводить новые конструкты, или универсализировать существующие. Лично я предпочитаю второе. Если ввели процедурные переменные, значит они должны работать с любыми процедурами.
Предлагаете добавить замыкания? Или запретить присваивать локальные процедуры нелокальным переменным?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Февраль, 2011 12:33 

Зарегистрирован: Понедельник, 05 Июнь, 2006 09:49
Сообщения: 327
Откуда: Ленинград, Емельянов Алексей Николаевич
Александр Ильин писал(а):
...Предлагаете добавить замыкания? Или запретить присваивать локальные процедуры нелокальным переменным?

Скорее второе, либо исключить процедурные переменные (как предлагал Омник)


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

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


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

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


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

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