About scientific computing with ATS and notation

[Yann Le Du]

Dear ATSites,

First, impressed by the power of ATS which unfortunately for me is still inaccessible even after spending the typical time I spend overviewing other languages. For sure, I've listened to many people saying how hard it was, so that didn't help ;-) Maybe they want to keep ATS for themselves and frighten away potential new users ?

I'm a physicist, cosmologist, currently working on setting up a project involving image reconstruction, around what the Chebfun matlab toolbox implements. Now, I've been looking at Dex, he new google research language, because that's typically what I need,for exactly the same reason the designers made Dex (escape Matlab and go for more than its clone on juice, Julia) but it looks very experimental and doesn't really have all I need, especially interfacing with C.

So first, would I be able to massage ATS into allowing some nice syntax, I mean can I code a library (using whatever tools I totally don't understand today) that would allow me to write

`for i,j: C.i.j = A.i.k * B.k.j`

In a very similar way to Dex (who has ranged integer type for the indices), i.e. which would be interpreted as :

```
for i in rows range of A:

  for j in colums range of B:

    for k in cols of A == rows of B:

      C[i,j] = A[i,k] * B[k,j]

```

or whatever equivalent in ATS.

You will notice that it loops implicitly on k (Einstein summation), thus without me specifying k, and all the indices getting checked like in Dex at compile time, with inference wherever needed. This means I want to be able to write M.2.3 = 25 (meaning M[2,3]=5) without casting overhead like in Dex (they have to cast from integers to ranged ordinals if I remember).

I would also need support for 128 bit integers and all for cryptographic uses, the possibility of defining

foo(m `Matrix[12 rows, any u32 in [0,23] columns, any float type for the elements, unknown variance]`)

and then call foo with `foo(b)` and b is checked to fit the type declared for foo's arguments, so it wold tell me if I try to put in a matrix with too many rows, but accept a matrix with 12 rows and 21 columns filled with f32, the possibility of defining a set of accepted types, including constants, and check if what I use belongs to that set, abstractions like OO to better contain the math abstractions we manipulate.

Also, the possibility to implement the right structures for SIMD and all that, SOA, etc. This organizing my memory as I want, perhaps not from the start, but as the project progresses.

The possibility of multicores, and distributed computing.

Proving that some functions are right.

And last but not least, how much will I have to [un|re]learn when ATS3 is released ?

And maybe other questions will follow if the above receives positive answers...

By the way, why no Discord channel ? It's so helpful for a community.

It's a big pile of questions, I just want to know if learning ATS could make those features possible. My other path is to go to Rust and hope I can massage the macros to handle my syntax, but Rust doesn't have true range types for the tensor indices I want to use, although some crate imitates them, and ATS looks much more powerful to me.

That's it, I hope ATS can do all that.

Best,

Yann

[d4v3y_5c0n3s]

Hi Yann,

  I'm glad to see others showing interest in ATS :D.  I'm not very familiar with the sort of scientific programming that you are talking about, but I'll do my best to respond to your questions regardless.

  You asked whether you could use 128 bit integers, SIMD, multicore, and even distributed computing.  Like, holy moly man.  :D  But yea, ATS can do basically anything C can, with the caveat that you may need to write FFI code due to the small size of the ATS ecosystem.

  As for the static capabilities of ATS, this I believe to be the strongest quality of ATS.  Indexing into arrays/matrices is verified at compile time so your example should be recreate-able in ATS.  And no, ATS' type system doesn't require you to constantly cast to verify the range of an integer, but it will force you write your code in such a way that the system knows without a doubt that the integer is not out of range.  It's hard to explain, but if you are interested I'd recommend working through the Intro to ATS book in the documentation on the website.

  I'm not involved with the development of ATS3, so gmhwxi would know more about how much it will change.  I'd recommend reading previous posts about ATS3 to find out more.

Good luck.

[Yann Le Du]

Thanks for your interest in my questions. Just to clarify a few things :

1. Can I use some form of macros like in rust or Julia to allow new syntax inside ATS ? My goal is to allow writing directly something like `A.i.j = 12` or something more complex like I showed in my original mail.

2. If adding some new syntax is not possible, can I write a parser with ATS itself to do that and generate ATS code behind ?

3. In the meantime I looked into more detail into the possibilities of ATS with regards to ranged indexing, and indeed I can do exactly what I want, but again I would like to know if I can create a specific syntax for some manipulations,.

4. You mention writing FFI but can I keep all of ATS advantages (proofs, types, etc.) while writing FFI ? In my mind, if I go to another language, I lose all guarantees.

5. Concerning syntax again, it looks like ATS does not support UTF-8 names for `var` or `fn` : is there a way around this ? Or maybe this goes back to question 2. ?

6. As for concurrency, how does the actor model make sense within ATS ? Is the ATS type-system a superset of the actor model as implemented in Pony for example ? To finish, does using pthreads mean I write some wrappers on top of libpthread or similar like Rust does and have ATS bring me guarantees with my concurrent code ?

[gmhwxi]

Hi Yann,

It is difficult to keep up with your questions :)

