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/50885b34-7608-4b51-a053-1e19f951658a%40googlegroups.com.
