Какие полезные альтернативные структуры управления вы знаете? [закрыто]

Подобный вопрос был закрыт на SO.

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

Какие альтернативные структуры управления, по вашему мнению, являются полезным способом организации вычислений?

Цель здесь состоит в том, чтобы получить новые способы мышления о структурировании кода, чтобы улучшить чанкинг и рассуждение.

Вы можете создать желаемый синтаксис / семантику, недоступную сейчас, или привести менее известную структуру управления на существующем языке программирования.

Ответы должны дать идеи для нового языка программирования или улучшения реального языка.

Думайте об этом как о мозговом штурме, поэтому опубликуйте что-то, что вы считаете сумасшедшей идеей, но это может быть жизнеспособным в некотором сценарии.

Это про императивное программирование.

ОК, это забавный вопрос.

Я также хотел бы иметь общее elseдля циклов while и for, когда условие не выполняется в первом тесте:

while (condition) {
    // process
}
else {
    // condition was never true
}

Это позволяет избежать неловкого пересчета условия или сохранения его в переменной.

Почему бы не смешать несколько ответов в один?

while (expr) {

    // Executed every iteration, unless first{} is present.
    // May be explicitly called rest{} if you like first{} to come first.

    // Blocks may return results, and consequently be used in expressions.
    return expr;

} first {

    // Executed only on the first iteration.

} pre {

    // Executed before every iteration.

} post {

    // Executed after every iteration.

} catch (oops) {

    // All blocks are implicitly try{}ed if followed by a catch{}.

} finally {

    // Executes after the block completes, regardless of exceptions.

} else {

    // Executed if the loop body or rest{} never executes.

} never {

    // Executes only when a client is present.

} drop (bad, worse), // Explicitly ignore certain exceptions.
  until (expr);      // Here, have a post-body condition, too.

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

Управляющие структуры как функции.

Я хочу for, if, else, whileи т.д. , чтобы быть функции, а не специальные структуры.

Я хочу return, try/exceptи gotoбыть производными продолжения.

Это, конечно, связано не столько с конкретной структурой управления, сколько с тем, как вы видите структуры управления в целом, с мета структур управления.

Связанная статья определенно делает это правильно о петлях N + 1/2 Дональда Кнута . Выражается в C / C ++ / Java:

for (;;) {
  get next element;
  if (at the end) break;
  process the element;
}

Это полезно для чтения строк или символов из файла, проверки достижения EOF и последующей обработки. Я так привык видеть этот шаблон, for(;;)..if(..)break;что он идиоматичен для меня. (До того, как я прочитал статью Кнута, перепечатанную в книге « Грамотное программирование» , эта статья была «wtf?».)

Кнут предложил ключевые слова loop/while/repeat:

loop:
  S;
while C:
  T;
repeat

Где Sи Tявляются местозаполнителями для ряда нулевых или более операторов, и Cэто логическое условие. Если бы не было Sоператора, то это был бы цикл while, а если бы не было Tоператора, то это был бы цикл do.

Эту конструкцию можно обобщить, допуская ноль или более while Cпредложений, что делает ее идеальной для выражения бесконечных циклов, а затем некоторых более редких условий, которые потребуют двух проверок.

В той же статье Кнут предложил механизм сигнализации, который будет локальной версией исключения / перехвата (в качестве альтернативы использованию goto).

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

Обновление: я забыл упомянуть, что многие программисты на C / C ++ / Java обходят это, используя встроенное присваивание в условии while:

while ((c = getc(f)) != -1) {
   T;
}

Используя термины из конструкции Кнута, это допустимо, когда Sи Cможет быть объединено в одно выражение. Некоторые люди не хотят видеть внедренный назначение выше, в то время как другие ненавидят , чтобы увидеть breakв for (;;)выше. Но когда Sи Cне могут быть объединены, например, когда Sимеет несколько операторов, for (;;)единственная альтернатива без повторения кода. Другой вариант - просто продублировать Sкод:

S;
while (C) {
  T;
  S;
}

loop/while/repeatАльтернатива Кнута кажется намного лучше.

В языке BCPL есть valueofвыражение, которое можно использовать для преобразования последовательности операторов в одно выражение:

foo(a, b, valueof {some series of statements; resultis v});

Где some series of statementsможет быть что угодно, и все valueofоценивает v.

Это может быть удобно в Java, когда вам нужно вычислить аргумент для вызова a this()или super()(который требует, чтобы ничего не происходило до этого). Конечно, вы можете просто написать отдельный метод, но это может быть неприятно, если вам нужно передать много локальных значений для контекста.

Если вы можете использовать finalпеременные, которые вам нужны, вы уже можете делать valueofв Java, используя анонимные внутренние классы:

foo(a, b, new Object(){String valueof(){
    String v ...; some series of statements; return v;}}.valueof());

unless(condition) {
  // ...
}

делает то же самое, что и:

if(!condition) {
  // ...
}

repeat {
  // ...
} until(condition)

делает то же самое, что и:

do {
  // ...
} while(!condition)

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

for (String s, Integer i : stringsSet, integersSet) {
    // use the pair (s, i)
}

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

Если два набора не имеют одинаковый размер, это может вызвать исключение, или вы могли бы иметь elseпосле цикла, чтобы сигнализировать о разнице в размерах.

Естественно, вы могли бы обобщить это для перехода в три или более списков.

Обновление: также полезно было бы делать декартово произведение между итерациями:

for (String s, Integer i : stringsSet * integersSet) {
    // use the pair (s, i), each s with each i
}

который был бы не более чем вложенными циклами:

for (String s : stringsSet) {
    for (Integer i : integersSet) {
        // use the pair (s, i), each s with each i
    }
}

Я немного обеспокоен тем, что между двумя обозначениями, которые я привел здесь, есть разница O (n) и O (n ^ 2) в количестве пар, с изменением только одного символа.

Существует так называемая «петля Дейкстры» (также называемая «охраняемая петля Дейкстры»). Это было определено в «Охраняемом командном языке» (GCL) . Вы можете найти некоторую информацию о его синтаксисе и семантике в вышеупомянутой статье в Википедии в разделе 6 Повторение: сделайте .

В настоящее время я на самом деле знаю один язык программирования, который напрямую поддерживает эту структуру управления. Это Оберон-07 (PDF, 70 КБ). И он поддерживает «петлю Дейкстры» в форме оператора while. Взгляните на раздел 9.6. Хотя заявления в приведенном выше PDF.

WHILE m > n DO m := m – n 
ELSIF n > m DO n := n – m 
END

PS Это копия моего SO ответа .

Выражения в стиле иконок со встроенным возвратом.

Python получает много преимуществ генератора иконок - и делает их лучше в целом, IMO. И в принципе обратный путь был просто своего рода исключением, но это была простота выражений, грубый эквивалент ...

x = (a / b) else c;

обрабатывать неудачные случаи, такие как деление на ноль.

Куда Icon сходила с ума - никаких операторов сравнения с логическим возвратом. Сравнения всегда либо удавались, либо вызывали обратное отслеживание, и была еще одна семантическая проблема, которую я сейчас отчаянно пытаюсь вспомнить ... ну, скажем так, это скорее подавлено, чем забыто.

Я всегда думал, что у них должно быть ifвыражение без какой-либо другой части - что-то if (condition, success-value)вроде этого, возвращаться назад, если условие возвращает false - и отбрасывать странные сравнения.

РЕДАКТИРОВАТЬ Я помню - очевидно, действительно Сравнение с двумя аргументами либо успешное, либо неудачное - оно не вычисляет новое значение для возврата. Поэтому , когда это удается, что делает его вернуть? Ответ - один из аргументов. Но если вы напишите a > b, какой логический аргумент для возврата - aили b? А что если b < aвместо этого написать ? Я думаю, что он всегда возвращал правильный аргумент, который имеет столько же смысла, как и все остальное, но обычно он мне показался неправильным аргументом.

