Здравствуйте, Serginio1, Вы писали:

S> а где здесь таски?

По ссылке то ходил? Или тебе конкретный объект Task<> нужен? Их, когда делали эту мару, еще не было. Но получилось даже лучше. По ссылке есть пример демонстрирющий переключение в GUI-потом из async-а:

private button1_Click (sender : object,  e : System.EventArgs) : void
{
  def formContext = SystemExecutionContexts.FromCurrentSynchronizationContext();
  def task = comp async
  {
    Thread.Sleep(5000);
    callcomp Async.SwitchTo(formContext);
    label1.Text = "success";
  }
  _ = task.Start(SystemExecutionContexts.ThreadPool());
}

S>И yield разве не конструкция .Net?

yield — это ключевое слово. В Немерле — это макра.

S>Да на ней сделаны и async и, но там куча вещей для работы с пулом потоков.

Любишь ты мысли не правильно излагать. Не "на ней", а "сходным образом", это если ты хочешь сказать, что и итераторы, и асинки в шарпе сделаны через генерацию конечных автоматов. Но Немерле это не так. В Немерле макра сделана на основе монад.

S> Да и разве в немерле был ref readonly?

В немерле были макры, которыми можно сделать и это тоже.

S>вот это нужные конструкции. Но это решение не на базе языка, а платформу.

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

S>Кстати в TypeScript поддержка await ов есть и в ES3. Там идет компиляция автомата в JS.

Ну, вот и подумай что это если не просто сахар? А если это сахр, то на фиг его хардкодить в языке? Не лучше ли сделать универсальное решение, которое позволит реализовывать сахар в виде библиотек?