Хочу прояснить механизм работы меток в языке.
Например есть следующий код:

def a = [1, 2, 3, 4];
def x = x_result: {
    foreach(i in a) {
        when(i == 3)
            x_result(i)
    }
    0;
}
WriteLine(x);

Если принять к сведению, что foreach — это макрос, разворачивающийся в рекурсивную функцию, — то каким образом происходит передача управления изнутри нее в метку x_result, находящуюся вовне?
Видимо близким аналогом можно считать такой код:

def a = [1, 2, 3, 4];
def x = x_result: {
    def loop(lst) {
        | i :: tail => 
            when(i == 3)
                x_result(i);
            loop(tail)
        | _ => 0
    }
    loop(a)
}
WriteLine(x);

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

Похоже что механизм меток контролирует логику переходов уже после того, как произошли все оптимизации хвостовых рекурсий, так как на код вида

def x = x_result: {
    def loop(lst) {
        | i :: tail => 
            _ = loop(tail);
            when(i == 3)
                x_result(i);
            0
        | _ => 0
    }
    loop(a)
}
WriteLine(x);

компилятор сообщает об ошибке перехода

Error: non local goto (block return?) detected

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

H>Хочу прояснить механизм работы меток в языке.
H>Например есть следующий код:
H>

H>def a = [1, 2, 3, 4];
H>def x = x_result: {
H>    foreach(i in a) {
H>        when(i == 3)
H>            x_result(i)
H>    }
H>    0;
H>}
H>WriteLine(x);
H>

Это не метки, а именованные блоки — базовая фича языка.

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

H>Похоже что механизм меток контролирует логику переходов уже после того, как произошли все оптимизации хвостовых рекурсий
Ну да, примерно так и есть, от того инлайнится ли функция может зависеть компилируемость block return и yield.

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

H>Error: non local goto (block return?) detected
H>

Эх, а со стороны так на named let было похоже.

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

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

H>Похоже что механизм меток контролирует логику переходов уже после того, как произошли все оптимизации хвостовых рекурсий, так как на код вида
H>

H>def x = x_result: {
H>    def loop(lst) {
H>        | i :: tail => 
H>            _ = loop(tail);
H>            when(i == 3)
H>                x_result(i);
H>            0
H>        | _ => 0
H>    }
H>    loop(a)
H>}
H>WriteLine(x);
H>

H>компилятор сообщает об ошибке перехода

H>

H>Error: non local goto (block return?) detected
H>

А ведь в принципе такой код можно сделать рабочим, стоит только вспомнить об исключениях.
x_result(i) выбрасывает исключение, а в блоке x_result происходит его перехват — вуаля, мы получаем результат (да здравствует доширак!). Но, конечно, производительность такого подхода будет невысока.

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

H>А ведь в принципе такой код можно сделать рабочим, стоит только вспомнить об исключениях.
H>x_result(i) выбрасывает исключение, а в блоке x_result происходит его перехват — вуаля, мы получаем результат (да здравствует доширак!). Но, конечно, производительность такого подхода будет невысока.

И промежуточный catch все испортит. Так, кстати, было сделано в Scala.

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

N>И промежуточный catch все испортит.

Да, заэкранировать catch во внешнем коде не выйдет.

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

N>И промежуточный catch все испортит. Так, кстати, было сделано в Scala.

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