Closed dram closed 8 years ago
I wonder if any Dylan code contained within Mindy relies upon this.
One way to find out?
On 29 October 2015 15:07:40 CET, Bruce Mitchener notifications@github.com wrote:
I wonder if any Dylan code contained within Mindy relies upon this.
Reply to this email directly or view it on GitHub: https://github.com/project-mindy/mindy/issues/39#issuecomment-152191641
Sent from my Android device with K-9 Mail. Please excuse my brevity.
@dram Have you tried fixing this and seeing what happens?
I'm a bit busy recently, do not have time to inspect whole Mindy codebase for usages of logical operators. If someone can help out, please go ahead.
A quick grep finds:
libraries/regular-expressions/interface.dylan: if (~substring-start | (count & (count <= string-number)))
libraries/string-extensions/character-type.dylan: (c >= 'a' & c <= 'z') | (c >= 'A' & c <= 'Z');
libraries/string-extensions/character-type.dylan: (c >= 'a' & c <= 'z') | (c >= 'A' & c <= 'Z') | (c >= '0' & c <= '9');
libraries/string-extensions/character-type.dylan: (c >= '0' & c <= '9') | (c >= 'a' & c <= 'f') | (c >= 'A' & c <= 'F');
mindy/dbmc/header.dylan: | ('A' <= char & char <= 'Z')
mindy/dbmc/header.dylan: | ('0' <= char & char <= '9')
mindy/dbmc/header.dylan: | ('A' <= char & char <= 'Z'))
mindy/dbmc/lexer.dylan: elseif ((char == '\n' | char == '\r') & posn > lexer.line-start)
mindy/dbmc/lexer.dylan: elseif ((char == '\n' | char == '\r') & posn > lexer.line-start)
mindy/dbmc/lexer.dylan: elseif ((char == '\n' | char == '\r') & posn > lexer.line-start)
mindy/dbmc/lexer.dylan: if ((char == '\n' | char == '\r') & posn > lexer.line-start)
tests/dylan-test.dylan: (#t & #t) | signal("#t & #t is not true!\n");
tests/dylan-test.dylan: (#f | #f) & signal("#f | #f is not false!\n");
to-be-migrated/common-dylan/format.dylan: | (str[start] = '0' & str[start + 1] = 'x')))
to-be-migrated/file-system/helpers.dylan: size(ans) > 0 & (ans[0] = 'Y' | ans[0] = 'y')
to-be-migrated/locators/locators.dylan: | (base & base ~== $unsupplied)
to-be-migrated/locators/locators.dylan: | (extension & extension ~== $unsupplied))
to-be-migrated/tests/streams.dylan: & (~test-function-direction | test-function-direction == #"input");
to-be-migrated/tests/streams.dylan: & (~test-function-direction | test-function-direction == #"output");
tools/melange/c-decl.dylan: decl.map-type | (~explicit-only? & decl.type-name);
tools/melange/c-decl.dylan: | (~explicit-only? & decl.type-name);
tools/melange/c-decl.dylan: decl.map-type | (~explicit-only? & decl.type-name);
tools/melange/c-decl.dylan: | (~explicit-only? & decl.type-name);
tools/melange/c-decl.dylan: decl.map-type | decl.type.map-type | (~explicit-only? & decl.type-name);
tools/melange/c-decl.dylan: | (~explicit-only? & decl.type-name);
tools/melange/c-lexer-cpp.dylan: & (empty?(rest) | head(rest) == #"accept"))
tools/melange/c-lexer-cpp.dylan: & (empty?(rest) | head(rest) == #"accept")
tools/melange/c-lexer.dylan: | ~(whitespace?(contents[i]) & contents[i] ~== '\n')))
tools/melange/c-lexer.dylan: if (pos = contents.size | (cpp-line & contents[pos] == '\n'))
I think that it is safe to fix this bug.
Just find that actually both precedence and association are incorrect. This bug is quite anonying, hope that no code rely on this.
In DRM,
&
and|
have same precedence. Open Dylan is confirm to DRM, but in Mindy&
has higher precedence, as specified in compiler/info.c.For example, Open Dylan and Mindy show different result for following code:
Mindy:
Open Dylan:
Curious that why Dylan is designed to have same precedence for
&
and|
, which is different to many other languages.