On Tuesday, January 25, 2022 at 7:29:39 PM UTC-5 Yann Le Du wrote:

Thanks for your interest in my questions. Just to clarify a few things :

1. Can I use some form of macros like in rust or Julia to allow new syntax inside ATS ? My goal is to allow writing directly something like `A.i.j = 12` or something more complex like I showed in my original mail.

There is a macro language within ATS. I believe that you could write something like A[i,j] = 12 or A[i][j]  = 2.

2. If adding some new syntax is not possible, can I write a parser with ATS itself to do that and generate ATS code behind ?

 I like this approach. This is the way I intend to build various ATS extensions to support special programming (or DSLs).

3. In the meantime I looked into more detail into the possibilities of ATS with regards to ranged indexing, and indeed I can do exactly what I want, but again I would like to know if I can create a specific syntax for some manipulations,.

See above.

4. You mention writing FFI but can I keep all of ATS advantages (proofs, types, etc.) while writing FFI ? In my mind, if I go to another language, I lose all guarantees.

 Of course, you have to assume some form of correctness of the "foreign" code.

5. Concerning syntax again, it looks like ATS does not support UTF-8 names for `var` or `fn` : is there a way around this ? Or maybe this goes back to question 2. ?

Maybe this could be first tried in an extension.

 

6. As for concurrency, how does the actor model make sense within ATS ? Is the ATS type-system a superset of the actor model as implemented in Pony for example ? To finish, does using pthreads mean I write some wrappers on top of libpthread or similar like Rust does and have ATS bring me guarantees with my concurrent code ?

ATS  itself is not tied to pthreads. Yes, you can use pthreads by writing some wrappers (of zero runtime cost) on top of libpthread.

The type system of ATS  can detect a variety of concurrency related issues during type-checking (e.g., potential race conditions and deadlocks).

--Hongwei

[gmhwxi]

After reading and re-reading your message, I think that what you need is some kind of extension of ATS.

>> It's a big pile of questions, I just want to know if learning ATS could make those features possible.

I feel that ATS and these programming features are kind of orthogonal.

Say you want some code in a language called XYZ. For instance, XYZ can be C, Javascript or some assembly.

You can build a compiler from ATS to XYZ so that *some* (not all) code in XYZ that you need can be generated

from ATS source. By taking such an approach, you get the chance to use the type system of ATS to flush out a

large variety of potential bugs in your code. Also, the hope is that you can be a lot more productive at writing code

by making extensive use of the templates in ATS library.

While we all love concise and elegant syntax, the syntax of ATS (as of now) is quite verbose. One big reason for this

is that ATS aims to provide extensive debugging support at compile-time. Say you have just finished writing a Python

program. Then it is only logical that you test it by running it. After finishing writing an ATS program, you could run it or

you could find ways strength the types used in it so as to flush out potential bugs.

Now let me say a few words about the following syntax:

`for i,j: C.i.j = A.i.k * B.k.j`

Clearly, this syntax indicates that the sizes (nrow and ncol) of a matrix needs to be attached to the matrix. This would

cause serious problems if you want to process submatrices (e.g., when implementing Strassen's matrix multiplication).

In order to process arrays efficiently, the sizes of arrays really need to be detached from the arrays themselves.

Another issue with "elegant" syntax is that it does not go well with debugging. Often, "elegant" code is only obtained at

the end of a "messy" debugging process.

Hope this can clarify a few things on ATS for you.

--Hongwei

On Sunday, January 23, 2022 at 12:46:12 PM UTC-5 Yann Le Du wrote:

[Yann Le Du]

Many thanks for taking the time to write such detailed answers. I will think about all this as I continue learning ATS, and hopefully understand better how all this can can be implemented and put together in practice.