To me the main appeal of C over ATS is the existence of a standard and several competing compilers. (I also like the fact that C has an ABI, but then ATS benefits from this as well :)). It's just a more stable language and there's guarantees of better support. C features are documented and there are decades of books by multiple authors.
I realize Zig has a lot of marketing going on behind it but tbh I don't see much there. People confuse "author doesn't know PL theory" for "practical." On 10/01/2018 05:50 PM, 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 > <mailto:ats-lang-users+unsubscr...@googlegroups.com>. > To post to this group, send email to ats-lang-users@googlegroups.com > <mailto: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 > <https://groups.google.com/d/msgid/ats-lang-users/50885b34-7608-4b51-a053-1e19f951658a%40googlegroups.com?utm_medium=email&utm_source=footer>. -- *Vanessa McHale* Functional Compiler Engineer | Chicago, IL Website: www.iohk.io <http://iohk.io> Twitter: @vamchale PGP Key ID: 4209B7B5 Input Output <http://iohk.io> Twitter <https://twitter.com/InputOutputHK> Github <https://github.com/input-output-hk> LinkedIn <https://www.linkedin.com/company/input-output-global> This e-mail and any file transmitted with it are confidential and intended solely for the use of the recipient(s) to whom it is addressed. Dissemination, distribution, and/or copying of the transmission by anyone other than the intended recipient(s) is prohibited. If you have received this transmission in error please notify IOHK immediately and delete it from your system. E-mail transmissions cannot be guaranteed to be secure or error free. We do not accept liability for any loss, damage, or error arising from this transmission -- 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/22037ead-64d6-32b6-8c33-e7704e69861c%40iohk.io.
signature.asc
Description: OpenPGP digital signature
