16

According to the F# spec (see §6.5.7), simple for loops are bounded by integer (int aka int32 aka System.Int32) limits start and stop, e.g.

for i = start to stop do
    // do sth.

I wonder why the iteration bounds for this type of for loop are required to be int32. Why not allow uint32? int64? bigint?

I'm aware that sequence iteration expressions (for ... in ...) can iterate over arbitrary sequences; that however requires allocating an iterator and calling MoveNext and Current and what not and can thus be considerably less efficient than a plain loop could be (increment counter, compare, conditonal jump). To avoid that, you are stuck with using while and a manually incrementing loop counters...

Strangely enough, F# does allow non-int32 loop bounds, if the for expression is wrapped in a sequence expression, e.g.

seq { for i = 0I to 10I do
        printfn "%A" i }

So, I guess the question is: Is there a particular reason for only allowing int32 for loops? And why does this restriction not apply to for loops wrapped in seq expressions?

Guy Coder
  • 24,501
  • 8
  • 71
  • 136
Frank
  • 2,738
  • 19
  • 30
  • In general, the .NET framework uses `int` as a general-purpose integer, including its use in all sorts of numerical indexing scenarios. Example: http://msdn.microsoft.com/en-us/library/system.array.indexof(v=vs.71).aspx. Counter-example: http://msdn.microsoft.com/en-us/library/system.io.filestream.position.aspx, which uses a long. – Robert Harvey Apr 16 '13 at 19:59
  • 4
    F# encourages functional programming and therefore stops short of full imperative support (e.g., the lack of `break`/`return`). Within a computation expression `for` is desugared to a method call, which isn't inherently imperative like a loop, and therefore doesn't have the same limits. I can understand the mystery though. +1 – Daniel Apr 16 '13 at 20:32
  • @Daniel +1 "Within a computation expression for is desugared to a method call". I see; actually the code generated for `seq { for .. to .. do .. }` and `seq { for .. in .. do }` is largely identical, both are transformed to a `GeneratedSequenceBase<_>` enumerator. – Frank Apr 17 '13 at 08:49

3 Answers3

7

I'm not sure why F# does not allow int64 ranges. It sounds like a useful feature... (but I can understand that int is the standard type for this in C# and perhaps F# tries to follow this pattern).

As for the workarounds, it is worth adding that you can also write inline higher-order function:

let inline longFor low high f = 
  let rec loop n =
    if n < high then f n; loop (n + 1L)
  loop low

...and then you can express for loops over int64 ranges in a fairly succinct way:

longFor 1L 100L (fun n -> 
  <whatever> )

I did a couple of experiments and it seems that the F# compiler is able to optimize this fairly decently (the lambda function is inlined and the tail-recursive loop function is turned into a while loop). I do not think this is guaranteed so you may need to check this by hand in high-performance code, but it seems to work fine for simpler examples.

There is only one disadvantage - you won't be able to use local mutable variables (let mutable) because these cannot be captured by a lambda function. So there may be additional cost with indirect ref cells (but I'm not sure how big problem this is).

Tomas Petricek
  • 240,744
  • 19
  • 378
  • 553
  • 1
    +1 I also recently experimented with how the F# compilers handles inlined higher-order functions and I was quite surprised (and pleased) to see that it even inlines lambdas at the call site, at least as of F# 3.0. I now use an approach very similar to your suggestion, but with an imperative while loop instead of tail-recursion (so I can use a plain mutable instead of a ref cell). Seems to work fine so far. – Frank Apr 17 '13 at 08:37
2

If you want to keep the for-loop, there's a very simple work-around using the for...in loop with a sequence range operator:

for i in 0I .. 10I do
    printfn "%A" i

The range operator will accept any integer of any size as long as both types match. For example, the following will not compile:

for i in 0 .. 10I do
    printfn "%A" i
JDB
  • 25,172
  • 5
  • 72
  • 123
  • Thanks, but I'm aware of that; read the second paragraph of my question. – Frank Jan 24 '14 at 21:33
  • Oops... missed that. Was coming from [another question](http://stackoverflow.com/q/21292082/211627)... – JDB Jan 25 '14 at 03:20
0

Another possible workaround:

[1L..100L] |> List.iter (fun i -> printfn "%i" i)

Kit
  • 2,089
  • 1
  • 11
  • 23