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


On Saturday, January 28, 2023 at 2:03:36 PM UTC-5 [email protected] wrote:

> 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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ats-lang-users/deb9a707-08b8-4494-b846-fb7a272718d4n%40googlegroups.com.

Reply via email to