I'm actually not a huge fan of Scala syntax, simply because I find it verbose and I believe that it is not suited to functional programming in general. If there are reasons to support methods and whatnot, then I would be more amenable to it.
As for build systems, I think that shake <http://hackage.haskell.org/package/shake> is probably good to have. I've learned a lot of lessons from language-ats, and I believe I could write a language-xanadu package that worked and stayed up-to-date with the actual compiler. This would (among other things) make builds much, much simpler. I am against any use Scala on technical grounds, and shake is much better established, having led to several published papers. I actually kind of like the versatility and portability of make/configure, but I should be able to maintain a shake-xanadu package as well to provide an alternate/simpler solution. I'm also not really sure how string interpolation works in Scala. I know Rust does something at the macro level, so that may be an option - it would allow errors to be generated at compile-time. On the ATS front: I am curious as to how ATS optimizes tail recursion. I know Scala doesn't actually optimize tail recursion (unless the values are of the same type) which is immensely limiting in practice. A lot of interesting stuff (e.g. monadic recursion) relies on such optimizations in practice. Cheers Vanessa M. On Wednesday, March 7, 2018 at 10:52:49 AM UTC-6, Brandon Barker wrote: > > Glad to see this thread is here. I will just share some general thoughts > for syntax as my ATS is a bit rusty: > > 1. I like Scala style syntax - I think it is easy enough to read, unless > maybe you are doing stuff at the type level, where ATS seems to have an > advantage over Scala. I think Scala is similar to python in a lot of ways > (especially with Python 3.6 typing styles), aside from making indentation > part of the syntax. My thought is that Python doing this helps to force > people to write somewhat readable code (think beginner Python vs beginner > Perl), but I think we can assume that if you are coding in ATS, or at least > publishing code in ATS, you will be sensible enough to have some kind of > good programming style. So I would vote for leaving indentation to a style > checker/linter. > 2. Concision: I sadly don't know Idris or Haskell, and am very tempted to > learn one of them to get a better appreciation of them, but I'd rather > focus on ATS again. However, I do appreciate that they are concise, even > more so than Scala, which is generally laudable. > 3. Feature hiding: Facilitate the principle of least powe > <http://www.lihaoyi.com/post/StrategicScalaStylePrincipleofLeastPower.html>r. > ATS has a lot of advanced features, as does Scala (of course ATS has more). > Scala is pretty good at letting you hide them. I swear, I'd been coding in > Scala for 3 years and was still amazed at how simple you could make the > code if you try - just take a look at http://www.kogics.net/kojo - it is > nearly as easy as python I would say, and preferable to me. The lack of > types in the coding examples is almost annoying to me, but I understand it > is beneficial to young readers. Now, I'm not saying we can do all this in > ATS, but Scala is so named because it is a "language that scales with you", > and I believe ATS is this too, but it would be good to make that scaling a > bit more smooth, like climbing a Olympus Mons > <https://en.wikipedia.org/wiki/Olympus_Mons#/media/File:Olympus_Mons_Side_View.svg> > > rather than K2. > > > Other goals: > - Build systems: I think cross builds are very important as already > stated. In scala land, there is Scala (JVM), scala.js, and now > scala-native. Usually, we can create cross builds by having some source > that is platform independent (e.g. APIs/interfaces/types) and other bits > that are platform specific and rely on the platform independent bits. This > is great. Related to this, I actually think it may be worthwhile looking > into an existing build tool with a larger community rather than using make > and autotools, which seem to me a bit antiquated and unfriendly to other > platforms. I recall Hongwei and I were both a bit jaded by our experience > with using gradle, so I'm both excited to say Mill > <https://github.com/lihaoyi/mill> looks like a promising alternative, > though I'm also hesitant to make a suggestion after the last failure with > Gradle :-) But I believe a lot in Mill's stated goals, especially insofar > as they overlap with CBT's <https://github.com/cvogt/cbt> and the idea of > being designed to support multiple languages. If we can agree that Scala > isn't terrible, I say let's not reinvent the wheel, and try to comingle a > bit with them. This could be beneficial for both communities. Let's think > about using their build tools. At the moment, Mill seems to be creating a > lot of excitement, so it might be worth looking into it first. > > I'll try to give more concrete feedback in the future. > > On Friday, February 9, 2018 at 1:15:22 PM UTC-5, 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/876a2928-ab2c-4e50-814f-6f85696fb7f5%40googlegroups.com.
