def concat(a, b):
  for elt in a:
    yield return elt;
  for elt in b:
    yield return elt;

Я очень горд, что в этой книжке (Elements of Programming) есть, вы сейчас просто @#$%&%@#, GOTOS. Почему? Потому что в какой-то момент мы показываем, специально, потому что знаем, что вы будете кричать БУУУУУ и писать письма, может быть не все, но некоторые — мне всегда пишут письма что я дурак — потому что я не верю в объектную ориентацию, я использую goto — пропащий человек. И многие люди, в программировании есть такая идея что люди считают что это очень мило написать незнакомому человеку письмо говорящие что "ты дурак". Даже если вы так думаете — вы мне не говорите, потому что — не нужно, не обязательно.
Мы используем goto, для чего — потому что у нас есть структура которая реально является конечным автоматом. Если вы описываете конечный автомат, что он делает — он переходит из состояния этого в состояние то. Как нужно переходить из одного состояния в другое? Есть правильная инструкция — называется goto: идите от туда — туда. И структура программы становится очень элегантной.
То есть идея Дейкстры, Дейкстра великий человек — вы не думайте что $#%@#$%@#$, но он конечно же был не прав, потому что он думал, что плохая программа, потому что она пользуется какой-то синтаксической структурой. Нет — программа плохая, если она плохая.
То есть может быть очень красивая программа на языке Assembler — очень элегантная. Может быть очень плохая программа на Java, уверяю вас.
Немецкий язык такой непоэтичный — но какая поэзия Самые красивые песни на каком языке? На немецком — Шуберт — необыкновенная красота. Хотя у них там гортанный, странный язык, но невероятно красивый.
Всё можно сделать. goto может быть красивым. Я не верю в синтаксические лишения в семантических вопросах.
В меня всю жизнь камнями кидают, потому что я всё время такие вещи говорю — и мне говорят что я дурак. Но я не пытаюсь просто сказать дерзость. Я на самом деле пытаюсь объяснить какие-то вещи и в этой книжке никаких дерзостей.

Enable exception handling for real-time critical programs only if exceptions are actually used. A complete analysis must always include the throwing of an exception, and this analysis will always be implementation dependent.
On the other hand, the requirement to act within a deterministic time might loosen in the case of an exception (e.g. there is no need to handle any more input from a device when a connection has broken down).

I do not buy the author's arguments either. I keep running into this meme at least a few times every year "exceptions are bad, they're a nightmare, etc..."

My typical reply is also somewhere along the same lines: if you don't like to use exceptions, then just don't use them. Leave that job to the professionals

uint n = file.get_size();
void* buf = alloc(n);
file.read_to_buf(buf, n);

#define RNOK(e) if (err_t err = e) return err

uint n;
RNOK(file.get_size(n));
void* buf;
RNOK(malloc(buf, n));
RNOK(file.read_to_buf(buf, n));

err_t e = E_OK;
uint n;
e = file.get_size(n);
if (!e)
{
    void* buf;
    e = malloc(buf, n);
    if (!e)
    {
        e = file.read_to_buf(buf, n));
    }
}
return e;

void UI_Controller::validateFile()
{
    string localFileMd5, remoteFileMd5;
    thread th1([&]{ localFileMd5 = md5(fileName); });
    thread th2([&]{ remoteFileMd5 = http_get("http://site/md5/" + fileName); });
    th1.join();
    th2.join();

    ui.invoke([=]{ ui.checkbox.set(localFileMd5 == remoteFileMd5); });
}

E>Часто всё-таки есть конфликт интересов между "всем удобнее и проще", и "выгоднее для бизнеса"...

E>Поэтому в подобных случаях ЭКОНОМИЧЕСКОЕ и ТЕХНИЧЕСКОЕ обоснования таки требуются, а по умолчанию, без обонований -- запретить.

