OberonCore https://forum.oberoncore.ru/ |
|
Управляющие конструкции в алгоритмах https://forum.oberoncore.ru/viewtopic.php?f=86&t=3237 |
Страница 2 из 3 |
Автор: | Сергей Прохоренко [ Четверг, 03 Февраль, 2011 20:11 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Илья Ермаков писал(а): Иначе Вы замахаетесь протаскивать это параметрами - и просто плюнете на разделение, и оставите это одной процедурой. Не замахаюсь. В PureBuilder таблица с параметрами должна заполняться автоматически при выделении части программы в отдельную процедуру. |
Автор: | Илья Ермаков [ Четверг, 03 Февраль, 2011 20:28 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Боязнь побочных эффектов доводить до крайности - не совсем разумно. Общий контекст для нескольких процедур - вполне нормально. В конце концов, ООП на этом построено. Рассмотрите, например, верхнюю процедуру, как объект (он родился, когда её вызвали, и исчез, когда она завершилась), а её вложенные процедуры - как методы этого объекта. А.А. Берс (ИСИ СО РАН) в одной из своих лекций даже подвёл некую общую классификацию для этих... контекстов всяких. viewtopic.php?f=62&t=3031 |
Автор: | albobin [ Четверг, 03 Февраль, 2011 21:34 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Для разнообразия немного сомнений. А стоит ли овчинка выделки? 1. Синтаксис с ограниченностью применения , а по сути директива компилятору. 2. В том виде как изложено для рекурсивных вызовов не пригодна.Будет зацикливание даже и без оптимизации. Вызов концевой процедуры в рекурсивных вариантах должен быть условным в составе IF,ELSE ... или в CASE . И вообще рекурсивные вызовы в моей практике всё больше внутри циклов. Да и без передачи параметров как-то о рекурсии говорить тяжело. 3.А есть реально нужда стек экономить. Обращаясь опять к своей практике (MUMPS), да, раньше надо было экономить несчастные несколько килобайт.Теперь у меня десятки и сотни килобайт (вам не смешны эти цифры). Но это MUMPS (много юзеров, процессов). А здесь, наверное речь будет идти мегабайтах как минимум. Пока на сегодня всё. |
Автор: | Сергей Прохоренко [ Четверг, 03 Февраль, 2011 22:12 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Илья Ермаков писал(а): Боязнь побочных эффектов доводить до крайности - не совсем разумно. Когда меня толкают на компромисс, я хочу знать, а ради чего? Что взамен? И вижу, что ничего. И зачем тогда эти побочные эффекты плюс усложнение синтаксиса (не забудьте!)? Что касается ООП, то это ГИГАНТСКИЙ КОМПРОМИСС ради такой маленькой вещи, как повторное использование кода. И я теперь должен благоговеть перед ООП? Не стоит его приводить в качестве положительного примера, хотя я не принципиальный противник ООП. |
Автор: | Илья Ермаков [ Четверг, 03 Февраль, 2011 22:36 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
albobin писал(а): 2. В том виде как изложено для рекурсивных вызовов не пригодна.Будет зацикливание даже и без оптимизации. Вызов концевой процедуры в рекурсивных вариантах должен быть условным в составе IF,ELSE ... или в CASE . Конечно же!! Концевой - не значит синтаксически в конце!! Если говорить об обычном вызове, то он считается концевым, если после возврата из него текущая процедура тоже закончит свою работу. Функциональные компиляторы это распознают и оптимизируют. В частности, ту же рекурсию - до цикла. Я же просто предложил, чтобы не полагаться на такую несколько эфемерную вещь, как "понимание" компилятора, явную конструкцию. Она всегда "концевая", в каком бы месте не встретилась. Т.е. это как будто вызов функции, а потом сразу RETURN стоит. Разумеется, правила стиля те же, что и для RETURN - ставить на действительно концевом месте. Цитата: И вообще рекурсивные вызовы в моей практике всё больше внутри циклов. Да и без передачи параметров как-то о рекурсии говорить тяжело. У вас переменные объемлющей процедуры - делайте рекурсию над ними! Концевая рекурсия реализуется в фиксированном объёме памяти. Фактически, такая рекурсия - сложный цикл. Логично, что есть вместо параметров просто переменные цикла. Цитата: 3.А есть реально нужда стек экономить. Обращаясь опять к своей практике (MUMPS), да, раньше надо было экономить несчастные несколько килобайт. А Вы представьте, что это логика какого-нибудь цикла обработки событий, автоматного, который крутится день и ночь. И реализован он на этих концевых вызовах вместо SWITCH. Функциональщики, кстати, именно так и реализуют. |
Автор: | albobin [ Пятница, 04 Февраль, 2011 08:13 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Тогда это возврат к теме множественный выход из процедуры.Хорошо это или плохо? По мне так лучше один выход, хоть я и MUMPSист И вообще, мне кажется, что пусть эту оптимизацию делает компилятор(опционально), тогда и синтаксис можно не менять(добавлять). |
Автор: | albobin [ Пятница, 04 Февраль, 2011 08:26 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Илья Ермаков писал(а): А Вы представьте, что это логика какого-нибудь цикла обработки событий, автоматного, который крутится день и ночь. И реализован он на этих концевых вызовах вместо SWITCH. Функциональщики, кстати, именно так и реализуют. А для цикла обработки событий с автоматной логикой не вижу причин роста стека. Для этого достаточно выделить в процедуру логику работы одного автоматного такта и кормить её событиями (кивок в сторону Шалыто А.А. как пример) Это я к тому, что бороться можно разными способами, иногда лучше пересмотреть подход к решению задачи. |
Автор: | albobin [ Пятница, 04 Февраль, 2011 13:01 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Илья Ермаков писал(а): У вас переменные объемлющей процедуры - делайте рекурсию над ними! Концевая рекурсия реализуется в фиксированном объёме памяти. Фактически, такая рекурсия - сложный цикл. Логично, что есть вместо параметров просто переменные цикла. Это когда концевая. Углубились - всплыли. А если как челнок ( типа по дереву ползать) - то сразу встанет проблема восстановления контекста. Если уж и ограничиваться переменными объемлющей процедуры, то тогда надо и от рекурсии избавляться, сводить к автоматному циклу(например) |
Автор: | Илья Ермаков [ Пятница, 04 Февраль, 2011 13:05 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Так неконцевая-то как относится к обсуждаемому вопросу? Никак. Речь в данной теме исключительно о концевой. |
Автор: | Илья Ермаков [ Пятница, 04 Февраль, 2011 13:16 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Поскольку ни одного куска кода ещё приведено не было, то приведу примитивный пример. Вместо 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 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Илья Ермаков писал(а): Не знаю, видимо, кто-то так и делает, но обычно такой стиль как-то "выбивается" ещё у новичков, как "наивный". Мне кажется, что в приведённом примере (возможно, я просто не вижу более общей картины) решение о продолжении работы должно приниматься не процедурой 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; |
Автор: | albobin [ Пятница, 04 Февраль, 2011 13:56 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Илья Ермаков писал(а): Так неконцевая-то как относится к обсуждаемому вопросу? Никак. Речь в данной теме исключительно о концевой. Согласен, оставим вообще рекурсию в покое. Тогда тем более большого смысла нет.Один только геморрой. Хотя бы из-за необходимости в описании синтаксиса формализовать применимость этой конструкции. Повторюсь: пусть эту оптимизацию делает компилятор(опционально). Если его научить, то и с параметрами концевой процедуры разберётся. P.S. Это сообщение уже лишнее. Не заметил "stop" Илья Ермаков писал(а): Отсюда предложение: ...
|
Автор: | Илья Ермаков [ Пятница, 04 Февраль, 2011 14:33 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Александр Ильин писал(а): Мне кажется, что в приведённом примере (возможно, я просто не вижу более общей картины) решение о продолжении работы должно приниматься не процедурой Stage1, а вызывающей стороной: Александр, так я начал с этого: с того, что есть декомпозиция древовидная, а есть списочная - viewtopic.php?p=59493#p59493 Вы предлагаете решение в рамках древовидной, а всё обсуждение предлагаю подумать над списочной |
Автор: | Александр Ильин [ Пятница, 04 Февраль, 2011 14:58 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Илья Ермаков писал(а): Александр, так я начал с этого: с того, что есть декомпозиция древовидная, а есть списочная - 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 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Да, Александр, Вы правильно поняли и привели интересный код, спасибо. Более того, этот код похож как две капли воды на принцип моего диспетчера легкого параллелизма, который был у меня в одном проекте пару лет назад |
Автор: | Axcel [ Пятница, 04 Февраль, 2011 18:40 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Илья Ермаков писал(а): Да, Александр, Вы правильно поняли и привели интересный код, спасибо. Более того, этот код похож как две капли воды на принцип моего диспетчера легкого параллелизма, который был у меня в одном проекте пару лет назад Код Александра понятен и нагляден. В этой связи: а нужен ли специальный языковый конструкт ? |
Автор: | Александр Ильин [ Пятница, 04 Февраль, 2011 19:52 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Axcel писал(а): Код Александра понятен и нагляден. В этой связи: а нужен ли специальный языковый конструкт ? Мой код не будет работать в Oberon/CP: локальные процедуры не могут быть присвоены процедурным переменным, так как в языке нет замыканий. Этот метод сработает только если в качестве контекста (группы локальных переменных) использовать RECORD или глобальные переменные модуля.
|
Автор: | Axcel [ Суббота, 05 Февраль, 2011 10:49 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Александр Ильин писал(а): Axcel писал(а): Код Александра понятен и нагляден. В этой связи: а нужен ли специальный языковый конструкт ? Мой код не будет работать в Oberon/CP: локальные процедуры не могут быть присвоены процедурным переменным, так как в языке нет замыканий. Этот метод сработает только если в качестве контекста (группы локальных переменных) использовать RECORD или глобальные переменные модуля.Ну да, а в ТМТ-Паскаль будет. Так в этом и вопрос, что лучше вводить новые конструкты, или универсализировать существующие. Лично я предпочитаю второе. Если ввели процедурные переменные, значит они должны работать с любыми процедурами. |
Автор: | Александр Ильин [ Суббота, 05 Февраль, 2011 11:05 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Axcel писал(а): Ну да, а в ТМТ-Паскаль будет. Так в этом и вопрос, что лучше вводить новые конструкты, или универсализировать существующие. Лично я предпочитаю второе. Если ввели процедурные переменные, значит они должны работать с любыми процедурами. Предлагаете добавить замыкания? Или запретить присваивать локальные процедуры нелокальным переменным?
|
Автор: | Axcel [ Суббота, 05 Февраль, 2011 12:33 ] |
Заголовок сообщения: | Re: Управляющие конструкции в алгоритмах |
Александр Ильин писал(а): ...Предлагаете добавить замыкания? Или запретить присваивать локальные процедуры нелокальным переменным? Скорее второе, либо исключить процедурные переменные (как предлагал Омник) |
Страница 2 из 3 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |