One thing that has been a little confusing to me is the .. vs ... operators for int ranges. I can never remember which is which: does more dots mean more numbers in the range? (no)

Last month I read through a Haskell tutorial where the range operators are .. and ..<. That is:

(1..5).toList  => [1, 2, 3, 4, 5]
(1..<5).toList => [1, 2, 3, 4]

What I like most about these is that they translate naturally into speech: 1 to 5 vs. 1 to less than 5.

Maybe I've missed an old discussion where this was already debated, but I think it would do wonders for code clarity if we could reconsider the syntax in this case.

I'm going with, two dots is the to operator; 1..5 is 1 to 5 is 1,2,3,4,5.

Those operators are taken straight from Ruby. I can't disagree that it takes a little while to get use to them. Here is something I found on the web a while ago:

Are you finding it hard to remember which is which? My way of remembering is: every range is the same width, in relation to the operators. Since the ... operator is wider, the end-point gets pushed outside the range:

v  v
a..b
a...b
^  ^

I am open to changing to the syntax if something I really love is proposed, otherwise I'd prefer to copy an existing language. I don't particularly love either ..< or to.

Groovy also uses .. and ..<, and I think they are much easier to remember. I think they started out with Ruby syntax but changed it along the way (presumably for the reasons brought up here).

Yeah I have the same problem remembering sometimes. I don't think its a huge deal - but I do sort of like the ..< syntax.

I don't particularly love ..< either but it's more intuitive than ....

Any particular grammar problems with the math notation:

[1..3] = 1,2,3

