Some interesting syntax ideas here: https://rise4fun.com/Dafny/nbNTl. This
is probably pretty readable to ATS programmers.
On Thursday, April 12, 2018 at 11:49:54 AM UTC-5, Brandon Barker wrote:
> Apparently there is at least one example of Shake being used for the JVM:
> On Thu, Apr 12, 2018 at 10:47 AM, Brandon Barker <brandon...@gmail.com
>> 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
>> verbose aside from type annotations. However, as we're talking about
>> 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:
>>> 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
>>> 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
>>>> 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,
>>>> 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
>>>> ATS has a lot of advanced features, as does Scala (of course ATS has
>>>> 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
>>>> 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
>>>> 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
>>>> 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.
>>>>> 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
>>> To unsubscribe from this group and all its topics, send an email to
>>> To post to this group, send email to ats-lan...@googlegroups.com
>>> Visit this group at https://groups.google.com/group/ats-lang-users.
>>> To view this discussion on the web visit
>> Brandon Barker
> Brandon Barker
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit