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 <brandon.bar...@gmail.com>
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, <vamch...@gmail.com> 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
>> 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/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
> brandon.bar...@gmail.com
>



-- 
Brandon Barker
brandon.bar...@gmail.com

-- 
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/CAORbNRpJ1RioOsnZ%3DFAv3HaHoUxEZiGxXf6WbWqbmnQXOzVb_g%40mail.gmail.com.

Reply via email to