wrong error on load "1abcde"

[Siskin-Bot]

Submitted by: IngoHohmann

LOADing a number followed by upto 4 characters returns an invalid integer error.
With more than 4 characters invalid decimal is returned

>> load "1abcd"   
** Syntax error: invalid "integer" -- "1abcd"
** Where: to case load
** Near: (line 1) 1abcd

>> load "1abcde"
** Syntax error: invalid "decimal" -- "1abcde"
** Where: to case load
** Near: (line 1) 1abcde

---

^{Imported from: CureCode [ Version: r3 master Type: Bug Platform: All Category: Error Handling Reproduce: Always Fixed-in:none ]
Imported from: metaeducation#2036}

Comments:

Rebolbot commented on Jul 3, 2013:

Submitted by: BrianH

It's guessing you're trying to write a decimal because of the e, which it interprets as an attempt at scientific notation. It's an error either way, so it's not really a bug.

---

Rebolbot commented on Jul 4, 2013:

Submitted by: IngoHohmann

I find the difference between raised errors unintuitive, and they make it hard to use transcode/next/error

See this difference between "1km" and "1miles"

>> transcode/next/error to binary! "1km"
== [make error! [
        code: 200
        type: 'Syntax
        id: 'invalid
        arg1: "integer"
        arg2: "1km"
        arg3: none
        near: "(line 1) 1km"
        where: [transcode]
    ] #{}]

>> transcode/next/error to binary! "1miles"
== [make error! [
        code: 200
        type: 'Syntax
        id: 'invalid
        arg1: "decimal"
        arg2: "1miles"
        arg3: none
        near: "(line 1) 1miles"
        where: [transcode]
    ] #{}]

Furthermore, the error may hint at a possible place for optimization. The moment, that a character other than "e" is found, it is clear that it is an error, so why check the following characters, wether there might be an "e"?

---

Rebolbot commented on Jul 8, 2013:

Submitted by: BrianH

TRANSCODE needs a lot of work (see #1327, #1857, #1915, #1916, and possibly #537, plus any syntax tickets), so we might want to adjust things. However, I don't think that you are right here. The errors triggered or returned by TRANSCODE are some of its most important features, and we need to make them as useful as possible.

Given that what you are trying to load is not correct, TRANSCODE can only apply some heuristics and guess that you were trying to do. Seeing whether there is an e there is a reasonable clue that you were failing to write a decimal, rather than failing to write an integer. TRANSCODE can't read your mind, it has to go by the evidence at hand to guess your intentions. Nonetheless, tweaking the heuristics (like in #537) might help us improve the errors triggered.

---

Rebolbot commented on Jul 16, 2013:

Submitted by: Ladislav

"The errors triggered or returned by TRANSCODE are some of its most important features, and we need to make them as useful as possible." - agreed.

However, Ingo is right that after finding out that there was an error it is a bad idea to parse additional characters from the input. Without a mind-reading module TRANSCODE cannot guess what the intent was. (might have been some kind of cut&paste error inserting some garbage)

The most useful information for me would be a part of input found to be wrong by TRANSCODE. What it was meant to be is not useful since there is no way how to correctly determine that.

---

Rebolbot added Type.bug and Status.dismissed on Jan 12, 2016

---

[Oldes]

Checking the source, there is not much space for optimization... for example in case 1xb the scanner tries to load integer, as there is 1, then finds x so changes its state to pair!, but then finds b, which is invalid, so throws invalid pair!.