Is there "uint32" literal on ATS language?

[Kiwamu Okabe]

Hi,

I re-write some C language programs using ATS language.
However, the programs use "uint32" and "uint16", "uint8" many times.

Is there "uint32" literal on ATS language?

Thank's,
--
Kiwamu Okabe at METASEPI DESIGN

[Hongwei Xi]

Yes, there are int8/uint8, int16/uint16, int32/uint32 and int64/uint64.

Operations on these types are declared in prelude/integer_fixed.sats

--
You received this message because you are subscribed to the Google Groups "ats-lang-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-user...@googlegroups.com.
To post to this group, send email to ats-lan...@googlegroups.com.
Visit this group at http://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAEvX6dmimOKsT6%3DaUym2nLqxOfXqbjCEyWkjPG%2BypDZDVPDb2A%40mail.gmail.com.

[Kiwamu Okabe]

Hi Hongwei,

On Sun, Nov 23, 2014 at 2:50 AM, Hongwei Xi <gmh...@gmail.com> wrote:
> Yes, there are int8/uint8, int16/uint16, int32/uint32 and int64/uint64.

Ah, I think I know that.
I think "80U" is for "uint" literal and "80UL" is for "ullint" literal.
Then what is for "uint32" literal?

[gmhwxi]

I would just do a cast. For instance, $UN.cast{uint32}(100U)

[Kiwamu Okabe]

Hi,

On Sun, Nov 23, 2014 at 2:26 PM, gmhwxi <gmh...@gmail.com> 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.

Is there more better way?

[Barry Schwartz]

Kiwamu Okabe <kiw...@debian.or.jp> skribis:

> On Sun, Nov 23, 2014 at 2:26 PM, gmhwxi <gmh...@gmail.com> 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.
>
> Is there more better way?

I have typically made a macro so I could write, for instance,

u32 100u

It is no more verbose than how Fortran 90 handles such things,
although Fortran avoids the whitespace.

IMO special notations for size_t and ssize_t might be a good idea,
though (zu and zd, respectively, perhaps, by analogy to printf).

[gmhwxi]

Here is a way that may be better:

staload
UN = "prelude/SATS/unsafe.sats"

#define pow2_31 0x80000000
#define pow2_32 0x100000000
extern
fun{} u32_int{i:nat | i < pow2_31} (int(i)): uint32(i)
extern
fun{} u32_uint{i:nat | i < pow2_32} (uint(i)): uint32(i)

implement{} u32_int (x) = $UN.cast(x)
implement{} u32_uint (x) = $UN.cast(x)

(* ****** ****** *)

postfix u32
symintr u32
overload u32 with u32_int
overload u32 with u32_uint

val x = (100)u32
val x = (100u)u32

(* ****** ****** *)

postfix _u32
symintr _u32
overload _u32 with u32_int
overload _u32 with u32_uint

val x = 100_u32
val x = 100u_u32

(* ****** ****** *)

[gmhwxi]

>> Is there more better way?

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.

[Barry Schwartz]

gmhwxi <gmh...@gmail.com> skribis:

> postfix _u32
> symintr _u32
> overload _u32 with u32_int
> overload _u32 with u32_uint
>
> val x = 100_u32
> val x = 100u_u32

Clever! Make it look like Fortran 90.

[Barry Schwartz]

gmhwxi <gmh...@gmail.com> skribis:

> >> Is there more better way?
>
> 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!".

That’s one of the things I never liked about, for instance, Icon. A
hello-world program is simple, but no matter how many years I had used
the language from time to time, I could not write in it without
keeping the book handy to remind me of the operators, their
precedences, and even some of the simplest of procedures. Having a
general method by which to write things is beneficial.

[Kiwamu Okabe]

Hi,

On Mon, Nov 24, 2014 at 4:18 AM, gmhwxi <gmh...@gmail.com> wrote:
> implement{} u32_int (x) = $UN.cast(x)
> implement{} u32_uint (x) = $UN.cast(x)

I think it's useful for me.
May I have the other question?

"Essentially, uint32 literal needs cast thing?
Is there a way to define the literal directly?"

I don't understand why some types have a literal, and the other types
have no literal.
Which is the boundary line?

[Kiwamu Okabe]

Hi Hongwei,

On Mon, Nov 24, 2014 at 4:37 AM, gmhwxi <gmh...@gmail.com> 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.

Do you mean "The library should do abstraction using $UN.cast,
and the compiler should not"?

In such case, we should care the data bit width and Endian program in
the library.

[gmhwxi]

>>Essentially, uint32 literal needs cast thing?

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")

[gmhwxi]

>>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.

[Barry Schwartz]

gmhwxi <gmh...@gmail.com> skribis:

> >>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.

One might have to be explicit in a ?: expression, I would think. It is
easy to get confused in those situations, if one is not used to
thinking in terms of distinct types.

uint32_t and such are just platform-dependent typedef’d synonyms in C,
anyway (with something analogously true in modern Fortran), and belong
to Posix header specifications rather than the language proper. In ATS
you can define your own distinct integer types and the situation could
get very messy.

[Kiwamu Okabe]

Hi Hongwei,

On Wed, Nov 26, 2014 at 4:26 AM, gmhwxi <gmh...@gmail.com> wrote:
>>>Essentially, uint32 literal needs cast thing?
>
> 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.

I think I understand it, and miss-understood C language.