On Monday, October 1, 2018 at 6:40:20 PM UTC-5, Vanessa McHale wrote: > > To me the main appeal of C over ATS is the existence of a standard and > several competing compilers. 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. >
This is all true of Common Lisp and Forth, apart from "better support" where it's still arguable. Actually I'd have trouble naming C books as good as those available for Common Lisp. But I'm still writing in C. If I pushed a CL or a Forth commit I'd just be asked how much job security I thought I needed, and couldn't they give me some of that in some other manner. > I realize Zig has a lot of marketing going on behind it but tbh I don't > see much there. > The salespitch is extremely weak. "A good cross-compiler."? "It can do without libc"? "It has stack traces."??? It's just all this boring stuff that makes programming a more pleasant and productive experience. You can hardly even call that a language. > People confuse "author doesn't know PL theory" for "practical." > This is just bigotry. How do you think that works? "Oh, the moment he couldn't explain type preservation, I realized that this was the language for me." > 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-user...@googlegroups.com <javascript:>. > To post to this group, send email to ats-lan...@googlegroups.com > <javascript:>. > 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 > > [image: Input Output] <http://iohk.io> > > [image: Twitter] <https://twitter.com/InputOutputHK> [image: Github] > <https://github.com/input-output-hk> [image: 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/7f7e933c-080b-4e7a-b981-03da73a6f4a5%40googlegroups.com.
