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 
<https://microsoft.github.io/language-server-protocol/> is a useful 
standard for languages that don't have a IDE. Many newer languages 
(including compile to c languages like nelua 
<https://github.com/codehz/nelua-lsp> and nim 
<https://github.com/PMunch/nimlsp>) have language servers. Many editors 
<https://microsoft.github.io/language-server-protocol/implementors/tools/> 
(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 
<https://docs.python.org/3/>.

*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 
<https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_rangeFormatting>.
 
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.

-- 
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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ats-lang-users/9f8290d2-b93b-4705-8f88-40142af1393an%40googlegroups.com.

Reply via email to