search

gracelang / minigrace

Self-hosting compiler for the Grace programming language
39 stars 22 forks source link

".." range operator fails to raise exceptions on invalid ranges #168

Closed petercowal closed 8 years ago

petercowal commented 8 years ago

While range.from 1 to 1.5 raises the proper exception, 1..1.5 fails to raise an exception. Similarly, 1.."foobar" also fails to raise an exception.

apblack commented 8 years ago

Fixed in 722297dc6c9e8c1126f8d0c1fa3a25013a44cdcb

KimBruce commented 8 years ago

The program

for (1..3.1) do {n ->
    print(n)
}

Results in the error message: "TypeError: Cannot read property 'asString' of undefined"

It needs something more helpful than that.

Note that originally the semantics of 1..3.1 was to return the same as 1..3. I actually took advantage of that in some of my code. However, the more restrictive approach makes sense.

kjx commented 8 years ago

On 4/06/2016, at 09:39, Kim Bruce notifications@github.com wrote:

1..3.1

Which is why we should have spaces around operators...

apblack commented 8 years ago

I think that you are using an out-of date version — from before this bug was fixed. On your example (in version 3223) I get:

RequestError on line 1 of range_test: upper bound of range (3.1) not an integer.
  raised at number... at line 1 of range_test
  called from execution environment.
   1: for (1..3.1) do {n ->
   2:     print(n)
Stack frames:
  range_test module

If you want .. to just take the floor, we could do that. What about range.from(_)to(_)? I think that I decided that checking for the argument being an integer made more sense, but I can see both sides.