Re: ATS3: ATS/Xanadu

[Hongwei Xi]

>>As for build systems, I think that shake
 is probably good to have ...

That would be great! I plan to export the syntax tree of an ATS program
into JSON.

>>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.

It is pretty straightforward. After typechecking, proofs are erased. Then
the compiler marks each recursive call that happens to be a tail-call; each
marked call is converted into a local jump.

On Mon, Apr 9, 2018 at 7:52 PM,  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
>  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
>> 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
>> 
>> 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
>> pl

Re: ATS3: ATS/Xanadu

[vamchale]

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 
 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 
> 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 
> 
>  
> 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 
>  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  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 l

Re: Functions from datasorts to datasorts

[Hongwei Xi]

I think I understand you mean here.

In ATS3, I plan to have an evaluator for evaluating
compile-time constant expressions. This evaluator
can evaluate an expression like tlist_append(constant1, constant2).
Of course tlist_append needs to be defined at the sort level first.

On Mon, Apr 9, 2018 at 2:29 AM, Andrew Knapp  wrote:

> My one example, serialization of nested records from a tlist of
> @(string,t0ype), turned out to not need append. Anyhow, that's blocked for
> now, since I don't think you can reflect a template-argument string literal
> to the value level.
>
> But more generally, a convenient way to write functions between datasorts
> would be a large step towards very powerful metaprogramming in ATS.
>
> With a few more features, ATS could have a very clean and conceptually
> simple metaprogramming approach: templates are interpreters for datasorts.
> Just like a value-level interpreter, it would be nice to separate
> generation and evaluation stages.
>
> People wrote Boost Hana in C++ to do all kinds of computation on
> type-level data structures, despite how painful C++ metaprogramming is.
>
> https://www.boost.org/doc/libs/1_61_0/libs/hana/doc/html/index.html
>
> ATS is not that far from being Boost.Hana on steroids.
>
> The typechecking is already there, and is SO. MUCH. BETTER. than the mess
> you get when trying to write untyped purely functional programs in C++
> templates.
>
> For example, if you pass a bool to a template that expects a tlist, the
> compiler tells you exactly what happened.
>
> --
> 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/a6a26a70-7b0c-4465-8e0c-f20f2fdba6e0%
> 40googlegroups.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/CAPPSPLofDexGrp%3DTNE2oTjQeuw2Dyi1t0TA%3DtVLg%2B4rDAn3Rvg%40mail.gmail.com.