Thanks for all of your input and effort! In ATS3, syntax errors of a program are internalized in its abstract syntax tree. I expect that various syntax-checkers can be written to explain the cause of syntax errors.
With good support from the community, the learning curve for ATS3 should be a lot less steeper than that of ATS2. This is certainly what I hopes :) Cheers! On Monday, October 1, 2018 at 6:50:11 PM UTC-4, Julian Fondren wrote: > > Prompted by Zig's 0.3.0 release, I thought about ATS3 a little > more. Zig prompted that in two different ways: first, the release > notes had this charming assertion: "Zig intends to be so practical > that people find themselves using it even if they dislike it." > Second, while considering Zig, although it's a much less capable > language than ATS, I thoght it might be good to know as a language > 'for other people'. In the past I've done some work in C for groups, > because C -- if there were a justification for not just using a > scripting language -- would be accepted, while ATS certainly wouldn't. > Zig manages to look like a much better language than C, while still > being a language that could be accepted. > > On the first point, ATS is already so capable that it's worth using > even if the syntax is off-putting in places. Although I think that it > would be pretty easy to shave off the off-putting aspects (make > 't@ype' the default, so spelled 'type', and the old 'type' something > like 'boxed'; keep 'fun' and 'implement' as the defaults, but remove > the easy alternatives that you rarely need, and make .<>. the only way > to denote a non-recursive function -- this sort of stuff, just > emphasizing clean defaults rather than massively rewriting the > syntax), those aspects are only off-putting. I think people can get > over that pretty easily, and that worries about it would be better > directed at making ATS even more capable. I like Zig's attitude here. > > On the second point, I don't like my own 'language for other people' > logic. As a social animal I'd rather just use a language 'for other > people'. So, why wouldn't I feel comfortable submitting an ATS > implementation for an employer, where other people will potentially > have to maintain it? It's *definitely not* because of stuff like > t@ype. That doesn't even come into the top ten of reasons--it doesn't, > even when I don't have ten reasons in total. My reasons are: > > 1. the error messages are extremely hard to read, as they're expressed > in internal compiler constructions. I just know that a maintainer will > try to do something that looks obvious, get a bunch of > impossible-for-a-casual-maintainer-to-understand error messages, and > then immediately commit to rewriting my entire project. Even though > I've gotten to where I can often read and benefit from ATS's error > messages, I just can't expect anyone else to do this. > > And it doesn't matter how good my code is if, the first time someone > wants to make a trivial modification to it, they throw it away and > rewrite it in Go. > > 2. there is no reference manual for ATS. There's an introductory work > that covers *most* of the language, but that not in a manner that you > could ask, "what is this thing I'm looking at in this specific code?" > and then look up the answer. A maintainer wants, ideally, no tutorial > at all because the code is clear enough on inspection after you've > grepped around to find the code you're concerned about, and two, a > reference manual so those specific constructs in use in some code can > be quickly understood. > > That's about it for reasons. although I could mention error messages > eight more times and still not give them their due emphasis. > > 11. There's no interactive mode, no REPL. This is again a great help > to people who don't know a language well--like someone tasked to make > a small change to a program someone else has written in that language. > A REPL would naturally allow someone to test small bits of code in an > easy manner, as well as load an interrogate bodies of code. What type > does that have? How many overloads of * are there? etc. > > Zig isn't perfect here--it doesn't have a lot of docs either. It seems > like 2-hour screencasts are how you're supposed to learn the language. > But it has good, clear error messages, and it prints out your code and > graphically points to the problem, and you can build in a safe runtime > where many errors in code are caught and result in a stack > trace. True, ATS has the ideal where you catch many errors at > compile-time, but it's very easy to get a segfault from ATS too, as > simply as saying that some C function returns a string when it could > return NULL > > Error categories: > > 1. syntax errors. I once had a function "= void", instead of ": void", and > it took me over five minutes to find that problem. This isn't such a big > deal but improvements are improvements. > > 2. template errors. ATS has no problem and then gcc gives you pages > and pages of not very directly useful errors. I learn to recognize them > as 'template errors' but don't bother trying to extract information like > "what exact template is missing?" from them. > > 3. type errors. in your code you have uints, in your errors you have > g0uint_t0ype and such. I'd rather see typedefs by default and have an > option to expand those. > > 4. constraint errors. on line 11, column 30, you fail to show that n >= 0 > ... oh, there's no 'n' at all in your code? > that's because it's somewhere in a prelude .sats > > That's all. > > For my part I've got a new video series where I'm going through > Introduction to Programming in ATS. After that I might write some docs. > > On Friday, February 9, 2018 at 12:15:22 PM UTC-6, gmhwxi wrote: >> >> For the moment, I just want to open a thread for ATS3. >> >> I decided to pick ATS/Xanadu for the full project name. I like the name >> Xanadu >> because it is poetic and brings a feel of exoticness. >> >> ATS3 is supposed to be compiled to ATS2. At least at the beginning. I >> will try to >> write more about what I have in mind regarding ATS3. >> >> I know that a lot of people have been complaining about the syntax of >> ATS2. So >> we can start the effort of designing some "nice" syntax for ATS3. Please >> feel free >> to post here if you would like share your opinions and ideas. >> >> I will be happy to take the lead but we definitely need to have some form >> of community >> effort on this project given its size and scope. >> >> Cheers! >> >> --Hongwei >> >> PS: I felt rushed every time up to now when implementing ATS. This time I >> am hoping >> to have the luxury of thinking about implementation a bit before actually >> doing it :) >> >> -- 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 post to this group, send email to ats-lang-users@googlegroups.com. Visit this group at https://groups.google.com/group/ats-lang-users. To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/9109250f-4c7c-45fb-998f-e6528dfb6d83%40googlegroups.com.
