I've checked in a fix for the match problem (which is how the report originally came in) by changing the
signature of match, match-i, substitute, and substitute-i. The fix is checked into the Release_0_4-bugfix
branch. However, there are still related problems, such as:
"1.2" "a" =
should probably treat "1.2" as a path instead of a float. There seems to be a whole category of problems
related to operator signatures.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is probably a tweak to the scanner, and to the function
that generates code elements from strings. They should both
treat strings like 1.2 as both a number and a path.
In addition, strings like
1231231212312123121212312124124124, which can't be
represented as numbers, should generate an error unless they
are quoted. Strings like
123123124124124124.12412412412412412412, on the other hand,
are fine unquoted, because they are also paths.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=536981
I've checked in a fix for the match problem (which is how the report originally came in) by changing the
signature of match, match-i, substitute, and substitute-i. The fix is checked into the Release_0_4-bugfix
branch. However, there are still related problems, such as:
"1.2" "a" =
should probably treat "1.2" as a path instead of a float. There seems to be a whole category of problems
related to operator signatures.
Logged In: YES
user_id=405402
This is probably a tweak to the scanner, and to the function
that generates code elements from strings. They should both
treat strings like 1.2 as both a number and a path.
In addition, strings like
1231231212312123121212312124124124, which can't be
represented as numbers, should generate an error unless they
are quoted. Strings like
123123124124124124.12412412412412412412, on the other hand,
are fine unquoted, because they are also paths.