... как показывают исследование, А% программистов С++ с опытом от года понимают эту конструкцию правильно, так что если все теперешние программисты уволятся и придется набирать новых, проблемы с использованием этого возникнут с вероятностью Б%. Если повысить требования к набираемым программистам, проблемы возникнут с вероятностью В%, но при этом зарплаты придется повысить на Г% и риск не найти на рынке специалистов повысится до Д%. Уровень проблем оценивается как Ж-12-47.

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

Оценки лежат в доверительном интервале +/- 2% с вероятностью 95%. Мы считаем выгоды значительными а риск приемлемым и рекомендуем разрешить.

ARK>Элементарно же. Вот это

ARK>IEnumerable<T> takewhile<T>(Predicate<T> predicate, IEnumerable<T> iterable)
ARK>{
ARK>  var result = new LazyList<T>();

ARK>  foreach (var x in iterable)
ARK>  {
ARK>    if (predicate(x))
ARK>      result.Add(x);
ARK>    else
ARK>      break;
ARK>  }

ARK>  return result;
ARK>}
ARK>

ARK>IEnumerable<T> takewhile<T>(Predicate<T> predicate, IEnumerable<T> iterable)
ARK>{
ARK>  foreach (var x in iterable)
ARK>  {
ARK>    if (predicate(x))
ARK>      yield return x;
ARK>    else
ARK>      break;
ARK>  }
ARK>}
ARK>

ARK>

IEnumerable<T> split(bool takeOdds, IEnumerable<T> iterable)
{
  var odds = new LazyList<T>();
  var events = new LazyList<T>(); 
  int i = 0;
  foreach(var item in iterable)
    if (i++ % 2 == 1)
      odds.Add(item);
    else
      evens.Add(item);

  return takeOdds? odds : evens;
}

ARK>Ошибка компиляции. LazyList должен быть только один. Но в принципе я согласен, что всякие подводные камни могут быть, возможно нужны и другие ограничения.

ARK>И, кстати, я не считаю все эволюционные решения C# правильными.

public void handleIncomingMail(Channel<string> smtpSession, Channel<MailMessage> messageQueue)
{
  handleHandshake(smtpSession); // EHLO, login sequence
  while(smtpSession.IsActive)
    handleSingleMessage(smtpSession, messageQueue);
}
public void handleSingleMessage(Channel<string> smtpSession, Channel<MailMessage> messageQueue)
{
  message = new MailMessage();
  message.From = parseMailFrom(smtpSession.pull());
  message.To = parseRcptTo(smtpSession.pull());
  message.Body = parseData(smtpSession.pull());
  messageQueue.push(message);
}

M>Вот в данном то конкретном случае нитей там и не было Это полностью однопоточный код (и вообще там в рантайме поддержки потоков нет!). Где-то на верхнем уровне он вырождатеся в тот самый цикл на сообщениях:

  loadDataA();
  loadDataB();
  preloadImages();
  someFunction();

  // parent process
  this.data = receive childChannel.GetData();
  someFunction();

  // ...

  // child channel
  public Data GetData()
  {
    loadDataA();
    loadDataB();
    preloadImages();
  }

M>public function doSomething(app, arg1, arg2) : OperationState<Void> {
M>  var dataA = loadSomethingVeryAsync(arg1);
M>  var dataB = loadSomethingOverAsync(arg2);
M>  var preloadedImages = Async.applyAsync(preloadImagesForData, [dataA]);
M>  var externalData = Async.applyAsync(loadDataFromExternalSystem, [dataB, arg2]);
M>  var appUI = Async.applySync(createUI, [app, dataA,  extenralData, preloadedImages]);
M>  return Async.applySync(app.addDialog, [appUI]);
M>}
M>

M>def listInTree(curNode, pred):
M>  if pred(curNode):
M>    yield return curNode
M>  else:
M>    for sub in curNode.children():
M>      for res in listInTree(sub, pred)
M>         yield return res
M>

  List<TreeNode> ListInTree(TreeNode node, Predicate pred)
  {
    var result = new List<TreeNode>();

    if (pred(node))
    {
      result.Add(node);

      foreach (var childNode in node.Children)
      {
        result.AddRange(ListInTree(childNode, pred));
      }
    }

    return result;
  }

