I don’t understand why some types have a literal, and the other types
have no literal.
Which is the boundary line?
In this case, the reason is that there is no special literal representation
for values of the type uint32_t in C. So casting/coercion is needed in C
as well, albeit it is done implicitly in C.On Tuesday, November 25, 2014 6:31:10 AM UTC-5, Kiwamu Okabe wrote:
Hi,
On Mon, Nov 24, 2014 at 4:18 AM, gmhwxi <gmh...@gmail.com <javascript:>> wrote:
As I see it, the problem with providing a better way to do this is that
a user has to learn it.
Without explicit casting, ATS could be notoriously difficult to use.
One often had to spend hours before one could even learn how to implement
a simple program like 'Hello, world!".
While $UN.cast may look ugly, it can get you going without having to learn
a new feature first. As one’s knowledge of ATS picks up, one should be able
to reduce the use of $UN.cast if it is desired.On Sunday, November 23, 2014 8:38:21 AM UTC-5, Kiwamu Okabe wrote:
Hi,
On Sun, Nov 23, 2014 at 2:26 PM, gmhwxi <gmh...@gmail.com <javascript:>> wrote:
I would just do a cast. For instance, $UN.cast{uint32}(100U)
Umm… I found the cast occurred some template error, in the past.
And I think many programmers will get a surprise using such cast many
times.
Yes. Otherwise, we have to do something about lexing/parsing in ATS.
I don’t feel it is worth it. If x is an integer, $UN.cast{uint32}(x) is
simply
treated as x once typechecking is finished.
Is there a way to define the literal directly?
The only other way I can think of is to do something like:
$extval(uint32, “123”)On Tuesday, November 25, 2014 6:31:10 AM UTC-5, Kiwamu Okabe wrote:
Hi,
On Mon, Nov 24, 2014 at 4:18 AM, gmhwxi <gmh...@gmail.com <javascript:>> wrote: