Избежание переполнения стека (с бесконечными последовательностями последовательностей F# )

у меня есть этот "обучающий код", который я написал для morris seq в f#, который страдает от переполнения стека, которого я не знаю, как избежать. "Моррис" возвращает бесконечную последовательность последовательностей" видеть и говорить " (т. е., {{1}, {1,1}, {2,1}, {1,2,1,1}, {1,1,1,2,2,1}, {3,1,2,2,1,1},...}).

    let printList l =
        Seq.iter (fun n -> printf "%i" n) l
        printfn ""

    let rec morris s = 
        let next str = seq {
            let cnt = ref 1  // Stack overflow is below when enumerating
            for cur in [|0|] |> Seq.append str |> Seq.windowed 2 do
                if cur.[0] <> cur.[1] then
                    yield!( [!cnt ; cur.[0]] )
                    cnt := 0
                incr cnt
        }
        seq {
        yield s
        yield! morris (next s) // tail recursion, no stack overflow
        }

    // "main"
    // Print the nth iteration
    let _ =  [1] |> morris |> Seq.nth 3125 |> printList 

вы можете выбрать N-ю итерацию с помощью Seq.nth, но вы можете получить только так далеко, прежде чем вы нажмете переполнение стека. Один бит рекурсии, который у меня есть, - это хвостовая рекурсия, и она по сути строит связанный набор переписчиков. Проблема не в этом. Это когда "перечисление" вызывается, скажем, в 4000-й последовательности. Обратите внимание, что это с F# 1.9.6.16, предыдущая версия превысила 14000). Это потому, что способ разрешения связанных последовательностей. Последовательности ленивы, и поэтому "рекурсия" ленива. То есть seq N вызывает seq n-1, который вызывает seq n-2 и т. д., Чтобы получить первый элемент (самый первый # - худший случай).

Я понимаю, что [|0|] |> Seq.append str |> Seq.windowed 2, у меня проблема хуже, и я мог бы утроить # , который я мог бы создать, если бы я исключил это. Практически говоря код работает достаточно хорошо. В 3125th итерации Моррис будет более 10^359 символов.

проблема, которую я действительно пытаюсь решить, - это как сохранить ленивый eval и не иметь ограничений на размер стека для итерации, которую я могу выбрать. Я ищу правильную идиому F#, чтобы сделать предел на основе размера памяти.

Обновить Oct '10

после изучения F# немного лучше, немного Haskell, думая и исследуя эту проблему в течение года, я, наконец, могу ответить на свой собственный вопрос. Но, как всегда в сложных случаях, проблема начинается с того, что это неправильный вопрос. Проблема не в последовательностях последовательностей-это действительно из-за рекурсивно определенной последовательности. Мои навыки функционального программирования теперь немного лучше, и поэтому легче увидеть, что происходит с версией ниже, которая по-прежнему получает stackoverflow

let next str = 
    Seq.append str [0]
    |> Seq.pairwise
    |> Seq.scan (fun (n,_) (c,v) ->
            if (c = v) then (n+1,Seq.empty)
            else (1,Seq.ofList [n;c]) ) (1,Seq.empty)
    |> Seq.collect snd

let morris = Seq.unfold(fun sq -> Some(sq,next sq))

это в основном создает действительно длинную цепочку вызовов функций обработки Seq для генерации последовательностей. Модуль Seq, который поставляется с F#, не может следовать цепочке без использования стека. Существует оптимизация, используемая для добавления и рекурсивно определенных последовательностей, но эта оптимизация работает только в том случае, если рекурсия реализует добавление.

так это будет работать

let rec ints n = seq { yield n; yield! ints (n+1) }
printf "%A" (ints 0 |> Seq.nth 100000);;

и этот получит сайте StackOverflow.

let rec ints n = seq { yield n; yield! (ints (n+1)|> Seq.map id) }
printf "%A" (ints 0 |> Seq.nth 100000);;

чтобы доказать, что F# libary был проблемой, я написал свой собственный модуль Seq, который реализовал добавление, попарно, сканирование и сбор с помощью continutions, и теперь я могу начать генерировать и распечатывать 50,000 seq без проблем (он никогда не закончится, так как он превышает 10^5697 цифр).

дополнительные сведения:

• продолжения были идиомой, которую я искал, но в этом случае они должны были идти в библиотеку F#, а не в мой код. Я узнал о продолжениях в F# от и Tomas Petricek это Реальное Функциональное Программирование книги.
• ленивый ответ списка, который я принял, содержал другую идиому; ленивая оценка. В моей переписанной библиотеке мне также пришлось использовать ленивый тип, чтобы избежать stackoverflow.
• ленивая версия списка работает на удачу (возможно, по дизайну, но это выходит за рамки моей текущей способности определять) - активный шаблон, который он использует, пока он построение и итерация заставляет списки вычислять значения до того, как требуемая рекурсия станет слишком глубокой, поэтому она ленива, но не настолько ленива, чтобы избежать stackoverflow. Например, ко времени, когда 2-й последовательности нужна цифра из 1-й последовательности, она уже вычислена. Другими словами, версия LL не является строго ленивой для генерации последовательности, только управление списком.