Apparently there is at least one example of Shake being used for the JVM: https://github.com/typelead/eta-benchmarks
On Thu, Apr 12, 2018 at 10:47 AM, Brandon Barker <[email protected]> wrote: > Ya, I really wish I had more experience with Haskell to give it a fair > comparison to Scala, but I get what you are saying. Compared to the > alternative 1 (Java) it is quite a bit less verbose, and compared to > alternative 2 (JavaScript), I'd say it is similar, but probably still less > verbose aside from type annotations. However, as we're talking about > JavaScript, I think it a fair trade! > > I wasn't suggesting ATS inherit the deficiencies of Scala, such as its > limited means of TCO (largely if not wholly due to limitations of the JVM; > I know ScalaNative plans to expand TCO functionality) or any unnecessary > syntax. I was just using it as an example that worked well for me; it > generally does a good job of allowing you to get work done with what you > know, without having to get entangled in more advanced features until you > are ready (or think you are ready, anyway). > > I am curious what the technical grounds you have for being against any use > of Scala whatsoever; sounds like it would be useful to know about. > > As for shake, looks like the site (hackage) is down when I tried just now, > but looking at https://shakebuild.com, I'll say it looks interesting, and > sounds as though it may be good for complex builds (involving multiple > languages). I'd love to give it a try - looks like it hasn't been used much > for the JVM, so not sure when I'll get time to try. > > Scala string interpolation works by providing an implicit value class for > Strings, which then can have additional methods, like the 's' method: > s"hello $name", so s is called on the following string. It isn't quite that > simple, here's the full details: https://docs.scala-la > ng.org/overviews/core/string-interpolation.html > > > On Mon, Apr 9, 2018 at 7:52 PM, <[email protected]> wrote: > >> 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 a topic in the >> Google Groups "ats-lang-users" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/to >> pic/ats-lang-users/mjS9NtQz6Pg/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To post to this group, send email to [email protected]. >> 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/ms >> gid/ats-lang-users/876a2928-ab2c-4e50-814f-6f85696fb7f5%40go >> oglegroups.com >> <https://groups.google.com/d/msgid/ats-lang-users/876a2928-ab2c-4e50-814f-6f85696fb7f5%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > > > -- > Brandon Barker > [email protected] > -- Brandon Barker [email protected] -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CAORbNRpJ1RioOsnZ%3DFAv3HaHoUxEZiGxXf6WbWqbmnQXOzVb_g%40mail.gmail.com.