[1..3[ = 1,2

]1..3[ = 2

?

Any particular grammar problems with the math notation

The index operator [] is orthogonal to range literals .., so the two syntax constructs don't know about each other.

For example:

fansh> r := 1..3
1..3
fansh> Int.random(0..100)
65

I like the ..< operator. It's simply more intuitive.

Here is the original discussion when we picked the two operators.

I also found this Groovy note (didn't search around for the mail list notes on the change).

Any more votes for changing from ... to ..< or other suggestions?

I don't have a strong opinion if everybody wants to switch.

Out of curiosity, what does fan do with an exclusive range like 0...0? e.g. in fansh (0...0).toList raises an error.

In my testing in fansh I've also noticed that (3..0).contains(2) evaluates to false so I think there's a bug in there.

Following up to my previous comment, I think it would make more sense for (0...0).toList (or (0..<0).toList) to return an empty list rather than throw an error.

In my testing in fansh I've also noticed that (3..0).contains(2) evaluates to false so I think there's a bug in there.

For whatever reason I made Range.toList support reverse ranges, but not contains and each. I pushed a fix so that all three toList, contains, and each handle both forward and reverse ranges consistently. I also fixed the empty list exception.

I just finished writing some tests to capture this, I'll mail you the diff.

You can go Number Theorist and do:

[0,3] // 0,1,2,3
(0,3] // 1,2,3
(0,3) // 1,2
[0,3) // 0,1,2

The Groovy thread is interesting reading - I strongly recommend reading this one message, as well as the rest of the thread.

http://markmail.org/search/?q=groovy+range+operator#query:groovy%20range%20operator+page:2+mid:gz4ogz3hilxofqwe+state:results

In particular, a usability survey was done to determine the best style for the operators.

I would support ..< as the exclusive range. I'd also question the negative range definitions based on the usability study in the link.

Alternativly we could just drop support for exclusive and simply have the single .. operator? Do we really need both?

I'd also question the negative range definitions based on the usability study in the link.

Mabye, but in practice that is way too nice a thing to give up IMO.

OK lets make the decision and switch from using the ... token to ..< for exclusive ranges. I will do that for the next build.

Regarding reverse ranges: in terms of slicing strings and list, if start < end then it is considered an empty range:

fansh> "abcd"[0...0].toCode
""
fansh> "abcd"[3..2].toCode
""

But in terms of Range.toList, each, and contains we do support reverse ranges:

fansh> (3..2).toList
[3, 2]

This seems like a practical trade-off to me. Slicing only supports forward ranges and negative indices have special semantics. On the other hand the Range methods are more pure mathematical. That inconsistency seems fine to me, but I'd be open to other suggestions.

Regarding reverse ranges: in terms of slicing strings and list, if start < end then it is considered an empty range:

Did you mean to say if end < start?

Did you mean to say if end < start?

Yes sorry

I started working on making this change in the compiler last night. I modified all pod sources (and fandocs) to use the new syntax. However I have to recompile the compiler pod to interpret the new operator before I can modify the compiler sources to actually use them.

I can run the buildboot.fan and buildpods.fan scripts successfully but when I try to copy the compiled pods from \dev\fan\lib\fan to \dev\rel\lib\fan and from \dev\fan\lib\java to \dev\rel\lib\java I get a compiler error:

C:\dev\fan\src>fan buildboot.fan clean full
clean [sys]
  Delete [/C:/dev/fan/lib/fan/sys.pod]
  Delete [/C:/dev/fan/lib/java/sys.jar]
  Delete [/C:/dev/fan/lib/dotnet/sys.dll]
  Delete [/C:/dev/fan/lib/dotnet/sys.pdb]
clean [java]
  Delete [/C:/dev/fan/src/sys/java/temp/]
clean [dotnet]
clean [compiler]
  Delete [/C:/dev/fan/lib/fan/compiler.pod]
clean [compilerJava]
  Delete [/C:/dev/fan/lib/fan/compilerJava.pod]
clean [build]
  Delete [/C:/dev/fan/lib/fan/build.pod]
clean [sys]
compile [sys]
  Compile [sys]
    FindSourceFiles [76 files]
    WritePod [/C:/dev/fan/lib/fan/sys.pod]
clean [java]
compile [java]
  CreateDir [/C:/dev/fan/src/sys/java/temp/]
  CompileJava
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
  Write Manifest [C:\dev\fan\src\sys\java\temp\Manifest.mf]
  Jar [C:\dev\fan\lib\java\sys.jar]
  Exec [C:\Program Files\Java\jdk1.6.0\bin\jar.exe cfm C:\dev\fan\lib\java\sys.jar C:\dev\fan\src\sys\java\temp\Manifest.mf -C C:\dev\fan\src\sys\java\temp .]
  clean [dotnet]
compile [dotnet]
  CompileCs
clean [compiler]
compile [compiler]
  Compile [compiler]
    Depends [/C:/dev/fan/lib/fan/]
     FPod.reading [/C:/dev/fan/lib/fan/sys.pod]...
    FindSourceFiles [87 files]
C:\dev\fan\src\compiler\fan\steps\InitEnum.fan(78,9): Self assignment
BUILD FAILED [8421ms]!

The self-assignment checks are a recent addition on the official repository so I don't think this error is caused by my changes. Can somebody verify whether they are able to build from source and then build the source again against said build?

I have not modified the boot strap pods (build and compiler) to work with the latest changes. I am trying to keep everything working using the build 40 as the bootstrap compiler. Otherwise it is too easy to screw yourself with a compiler bug.

How do you suggest I proceed? Should I revert all sources to use ... and then modify the compiler to allow both ... and ..< as a stopgap?

How do you suggest I proceed? Should I revert all sources to use ... and then modify the compiler to allow both ... and ..< as a stopgap?

In general I just change compiler and fix all the pods buildpods. Then when I am ready to upgrade the bootstrap is when I go back and fix compiler and build.

I've pushed my changes here.

The first changeset (modifying the compiler to expect ..< instead of ...) is here

Modifying the compiler to actually use internally ..< is next.

I forgot to mention I'm getting a compiler error in sys/fan/Locale.fan that Locale.with should use the override modifier--this looks like overlap with the current work on it-blocks.

I've updated my working copy to the official sources and following this process to try updating the bootstrap:

• C:\dev\fan\src>fan buildboot.fan clean full
  • build completes successfully
• C:\dev\fan\src>fan buildpods.fan clean full
  • ditto
• Rename C:\fan\lib\fan\ to fan_orig
• Copy C:\dev\fan\lib\fan folder into C:\fan\lib\fan
• Rename C:\fan\lib\java\ to java_orig
• Copy C:\dev\fan\lib\java folder into C:\fan\lib\java
• Add override keyword to sys::Locale.with method to keep new compiler happy
• C:\dev\fan\src>fan buildboot.fan clean full
  • Compiler error C:\dev\fan\src\compiler\fan\steps\InitEnum.fan(78,9): Self assignment

This is run against the official fandev tip so this is definitely isolated from my changes--there is a problem in the way the compiler detects self-assignment.

I pushed the change to support "..<" to hg. I left the old "..." operator in place (I will take it out after next build). qualidafial I didn't use your repo b/c I had some merge issues - but pretty much the same changes.

This is run against the official fandev tip so this is definitely isolated from my changes--there is a problem in the way the compiler detects self-assignment.

Don't bother trying to update your bootstrap compiler - there are a couple things I have to fix for that.

I think I found the reason my bootstrap build won't compile InitEnum: In Expr.fan the method LocalVarExpr.sameVarAs checks that two vars are using the same register but does not check whether they share the same context. So in InitEnum.addCtor the first local var (and thus the var in register #0) is:

MethodDef? m := null

Farther down the closure passed to ctors.each has a signature |MethodDef ctor|, so the ctor argument is in register #0 within the closure. So LocalVarExpr.sameVarAs returns true for the m and ctor expressions because they are both stored in register 0, even though they belong to different lexical scopes. Here is a test for testCompiler::CheckErrorsTest that captures this behavior:

Void testSelfAssignment() {
  verifyErrors(
    "class Foo
     {
        Obj a
        new b(Obj a) { this.a = a } // ok
        new b01(Obj a) { a = a } // self-assignment
        new b02() { Obj a := 1; [2].each |Obj b| { a = b } } // ok
     }",
      [
        5, 21, "Self assignment",
      ]);
}

I think I found the reason my bootstrap build won't compile InitEnum: In Expr.fan the method LocalVarExpr.sameVarAs checks that two vars are using the same register but does not check whether they share the same context.

Great catch Matthew! I started stubbing out the self assignment tests, but obviously they still needed some work. I pushed a fix which should fix the problem.

I've pulled the update and it seems to have fixed the problem--only to surface another compiler bug:

clean [compilerJava]
compile [compilerJava]
  Compile [compilerJava]
    FindSourceFiles [7 files]
C:\dev\fan\src\compilerJava\fan\JavaReflect.fan(86,13): Expected ';', not ':='

When I get some more time I'll try doing a bisect to find out which changeset broke it.

I've pulled the update and it seems to have fixed the problem--only to surface another compiler bug:

That is just an it keyword conflict. I pushed a fix.