Back to Questions
1.3k
views6
comments
the trouble brought by F# due to confused scope
f#

I know that in F#, no { } used as in c#/c++,

also no any endmark key word, therefore the effective scope such as for a for loop is only defined by appropriate indentation. it is really not convenient and it is easy to make a careless mistake, for example, the following simple two dim arry assignment and output, last line printfn "" with different indentations, it will output different matrix.

of course, it is a simple code, if for a more complicated code, I think it may not be easy to find out the exact indentation which one you really want. Then from this viewpoint, maybe { } is still better to have or one more key words such as end is appied. I do not know whether my suggestion is reasonable and necessay. This is just my feeling.

let array2=Array2.zero_create<int> 2 3;;

for i=0 to 1 do

for j=0 to 2 do

array2.[i,j]<- i+j

printf "%i " array2.[i,j]

printfn ""

.

Hi,
you can use "#light off" switch to make F# indentation-insensitive if you want. This of course requires additional keywords that specify what the code means, so your example would look like this:

1
2
3
4
5
6
7
8

#light "off"
let array2=Array2D.zeroCreate 2 3 in
for i=0 to 1 do 
for j=0 to 2 do 
array2.[i,j] <- i * j; printf "%i " array2.[i,j] 
done
done;
printfn ""

Note that I had to add "in" to the let declaration, added "done" keywords to end the loop and added couple of semicolons. You'd also need double-semicilon to end module declarations and some other noise. However, it's sometimes interesting to see this in order to understand how F# understands the code.

This is perfectly valid F# style and if you really prefer it then feel free to use it, however I think that most of the F# programmers prefer the lightweight noise-free version. Afterall, it's good practice to write properly indented code anyway, so if you're writing polished code, it should work in the lightwetigh mode.

By on 5/26/2009 12:55 PM ()

thank you for your hint.

It seems light off and on give both adv. and disadv. But I think for those who are familiar with c/c# like more light off grammar. unfortunately, most F# books only talk about light grammar. Are many differences between light and light off?

By on 5/26/2009 1:17 PM ()

There are not too many, but I don't know a good summary of differences; even the spec is short on a summary of examples here

[link:research.microsoft.com]

though you can read through the details of the spec, e.g. subsections of

[link:research.microsoft.com]

and see all the 'Note's about #light.

By on 5/26/2009 1:30 PM ()

The Dev10 Beta has online docs, which has a comparison of light and "verbose" syntax.

[link:msdn.microsoft.com]

Gordon

By on 5/26/2009 5:43 PM ()

Hello,
Good Stuff. I feel though that it may at times be better to save energy and keep the #light off. It is my main reason for staying away from IronPython (or all pythons in general). Good day.

Yemi Bedu

By on 7/16/2009 4:14 PM ()

Hi,
I think there is a relatively small number of differences. First of all, you have to insert ';' between every two expressions when you want to sequence them. Next, there are couple of changes like these:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

 
let x = 0
// becomes
let x = 0 in

let foo x = 
  printfn "%d" x
  x + 1
// becomes
let foo x = 
  printfn "%d" x;
  x + 1;;

type A() = 
  member x.Foo() = 0
// becomes
type A() = class // or 'interface' if it is an interface
    member x.Foo() = 0
  end;;

Next changes are that for & while loops have to be ended with done keyword. If you want to learn more about this syntax, you can possibly take a look at OCaml langauge, which inspired F#, but which uses only the non-light syntax: [link:www.ocaml-tutorial.org]. However things that are related to .NET objects in F# will be different.

By on 5/26/2009 1:25 PM ()

    Topic tags

    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