Это просто общая идея и синтаксис:

if (cond)
   //do something
else (cond)
   //do something
also (cond)
   //do something
else
   //do something
end

ТАКЖЕ условие всегда оценивается. ELSE работает как обычно.

Это работает для случая тоже. Вероятно, это хороший способ устранить оператор прерывания:

case (exp)
   also (const)
      //do something
   else (const)
      //do something
   also (const)
      //do something
   else
      //do something
end

можно прочитать как:

switch (exp)
   case (const)
      //do something
   case (const)
      //do something
      break
   case (const)
      //do something
   default
      //do something
end

Я не знаю, полезно ли это или просто читать, но это пример.

Продолжение Passing Style приходит на ум. Тогда, конечно, вы хотели бы также оптимизировать Tail Call .

Бесшовное ветвление потока, он имеет синтаксис как функция, но выполняется в отдельном потоке и не может получить доступ к данным, которые первоначально не были переданы ему.

branch foo(data, to, be, processed){
    //code
    return [resulting, data]
}

Когда ветка вызывается, она немедленно возвращает дескриптор.

handle=foo(here, is, some, data)

Дескриптор может использоваться, чтобы проверить, выполнена ли задача.

handle.finished() //True if the execution is complete

Если результат запрашивается до завершения выполнения, основной поток просто ждет.

[result, storage]=handle.result()

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

if (cond)
   //do something
else (cond)
   //do something
else (cond)
   //do something
first
   //do something
then
   //do something
else (cond)
   //do something
else
   //do something
end

Блоки FIRST и THEN запускаются, если любое из 3 условий оценивается как true. Первый блок выполняется до условного блока, а затем - после выполнения условного блока.

Условная или окончательная запись ELSE после операторов FIRST и THEN не зависит от этих блоков.

Это может читаться как:

if (cond)
   first()
   //do something
   then()
else (cond)
   first()
   //do something
   then()
else (cond)
   first()
   //do something
   then()
else (cond)
   //do something
else
   //do something
end


function first()
   //do something
return
function then()
   //do something
return

Эти функции просто форма для чтения. Они не будут создавать возможности. Это больше похоже на госуб / возврат из Basic.

Полезность и читаемость как предмет обсуждения.

Иногда я пишу цикл, который должен сделать что-то другое во время первой итерации. Например, отображение тегов <th> вместо тегов <td>.

Я справляюсь с этой ситуацией с помощью логического флага. Что-то вроде этого:

first = true

while (some_condition)
    if (first)
        do_something
        first = false
    else
        do_something_else

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

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

[скопировано из моего собственного ответа на stackoverflow]

ignoring - игнорировать исключения, возникающие в определенном блоке кода.

try {
  foo()
} catch {
  case ex: SomeException => /* ignore */
  case ex: SomeOtherException => /* ignore */
}

С игнорирующей управляющей конструкцией вы можете написать ее более кратко и более наглядно, как:

ignoring(classOf[SomeException], classOf[SomeOtherException]) {
  foo()
}

[Scala предоставляет это (и многие другие конструкции управления обработкой исключений) в своей стандартной библиотеке в пакете util.control. ]

Вместо того:

