Things to improve in ATS

[Jeffrey Brusseau]

There was a discussion a while back about what to improve on in the next version of ATS. There was talk about improving the semantics which I'm for and syntax which I don't think is a problem at all currently. But not as much on what really matters in a language: tooling and documentation. 

So here I go:

Compiler Error Messages need improvement:

example:

----

/home/monkeykong/ats/projects/INT2PROGINATS/function_templates.dats: 1017(line=48, offs=33) -- 1018(line=48, offs=34): error(parsing): the syntactic entity [funarrow] is needed.
/home/monkeykong/ats/projects/INT2PROGINATS/function_templates.dats: 1000(line=48, offs=16) -- 1003(line=48, offs=19): error(parsing): the syntactic entity [d0exp] is needed.
/home/monkeykong/ats/projects/INT2PROGINATS/function_templates.dats: 985(line=48, offs=1) -- 988(line=48, offs=4): error(parsing): the token is discarded.
exit(ATS): uncaught exception: _2home_2monkeykong_2ats_2ATS_INSTALL4_2ATS2_2src_2pats_error_2esats__FatalErrorExn(1025)

----

pats-filter shows what a less noisy error message would look like:

----

../function_templates.dats:48:33: the syntactic entity [funarrow] is needed.

../function_templates.dats:48:16: the syntactic entity [d0exp] is needed.

../function_templates.dats:48:1: the token is discarded.

exit(ATS): uncaught exception: _2home_2monkeykong_2ats_2ATS_INSTALL4_2ATS2_2src_2pats_error_2esats__FatalErrorExn(1025)

----

The uncaught exception part is still pretty meaningless. If it does mean something then I'm afraid I'll never know.

Names need to be better:

I don't just mean odd things like numbers and special characters finding there way into names either or excessively short or abbreviated words. I mean cryptic names devoid of meaning. For example these types: S2Etyrec, g0int_t0ype, S2Eextkind, atstype_int. I know very well that naming is hard but there has got to be better more meaningful names to use.

Types need documentation on how to use them:

ATS being a very strongly typed language means that you'll run into a lot of type errors. It would help if there were documentation that explained correct usage. This goes for builtin types and the library ATS comes with.

Maybe there needs to be a auto documentation system like rust has? (It still requires you write documentation but as part of the code)

ATS should have a Language Server:

Language Servers Protocol is a useful standard for languages that don't have a IDE. Many newer languages (including compile to c languages like nelua and nim) have language servers. Many editors (including emacs and vim) support the protocol.

Being able to jump to definition or hover over a type to see documentation for it would help a lot.

Documentation should all be unified and up to date:

There should be a singular reference document to go to look up any parts about the language and it's libraries. Right now there is the language website site, various GitHub repositories and wikis. It seems I have to read several long documents and the code and go through blogs to get an understanding of the core language.

I think python shows a pretty good way to do documentation.

There needs to be a code formatter or linter:

It's very useful to have a way to format code consistently again the language server protocol can help with this. Having to manually fix indenting and comment styles can be time consuming. But some code is just so hard to read (like the code in the ats books) because of weird styles that you need to reformat it for sanity.

There that's my two cents.

[gmhwxi]

Hi,

Thank you very much for your comments.

I have finally emerged out of a very deep dive into the implementation of ATS3/Xanadu.

Now I can take a breather. And I do need a breather :)

Up to ATS2 (inclusive), I mostly did what I would call experimental implementation. I hope

that we will be gradually having something of production quality from ATS3 onward.

Cheers,

--Hongwei