M>Ну как... В вашем же определении "Нет, не локальный, т.к. мы не знаем конечной точки." А конечной точки мы не знаем

ARK>>Куда инкапсулируем, в синглтоны?

M>В инстансы, которые потом по программе таскаем . А вообще, наверное, вы правы. Стоит различать глобальные переменные в смысле "нечто, что существует все время работы программы" и в более узком "переменная, объявленная на самом верхнем уровне/в единственном контексте". Со вторыми можно достаточно успешно бороться. Правда, не всегда удобно (в типичном UI много с собой носить приходится).

def takewhile(predicate, iterable):
    # takewhile(lambda x: x<5, [1,4,6,4,1]) --> 1 4
    for x in iterable:
        if predicate(x):
            yield x
        else:
            break

IEnumerable<T> takewhile<T>(Predicate<T> predicate, IEnumerable<T> iterable)
{
  var result = new List<T>();

  foreach (var x in iterable)
  {
    if (predicate(x))
      result.Add(x);
    else
      break;
  }

  return result;
}

def Fib(n):
    a, b = 0, 1
    for i in xrange(n):
        yield a
        a, b = b, a + b

class Fibonacci:
  def __init__(self, max):
    self.n, self.a, self.b, self.max = 0, 0, 1, max
  def __iter__(self):
    return self
  def next(self):
    if self.n < self.max:
      a, self.n, self.a, self.b = self.a, self.n+1, self.b, self.a+self.b
      return a
    else:
      raise StopIteration

ARK> А где квадратичная? По памяти в 2 раза больше, по времени то же самое. Нет?

ARK>Элементарно же. Вот это

var lazyList = new LazyList<String>()
var file = new File("someFile");
try {
  for (String line in file.lines())
    lazyList.add(file);
} finally {
  file.close();
}
return lazyList;

Хорошие программы – это продукт хорошего образования, удачного проектирования, адекватного тестирования и т.д., а не наличия в языке средств, которые предположительно должны использоваться только «правильно». Употребить во вред можно любое средство, поэтому вопрос не в том, можно ли чем-то воспользоваться неправильно (можно!) или будут ли этим неправильно пользоваться (будут!). Вопрос в том, необходимо ли данное средство при условии его правильного употребления настолько, чтобы оправдать затраты на его реализацию, удастся ли смоделировать его с помощью других средств языка и реально ли с помощью обучения обратить во благо неправильное использование.

while (true) {
  case (waitForNextMessage()) {
    case WM_RENDER:
      fireNextFrameListeners();
      renderNextFrame();
    case WM_NET_EVENT(e):
      var netQueue = findNetQueue(e.queueId);
      netQueue.appendData(e.data);
      ...
    case WM_MOUSE_EVENT(e):
      ...
  }
}

public function doSomething(app, arg1, arg2) : OperationState<Void> {
  var dataA = loadSomethingVeryAsync(arg1);
  var dataB = loadSomethingOverAsync(arg2);
  var preloadedImages = Async.applyAsync(preloadImagesForData, [dataA]);
  var externalData = Async.applyAsync(loadDataFromExternalSystem, [dataB, arg2]);
  var appUI = Async.applySync(createUI, [app, dataA,  extenralData, preloadedImages]);
  return Async.applySync(app.addDialog, [appUI]);
}

def listInTree(curNode, pred):
  if pred(curNode):
    yield return curNode
  else:
    for sub in curNode.children():
      for res in listInTree(sub, pred)
         yield return res

ARK>Не думаю, что взаимодействие с внешним миром стоит приравнивать к глобальным переменным. Мир — это не глобальная переменная, он меняется независимо от программы. Уйти от взаимодействия с ним обычно нельзя. А глобальные переменные просто ухудшают структуру программы, ничего не давая взамен (ну точнее они дают легкость написания неподдерживаемого быдлокода ).

