Hi -
I noticed that given
proc iraise()
{
var i32 = 1234567:uint(32);
var iXX = -i32;
var bad : int(32);
assert(numBits(iXX.type) == 64);
// bad = -i32;
}
iraise();
the default use of a uint(w) in a signed expression needs more precision.
Chapel is quite smart and promotes uint(w) to uint(w+w) because all the
possible uint(w)'s do not fit into a signed int of the same size.
Disabling the comment results in a compile-time error of a type-mismatch
as is very well covered/identified in the table on Page 42. That said, I
was mystified by the error message at first.
My first reaction here is to ask - is there an error message that would have
been more helpful? I'm not so confident that a better error message can be
implemented easily, but we might as well think about what the error message
would be before dismissing it as too hard to do. E.g. perhaps simply formatting
the error differently would make it clearer that `-i32` has type `int(64)`.
I tried to read 9.1.1 of the specification and see where this implicit
conversion was discussed and it was not obvious to me.
I thought about elaborating on it and adding some words to 9.1.1 but my
1st, 2nd and 3rd cut of explanations were unclear when I read them. Also,
I wondered what other nice features there were and realized that I was
not going to address all of the issues as I knew insufficient details.
A few extra lines by someone who knows heaps more than I do might be
advantageous.
This issue is a little bit tricky because it is a combination of things that
are strictly the language rules (rules for implicit conversion) and the set of
operator implementations available in the standard modules. In particular, if
one were to add a `proc -(x:uint(32))` to the standard module, that would be
called for your program, but it's intentional that such a routine doesn't
exist. Since `proc -(x:int(64))` is present there, that's the one that your `-`
call resolves to, and then you get an error when assigning from a `int(64)` to
a `uint(32)`.
I don't even know what words would help there. I think this is a case where you
might be able to propose something (knowing it is incomplete) and we can
iterate on GitHub.
I did not put this in Github because I cannot figure out to indent text,
cut-and-paste cleanly, justify text blocks,spell check, and so-on.
GitHub uses Markdown syntax and justification of text blocks doesn't really
matter. (It can change how wide one can make the paragraph, but that doesn't
really impact readability). I recommend looking at
https://guides.github.com/features/mastering-markdown/
and keep in mind that you can edit an issue once you create it. All the web
browsers I use underline misspellings in red in text boxes like the one in
which one types in an issue on GitHub. I personally have much more trouble with
the issues you cited with my email client...
Besides, I am sure the above discussion can be distilled to something
simpler but someone skilled in using Github.
Regards - Damian
Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
