Why is the F # compiler intertwined with seq {0L ..- 5L ..- 10L}?

I have a bit of a problem with declaring an int64 downstream sequence.

I want it:

 seq{0L..-5L..-10L};; 

However, I get the error message:

  seq{0L..-5L..-10L};; ---^^^^^^^^^^^^^^^ stdin(5,4): error FS0739: Invalid object, sequence or record expression 

Interestingly, it works with a regular int :

 > seq{0..-5..-10};; val it : seq<int> = seq [0; -5; -10] 

Even more interesting, if I put spaces between .. , it also starts working with int64 :

 > seq{0L .. -5L .. -10L};; val it : seq<int64> = seq [0L; -5L; -10L] 

Can someone explain why the compiler gets into a twist using seq{0L..-5L..-10L} ?

+6
source share
1 answer

I agree that this is a bit strange behavior. It is usually recommended (although not required by the specification) to write spaces around .. , in which case it works correctly. Therefore, I recommend using:

 seq { 0 .. -5 .. -10 } seq { 0L .. -5L .. -10L } 

Why does this behave differently for int and int64 ? You may notice that when writing 1..-2 and 1L..-2 Visual Studio colors the text differently (in the first case .. has the same color as numbers, in another case it has the same color as and .. with spaces).

The problem is that when the compiler sees 1. , it could mean a floating point value ( 1.0 ), or it could be the beginning of 1.. , so this case is handled specially. For 1L. this is not a problem - 1L. should be the beginning of 1L..

So, if you write 1..-5..-10 , the compiler uses special processing and generates a sequence. If you write 1L..-5..-10 , the compiler parses ..- as a unary operator that applies to 5L . Writing spaces allows ambiguity between the unary operator and .. , followed by a negative number.

For reference, here is a screenshot from my Visual Studio (which shows 10.. green, but .. on the second line in yellow - not a particularly noticeable difference, but they are different :-))

enter image description here

+6
source

Source: https://habr.com/ru/post/952886/


All Articles