ARK> Ничего не понял, зачем чего-то перестраивать.

ARK>Куда инкапсулируем, в синглтоны?

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

int someFunction(res, &abrupt) {
a(1,2,3);
b(2,3,4);
return c(d(3), r(5));
}
// переписывается в 
int someFunction(res, &abrupt) {
var state = Normal;
var rd, rr, res;
a(1, 2, 3, &state);
if (!isAbruptCompletion(state))
  b(2, 3, 4, &state)
if (!isAbruptCompletion(state))
  rd = d(3, &state);
if (!isAbruptCompletion(state))
  rr = r(5)
if (!isAbruptCompletion(state))
  res = c(rd, rr);
(*abrupt) = *state;
return res;
}

ARK>  // child channel
ARK>  public Data GetData()
ARK>  {
ARK>    loadDataA();
ARK>    loadDataB();
ARK>    preloadImages();
ARK>  }
ARK>

ARK>Вообще, больше обратил внимание на отсутствие типов данных и в связи с этим многое не понял. Что такое dataA, dataB — данные или методы?

public interface Reactive<T> {
  public T get();
  public void addChangeListener(...);
  public void removeChangeListener(...);
}

data CommState<a> = Error String | Progress Double | Result a;

var dataA : Reactive<CommState<Ta>>
var dataB : Reactive<CommState<Tb>>
var preloadImages : Reactive<CommState<Unit>>
var externalData : Reactive<CommState<ExtT>>
var appUI : Reactive<CommState<UIControl>>
function preloadImagesForData(a : TA) : Reactive<CommState<Unit>>{}
function loadDataFromExternalSystem(b : Tb, arg2: someType) : Reactive<CommState<ExtT>>
function createUI(app : Application, a : Ta, ext : ExtT, imagesLoaded : Unit) : UIControl
function app.addDialog(ui : UIControl) : Unit

In computer science and programming, a continuation is an abstract representation of the control state of a computer program. A continuation reifies the program control state, i.e. the continuation is a data structure that represents the computational process at a given point in the process' execution; the created data structure can be accessed by the programming language, instead of being hidden in the runtime environment.

ARK>  List<TreeNode> ListInTree(TreeNode node, Predicate pred)
ARK>  {
ARK>    var result = new List<TreeNode>();

ARK>    if (pred(node))
ARK>    {
ARK>      result.Add(node);

ARK>      foreach (var childNode in node.Children)
ARK>      {
ARK>        result.AddRange(ListInTree(childNode, pred));
ARK>      }
ARK>    }

ARK>    return result;
ARK>  }
ARK>

ARK>Если возврат через discriminated union, то забыть обработать не выйдет. Придется матчить тэг и смотреть, что вернулось.

ARK>Но в языках общего назначения отказаться от таких штук совсем затруднительно.

ARK>return вызывает переход на следующую строку после вызова. Вполне определенная точка.

package com.pm.application.api

object Test extends App {
  private def xxx(a: => Int) {
    System.out.println("In XXXX")
    val aa = a
    System.out.println("AAA : " + aa)
  }

  private def bbb() : Int = {
    xxx({
      return 5
    })
    System.out.println("After XXX")
    6
  }
  
  System.out.println("BBB : " + bbb())
}

---- Output:
In XXXX
BBB : 5

int calculateSomething() {
  int j = 5;
  for (int i = 0; i < 10; i++) {
    try {
      return i; /// Just a return!
    } finally {
      j = i;
      if (i != 7)
        continue;
      else
        break;
    }
  }

  return j+1;
}

M>На самом деле еще хуже. Мой код требует памяти O(depth), где depth — глубина дерева (на самом деле поиска, я в дочерние узлы не захожу, если текущий узел удовлетворяет результату). Результат "разбирается" на месте. Ваш код требует O(depth) на стеке и еще O(result) для возврата результата. Там что-то порядка двоечки в O(result) входит, потому что на самом верхнем уровне рекурсии мы можем копировать почти весь результат с одной из веток. Да и со временем выполнения у вас не все гладко .

