кажется, есть смысл для явного указания что вызов — хвостовой. ввести ключевое слово (типа "tail").

пока это позиционируется как "оптимизация", на неё можно только надеяться. однако, есть алгоритмы, где без неё — нельзя.

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

на feature request тянет?

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

__>кажется, есть смысл для явного указания что вызов — хвостовой. ввести ключевое слово (типа "tail").
__>пока это позиционируется как "оптимизация", на неё можно только надеяться. однако, есть алгоритмы, где без неё — нельзя.
__>программист мог бы явно указать компилятору чего он хочет, компилятор мог бы ругаться, если так сделать не получается.
__>на feature request тянет?
Нет. Оптимизация хвостовой рекурсии для функциональных языков является жизненно важной ибо циклы реализованны через нее.
Таким образом можешь не сомневаться что все хвостовые вызовы будут оптимизированны ибо без этого никак.

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

__>>кажется, есть смысл для явного указания что вызов — хвостовой. ввести ключевое слово (типа "tail").
__>>пока это позиционируется как "оптимизация", на неё можно только надеяться. однако, есть алгоритмы, где без неё — нельзя.
__>>программист мог бы явно указать компилятору чего он хочет, компилятор мог бы ругаться, если так сделать не получается.
__>>на feature request тянет?
WH>Нет. Оптимизация хвостовой рекурсии для функциональных языков является жизненно важной ибо циклы реализованны через нее.
WH>Таким образом можешь не сомневаться что все хвостовые вызовы будут оптимизированны ибо без этого никак.

Мне кажется, он говорил про введение некоего хинта компилятору. То есть, если программист думает, что вызов хвостовой, а он таковым не является, то компилятор должен ругнуться (при наличии хинта).

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

__>на feature request тянет?

Не очень, так как практического смысла в этом нет. Загрязнять код под. аннотациями? Ради чего?

_pk_sly сказал верно — оптимизация гарантированно будет если вызов концевой.

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

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

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

__>кажется, есть смысл для явного указания что вызов — хвостовой. ввести ключевое слово (типа "tail").

__>пока это позиционируется как "оптимизация", на неё можно только надеяться. однако, есть алгоритмы, где без неё — нельзя.

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

__>на feature request тянет?

Я бы засабмитил более практичный запросик: генерировать "acc", чтобы сделать вызов хвостовым.

def f (_) { //добавлением acc к параметрам превращается в хвостовую рекурскию
  | 0 => []
  | x => x :: f (x - 1) 
}
def g (_) { //немного сложнее, но добавлением  acc, mul тоже превращаемо в хвостовую рекурсию
  | 0 => 0
  | x when x % 2 == 1 => x + g (x / 2)
  | x => x * g (x - 2)
}

Это вполне стандартный рефакторинг рекурсии, его мог бы делать/подсказывать компилятор/макрос сам/(по запросу).

Изначальный feature request можно сделать, но желательно приложить к нему пример кода где хвостовой вызов ожидается, но не происходит.

Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Изначальный feature request можно сделать, но желательно приложить к нему пример кода где хвостовой вызов ожидается, но не происходит.

Вот:

 length[T] (l : list [T]) : int {
        match (l) {
          | _ :: tail => 1 + length(tail)
          | _ => 0
        }
    }

    length1[T](l: list[T], acc: int = 0): int {
        match (l) {
          | _ :: tail => length1(tail, acc + 1)
          | [] => acc
        }
    }

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

Здравствуйте, Иванков Дмитрий, Вы писали:

ИД>Я бы засабмитил более практичный запросик: генерировать "acc", чтобы сделать вызов хвостовым.

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

Здравствуйте, <Аноним>, Вы писали:

ИД>>Изначальный feature request можно сделать, но желательно приложить к нему пример кода где хвостовой вызов ожидается, но не происходит.
А>Вот:
А>

А> length[T] (l : list [T]) : int {
А>        match (l) {
А>          | _ :: tail => 1 + length(tail)
А>          | _ => 0
А>        }
А>    }

А>    length1[T](l: list[T], acc: int = 0): int {
А>        match (l) {
А>          | _ :: tail => length1(tail, acc + 1)
А>          | [] => acc
А>        }
А>    }
А>

А>второй вариант оптимизируется в цикл, а первый нет.

И что, в первом случае это ожидается? Это черезчур оптимистично, ведь в первом случае рекурсия вовсе не хвостовая.

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

именно так

K>в первом случае рекурсия вовсе не хвостовая.

првда??
а какая же?

а тут?

f(x)
{
  if (...) {
     f(x+1);
  } else if (...) {
     f(x-1);
  } else {
     0;
  }
}

все вызовы — хвостовые.

VD>В прочем, изложи свои аргументы в конфе на английском

лазил по сайту, конфы не нашёл.
нашёл maillist в google groups и багтрак.

что имеется ввиду?

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

K>>в первом случае рекурсия вовсе не хвостовая.

__>првда??
__>а какая же?

__>а тут?
__>

__>f(x)
__>{
__>  if (...) {
__>     f(x+1);
__>  } else if (...) {
__>     f(x-1);
__>  } else {
__>     0;
__>  }
__>}
__>

__>все вызовы — хвостовые.

Хвостовой вызов означает, что вызов есть последнее выражение, а для "1+f()" это не так.
Проблема в том, что надо хранить "1+_", в стеке(наряду с ним могут одновременно быть произвольные другие трансформации результата, "2*_", "g(_)", "1::_", ...), что уже не похоже на goto, просто обычный вызов.

Сделать из рекурсии хвостовую не всегда тривиальная задача.

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

__>лазил по сайту, конфы не нашёл.
__>нашёл maillist в google groups и багтрак.

__>что имеется ввиду?

Имелся в виду maillist, но по большому счету все равно. Группа гугля транслируется в него.