switch(myEnum) {
  case MyEnum.Val1: do1(); ...
  case MyEnum.Val2: do2(); ...
....

Сделайте это на Python, а теперь и на C #:

action = val2func[myEnum]
action()

Scala имеет много новых функций.

Наконец, языки, такие как Clojure, могут быть расширены для обеспечения дополнительной функциональности.

У меня есть две идеи.

Часто я обнаруживаю, что повторяюсь в catchблоках. Этому можно помочь с помощью извлечения методов, но это может вызвать ненужный беспорядок, если методы очень короткие или иным образом не заслуживают метода. Итак, было бы неплохо вложить catchблоки:

try {
    // Save something
} catch (Exception e) {
    // Something we do for all Exceptions
    catch (ProcessingException e) {
        // Something we do for all Processing exceptions
        catch (DBExcpetion e) {
            // DBExceptions are a subclass of ProcessingException
        }
        catch (BusinessRuleException e) {
            // BusinessRuleExceptions are also a subclass of ProcessingException
        }
    }
    // Something we do after specific sub class Exceptions
 }

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

Account a = getSavedAccount();
if (a == null) {
    a = getAccountFromSessionId();
}
if (a == null) {
    a = getAccountFromCookieId();
}
if (a == null) {
    a = createNewAccount();
}

В Javascript (ну, ECMAScript и, возможно, других, с которыми я не знаком), поскольку любое значение может быть оценено как условие, ||может помочь.

var a = getAFromLocation1() || getAFromLocation2() || default;

Мне действительно нравится, как это выглядит, и я хотел бы, чтобы больше языков, особенно некоторые на стороне сервера, имели поддержку для этого. (PHP может вычислить что-либо как условие, но преобразует все условное выражение в логическое значение вместо сохранения значения. Я не знаю насчет Python или Ruby.) Это может стать громоздким после трех случаев или около того, но если у вас есть больше чем в трех случаях, вы также можете иметь плохой дизайн программного обеспечения.

Обобщенный коммутатор сказал выше:

 switch(x){
  predicate1:
     dosomething();
  predicate2:
     dosomethingelse();
 }

В Хаскеле:

  switch' :: a -> [(a -> Bool, b)] -> b
  switch' a [] = undefined
  switch' a (f,b):xs = if f a
                     then b
                      else switch' a xs

В C # я хотел бы использовать простые switch () { ... }, но расширяемые с такими выражениями:

switch (value)
{
  // string-based operators:
  case begins "Maria": // to catch Maria Carey
    break;
  case ends "Washington": // to catch George Washington
    break;
  case like "ph": // to catch Phil, Phillip, Sophie
    break;
  case between "Aaron" and "April": // to catch all names between
    break;

  // use non-static variables in case expression:
  case Dao.GetDefaultBabyName():
    break;

  // continuable cases without breaking
  case "John":
    bonus = 25;
  case "Peter":
    salary = 500;
    break;

  // jumps between cases
  case "Aleron":
    // do something
    break;
  case "Bella":
    // do something
    jump "Aleron";
    break;

}

И так далее. То же самое с числами или другими типами (что поддерживает IComparable, IConvertible...)

Это может сделать мой код более лаконичным и читабельным.

Это интересный вопрос, как сказал @Macneil.

Моя любимая необычная структура управления, которую я (смиренный кашель) обнаружил, это дифференциальное исполнение .

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

Обычно я реализую это с помощью макросов на C или C ++. В C # я должен делать это с помощью расширений рук. Это боль, но это работает.

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

«Традиционные» структуры управления, такие forкак управление рабочим человеком, подчинение его коррупционным идеологиям правящей капиталистической элиты. Вот почему я ph0rвместо этого использую альтернативные структуры управления . Это как for, но более радикально: вы не поймаете ph0rносить костюм и галстук, извергая некоторые корпоративные BS. ph0rДержи это по-настоящему, чувак.

Бороться с властью!

Самый forпростой цикл

for(100)
{
    //Will run for 100 times
}


for(i)
{
    //Will run for i times while i must be a positive integer
}


for(i as a)
{
    //Will run for i times while i must be a positive integer
    //and a is the incremental loop variable starting from 0 and 
    //scoped within the loop
}


for(i as a=2)
{
    //Will run for i times while i must be a positive integer
    //and a is the incremental loop variable starting from 2 and 
    //scoped within the loop
}