M>Что характерно, после введения нормальных union types и вывода типов, вы получите те же самые checked exceptions, реализованные вручную

ARK>>return вызывает переход на следующую строку после вызова. Вполне определенная точка.

  try
  {
    return 1;
  }
  finally
  {
    return 2;
  }

ARK>Посмотрел. Вроде тут везде просто применение уже готовых функций из itertools.

euler2 = fib() | where(lambda x: x % 2 == 0)
               | take_while(lambda x: x < 4000000)
               | add

ARK>  try
ARK>  {
ARK>    return 1;
ARK>  }
ARK>  finally
ARK>  {
ARK>    return 2;
ARK>  }
ARK>

ARK>Это — чистой воды говнокод. И, заметьте, из-за goto-подобных операторов return, break и continue. Если бы их не было, то таких вопросов не было бы в принципе.

int retval;
{
  {
    retval = 1;
  }
  retval = 2;
}
return retval;

ARK>В целом из всех "прыгающих" операторов я пока не знаю, как отказаться от исключений (про это писал в одном из постов выше). Ну и от полиморфизма отказываться не стоит. Остальное, ИМХО, вполне можно упразднить с разной степенью успеха.

IEnumerable<T> takewhile<T>(Predicate<T> predicate, IEnumerable<T> iterable)
{
  var result = new LazyList<T>();

  foreach (var x in iterable)
  {
    if (predicate(x))
      result.Add(x);
    else
      break;
  }

  return result;
}

IEnumerable<T> takewhile<T>(Predicate<T> predicate, IEnumerable<T> iterable)
{
  foreach (var x in iterable)
  {
    if (predicate(x))
      yield return x;
    else
      break;
  }
}

ARK>Внезапно разницы между моим вариантом и использованием yield return в этом аспекте нет, поэтому к чему все эти претензии —

ARK>Ай-яй-яй, обсуждаете мою квалификацию. Нехорошо-о-о.

ARK>Что именно непонятно? Семантически мы имеем просто список (с несколько урезанным функционалом, конечно ) или какой-то другой специфический контейнер. Можем абстрагироваться от того, что на самом деле вместо списка генератор.

IEnumerable<T> Repeat10000times<T>(T item)
{
  for(int i=0; i<10000; i++)
      result.Add(item);
  return result;
}

IEnumerable<T> split(bool takeOdds, IEnumerable<T> iterable)
{
  var odds = new List<T>();
  var evens = new LazyList<T>(); 
  int i = 0;
  foreach(var item in iterable)
    if (i++ % 2 == 1)
      odds.Add(item);
    else
      lazy evens.Add(item);

  return takeOdds? odds : evens;
}

ARK> Спасибо, хороший пример. Да, такой вариант не прокатит.

ARK>Этот ваш пример окончательно меня убедил, что свистоперделка под названием "yield return" не нужна. Если, конечно, не ставить целью засунуть в язык все, что может хоть когда-нибудь пригодиться.

public static IEnumerable<T> IterateTree<T>(this T root, Function<T, IEnumerable<T>> children)
{
  yield return root;
  foreach(var child in children(root))
    yield return child.IterateTree(children);
}

from Control c in this.IterateTree(control => control.Controls.Cast<Control>() 
 select c.ControlID)

var readTask = ReadTextAsync(someFile); // Запускаем асинхронное чтение

DoSomething(); // Метод выполняется синхронно

var text = await readTask; // Дожидаемся завершения чтения

// Продолжаем работу

var x = Enumerable.Range(1, 1000*1000*1000).AsParallel().Sum

ARK>Не нужно — пока, потому что нет нормальных решений. Кстати, я уже забыл, с чего все началось.

ARK>По моему мнению, чтобы эффективно писать программы с действительно массовым параллеллизмом (тысячи потоков), многопоточный код должен всячески мимикрировать под однопоточный. А у вас наоборот получается. Все ИМХО.