I guess this behaviour is incorrect and it has probably been a bit overlooked. I don't think it could be done intentionally because zipping finite and infinite sequences is a common functional programming pattern. This is probably subject to be corrected in the future but currently you may use a workaround function. I have recenlty faced the same problem, here's the solution (I'm not sure about its performance though):

1
2
3
4
5
6
7
8
9
module SCG = System.Collections.Generic
      
let zipT (s1: #seq<'a>) (s2: #seq<'b>) =
  let rec z' (e1: 'a SCG.IEnumerator) (e2: 'b SCG.IEnumerator) =
    seq { if (e1.MoveNext()) && (e2.MoveNext()) then
           yield (e1.Current, e2.Current)
           yield! z' e1 e2
      }
  z' (s1.GetEnumerator()) (s2.GetEnumerator())

Then it's quite ok to write:

1
2
3
4
5
  let s1 = { 1 .. 10 }
  let s2 = { 1 .. 100 }
  let s3 = zipT s1 s2
  s3 |> Seq.to_list |> List.iter (fun (a, b) -> System.Console.WriteLine("{0}, {1}", a, b ))
By on 5/30/2008 7:41 AM ()

I've sent an email to fsbugs@microsoft.com (although the F# team is probably reading this forum).

By on 5/30/2008 3:15 PM ()

Yes, we do read this forum. [:)]

As we told Felixmar, it was a known issue in the released bits which we already fixed in our live branch.

-Matteo (F# Team)

By on 6/2/2008 5:16 PM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper