Re: ATS3: ATS/Xanadu

[gmhwxi]

Thanks for your interest in ATS!

Will take into consideration your suggestions.

The current implementation of ATS3 is done in a way that
should make it straightforward for other people to implement
tools performing code analysis. My hope is that such tools can
be distributed independently and shared by the ATS community.
For instance, the compiler flags you mentioned can be supported
in this way.

On Wednesday, December 4, 2019 at 2:23:13 AM UTC-5, rodol wrote:
>
> Hello, I have been learning ATS2, and wanted to chime in. I'm a bit late 
> to the party, but I've given these quite a bit of thought. I have more, but 
> I need to learn more about ATS2 before being sure enough to suggest them. 
> I'll be asking a few things soon :)
>
> I don't have an issue with how 'weak' the type inference is in ATS2. I 
> really like how dependent types are handled in ATS2, and the level of 
> expressiveness possible with them. I hope changing the template system to 
> use simpler types doesn't cripple it.
>
> Here are my ideas for ATS3, sorted from more important to less important 
> in each of the 3 categories, numbered for easy reference:
>
>
>
> a. Things to add:
>
> 1. Compiler flags. Examples:
> --wproof: warn about un`primplement`ed `prfun`s
> --waxiom: warn about axioms
> --wtco: warn about recursive functions that can't be TCO'd.
> --wunused: warn about locals that are never called
> --wstrict: treat `case` as `case+`, `val` as `val+`
> --wsafe: warn about `$UNSAFE` code
> --wall: enable some useful subset of the above warnings
> --wextra: enable all above warnings
> --werror: treat warnings as errors
>
> 2. Allow using compiler flags as pragmas at the top of a file, like `#warn 
> tco` to warn about any unTCO'd function bodies in the file, or `#warn all` 
> for --wall. (could also be `#pragma wall` for flexibility later?)
>
> 3. Standardized attribute system to label functions with compiler flags or 
> other information/tags, like C# attributes or Java annotations. The closest 
> thing to this in ATS2 is the - pattern.
>
> 4. Have metaprogramming at the level of compile-time code generation. For 
> example, implementing a static function that generates optimal matrix 
> multiplication for a given callsite's matrix dimensions should be possible. 
> Maybe this is already possible in ATS2 and I just don't know it. This would 
> depend on (haha) dependent types to know the dimensions of the matrices at 
> the callsite. This paper is interesting, I have not read all of it but it 
> may be relevant: 
> https://www.ccs.neu.edu/home/stchang/pubs/ckg-popl2017.pdf
>
>
>
> b. Things to change:
>
> 1. Rename `praxi` to `axiom`, `prfun` to `claim`, `primplement` to `proof`.
>
> 2. Force function forward declaration like in haskell, splitting the 
> parameter types from parameter names. Pattern matching isn't necessary, the 
> syntax is just nicer this way and separates concerns. The caller only needs 
> to know the *type* signature.
>
> 3. Unite `fun` and `fn`. I do not know why this distinction exists, does 
> it make the compiler faster somehow to know that the function may call 
> itself?
>
>
>
> c. Things to remove:
>
> 1. Remove `andalso` and `orelse`. `&&` and `||` are standard in 
> programming, we don't need more keywords to mentally keep track of.
>
> 2. Remove `implmnt` and `primplmnt` variants. `fn`/`fun` already sets 
> precedent for spelling variations changing meaning, but here the variation 
> doesn't.
>
> 3. Remove `(**)` comment syntax. It prevents us from using * as prefix 
> function, like `(*) 2 1`. `/**/` does not have this issue.
>
> 4. Remove mutual function declarations with `and` in favor of private 
> local functions that call their parents. The second function in a mutual 
> declaration can't be referenced externally anyways, so it would be easier 
> to understand the scope. `fnx` is unneeded after a.2
>
> 5. Remove `~` unary negation. I don't mean replace it with `-`, I mean 
> take it out completely. Just subtract from 0 instead. `~` should be 
> reserved for bitwise negation, and `-` for subtraction.
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/ats-lang-users/53286644-7872-4828-8e5c-9f733b401245%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[gmhwxi]

Thanks for your continued interest.

I have not started this line of work yet. Currently I am working on an
interpreter for ATS3, trying to complete a reference implementation before
going forward.

On Friday, December 6, 2019 at 10:49:54 AM UTC-5, Dan'l Miller wrote:
>
> In ATS3, how is the alternate-syntax-to-ground-syntax coming along as an 
> archetypical mechanism (not any one particular transform yet) or is that 
> capability still future work yet to be added to ATS3's source code?  Is 
> alternate-to-ground syntax transforms envisioned to be tree transductions 
> from the alternate-syntax AST to the analogous ground-syntax AST (as 2 
> [effectively-]separate ASTs)?  Are any demonstrations/examples of 
> alternate-to-ground syntax transforms extant yet?
>
> On Tuesday, October 2, 2018 at 7:22:13 AM UTC-5, gmhwxi wrote:
>>
>> Thanks for all the input!
>>
>> Still working on the parser. Will post a message on its progress shortly.
>>
>> I personally like SML-like syntax, which is quite different from OCaml's.
>> After I publish the syntax for ATS3, I hope that someone could design a 
>> version
>> for it based on Lisp's syntax.
>>
>> Cheers!
>>
>> On Saturday, September 22, 2018 at 1:44:30 PM UTC-4, Brian Rogoff wrote:
>>>
>>> As I'm sure you're aware OCaml's syntax is not widely liked, leading to 
>>> a lot of attempts at resyntaxing (Revised, Pidgin, ReasonML amongst others) 
>>> so attempting to copy it doesn't strike me as a good idea.
>>> SML is not widely used enough for me to have a sense of how much the 
>>> syntax was liked.
>>>
>>> I love Lisps, and, like Barry Schwartz, prefer it to others. However, I 
>>> realize that this is a minority opinion and many programmers *hate* it. 
>>> Probably also not a great idea if you're trying to make ATS popular, 
>>> especially amongst low level programmers.
>>>
>>> Python syntax is well liked (and well hated :-) by a large number of 
>>> programmers. The Nim language has a kind of Pythonesque syntax with static 
>>> typing, and it also has powerful metaprogramming features.
>>> It's also used in low-level programming. It would be valuable to take a 
>>> look at Nim and see what lessons can be learned there.
>>>
>>> C language syntax is the most widely used, with C++ and Rust being the 
>>> competitors for ATS3. I happen to think D language got the template syntax 
>>> (and templates) right-er and provide a better model for template 
>>> meta-programming. A C like syntax is the safest bet IMO.
>>>
>>> Good luck, and please get ATS3 out there soon.
>>>
>>> On Sunday, September 16, 2018 at 8:58:55 AM UTC-7, gmhwxi wrote:


 It is not too late :)

 For meta-programming support, LISP-like syntax is definitely
 on my mind.

 At this point, I want to first finish designing and implementing
 some ML-like (ML-inspired) syntax for ATS. I am getting there :)

 Once this ML-like syntax is done, it can readily serve as the basis for
 a design of LISP-like syntax for ATS.

 Cheers!

 On Thursday, August 30, 2018 at 4:03:36 PM UTC-4, Barry Schwartz wrote:
>
> I know this comes too late and was doomed anyway, but my opinion is 
> the best syntax is always Lisp. :)
>
> On Friday, February 9, 2018 at 12:15:22 PM UTC-6, 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/ats-lang-users/8e4cc05e-9b44-4f68-8d0a-e643029681c2%40googlegroups.com.

Re: ATS3: ATS/Xanadu

['Dan'l Miller' via ats-lang-users]

In ATS3, how is the alternate-syntax-to-ground-syntax coming along as an 
archetypical mechanism (not any one particular transform yet) or is that 
capability still future work yet to be added to ATS3's source code?  Is 
alternate-to-ground syntax transforms envisioned to be tree transductions 
from the alternate-syntax AST to the analogous ground-syntax AST (as 2 
[effectively-]separate ASTs)?  Are any demonstrations/examples of 
alternate-to-ground syntax transforms extant yet?

On Tuesday, October 2, 2018 at 7:22:13 AM UTC-5, gmhwxi wrote:
>
> Thanks for all the input!
>
> Still working on the parser. Will post a message on its progress shortly.
>
> I personally like SML-like syntax, which is quite different from OCaml's.
> After I publish the syntax for ATS3, I hope that someone could design a 
> version
> for it based on Lisp's syntax.
>
> Cheers!
>
> On Saturday, September 22, 2018 at 1:44:30 PM UTC-4, Brian Rogoff wrote:
>>
>> As I'm sure you're aware OCaml's syntax is not widely liked, leading to a 
>> lot of attempts at resyntaxing (Revised, Pidgin, ReasonML amongst others) 
>> so attempting to copy it doesn't strike me as a good idea.
>> SML is not widely used enough for me to have a sense of how much the 
>> syntax was liked.
>>
>> I love Lisps, and, like Barry Schwartz, prefer it to others. However, I 
>> realize that this is a minority opinion and many programmers *hate* it. 
>> Probably also not a great idea if you're trying to make ATS popular, 
>> especially amongst low level programmers.
>>
>> Python syntax is well liked (and well hated :-) by a large number of 
>> programmers. The Nim language has a kind of Pythonesque syntax with static 
>> typing, and it also has powerful metaprogramming features.
>> It's also used in low-level programming. It would be valuable to take a 
>> look at Nim and see what lessons can be learned there.
>>
>> C language syntax is the most widely used, with C++ and Rust being the 
>> competitors for ATS3. I happen to think D language got the template syntax 
>> (and templates) right-er and provide a better model for template 
>> meta-programming. A C like syntax is the safest bet IMO.
>>
>> Good luck, and please get ATS3 out there soon.
>>
>> On Sunday, September 16, 2018 at 8:58:55 AM UTC-7, gmhwxi wrote:
>>>
>>>
>>> It is not too late :)
>>>
>>> For meta-programming support, LISP-like syntax is definitely
>>> on my mind.
>>>
>>> At this point, I want to first finish designing and implementing
>>> some ML-like (ML-inspired) syntax for ATS. I am getting there :)
>>>
>>> Once this ML-like syntax is done, it can readily serve as the basis for
>>> a design of LISP-like syntax for ATS.
>>>
>>> Cheers!
>>>
>>> On Thursday, August 30, 2018 at 4:03:36 PM UTC-4, Barry Schwartz wrote:

 I know this comes too late and was doomed anyway, but my opinion is the 
 best syntax is always Lisp. :)

 On Friday, February 9, 2018 at 12:15:22 PM UTC-6, 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/ats-lang-users/12a0db96-a4f2-454e-b85b-06ef93340a3f%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[rodol]

Hello, I have been learning ATS2, and wanted to chime in. I'm a bit late to 
the party, but I've given these quite a bit of thought. I have more, but I 
need to learn more about ATS2 before being sure enough to suggest them. 
I'll be asking a few things soon :)

I don't have an issue with how 'weak' the type inference is in ATS2. I 
really like how dependent types are handled in ATS2, and the level of 
expressiveness possible with them. I hope changing the template system to 
use simpler types doesn't cripple it.

Here are my ideas for ATS3, sorted from more important to less important in 
each of the 3 categories, numbered for easy reference:



a. Things to add:

1. Compiler flags. Examples:
--wproof: warn about un`primplement`ed `prfun`s
--waxiom: warn about axioms
--wtco: warn about recursive functions that can't be TCO'd.
--wunused: warn about locals that are never called
--wstrict: treat `case` as `case+`, `val` as `val+`
--wsafe: warn about `$UNSAFE` code
--wall: enable some useful subset of the above warnings
--wextra: enable all above warnings
--werror: treat warnings as errors

2. Allow using compiler flags as pragmas at the top of a file, like `#warn 
tco` to warn about any unTCO'd function bodies in the file, or `#warn all` 
for --wall. (could also be `#pragma wall` for flexibility later?)

3. Standardized attribute system to label functions with compiler flags or 
other information/tags, like C# attributes or Java annotations. The closest 
thing to this in ATS2 is the - pattern.

4. Have metaprogramming at the level of compile-time code generation. For 
example, implementing a static function that generates optimal matrix 
multiplication for a given callsite's matrix dimensions should be possible. 
Maybe this is already possible in ATS2 and I just don't know it. This would 
depend on (haha) dependent types to know the dimensions of the matrices at 
the callsite. This paper is interesting, I have not read all of it but it 
may be relevant: https://www.ccs.neu.edu/home/stchang/pubs/ckg-popl2017.pdf



b. Things to change:

1. Rename `praxi` to `axiom`, `prfun` to `claim`, `primplement` to `proof`.

2. Force function forward declaration like in haskell, splitting the 
parameter types from parameter names. Pattern matching isn't necessary, the 
syntax is just nicer this way and separates concerns. The caller only needs 
to know the *type* signature.

3. Unite `fun` and `fn`. I do not know why this distinction exists, does it 
make the compiler faster somehow to know that the function may call itself?



c. Things to remove:

1. Remove `andalso` and `orelse`. `&&` and `||` are standard in 
programming, we don't need more keywords to mentally keep track of.

2. Remove `implmnt` and `primplmnt` variants. `fn`/`fun` already sets 
precedent for spelling variations changing meaning, but here the variation 
doesn't.

3. Remove `(**)` comment syntax. It prevents us from using * as prefix 
function, like `(*) 2 1`. `/**/` does not have this issue.

4. Remove mutual function declarations with `and` in favor of private local 
functions that call their parents. The second function in a mutual 
declaration can't be referenced externally anyways, so it would be easier 
to understand the scope. `fnx` is unneeded after a.2

5. Remove `~` unary negation. I don't mean replace it with `-`, I mean take 
it out completely. Just subtract from 0 instead. `~` should be reserved for 
bitwise negation, and `-` for subtraction.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/ats-lang-users/547b0150-71c2-468b-877a-f12055d27ad9%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Hongwei Xi]

Yes, targeting LLVM is in the plan.

I have not tried Webassembly. For targeting Webassembly, the biggest issue
I can see right now is how to deal with call-by-reference. The current
transpiler
for targeting JS (atscc2js) does not support call-by-reference.

Cheers!


On Sat, Jan 5, 2019 at 4:02 AM Chris McCulloch  wrote:

> Are there any plans on streamlining it's use with LLVM and/or the musl
> libc library?
>
> Have you (or anyone else) tested it's usefulness with Webassembly?
>
> These would come in handy.
>
> Diogenes
>
> --
> 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/9c0ec72d-2e61-4c1c-8230-a87eabbcaa25%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/CAPPSPLqVVQe4hXV-zZpAJ4y6rzzE8ZKoRU9_OX3p5Vpp1dCZqw%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[Chris McCulloch]

Are there any plans on streamlining it's use with LLVM and/or the musl libc 
library?

Have you (or anyone else) tested it's usefulness with Webassembly?

These would come in handy.

Diogenes

-- 
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/9c0ec72d-2e61-4c1c-8230-a87eabbcaa25%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Chris Double]

On Mon, Oct 22, 2018 at 1:38 AM gmhwxi  wrote:
>
>
> Yes, you can already use ATS2 with Z3:
>
> https://github.com/githwxi/ATS-Postiats/tree/master/contrib/ATS-extsolve-z3
>

I wrote a bit about using it here:
https://bluishcoder.co.nz/2018/01/03/writing-basic-proofs-in-ats.html

-- 
http://bluishcoder.co.nz

-- 
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/CALn1vHFEB_%2B6isw%2BO4A%3Dz_MMTxGikYx0JXFeoQQZae5ZcHcVnw%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[gmhwxi]

Yes, you can already use ATS2 with Z3:

https://github.com/githwxi/ATS-Postiats/tree/master/contrib/ATS-extsolve-z3

On Sunday, October 21, 2018 at 3:19:39 AM UTC-4, Kiwamu Okabe wrote:
>
> On Sun, Oct 21, 2018 at 8:05 AM Hongwei Xi <...> wrote: 
> > I hope 
> > to be able to export theorems needed by a ATS program to external 
> theorem-provers. 
> > I think a particular focus should be on automated theorem-proving. 
>
> Do you use Z3 such like F*? 
> https://www.fstar-lang.org/ 
> -- 
> Kiwamu Okabe at METASEPI DESIGN 
>

-- 
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/41e8f031-69cb-4ed2-913e-108b384b6cab%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Kiwamu Okabe]

On Sun, Oct 21, 2018 at 8:05 AM Hongwei Xi  wrote:
> I hope
> to be able to export theorems needed by a ATS program to external 
> theorem-provers.
> I think a particular focus should be on automated theorem-proving.

Do you use Z3 such like F*?
https://www.fstar-lang.org/
-- 
Kiwamu Okabe at METASEPI DESIGN

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

Re: ATS3: ATS/Xanadu

[Hongwei Xi]

There will still be ATS/LF inside ATS3. However, for heavy lifting, I hope
to be able to export theorems needed by a ATS program to external
theorem-provers.
I think a particular focus should be on automated theorem-proving.

On Sat, Oct 20, 2018 at 6:27 PM Brandon Barker 
wrote:

> Does this mean one of the external theorem provers will replace ATS/LF?
> Will one be chosen or will it be relatively easy for a user to choose
> without much tooling for ATS3? I've never used one but have it on my list
> to try out out. I've heard good things about the generality of Coq but also
> complaints about interactions with e.g. OCaml. Any suggestions on which
> theorem prover is the most general (most powerful ... To use very non mathy
> terms that likely aren't helpful)?
>
> On Fri, Oct 19, 2018, 9:48 PM gmhwxi  wrote:
>
>>
>> Hi Kiwamu,
>>
>> As always, thanks for your input!
>>
>> I currently have no plan to add more support for theorem-proving in ATS3.
>> My expectation is to find ways to make direct use of existing
>> theorem-proving
>> systems (e.g., Isabel, Coq, Lean, various SMT solvers, etc.).
>>
>> I certainly want to be ambitious but there are limits :)
>>
>> On Wednesday, October 17, 2018 at 3:17:21 AM UTC-4, Kiwamu Okabe wrote:Hi
>>>
>>> I slightly learn Prolog for the design of ATS3.
>>> My opinion is following:
>>>
>>> ## Variable is useful
>>>
>>> ```
>>> $ cat family.pl
>>> father(naoyuki, hyogo).
>>> father(saburo, naoyuki).
>>> father(saburo, shinji).
>>> father(yoshihisa, hisako).
>>> mother(hisako, hyogo).
>>> mother(yoko, naoyuki).
>>> mother(yoko, shinji).
>>> mother(nobuko, hisako).
>>> $ swipl
>>> ?- [family].
>>> true.
>>>
>>> ?- father(F, hyogo), father(G, F).
>>> F = naoyuki,
>>> G = saburo.
>>> ```
>>>
>>> Does ATS2 have such variable to prove something already?
>>>
>>> ## `spy` is useful
>>>
>>> ```
>>> $ cat fact.pl
>>> fact(0, 1).
>>> fact(N, F) :-
>>> N > 0,
>>> N1 is N-1,
>>> fact(N1, F1),
>>> F is N*F1.
>>> $ swipl
>>> ?- [fact].
>>> true.
>>>
>>> ?- spy(fact).
>>> % Spy point on fact/2
>>> true.
>>>
>>> [debug]  ?- fact(10,F).
>>>  * Call: (8) fact(10, _828) ? creep
>>>Call: (9) 10>0 ? creep
>>>Exit: (9) 10>0 ? creep
>>>Call: (9) _1052 is 10+ -1 ? creep
>>>Exit: (9) 9 is 10+ -1 ? creep
>>>  * Call: (9) fact(9, _1054) ? creep
>>>Call: (10) 9>0 ? creep
>>>Exit: (10) 9>0 ? creep
>>>Call: (10) _1058 is 9+ -1 ? creep
>>>Exit: (10) 8 is 9+ -1 ? creep
>>>  * Call: (10) fact(8, _1060) ? creep
>>>Call: (11) 8>0 ? creep
>>>Exit: (11) 8>0 ? creep
>>>Call: (11) _1064 is 8+ -1 ? creep
>>>Exit: (11) 7 is 8+ -1 ? EOF: exit
>>> ```
>>>
>>> There will be some debugger for proof things of ATS3?
>>> Or symbolic execution such like https://github.com/verifast/verifast
>>> is also useful.
>>>
>>> ## Compressed description of specification
>>>
>>> ```
>>> $ cat nat.pl
>>> nat(0).
>>> nat(s(X)) :- nat(X).
>>>
>>> plus(0, Y, Y).
>>> plus(s(X), Y, s(Z)) :- plus(X, Y, Z).
>>>
>>> le(X, Y) :- plus(X, _, Y).
>>>
>>> lt(X, Y) :- le(s(X), Y).
>>>
>>> quot(X, Y, 0, X) :- lt(X, Y).
>>> quot(X, Y, s(Q), R) :- plus(Y, X1, X), quot(X1, Y, Q, R).
>>>
>>> dnd(M, N) :- quot(N, M, _, s(_)).
>>>
>>> df(s(0), _).
>>> df(s(s(M)), N) :- dnd(s(s(M)), N), df(s(M), N).
>>>
>>> prime(s(X)) :- df(X, s(X)).
>>> $ swipl
>>> ?- [nat].
>>> true.
>>>
>>> ?- nat(N), prime(N).
>>> N = s(s(0))
>>> ```
>>>
>>> `nat(N), prime(N).` is very smart description of specification.
>>>
>>> Regards,
>>>
>> --
>> 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/topic/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/msgid/ats-lang-users/5215a856-028e-4472-8b46-eadfd1f0aeeb%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/CAORbNRpPM0riqGWz9N7c0WL-5a802j-WHPfQHxLhAMbYBFGvfQ%40mail.gmail.com
> 
> .

Re: ATS3: ATS/Xanadu

[Brandon Barker]

Does this mean one of the external theorem provers will replace ATS/LF?
Will one be chosen or will it be relatively easy for a user to choose
without much tooling for ATS3? I've never used one but have it on my list
to try out out. I've heard good things about the generality of Coq but also
complaints about interactions with e.g. OCaml. Any suggestions on which
theorem prover is the most general (most powerful ... To use very non mathy
terms that likely aren't helpful)?

On Fri, Oct 19, 2018, 9:48 PM gmhwxi  wrote:

>
> Hi Kiwamu,
>
> As always, thanks for your input!
>
> I currently have no plan to add more support for theorem-proving in ATS3.
> My expectation is to find ways to make direct use of existing
> theorem-proving
> systems (e.g., Isabel, Coq, Lean, various SMT solvers, etc.).
>
> I certainly want to be ambitious but there are limits :)
>
> On Wednesday, October 17, 2018 at 3:17:21 AM UTC-4, Kiwamu Okabe wrote:Hi
>>
>> I slightly learn Prolog for the design of ATS3.
>> My opinion is following:
>>
>> ## Variable is useful
>>
>> ```
>> $ cat family.pl
>> father(naoyuki, hyogo).
>> father(saburo, naoyuki).
>> father(saburo, shinji).
>> father(yoshihisa, hisako).
>> mother(hisako, hyogo).
>> mother(yoko, naoyuki).
>> mother(yoko, shinji).
>> mother(nobuko, hisako).
>> $ swipl
>> ?- [family].
>> true.
>>
>> ?- father(F, hyogo), father(G, F).
>> F = naoyuki,
>> G = saburo.
>> ```
>>
>> Does ATS2 have such variable to prove something already?
>>
>> ## `spy` is useful
>>
>> ```
>> $ cat fact.pl
>> fact(0, 1).
>> fact(N, F) :-
>> N > 0,
>> N1 is N-1,
>> fact(N1, F1),
>> F is N*F1.
>> $ swipl
>> ?- [fact].
>> true.
>>
>> ?- spy(fact).
>> % Spy point on fact/2
>> true.
>>
>> [debug]  ?- fact(10,F).
>>  * Call: (8) fact(10, _828) ? creep
>>Call: (9) 10>0 ? creep
>>Exit: (9) 10>0 ? creep
>>Call: (9) _1052 is 10+ -1 ? creep
>>Exit: (9) 9 is 10+ -1 ? creep
>>  * Call: (9) fact(9, _1054) ? creep
>>Call: (10) 9>0 ? creep
>>Exit: (10) 9>0 ? creep
>>Call: (10) _1058 is 9+ -1 ? creep
>>Exit: (10) 8 is 9+ -1 ? creep
>>  * Call: (10) fact(8, _1060) ? creep
>>Call: (11) 8>0 ? creep
>>Exit: (11) 8>0 ? creep
>>Call: (11) _1064 is 8+ -1 ? creep
>>Exit: (11) 7 is 8+ -1 ? EOF: exit
>> ```
>>
>> There will be some debugger for proof things of ATS3?
>> Or symbolic execution such like https://github.com/verifast/verifast
>> is also useful.
>>
>> ## Compressed description of specification
>>
>> ```
>> $ cat nat.pl
>> nat(0).
>> nat(s(X)) :- nat(X).
>>
>> plus(0, Y, Y).
>> plus(s(X), Y, s(Z)) :- plus(X, Y, Z).
>>
>> le(X, Y) :- plus(X, _, Y).
>>
>> lt(X, Y) :- le(s(X), Y).
>>
>> quot(X, Y, 0, X) :- lt(X, Y).
>> quot(X, Y, s(Q), R) :- plus(Y, X1, X), quot(X1, Y, Q, R).
>>
>> dnd(M, N) :- quot(N, M, _, s(_)).
>>
>> df(s(0), _).
>> df(s(s(M)), N) :- dnd(s(s(M)), N), df(s(M), N).
>>
>> prime(s(X)) :- df(X, s(X)).
>> $ swipl
>> ?- [nat].
>> true.
>>
>> ?- nat(N), prime(N).
>> N = s(s(0))
>> ```
>>
>> `nat(N), prime(N).` is very smart description of specification.
>>
>> Regards,
>>
> --
> 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/topic/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/msgid/ats-lang-users/5215a856-028e-4472-8b46-eadfd1f0aeeb%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/CAORbNRpPM0riqGWz9N7c0WL-5a802j-WHPfQHxLhAMbYBFGvfQ%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[Kiwamu Okabe]

On Sat, Oct 20, 2018 at 11:35 PM Vanessa McHale  wrote:
> language-xats is being written by reading the source code

Yes. I agree. It seems like readable specification for me.
(But... do you mean Hongwei's ATS3 parser is not human readable? :) )

> - that of the
> lexer and that of the parser. The parser has some comments which I
> assume are a notation like BNF, e.g.
> https://github.com/githwxi/ATS-Xanadu/blob/master/srcgen/xats/SATS/parsing.sats#L349

Thanks. It's a best starting point on ATS3 for me.
-- 
Kiwamu Okabe at METASEPI DESIGN

-- 
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/CAEvX6dmjw6BGGaA6UONSFu%2Bx%3D5ZL1O0LtQn7Cz5YNNFDnk9kcQ%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[Hongwei Xi]

Thanks!

Yes, the syntax design for the core of ATS3 is mostly done
at this stage. The comments may not be up-to-date but should
not be far off. Here are a few notes:

Keywords for initiating a declaration usually start with the symbol #

For instance,

#infixl (50) + -

#include "a-path-to-a-file"

A function-like in ATS is something like a function but not a function.
For example, $delay, $raise, $extcode,  As you may have guessed
correctly,
the name for a function-like usually starts with the symbol $.

Pointed brackets are now used to group parameters for templates. For
instance,

fun foo(...) = ...

'type' in ATS3 is for 't@ype' in ATS2; 'tbox' for 'type'.  And annother
name for 'type'
is 'tflt' / 'tflat'.

I assume that you will provide some documentation for language-xats :)
This will be a BIG help for people interested in implementing things like
emacs modes.

Cheers!


On Sat, Oct 20, 2018 at 10:35 AM Vanessa McHale 
wrote:

> language-xats is being written by reading the source code - that of the
> lexer and that of the parser. The parser has some comments which I
> assume are a notation like BNF, e.g.
>
> https://github.com/githwxi/ATS-Xanadu/blob/master/srcgen/xats/SATS/parsing.sats#L349
>
> On 10/20/18 1:02 AM, Kiwamu Okabe wrote:
> > On Sat, Oct 20, 2018 at 1:42 PM Vanessa McHale 
> wrote:
> >> Cross-compilation is in decent shape even with ATS2, at least on Debian.
> > Thanks. I hope ATS3 also do that.
> >
> >> I have built binaries for many platforms you can imagine, including
> >> Redox https://github.com/vmchale/illiterate/releases
> > Wow! Literate programming for ATS!!!
> > I believe you are the best architect of ATS ecosystem. Best balance.
> >
> >> As for package management - that I hope to handle (in part) myself. I
> >> have a much better grasp of ATS now and so I can read the canonical
> >> parser/lexer and should be able to write a better language library:
> >> https://github.com/vmchale/language-xats
> > Are you writing above library without any documentation? Just reading
> > Hongwei's code?
> > I think your parser is useful for me to understand ATS3 language.
> >
> >> The dependency resolution (and some of the cross-compiling/caching edge
> >> cases) for atspkg are broken, but I think I can fix much of that when
> >> writing xpkg :)
> > Thanks. Great.
> >
> >> As for an assembler backend - that may be out of my area of expertise
> >> but there are relatively few places where GCC/C is not expressive
> >> enough. I'd love to see ATS genuinely beat C, but the opportunities for
> >> doing so seem sparse - only FORTRAN and C++ (or maybe J) do this
> reliably.
> > I also like C backend. My motivation is based on waning debugable binary
> > with ATS3 such using DWARF. Such assembler backend with LLVM may be
> > useful than swapping C's DWARF with own ATS own DWARF. Maybe.
> >
> > Best,
> > --
> > Kiwamu Okabe at METASEPI DESIGN
> >
>
> --
> 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/b7750359-e809-7c58-5c5e-9c5f5c047ba6%40iohk.io
> .
>

-- 
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/CAPPSPLoRykaR5WH%2BJ%3DRuZpFnw1mf2Hwucg%3Dgw7eCuaSAWRF1ZQ%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[Vanessa McHale]

language-xats is being written by reading the source code - that of the
lexer and that of the parser. The parser has some comments which I
assume are a notation like BNF, e.g.
https://github.com/githwxi/ATS-Xanadu/blob/master/srcgen/xats/SATS/parsing.sats#L349

On 10/20/18 1:02 AM, Kiwamu Okabe wrote:
> On Sat, Oct 20, 2018 at 1:42 PM Vanessa McHale  wrote:
>> Cross-compilation is in decent shape even with ATS2, at least on Debian.
> Thanks. I hope ATS3 also do that.
>
>> I have built binaries for many platforms you can imagine, including
>> Redox https://github.com/vmchale/illiterate/releases
> Wow! Literate programming for ATS!!!
> I believe you are the best architect of ATS ecosystem. Best balance.
>
>> As for package management - that I hope to handle (in part) myself. I
>> have a much better grasp of ATS now and so I can read the canonical
>> parser/lexer and should be able to write a better language library:
>> https://github.com/vmchale/language-xats
> Are you writing above library without any documentation? Just reading
> Hongwei's code?
> I think your parser is useful for me to understand ATS3 language.
>
>> The dependency resolution (and some of the cross-compiling/caching edge
>> cases) for atspkg are broken, but I think I can fix much of that when
>> writing xpkg :)
> Thanks. Great.
>
>> As for an assembler backend - that may be out of my area of expertise
>> but there are relatively few places where GCC/C is not expressive
>> enough. I'd love to see ATS genuinely beat C, but the opportunities for
>> doing so seem sparse - only FORTRAN and C++ (or maybe J) do this reliably.
> I also like C backend. My motivation is based on waning debugable binary
> with ATS3 such using DWARF. Such assembler backend with LLVM may be
> useful than swapping C's DWARF with own ATS own DWARF. Maybe.
>
> Best,
> --
> Kiwamu Okabe at METASEPI DESIGN
>

-- 
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/b7750359-e809-7c58-5c5e-9c5f5c047ba6%40iohk.io.


signature.asc
Description: OpenPGP digital signature

Re: ATS3: ATS/Xanadu

[Kiwamu Okabe]

On Sat, Oct 20, 2018 at 1:42 PM Vanessa McHale  wrote:
> Cross-compilation is in decent shape even with ATS2, at least on Debian.

Thanks. I hope ATS3 also do that.

> I have built binaries for many platforms you can imagine, including
> Redox https://github.com/vmchale/illiterate/releases

Wow! Literate programming for ATS!!!
I believe you are the best architect of ATS ecosystem. Best balance.

> As for package management - that I hope to handle (in part) myself. I
> have a much better grasp of ATS now and so I can read the canonical
> parser/lexer and should be able to write a better language library:
> https://github.com/vmchale/language-xats

Are you writing above library without any documentation? Just reading
Hongwei's code?
I think your parser is useful for me to understand ATS3 language.

> The dependency resolution (and some of the cross-compiling/caching edge
> cases) for atspkg are broken, but I think I can fix much of that when
> writing xpkg :)

Thanks. Great.

> As for an assembler backend - that may be out of my area of expertise
> but there are relatively few places where GCC/C is not expressive
> enough. I'd love to see ATS genuinely beat C, but the opportunities for
> doing so seem sparse - only FORTRAN and C++ (or maybe J) do this reliably.

I also like C backend. My motivation is based on waning debugable binary
with ATS3 such using DWARF. Such assembler backend with LLVM may be
useful than swapping C's DWARF with own ATS own DWARF. Maybe.

Best,
--
Kiwamu Okabe at METASEPI DESIGN

-- 
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/CAEvX6d%3D3smCn73ZY-232X5mb0f7U%2BkF459u0U_DPj7rie_29eA%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[Vanessa McHale]

Cross-compilation is in decent shape even with ATS2, at least on Debian.
I can cross-compile a program for Raspberry Pi using Debian-provided
cross-compilers.

I have built binaries for many platforms you can imagine, including
Redox https://github.com/vmchale/illiterate/releases

As for package management - that I hope to handle (in part) myself. I
have a much better grasp of ATS now and so I can read the canonical
parser/lexer and should be able to write a better language library:
https://github.com/vmchale/language-xats

The dependency resolution (and some of the cross-compiling/caching edge
cases) for atspkg are broken, but I think I can fix much of that when
writing xpkg :)

As for an assembler backend - that may be out of my area of expertise
but there are relatively few places where GCC/C is not expressive
enough. I'd love to see ATS genuinely beat C, but the opportunities for
doing so seem sparse - only FORTRAN and C++ (or maybe J) do this reliably.

On 10/19/18 10:30 PM, Kiwamu Okabe wrote:
> Dear Hongwei,
>
> Thanks for your great effort for developing ATS3.
> I can hardly wait publishing your first release of ATS3 manual!
>
> On Sat, Oct 20, 2018 at 10:48 AM gmhwxi  wrote:
>> I currently have no plan to add more support for theorem-proving in ATS3.
> OK. It's just idea. No problem.
>
>> My expectation is to find ways to make direct use of existing theorem-proving
>> systems (e.g., Isabel, Coq, Lean, various SMT solvers, etc.).
> Coq's tactic is very useful for huge proof!
>
>> I certainly want to be ambitious but there are limits :)
> Yes. I think you should focus to implement the ATS3 core.
> I just say:
>
> "We need some ecosystem on ATS3 core, because someone can shape:
> * Coq's tactic
> * Package manager such like atspkg
> * Assembler backend
> * Debug support with DWARF
> * Cross compil
> ...etc...
> Some of them should be created by me."
>
> Best regards,

-- 
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/201f7a8d-0dfa-5ccb-a3d4-475e478ee66e%40iohk.io.


signature.asc
Description: OpenPGP digital signature

Re: ATS3: ATS/Xanadu

[Kiwamu Okabe]

Dear Hongwei,

Thanks for your great effort for developing ATS3.
I can hardly wait publishing your first release of ATS3 manual!

On Sat, Oct 20, 2018 at 10:48 AM gmhwxi  wrote:
> I currently have no plan to add more support for theorem-proving in ATS3.

OK. It's just idea. No problem.

> My expectation is to find ways to make direct use of existing theorem-proving
> systems (e.g., Isabel, Coq, Lean, various SMT solvers, etc.).

Coq's tactic is very useful for huge proof!

> I certainly want to be ambitious but there are limits :)

Yes. I think you should focus to implement the ATS3 core.
I just say:

"We need some ecosystem on ATS3 core, because someone can shape:
* Coq's tactic
* Package manager such like atspkg
* Assembler backend
* Debug support with DWARF
* Cross compil
...etc...
Some of them should be created by me."

Best regards,
-- 
Kiwamu Okabe at METASEPI DESIGN

-- 
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/CAEvX6d%3DkJeY11y2ZecOHTY5%3DyoQbdv%3Dx4aFGcZ_pto-WnBOA6Q%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[gmhwxi]

Hi Kiwamu,

As always, thanks for your input!

I currently have no plan to add more support for theorem-proving in ATS3.
My expectation is to find ways to make direct use of existing 
theorem-proving
systems (e.g., Isabel, Coq, Lean, various SMT solvers, etc.).

I certainly want to be ambitious but there are limits :)

On Wednesday, October 17, 2018 at 3:17:21 AM UTC-4, Kiwamu Okabe wrote:Hi
>
> I slightly learn Prolog for the design of ATS3. 
> My opinion is following: 
>
> ## Variable is useful 
>
> ``` 
> $ cat family.pl 
> father(naoyuki, hyogo). 
> father(saburo, naoyuki). 
> father(saburo, shinji). 
> father(yoshihisa, hisako). 
> mother(hisako, hyogo). 
> mother(yoko, naoyuki). 
> mother(yoko, shinji). 
> mother(nobuko, hisako). 
> $ swipl 
> ?- [family]. 
> true. 
>
> ?- father(F, hyogo), father(G, F). 
> F = naoyuki, 
> G = saburo. 
> ``` 
>
> Does ATS2 have such variable to prove something already? 
>
> ## `spy` is useful 
>
> ``` 
> $ cat fact.pl 
> fact(0, 1). 
> fact(N, F) :- 
> N > 0, 
> N1 is N-1, 
> fact(N1, F1), 
> F is N*F1. 
> $ swipl 
> ?- [fact]. 
> true. 
>
> ?- spy(fact). 
> % Spy point on fact/2 
> true. 
>
> [debug]  ?- fact(10,F). 
>  * Call: (8) fact(10, _828) ? creep 
>Call: (9) 10>0 ? creep 
>Exit: (9) 10>0 ? creep 
>Call: (9) _1052 is 10+ -1 ? creep 
>Exit: (9) 9 is 10+ -1 ? creep 
>  * Call: (9) fact(9, _1054) ? creep 
>Call: (10) 9>0 ? creep 
>Exit: (10) 9>0 ? creep 
>Call: (10) _1058 is 9+ -1 ? creep 
>Exit: (10) 8 is 9+ -1 ? creep 
>  * Call: (10) fact(8, _1060) ? creep 
>Call: (11) 8>0 ? creep 
>Exit: (11) 8>0 ? creep 
>Call: (11) _1064 is 8+ -1 ? creep 
>Exit: (11) 7 is 8+ -1 ? EOF: exit 
> ``` 
>
> There will be some debugger for proof things of ATS3? 
> Or symbolic execution such like https://github.com/verifast/verifast 
> is also useful. 
>
> ## Compressed description of specification 
>
> ``` 
> $ cat nat.pl 
> nat(0). 
> nat(s(X)) :- nat(X). 
>
> plus(0, Y, Y). 
> plus(s(X), Y, s(Z)) :- plus(X, Y, Z). 
>
> le(X, Y) :- plus(X, _, Y). 
>
> lt(X, Y) :- le(s(X), Y). 
>
> quot(X, Y, 0, X) :- lt(X, Y). 
> quot(X, Y, s(Q), R) :- plus(Y, X1, X), quot(X1, Y, Q, R). 
>
> dnd(M, N) :- quot(N, M, _, s(_)). 
>
> df(s(0), _). 
> df(s(s(M)), N) :- dnd(s(s(M)), N), df(s(M), N). 
>
> prime(s(X)) :- df(X, s(X)). 
> $ swipl 
> ?- [nat]. 
> true. 
>
> ?- nat(N), prime(N). 
> N = s(s(0)) 
> ``` 
>
> `nat(N), prime(N).` is very smart description of specification. 
>
> Regards, 
>

-- 
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/5215a856-028e-4472-8b46-eadfd1f0aeeb%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Hongwei Xi]

Thanks!

For the moment, I will work on what I have.
Later on, we can have discussion for further extensions.
As I said repeatedly before, I see ATS3 both as a source language and as a
target language.
Programming extensions can and will be designed on top of ATS3. For now, I
focus on ATS3
proper.

On Wed, Oct 17, 2018 at 3:22 AM Kiwamu Okabe  wrote:

> And I would like to forward @h_sakurai's opinion:
>
> ```
> How about introduce notation such like Coq
>
> https://coq.inria.fr/refman/user-extensions/syntax-extensions.html
>
> It may be a hint for the template system in ATS3.
> ```
>
> --
> 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/CAEvX6dmWWFq8H0uuBUQD-eBrwY6KnjtpN%3DE9oNsJw22kzwzy8A%40mail.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/CAPPSPLpEavJSjciDPeaRWKfuzQxLrGMCO_hiw4SEeHsCMXAegA%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[Kiwamu Okabe]

And I would like to forward @h_sakurai's opinion:

```
How about introduce notation such like Coq

https://coq.inria.fr/refman/user-extensions/syntax-extensions.html

It may be a hint for the template system in ATS3.
```

-- 
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/CAEvX6dmWWFq8H0uuBUQD-eBrwY6KnjtpN%3DE9oNsJw22kzwzy8A%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[Kiwamu Okabe]

I slightly learn Prolog for the design of ATS3.
My opinion is following:

## Variable is useful

```
$ cat family.pl
father(naoyuki, hyogo).
father(saburo, naoyuki).
father(saburo, shinji).
father(yoshihisa, hisako).
mother(hisako, hyogo).
mother(yoko, naoyuki).
mother(yoko, shinji).
mother(nobuko, hisako).
$ swipl
?- [family].
true.

?- father(F, hyogo), father(G, F).
F = naoyuki,
G = saburo.
```

Does ATS2 have such variable to prove something already?

## `spy` is useful

```
$ cat fact.pl
fact(0, 1).
fact(N, F) :-
N > 0,
N1 is N-1,
fact(N1, F1),
F is N*F1.
$ swipl
?- [fact].
true.

?- spy(fact).
% Spy point on fact/2
true.

[debug]  ?- fact(10,F).
 * Call: (8) fact(10, _828) ? creep
   Call: (9) 10>0 ? creep
   Exit: (9) 10>0 ? creep
   Call: (9) _1052 is 10+ -1 ? creep
   Exit: (9) 9 is 10+ -1 ? creep
 * Call: (9) fact(9, _1054) ? creep
   Call: (10) 9>0 ? creep
   Exit: (10) 9>0 ? creep
   Call: (10) _1058 is 9+ -1 ? creep
   Exit: (10) 8 is 9+ -1 ? creep
 * Call: (10) fact(8, _1060) ? creep
   Call: (11) 8>0 ? creep
   Exit: (11) 8>0 ? creep
   Call: (11) _1064 is 8+ -1 ? creep
   Exit: (11) 7 is 8+ -1 ? EOF: exit
```

There will be some debugger for proof things of ATS3?
Or symbolic execution such like https://github.com/verifast/verifast
is also useful.

## Compressed description of specification

```
$ cat nat.pl
nat(0).
nat(s(X)) :- nat(X).

plus(0, Y, Y).
plus(s(X), Y, s(Z)) :- plus(X, Y, Z).

le(X, Y) :- plus(X, _, Y).

lt(X, Y) :- le(s(X), Y).

quot(X, Y, 0, X) :- lt(X, Y).
quot(X, Y, s(Q), R) :- plus(Y, X1, X), quot(X1, Y, Q, R).

dnd(M, N) :- quot(N, M, _, s(_)).

df(s(0), _).
df(s(s(M)), N) :- dnd(s(s(M)), N), df(s(M), N).

prime(s(X)) :- df(X, s(X)).
$ swipl
?- [nat].
true.

?- nat(N), prime(N).
N = s(s(0))
```

`nat(N), prime(N).` is very smart description of specification.

Regards,

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

Re: ATS3: ATS/Xanadu

[Kiwamu Okabe]

On Thu, Oct 11, 2018 at 1:40 PM Kiwamu Okabe  wrote:
> A. Symbolic execution such like https://github.com/verifast/verifast IDE,
>because we can watch execution sequence on the IDE.
>See the following Steps pane on figure 1 at page 4.
>https://people.cs.kuleuven.be/~bart.jacobs/verifast/tutorial.pdf

Also VeriFast can show tree of execution at right pane of IDE!
https://www.flickr.com/photos/masterq/36292655852/

-- 
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/CAEvX6dnOuzvQHcGsn5xOHiwgC9NTxb%3DMgN8rn5soG%3DLAgHsx_Q%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[Kiwamu Okabe]

Also I think following are good parts:

A. Symbolic execution such like https://github.com/verifast/verifast IDE,
   because we can watch execution sequence on the IDE.
   See the following Steps pane on figure 1 at page 4.
   https://people.cs.kuleuven.be/~bart.jacobs/verifast/tutorial.pdf
B. Tactic such like Coq, which is useful to prove large code.

-- 
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/CAEvX6dkBh_4Sq4D6ZYxK_EtRY%2B5%3Dgt1n%3DcKA6fTGEBTvjausMg%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[Kiwamu Okabe]

On Thu, Oct 11, 2018 at 12:07 PM Hongwei Xi  wrote:
> I hope that I can structure the ATS3 compiler in such a way that you
>  should be to add DWALF support on your own.

Yes.
I believe such DWARF support is only hoped by me.
-- 
Kiwamu Okabe at METASEPI DESIGN

-- 
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/CAEvX6d%3DexGcuKcWgZFbi8434CyY4Mh8HOaZbRWVZzfmGdE%2BBJQ%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[Hongwei Xi]

Okay. I keep this in mind.

I hope that I can structure the ATS3 compiler in such a way that you
 should be to add DWELF support on your own.

On Wed, Oct 10, 2018 at 10:48 PM Kiwamu Okabe  wrote:

> May I add more requirement?
>
> ## Debugger support with DWARF
>
> * Rust support showing backtrace on the Rust source code.
>
> https://rust-embedded.github.io/bookshelf/discovery/05-led-roulette/debug-it.html
> * It's useful to debug hardware, not software.
> * Sometime we face such hardware bugs and end up to debug it.
> * The hardware bugs are not caused by ATS language, and stand
>   on hardware registers.
> * ATS2 has less power to debug such hardware bugs, because
>   the ELF binary has DWARF of C language, not ATS.
> --
> Kiwamu Okabe
>
> --
> 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/CAEvX6dnfHUzCYG-cjx1_RVd%3D_VR%3DDnv%2BVMbyAUFK9EK%2B5qmj1Q%40mail.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/CAPPSPLqaSjnnWR%2Bi3zm_xYn5-W1vz6q3gCYU7J4tS8GBjZNpQQ%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[Kiwamu Okabe]

May I add more requirement?

## Debugger support with DWARF

* Rust support showing backtrace on the Rust source code.
  
https://rust-embedded.github.io/bookshelf/discovery/05-led-roulette/debug-it.html
* It's useful to debug hardware, not software.
* Sometime we face such hardware bugs and end up to debug it.
* The hardware bugs are not caused by ATS language, and stand
  on hardware registers.
* ATS2 has less power to debug such hardware bugs, because
  the ELF binary has DWARF of C language, not ATS.
-- 
Kiwamu Okabe

-- 
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/CAEvX6dnfHUzCYG-cjx1_RVd%3D_VR%3DDnv%2BVMbyAUFK9EK%2B5qmj1Q%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[gmhwxi]

Indeed, this can be a very useful feature.

When I implemented macdef (and macrodef as the recursive version of macdef),
I only handled certain forms of expression (to be used as the definition of 
a macro).
I could try to see if it is easy to add a few more forms so as to handle 
your example.

Right now, I am just too focused on ATS3.

On Thursday, October 4, 2018 at 9:47:31 PM UTC-4, M88 wrote:
>
>
> I'd agree in general that documentation, errors and usability improvements 
> are very important in ATS3 -- ATS2 is a feature-rich language as it is, but 
> exceedingly difficult to navigate.  I will go on to propose a feature, but 
> the former aspect should get more of the focus.
>
> Recently I was attempting to write parser combinators without 
> heap-allocated closures (or any sort of allocation).  It was a bit 
> difficult because stack-allocated closures are of varying size and must be 
> affixed to a `var`.  I did find a successful approach using templates.
>
> It went a little something like:
>
> implement parse_token$tok<>() = "this"
> val THIS = parse_token<>
> implement parse_token$tok<>() = "that"
> val THAT = parse_token<>
>
> implement parse_or$p1(str,tup) = THIS(str,tup)
> implement parse_or$p2(str,tup) = THAT(str,tup)
> val THIS_or_THAT = parse_or
>
> It would be nice if something like this were possible:
>
> macdef token(str) = let
>implement parse_token$tok<>() = ,(str)
>in parse_token<>
>end
>
> macdef ||(p1,p2) = let
>implement parse_or$p1(str,tup) = ,(p1)(str,tup)
>implement parse_or$p2(str,tup) = ,(p2)(str,tup)
> in parse_or
> end
>
> val this_or_that = token("this") || token("that")  // returns a constant 
> cfun.
>
> This probably only makes sense in the domain of embedded programming 
> (otherwise closures could be used). 
>
>
>
> 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/b7c12e3a-c95e-43e7-8cb5-d13f20db12b4%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[M88]

Thanks Julian,

I could see this as a possible implementation of the original templates.  
Ultimately, I would see the parser parameterized over different input / 
output types, and stack allocated variables could be different sizes, 
depending on what is being parsed.  I think templates would be necessary 
for that (or at least, convenient).  

My original suggestion has caveats (eg, binary size could explode, *maybe*).  
While I'm not sure macros are the right answer ( I chose them because it's 
syntactically valid ATS2 ), I could see the ability to compose template 
instantiations on a high level being rather useful.  

More broadly, I've been toying with the observation that, in many cases, 
implicit closure arguments are actually constants. Perhaps there are ways 
to exploit this for high-level programming.  I'm getting ahead of myself 
(it's probably frivolous just to save on a few cloref allocations), but my 
idea went something like this:

In this contrived example, let's say we wanted to curry an envless cfun, 
returning an envless cfun.  We could do this in ATS2 like so:

extern
fun {a,b,c:t@ype} curry$fopr(a,b) : c

extern
fun {a:t@ype} curry$arg() : a

extern
fun {a,b,c:t@ype} curry() :  b -> c 

implement {a,b,c}
curry () =
let
fun f1 (b) : c =
curry$fopr(curry$arg(),b) 
in f1
end


This would be difficult to actually use, in practice.  

What if it could be transformed into something like this, where cst() is a 
type specifier, requiring the value to be a top-level declaration or a 
constant literal:

extern
fun {a,b,c:t@ype} curry( cst( (a,b) -> c ) ) :  cst( cst(a) -> b -> c )

implement {a,b,c}
curry ( f ) = 
   lam( x ) => lam (y) => f(x,y) // no error about this not being envless, 
because f and x are cst()

This is more limited than closures, but still useful.  For instance, all 
envless lambda literals would be cst.  Then it'd be possible to do things 
like:

val f = curry( lam ( x: int, y : int ) : int => x + y )
val y = f(5)(2)  // returns 7

I would think that any function that accepted or returned a cst(...) value 
would need to be a template for it to work. 

I suppose implementing this idea  may not be worth it, but I thought the 
ability to instantiate templates in macros might still be nice to have.



On Friday, October 5, 2018 at 3:17:55 AM UTC-4, Julian Fondren wrote:
>
> On Thursday, October 4, 2018 at 8:47:31 PM UTC-5, M88 wrote:
>>
>> Recently I was attempting to write parser combinators without 
>> heap-allocated closures (or any sort of allocation).  It was a bit 
>> difficult because stack-allocated closures are of varying size and must be 
>> affixed to a `var`.  I did find a successful approach using templates.
>>
>
> With a linear object that includes a stack (which can avoid allocation if 
> you implement that with a fixed array) you can have code like
>
> let
> val p = new_parser(argv[1])
> fun parseHello(p: !parser_vt): void = parse(p, "hello")
> fun parseQuery(p: !parser_vt): void = parse(p, "what day of the month is 
> it?")
> fun parseAcceptable(p: !parser_vt): void = (
> push(p); parseHello(p);
> if failed(p) then (
> pop(p); parseQuery(p);
> ) else commit(p)
> )
> in
> parseAcceptable(p);
> if isdone(p) then
> println!("Hi, it's the first of the month.");
> free_parser(p);
> end
>
>
> In general, think of linear objects when you're looking at some pretty 
> do-notation, from how purely functional languages with uniqueness types do 
> I/O. 
>
>
> The local-function-: transformation (turning apparently 
> closed-over variables into implicit parameters) will try to consume your 
> linear variables, so you can't easily do without those p arguments. That 
> same transformation could be used though if you kept your state in mutable 
> local variables, which might not be so bad if you #include the : 
> functions into your let-declaration from a .hats file with stuff like:
>
> fun parse(str: string): void = (
> if !reading then (
> if is_prefix(str, input, !input$at) then
> !input$at := !input$at + strlen(str)
> else
> !reading := false
> )
> )
>
>
> It went a little something like:
>>
>> implement parse_token$tok<>() = "this"
>> val THIS = parse_token<>
>> implement parse_token$tok<>() = "that"
>> val THAT = parse_token<>
>>
>> implement parse_or$p1(str,tup) = THIS(str,tup)
>> implement parse_or$p2(str,tup) = THAT(str,tup)
>> val THIS_or_THAT = parse_or
>>
>> It would be nice if something like this were possible:
>>
>> macdef token(str) = let
>>implement parse_token$tok<>() = ,(str)
>>in parse_token<>
>>end
>>
>> macdef ||(p1,p2) = let
>>implement parse_or$p1(str,tup) = ,(p1)(str,tup)
>>implement parse_or$p2(str,tup) = ,(p2)(str,tup)
>> in parse_or
>> end
>>
>> val this_or_that = token("thi

Re: ATS3: ATS/Xanadu

[Julian Fondren]

On Thursday, October 4, 2018 at 8:47:31 PM UTC-5, M88 wrote:
>
> Recently I was attempting to write parser combinators without 
> heap-allocated closures (or any sort of allocation).  It was a bit 
> difficult because stack-allocated closures are of varying size and must be 
> affixed to a `var`.  I did find a successful approach using templates.
>

With a linear object that includes a stack (which can avoid allocation if 
you implement that with a fixed array) you can have code like

let
val p = new_parser(argv[1])
fun parseHello(p: !parser_vt): void = parse(p, "hello")
fun parseQuery(p: !parser_vt): void = parse(p, "what day of the month is 
it?")
fun parseAcceptable(p: !parser_vt): void = (
push(p); parseHello(p);
if failed(p) then (
pop(p); parseQuery(p);
) else commit(p)
)
in
parseAcceptable(p);
if isdone(p) then
println!("Hi, it's the first of the month.");
free_parser(p);
end


In general, think of linear objects when you're looking at some pretty 
do-notation, from how purely functional languages with uniqueness types do 
I/O. 


The local-function-: transformation (turning apparently 
closed-over variables into implicit parameters) will try to consume your 
linear variables, so you can't easily do without those p arguments. That 
same transformation could be used though if you kept your state in mutable 
local variables, which might not be so bad if you #include the : 
functions into your let-declaration from a .hats file with stuff like:

fun parse(str: string): void = (
if !reading then (
if is_prefix(str, input, !input$at) then
!input$at := !input$at + strlen(str)
else
!reading := false
)
)


It went a little something like:
>
> implement parse_token$tok<>() = "this"
> val THIS = parse_token<>
> implement parse_token$tok<>() = "that"
> val THAT = parse_token<>
>
> implement parse_or$p1(str,tup) = THIS(str,tup)
> implement parse_or$p2(str,tup) = THAT(str,tup)
> val THIS_or_THAT = parse_or
>
> It would be nice if something like this were possible:
>
> macdef token(str) = let
>implement parse_token$tok<>() = ,(str)
>in parse_token<>
>end
>
> macdef ||(p1,p2) = let
>implement parse_or$p1(str,tup) = ,(p1)(str,tup)
>implement parse_or$p2(str,tup) = ,(p2)(str,tup)
> in parse_or
> end
>
> val this_or_that = token("this") || token("that")  // returns a constant 
> cfun.
>
> This probably only makes sense in the domain of embedded programming 
> (otherwise closures could be used). 
>
>
>
> 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/cd8f9825-c7bd-462e-9120-87a99f867a23%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[M88]

I'd agree in general that documentation, errors and usability improvements 
are very important in ATS3 -- ATS2 is a feature-rich language as it is, but 
exceedingly difficult to navigate.  I will go on to propose a feature, but 
the former aspect should get more of the focus.

Recently I was attempting to write parser combinators without 
heap-allocated closures (or any sort of allocation).  It was a bit 
difficult because stack-allocated closures are of varying size and must be 
affixed to a `var`.  I did find a successful approach using templates.

It went a little something like:

implement parse_token$tok<>() = "this"
val THIS = parse_token<>
implement parse_token$tok<>() = "that"
val THAT = parse_token<>

implement parse_or$p1(str,tup) = THIS(str,tup)
implement parse_or$p2(str,tup) = THAT(str,tup)
val THIS_or_THAT = parse_or

It would be nice if something like this were possible:

macdef token(str) = let
   implement parse_token$tok<>() = ,(str)
   in parse_token<>
   end

macdef ||(p1,p2) = let
   implement parse_or$p1(str,tup) = ,(p1)(str,tup)
   implement parse_or$p2(str,tup) = ,(p2)(str,tup)
in parse_or
end

val this_or_that = token("this") || token("that")  // returns a constant 
cfun.

This probably only makes sense in the domain of embedded programming 
(otherwise closures could be used). 



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/7674f7d9-a788-4296-b413-ee8f58f9aed5%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[gmhwxi]

Thanks for all of your input and effort!

In ATS3, syntax errors of a program are internalized in its abstract
syntax tree. I expect that various syntax-checkers can be written to
explain the cause of syntax errors.

With good support from the community, the learning curve for ATS3
should be a lot less steeper than that of ATS2. This is certainly what
I hopes :)

Cheers!

On Monday, October 1, 2018 at 6:50:11 PM UTC-4, Julian Fondren wrote:
>
> Prompted by Zig's 0.3.0 release, I thought about ATS3 a little
> more. Zig prompted that in two different ways: first, the release
> notes had this charming assertion: "Zig intends to be so practical
> that people find themselves using it even if they dislike it."
> Second, while considering Zig, although it's a much less capable
> language than ATS, I thoght it might be good to know as a language
> 'for other people'. In the past I've done some work in C for groups,
> because C -- if there were a justification for not just using a
> scripting language -- would be accepted, while ATS certainly wouldn't.
> Zig manages to look like a much better language than C, while still
> being a language that could be accepted.
>
> On the first point, ATS is already so capable that it's worth using
> even if the syntax is off-putting in places. Although I think that it
> would be pretty easy to shave off the off-putting aspects (make
> 't@ype' the default, so spelled 'type', and the old 'type' something
> like 'boxed'; keep 'fun' and 'implement' as the defaults, but remove
> the easy alternatives that you rarely need, and make .<>. the only way
> to denote a non-recursive function -- this sort of stuff, just
> emphasizing clean defaults rather than massively rewriting the
> syntax), those aspects are only off-putting. I think people can get
> over that pretty easily, and that worries about it would be better
> directed at making ATS even more capable. I like Zig's attitude here.
>
> On the second point, I don't like my own 'language for other people'
> logic. As a social animal I'd rather just use a language 'for other
> people'. So, why wouldn't I feel comfortable submitting an ATS
> implementation for an employer, where other people will potentially
> have to maintain it? It's *definitely not* because of stuff like
> t@ype. That doesn't even come into the top ten of reasons--it doesn't,
> even when I don't have ten reasons in total. My reasons are:
>
> 1. the error messages are extremely hard to read, as they're expressed
> in internal compiler constructions. I just know that a maintainer will
> try to do something that looks obvious, get a bunch of
> impossible-for-a-casual-maintainer-to-understand error messages, and
> then immediately commit to rewriting my entire project. Even though
> I've gotten to where I can often read and benefit from ATS's error
> messages, I just can't expect anyone else to do this.
>
> And it doesn't matter how good my code is if, the first time someone
> wants to make a trivial modification to it, they throw it away and
> rewrite it in Go.
>
> 2. there is no reference manual for ATS. There's an introductory work
> that covers *most* of the language, but that not in a manner that you
> could ask, "what is this thing I'm looking at in this specific code?"
> and then look up the answer. A maintainer wants, ideally, no tutorial
> at all because the code is clear enough on inspection after you've
> grepped around to find the code you're concerned about, and two, a
> reference manual so those specific constructs in use in some code can
> be quickly understood.
>
> That's about it for reasons. although I could mention error messages
> eight more times and still not give them their due emphasis.
>
> 11. There's no interactive mode, no REPL. This is again a great help
> to people who don't know a language well--like someone tasked to make
> a small change to a program someone else has written in that language.
> A REPL would naturally allow someone to test small bits of code in an
> easy manner, as well as load an interrogate bodies of code. What type
> does that have? How many overloads of * are there? etc.
>
> Zig isn't perfect here--it doesn't have a lot of docs either. It seems
> like 2-hour screencasts are how you're supposed to learn the language.
> But it has good, clear error messages, and it prints out your code and
> graphically points to the problem, and you can build in a safe runtime
> where many errors in code are caught and result in a stack
> trace. True, ATS has the ideal where you catch many errors at
> compile-time, but it's very easy to get a segfault from ATS too, as
> simply as saying that some C function returns a string when it could
> return NULL
>
> Error categories:
>
> 1. syntax errors. I once had a function "= void", instead of ": void", and
> it took me over five minutes to find that problem. This isn't such a big
> deal but improvements are improvements.
>
> 2. template errors. ATS has no problem and then gcc gives you pages
>

Re: ATS3: ATS/Xanadu

[gmhwxi]

Thanks for all the input!

Still working on the parser. Will post a message on its progress shortly.

I personally like SML-like syntax, which is quite different from OCaml's.
After I publish the syntax for ATS3, I hope that someone could design a 
version
for it based on Lisp's syntax.

Cheers!

On Saturday, September 22, 2018 at 1:44:30 PM UTC-4, Brian Rogoff wrote:
>
> As I'm sure you're aware OCaml's syntax is not widely liked, leading to a 
> lot of attempts at resyntaxing (Revised, Pidgin, ReasonML amongst others) 
> so attempting to copy it doesn't strike me as a good idea.
> SML is not widely used enough for me to have a sense of how much the 
> syntax was liked.
>
> I love Lisps, and, like Barry Schwartz, prefer it to others. However, I 
> realize that this is a minority opinion and many programmers *hate* it. 
> Probably also not a great idea if you're trying to make ATS popular, 
> especially amongst low level programmers.
>
> Python syntax is well liked (and well hated :-) by a large number of 
> programmers. The Nim language has a kind of Pythonesque syntax with static 
> typing, and it also has powerful metaprogramming features.
> It's also used in low-level programming. It would be valuable to take a 
> look at Nim and see what lessons can be learned there.
>
> C language syntax is the most widely used, with C++ and Rust being the 
> competitors for ATS3. I happen to think D language got the template syntax 
> (and templates) right-er and provide a better model for template 
> meta-programming. A C like syntax is the safest bet IMO.
>
> Good luck, and please get ATS3 out there soon.
>
> On Sunday, September 16, 2018 at 8:58:55 AM UTC-7, gmhwxi wrote:
>>
>>
>> It is not too late :)
>>
>> For meta-programming support, LISP-like syntax is definitely
>> on my mind.
>>
>> At this point, I want to first finish designing and implementing
>> some ML-like (ML-inspired) syntax for ATS. I am getting there :)
>>
>> Once this ML-like syntax is done, it can readily serve as the basis for
>> a design of LISP-like syntax for ATS.
>>
>> Cheers!
>>
>> On Thursday, August 30, 2018 at 4:03:36 PM UTC-4, Barry Schwartz wrote:
>>>
>>> I know this comes too late and was doomed anyway, but my opinion is the 
>>> best syntax is always Lisp. :)
>>>
>>> On Friday, February 9, 2018 at 12:15:22 PM UTC-6, 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/0854e187-6966-414a-adb3-d9480c14cc29%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Julian Fondren]

On Monday, October 1, 2018 at 6:40:20 PM UTC-5, Vanessa McHale wrote:
>
> To me the main appeal of C over ATS is the existence of a standard and 
> several competing compilers. It's just a more stable language and there's 
> guarantees of better support. C features are documented and there are 
> decades of books by multiple authors.
>

This is all true of Common Lisp and Forth, apart from "better support" 
where it's still arguable. Actually I'd have trouble naming C books as good 
as those available for Common Lisp. But I'm still writing in C. If I pushed 
a CL or a Forth commit I'd just be asked how much job security I thought I 
needed, and couldn't they give me some of that in some other manner.
 

> I realize Zig has a lot of marketing going on behind it but tbh I don't 
> see much there.
>

The salespitch is extremely weak. "A good cross-compiler."? "It can do 
without libc"? "It has stack traces."???

It's just all this boring stuff that makes programming a more pleasant and 
productive experience. You can hardly even call that a language.
 

> People confuse "author doesn't know PL theory" for "practical."
>

This is just bigotry. How do you think that works? "Oh, the moment he 
couldn't explain type preservation, I realized that this was the language 
for me."
 

> On 10/01/2018 05:50 PM, Julian Fondren wrote:
>
> Prompted by Zig's 0.3.0 release, I thought about ATS3 a little
> more. Zig prompted that in two different ways: first, the release
> notes had this charming assertion: "Zig intends to be so practical
> that people find themselves using it even if they dislike it."
> Second, while considering Zig, although it's a much less capable
> language than ATS, I thoght it might be good to know as a language
> 'for other people'. In the past I've done some work in C for groups,
> because C -- if there were a justification for not just using a
> scripting language -- would be accepted, while ATS certainly wouldn't.
> Zig manages to look like a much better language than C, while still
> being a language that could be accepted.
>
> On the first point, ATS is already so capable that it's worth using
> even if the syntax is off-putting in places. Although I think that it
> would be pretty easy to shave off the off-putting aspects (make
> 't@ype' the default, so spelled 'type', and the old 'type' something
> like 'boxed'; keep 'fun' and 'implement' as the defaults, but remove
> the easy alternatives that you rarely need, and make .<>. the only way
> to denote a non-recursive function -- this sort of stuff, just
> emphasizing clean defaults rather than massively rewriting the
> syntax), those aspects are only off-putting. I think people can get
> over that pretty easily, and that worries about it would be better
> directed at making ATS even more capable. I like Zig's attitude here.
>
> On the second point, I don't like my own 'language for other people'
> logic. As a social animal I'd rather just use a language 'for other
> people'. So, why wouldn't I feel comfortable submitting an ATS
> implementation for an employer, where other people will potentially
> have to maintain it? It's *definitely not* because of stuff like
> t@ype. That doesn't even come into the top ten of reasons--it doesn't,
> even when I don't have ten reasons in total. My reasons are:
>
> 1. the error messages are extremely hard to read, as they're expressed
> in internal compiler constructions. I just know that a maintainer will
> try to do something that looks obvious, get a bunch of
> impossible-for-a-casual-maintainer-to-understand error messages, and
> then immediately commit to rewriting my entire project. Even though
> I've gotten to where I can often read and benefit from ATS's error
> messages, I just can't expect anyone else to do this.
>
> And it doesn't matter how good my code is if, the first time someone
> wants to make a trivial modification to it, they throw it away and
> rewrite it in Go.
>
> 2. there is no reference manual for ATS. There's an introductory work
> that covers *most* of the language, but that not in a manner that you
> could ask, "what is this thing I'm looking at in this specific code?"
> and then look up the answer. A maintainer wants, ideally, no tutorial
> at all because the code is clear enough on inspection after you've
> grepped around to find the code you're concerned about, and two, a
> reference manual so those specific constructs in use in some code can
> be quickly understood.
>
> That's about it for reasons. although I could mention error messages
> eight more times and still not give them their due emphasis.
>
> 11. There's no interactive mode, no REPL. This is again a great help
> to people who don't know a language well--like someone tasked to make
> a small change to a program someone else has written in that language.
> A REPL would naturally allow someone to test small bits of code in an
> easy manner, as well as load an interrogate bodies of code. What type
> does that have? How ma

Re: ATS3: ATS/Xanadu

[Vanessa McHale]

To me the main appeal of C over ATS is the existence of a standard and
several competing compilers. (I also like the fact that C has an ABI,
but then ATS benefits from this as well :)). It's just a more stable
language and there's guarantees of better support. C features are
documented and there are decades of books by multiple authors.

I realize Zig has a lot of marketing going on behind it but tbh I don't
see much there. People confuse "author doesn't know PL theory" for
"practical."

On 10/01/2018 05:50 PM, Julian Fondren wrote:
> Prompted by Zig's 0.3.0 release, I thought about ATS3 a little
> more. Zig prompted that in two different ways: first, the release
> notes had this charming assertion: "Zig intends to be so practical
> that people find themselves using it even if they dislike it."
> Second, while considering Zig, although it's a much less capable
> language than ATS, I thoght it might be good to know as a language
> 'for other people'. In the past I've done some work in C for groups,
> because C -- if there were a justification for not just using a
> scripting language -- would be accepted, while ATS certainly wouldn't.
> Zig manages to look like a much better language than C, while still
> being a language that could be accepted.
>
> On the first point, ATS is already so capable that it's worth using
> even if the syntax is off-putting in places. Although I think that it
> would be pretty easy to shave off the off-putting aspects (make
> 't@ype' the default, so spelled 'type', and the old 'type' something
> like 'boxed'; keep 'fun' and 'implement' as the defaults, but remove
> the easy alternatives that you rarely need, and make .<>. the only way
> to denote a non-recursive function -- this sort of stuff, just
> emphasizing clean defaults rather than massively rewriting the
> syntax), those aspects are only off-putting. I think people can get
> over that pretty easily, and that worries about it would be better
> directed at making ATS even more capable. I like Zig's attitude here.
>
> On the second point, I don't like my own 'language for other people'
> logic. As a social animal I'd rather just use a language 'for other
> people'. So, why wouldn't I feel comfortable submitting an ATS
> implementation for an employer, where other people will potentially
> have to maintain it? It's *definitely not* because of stuff like
> t@ype. That doesn't even come into the top ten of reasons--it doesn't,
> even when I don't have ten reasons in total. My reasons are:
>
> 1. the error messages are extremely hard to read, as they're expressed
> in internal compiler constructions. I just know that a maintainer will
> try to do something that looks obvious, get a bunch of
> impossible-for-a-casual-maintainer-to-understand error messages, and
> then immediately commit to rewriting my entire project. Even though
> I've gotten to where I can often read and benefit from ATS's error
> messages, I just can't expect anyone else to do this.
>
> And it doesn't matter how good my code is if, the first time someone
> wants to make a trivial modification to it, they throw it away and
> rewrite it in Go.
>
> 2. there is no reference manual for ATS. There's an introductory work
> that covers *most* of the language, but that not in a manner that you
> could ask, "what is this thing I'm looking at in this specific code?"
> and then look up the answer. A maintainer wants, ideally, no tutorial
> at all because the code is clear enough on inspection after you've
> grepped around to find the code you're concerned about, and two, a
> reference manual so those specific constructs in use in some code can
> be quickly understood.
>
> That's about it for reasons. although I could mention error messages
> eight more times and still not give them their due emphasis.
>
> 11. There's no interactive mode, no REPL. This is again a great help
> to people who don't know a language well--like someone tasked to make
> a small change to a program someone else has written in that language.
> A REPL would naturally allow someone to test small bits of code in an
> easy manner, as well as load an interrogate bodies of code. What type
> does that have? How many overloads of * are there? etc.
>
> Zig isn't perfect here--it doesn't have a lot of docs either. It seems
> like 2-hour screencasts are how you're supposed to learn the language.
> But it has good, clear error messages, and it prints out your code and
> graphically points to the problem, and you can build in a safe runtime
> where many errors in code are caught and result in a stack
> trace. True, ATS has the ideal where you catch many errors at
> compile-time, but it's very easy to get a segfault from ATS too, as
> simply as saying that some C function returns a string when it could
> return NULL
>
> Error categories:
>
> 1. syntax errors. I once had a function "= void", instead of ": void", and
> it took me over five minutes to find that problem. This isn't such a big
> deal but improvements

Re: ATS3: ATS/Xanadu

[Julian Fondren]

Prompted by Zig's 0.3.0 release, I thought about ATS3 a little
more. Zig prompted that in two different ways: first, the release
notes had this charming assertion: "Zig intends to be so practical
that people find themselves using it even if they dislike it."
Second, while considering Zig, although it's a much less capable
language than ATS, I thoght it might be good to know as a language
'for other people'. In the past I've done some work in C for groups,
because C -- if there were a justification for not just using a
scripting language -- would be accepted, while ATS certainly wouldn't.
Zig manages to look like a much better language than C, while still
being a language that could be accepted.

On the first point, ATS is already so capable that it's worth using
even if the syntax is off-putting in places. Although I think that it
would be pretty easy to shave off the off-putting aspects (make
't@ype' the default, so spelled 'type', and the old 'type' something
like 'boxed'; keep 'fun' and 'implement' as the defaults, but remove
the easy alternatives that you rarely need, and make .<>. the only way
to denote a non-recursive function -- this sort of stuff, just
emphasizing clean defaults rather than massively rewriting the
syntax), those aspects are only off-putting. I think people can get
over that pretty easily, and that worries about it would be better
directed at making ATS even more capable. I like Zig's attitude here.

On the second point, I don't like my own 'language for other people'
logic. As a social animal I'd rather just use a language 'for other
people'. So, why wouldn't I feel comfortable submitting an ATS
implementation for an employer, where other people will potentially
have to maintain it? It's *definitely not* because of stuff like
t@ype. That doesn't even come into the top ten of reasons--it doesn't,
even when I don't have ten reasons in total. My reasons are:

1. the error messages are extremely hard to read, as they're expressed
in internal compiler constructions. I just know that a maintainer will
try to do something that looks obvious, get a bunch of
impossible-for-a-casual-maintainer-to-understand error messages, and
then immediately commit to rewriting my entire project. Even though
I've gotten to where I can often read and benefit from ATS's error
messages, I just can't expect anyone else to do this.

And it doesn't matter how good my code is if, the first time someone
wants to make a trivial modification to it, they throw it away and
rewrite it in Go.

2. there is no reference manual for ATS. There's an introductory work
that covers *most* of the language, but that not in a manner that you
could ask, "what is this thing I'm looking at in this specific code?"
and then look up the answer. A maintainer wants, ideally, no tutorial
at all because the code is clear enough on inspection after you've
grepped around to find the code you're concerned about, and two, a
reference manual so those specific constructs in use in some code can
be quickly understood.

That's about it for reasons. although I could mention error messages
eight more times and still not give them their due emphasis.

11. There's no interactive mode, no REPL. This is again a great help
to people who don't know a language well--like someone tasked to make
a small change to a program someone else has written in that language.
A REPL would naturally allow someone to test small bits of code in an
easy manner, as well as load an interrogate bodies of code. What type
does that have? How many overloads of * are there? etc.

Zig isn't perfect here--it doesn't have a lot of docs either. It seems
like 2-hour screencasts are how you're supposed to learn the language.
But it has good, clear error messages, and it prints out your code and
graphically points to the problem, and you can build in a safe runtime
where many errors in code are caught and result in a stack
trace. True, ATS has the ideal where you catch many errors at
compile-time, but it's very easy to get a segfault from ATS too, as
simply as saying that some C function returns a string when it could
return NULL

Error categories:

1. syntax errors. I once had a function "= void", instead of ": void", and
it took me over five minutes to find that problem. This isn't such a big
deal but improvements are improvements.

2. template errors. ATS has no problem and then gcc gives you pages
and pages of not very directly useful errors. I learn to recognize them
as 'template errors' but don't bother trying to extract information like
"what exact template is missing?" from them.

3. type errors. in your code you have uints, in your errors you have
g0uint_t0ype and such. I'd rather see typedefs by default and have an
option to expand those.

4. constraint errors. on line 11, column 30, you fail to show that n >= 0
... oh, there's no 'n' at all in your code?
that's because it's somewhere in a prelude .sats

That's all.

For my part I've got a new video series where I'm going throu

Re: ATS3: ATS/Xanadu

[Brian Rogoff]

As I'm sure you're aware OCaml's syntax is not widely liked, leading to a 
lot of attempts at resyntaxing (Revised, Pidgin, ReasonML amongst others) 
so attempting to copy it doesn't strike me as a good idea.
SML is not widely used enough for me to have a sense of how much the syntax 
was liked.

I love Lisps, and, like Barry Schwartz, prefer it to others. However, I 
realize that this is a minority opinion and many programmers *hate* it. 
Probably also not a great idea if you're trying to make ATS popular, 
especially amongst low level programmers.

Python syntax is well liked (and well hated :-) by a large number of 
programmers. The Nim language has a kind of Pythonesque syntax with static 
typing, and it also has powerful metaprogramming features.
It's also used in low-level programming. It would be valuable to take a 
look at Nim and see what lessons can be learned there.

C language syntax is the most widely used, with C++ and Rust being the 
competitors for ATS3. I happen to think D language got the template syntax 
(and templates) right-er and provide a better model for template 
meta-programming. A C like syntax is the safest bet IMO.

Good luck, and please get ATS3 out there soon.

On Sunday, September 16, 2018 at 8:58:55 AM UTC-7, gmhwxi wrote:
>
>
> It is not too late :)
>
> For meta-programming support, LISP-like syntax is definitely
> on my mind.
>
> At this point, I want to first finish designing and implementing
> some ML-like (ML-inspired) syntax for ATS. I am getting there :)
>
> Once this ML-like syntax is done, it can readily serve as the basis for
> a design of LISP-like syntax for ATS.
>
> Cheers!
>
> On Thursday, August 30, 2018 at 4:03:36 PM UTC-4, Barry Schwartz wrote:
>>
>> I know this comes too late and was doomed anyway, but my opinion is the 
>> best syntax is always Lisp. :)
>>
>> On Friday, February 9, 2018 at 12:15:22 PM UTC-6, 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/c10459fd-a8a1-4b68-94c2-06e3d4b61959%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[gmhwxi]

It is not too late :)

For meta-programming support, LISP-like syntax is definitely
on my mind.

At this point, I want to first finish designing and implementing
some ML-like (ML-inspired) syntax for ATS. I am getting there :)

Once this ML-like syntax is done, it can readily serve as the basis for
a design of LISP-like syntax for ATS.

Cheers!

On Thursday, August 30, 2018 at 4:03:36 PM UTC-4, Barry Schwartz wrote:
>
> I know this comes too late and was doomed anyway, but my opinion is the 
> best syntax is always Lisp. :)
>
> On Friday, February 9, 2018 at 12:15:22 PM UTC-6, 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/a2a19337-52ba-4687-a28d-52f973ca74cf%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Barry Schwartz]

I know this comes too late and was doomed anyway, but my opinion is the 
best syntax is always Lisp. :)

On Friday, February 9, 2018 at 12:15:22 PM UTC-6, 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/453f915f-d306-4c3f-9897-9f7d19740a7d%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Hongwei Xi]

Hi Andrew,

Many thanks for all these questions and links. Very thoughtful!

Besides being a programming language for people to write code in,
I certainly hope that ATS3 can also be a platform for you (and others)
to try out ideas (e.g., those you mentioned).

It may sound a bit strange but I do see ATS as some sort of high-level
assembly language as well.

>>give existing code new meaning...

Or I would call it a form of late-binding. As Alan Kay put it: extreme
late-binding
of all kinds.

>>A goal would be reinterpreting subprograms to work on vectors ("SPMD on
SIMD")

I think ATS3 should provide a suitable platform for trying it out.

To a large extent, the template system of ATS tries to facilitate
reinterpretation of
programs. I give an argument in support of this practice in the following
short article:

http://ats-lang.sourceforge.net/EXAMPLE/EFFECTIVATS/
DivideConquerPar/main.html

Again, many thanks. This message will definitely be revisited later when
ATS3 reaches
a stage for experimentation.

Cheers!



On Sun, Aug 5, 2018 at 1:13 AM, Andrew Knapp  wrote:

> Just some miscellaneous thoughts and questions.
>
> - Here's a paper ("Beyond Type Classes") that I found interesting. It's a
> generalization of Haskell's type class system that does type-directed
> overloading via user-defined Constraint Handling Rules (CHRs). It fits
> nicely with the logic metaprogramming idea, and it seems like something
> that would complement embeddable templates really nicely. Not sure about
> the type inference story.
>
> https://pdfs.semanticscholar.org/ba5c/7c7c719f5e6980b18147d19b5c3111
> 3fbb80.pdf
>
> - Getting the compiler to understand the idea of flat storage underneath a
> data(view)type would be really, really helpful. For example, I would like
> versions of constructors to be generated that take a pointer to
> datatype-specific flat storage, so you don't have to use malloc to
> construct something. Here's a quick and dirty example of what I'd like to
> see the compiler do.
>
> datavtype foo =
> | Bar of (int,int)
> | Baz of (string, double)
>
> // compiler would automatically generate an abstract type foo_  (foo flat)
> // which represents a union of Bar_pstruct(int,int) and
> Baz_pstruct(string,double).
> // the compiler would also generate
>
> symintr Bar Baz
>
> fn Bar_default(int, int):<> foo
> fn Baz_default(string, double):<> foo
>
> fn Bar_flat{l:addr}(!foo_?@l | ptr(l), int, int):<> foo
> fn Baz_flat{l:addr}(!foo_?@l | ptr(l), string, double):<> foo
>
> overload Baz Baz_default
> overload Baz Baz_flat
> overload Bar Bar_default
> overload Baz Bar_flat
>
> - Something like $d2ctype that gives the type of an arbitrary expression
> would be nice, as would a $tyrep that gave you a sort-level type
> description for use in templates.
>
> - Support for heterogeneous metaprogramming - sometimes it would be
> convenient to generate things in another language, or more generally, give
> existing code new meaning. This is probably the slickest thing I've used
> for doing that, but I don't think it would work as well in an impure
> language like ATS.
>
> http://conal.net/papers/compiling-to-categories/
> compiling-to-categories.pdf
>
> A goal would be reinterpreting subprograms to work on vectors ("SPMD on
> SIMD") - Edward Kmett talked about this a while ago, and he's about to
> start implementing it in a new functional language he'll be working on
> full-time. See also the Intel SPMD Program Compiler.
>
> https://www.youtube.com/watch?v=KzqNQMpRbac
>
> https://ispc.github.io/
>
> - Here's a few things I think are good test cases for evaluating
> metaprogramming capabilities. How do you see ATS3 solving the following
> problems, if at all?
>
> * automatically deriving (de)serialization for records and datatypes
>
> * generating parsers or API bindings from an XML description (sadly, XML
> is how many such things are provided)
>
> * given a skeleton of an algorithm for, say, matrix multiplication
> (parameterized by things like loop tiling depth, unrolling amount, etc.),
> generate a bunch of instantiations with different parameter choices, run
> and benchmark them, and use/save the best one
>
> --
> 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/c137a67c-3a81-4b3b-a34d-d579b32bd665%
> 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 rec

Re: ATS3: ATS/Xanadu

[Andrew Knapp]

Just some miscellaneous thoughts and questions.

- Here's a paper ("Beyond Type Classes") that I found interesting. It's a 
generalization of Haskell's type class system that does type-directed 
overloading via user-defined Constraint Handling Rules (CHRs). It fits 
nicely with the logic metaprogramming idea, and it seems like something 
that would complement embeddable templates really nicely. Not sure about 
the type inference story.

https://pdfs.semanticscholar.org/ba5c/7c7c719f5e6980b18147d19b5c31113fbb80.pdf

- Getting the compiler to understand the idea of flat storage underneath a 
data(view)type would be really, really helpful. For example, I would like 
versions of constructors to be generated that take a pointer to 
datatype-specific flat storage, so you don't have to use malloc to 
construct something. Here's a quick and dirty example of what I'd like to 
see the compiler do.

datavtype foo =
| Bar of (int,int)
| Baz of (string, double)

// compiler would automatically generate an abstract type foo_  (foo flat)
// which represents a union of Bar_pstruct(int,int) and 
Baz_pstruct(string,double).
// the compiler would also generate

symintr Bar Baz

fn Bar_default(int, int):<> foo
fn Baz_default(string, double):<> foo

fn Bar_flat{l:addr}(!foo_?@l | ptr(l), int, int):<> foo
fn Baz_flat{l:addr}(!foo_?@l | ptr(l), string, double):<> foo

overload Baz Baz_default
overload Baz Baz_flat
overload Bar Bar_default
overload Baz Bar_flat

- Something like $d2ctype that gives the type of an arbitrary expression 
would be nice, as would a $tyrep that gave you a sort-level type 
description for use in templates.

- Support for heterogeneous metaprogramming - sometimes it would be 
convenient to generate things in another language, or more generally, give 
existing code new meaning. This is probably the slickest thing I've used 
for doing that, but I don't think it would work as well in an impure 
language like ATS.

http://conal.net/papers/compiling-to-categories/compiling-to-categories.pdf

A goal would be reinterpreting subprograms to work on vectors ("SPMD on 
SIMD") - Edward Kmett talked about this a while ago, and he's about to 
start implementing it in a new functional language he'll be working on 
full-time. See also the Intel SPMD Program Compiler.

https://www.youtube.com/watch?v=KzqNQMpRbac

https://ispc.github.io/

- Here's a few things I think are good test cases for evaluating 
metaprogramming capabilities. How do you see ATS3 solving the following 
problems, if at all?

* automatically deriving (de)serialization for records and datatypes

* generating parsers or API bindings from an XML description (sadly, XML is 
how many such things are provided)

* given a skeleton of an algorithm for, say, matrix multiplication 
(parameterized by things like loop tiling depth, unrolling amount, etc.), 
generate a bunch of instantiations with different parameter choices, run 
and benchmark them, and use/save the best one

-- 
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/c137a67c-3a81-4b3b-a34d-d579b32bd665%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[gmhwxi]

Yes, I have a similar thought :)

On Thursday, May 10, 2018 at 8:35:57 PM UTC-4, Andrew Knapp wrote:
>
> Another idea/request: replace the use of 
> ATS_MEMALLOC_USER/ATS_MEMALLOC_LIBC and friends with embeddable templates.
>
> In this example
>
> let
>   implement allocate() = pool_allocate(the_message_pool)
>   implement free(p) = pool_free(the_message_pool, p)
> in
>   latency_critical_loop<>()
> end
>
> templatizing the memory management functions would allow 
> latency_critical_loop to be written like ordinary ATS code, but it would 
> benefit from fast message allocation at runtime.
>

-- 
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/a505d183-45e2-4569-853c-1fdff120e84d%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Andrew Knapp]

Another idea/request: replace the use of 
ATS_MEMALLOC_USER/ATS_MEMALLOC_LIBC and friends with embeddable templates.

In this example

let
  implement allocate() = pool_allocate(the_message_pool)
  implement free(p) = pool_free(the_message_pool, p)
in
  latency_critical_loop<>()
end

templatizing the memory management functions would allow 
latency_critical_loop to be written like ordinary ATS code, but it would 
benefit from fast message allocation at runtime.

-- 
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/21848c3c-c5a0-42c1-87b5-86a927a7de3e%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Steinway Wu]

Speaking of formalization of templates, I came upon this essay 
http://okmij.org/ftp/Computation/typeclass.html. Personally this is such a 
good read, and I finally understand how type classes are done. I feel like 
our templates is almost "local type class" in Oleg's words, except that ATS 
uses late-binding.  

On Tuesday, February 13, 2018 at 2:52:29 PM UTC-5, Steinway Wu wrote:
>
> Hi Hongwei, just for the record, let me put down some offline discussions. 
>
> 1. Programmers can decide how a literal is parsed, or even write some 
> plugins to parse some custom literals. For instance, 1 can be interpreted 
> as int, nat, and int(1) etc. Programmers should be able to either turn a 
> knob, or annotate the literal, to switch among interpretations. 
> 2. Some meta-programming supports via templates. E.g. `derive` of Haskell. 
> 3. Formalization of templates.
> 4. Module systems. 
> 5. Session types :)
> 6. Modular design of the whole tool chain. E.g. parsing, type equality, 
> constraints solving, template dispatch, type erasure, etc. 
> 7. Maybe database-based compilations? We can store compiled blocks as a 
> (hash, binary IR) pairs in some file-based databases, for easy reuse. Not 
> sure how feasible it is. 
> 8. Interpreter, REPL, language servers, documentation tools, standard 
> libraries, type inference, etc. 
> 9. More importantly, a process for open source contribution. 
>
> Exciting!
>
> 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/895549c8-51c7-4d06-92a1-a99bc1861cef%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[aditya siram]

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: 
> https://github.com/typelead/eta-benchmarks
>
> On Thu, Apr 12, 2018 at 10:47 AM, Brandon Barker  > 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-lang.org/overviews/core/string-interpolation.html
>>
>>
>> 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 g

Re: ATS3: ATS/Xanadu

[Brandon Barker]

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 
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,  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 am

Re: ATS3: ATS/Xanadu

[Brandon Barker]

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-lang.org/overviews/core/
string-interpolation.html


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 yo

Re: ATS3: ATS/Xanadu

[Hongwei Xi]

I think that ATS can already support this:

#include
"share/atspre_staload.hats"

fun ???(x: int, y: int): int = x + y

val x = op???(1, 2)

val y = 1 \op??? 2

val () = println! ("x = ", x)
val () = println! ("y = ", y)

implement main0() = ()


On Wed, Apr 11, 2018 at 3:55 PM, Steinway Wu  wrote:

> Did anyone mention operators definition/overloading? I think currently in
> ATS2, one can only overload a symbol with a function. But I actually prefer
> how OCaml and Haskell handles operators: they are just functions whose
> names happen to be symbols instead of alphabets. One use parenthesis around
> the symbols to define it, and use the symbol without parenthesis to invoke
> it. I hope ATS3 can have better support for first-class user-defined
> operators without relying on overloading.
>
> // something like this for any infix operators would be nice
> fun (?op) (arg1:type1, arg2:type2): type3 = ...
>
> val x = y ?op z // use it as infix op by default
> val x = (?op)(y, z) // temporarily use it as prefix op
>
>
>
> 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/07fc31bd-21c0-4d84-bed0-283bd9b40fb8%
> 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/CAPPSPLo9jA84aj_ECETJf821Xf-EC0w1Y%3DBP2zXfiWer8V27%3Dw%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[Steinway Wu]

Did anyone mention operators definition/overloading? I think currently in 
ATS2, one can only overload a symbol with a function. But I actually prefer 
how OCaml and Haskell handles operators: they are just functions whose 
names happen to be symbols instead of alphabets. One use parenthesis around 
the symbols to define it, and use the symbol without parenthesis to invoke 
it. I hope ATS3 can have better support for first-class user-defined 
operators without relying on overloading.

// something like this for any infix operators would be nice
fun (?op) (arg1:type1, arg2:type2): type3 = ...

val x = y ?op z // use it as infix op by default
val x = (?op)(y, z) // temporarily use it as prefix op



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/07fc31bd-21c0-4d84-bed0-283bd9b40fb8%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[M88]

I suppose there has been a fair bit of talk about syntax already.   I had 
been thinking a whitespace-significant  label-block structure (a-la Nim) 
might suit the language well, and some recent code sample inspired me to 
demonstrate. 

Original:
datasort tlist = tnil
| tcons of (t0ype, tlist)

extern fun {t:tlist} foo(): void
extern fun {a:t0ype} foo$fopr(): void

implement foo() = ()
implement(a,ts) foo() = {
  val () = foo$fopr()
  val () = foo()
  val () = ignoret (1)
}

implement main0 () = let
  implement foo$fopr() = println!("int")
  implement foo$fopr() = println!("string")
  implement foo$fopr() = println!("bool")
  val () = println!("test 1: should print int, string")
  val () = foo()
  val () = println!("test 2: should print bool, int")
  val () = foo()
in


Example:


datasort tlist = tnil
| tcons of (type, tlist)

extern 
   fun {t:tlist} foo(): void
   fun {a:type} foo$fopr(): void

impl 
foo() = ()

(a,ts) foo() = {
   val 
  () = foo$fopr()
  () = foo()
  
 }

main0 () = 
  let
 impl 
foo$fopr() = println!("int")
foo$fopr() = println!("string")
foo$fopr() = println!("bool")
 val 
() = println!("test 1: should print int, string")
() = foo()
() = println!("test 2: should print bool, int")
() = foo()
 in ()

I guess the good thing here is that it's 99% ATS2.  Of course, there are 
likely plenty of issues, including whitespace-significance (I was hesitant 
to post something this concrete). 

-- 
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/7a7e5e9d-5267-4499-9ebf-9ea51aeb2212%40googlegroups.com.

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: ATS3: ATS/Xanadu

[Hongwei Xi]

These are all great points. Thanks!

My hope is that the community can and is willing to take a big part in
designing and implementing upper level programming features once the
core of ATS3 is ready.

Cheers!

--Hongwei

On Tue, Mar 20, 2018 at 5:34 PM, Andrew Knapp 
wrote:

> After writing several thousand lines of ATS, I'd say there isn't terribly
> much I'd change, honestly. A lot less than when I got started, for sure.
>
> What I would like to see changed:
>
> 1. Real module system. MixML might not be a bad source of inspiration, as
> it would essentially be a better version of the ML "modules" you can fake
> with includes, e.g. funmap.hats, and there's an implementation available.
> Doing away with the sigil before module names would be nice.
>
> 2. Naming conventions in standard library changed. Less g0ofg1, i2r and so
> on would be nice. I also find the abbreviations you choose to be very
> difficult to read. With a real module system, it would be nice to have
> shorter function names: you could get away with Array.map or A.map instead
> of array_map. This way the user can choose how verbose to be about module
> names.
>
> 3. Integrating templates with the module system. BTW embeddable templates
> are my absolute favorite feature of ATS.
>
> 4. Accessing flat memory of sum types and some kind of analog of C++
> placement new. This would make certain things a lot safer and easier.
>
> 5. Real macros or very powerful metaprogramming support. I know
> metaprogramming can be abused, but there are many things where I wish I had
> even a customizable version of #codegen2 that I could use. D is probably a
> good source of inspiration for this subject.
>
> 6. General cleanup of cruft and making sure features work together.
>
> 7. Pretty-printed error messages.
>
> 8. REPL, perhaps via atscc2scm and an embedded R7RS-small interpreter?
>
> Anyways, I've found ATS to be a real pleasure to use overall, and I trust
> my code is correct a lot more than in C++.
>
> --
> 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/1b0f9f4f-51c3-46db-94a1-b0c91d1e4f9c%
> 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/CAPPSPLrzQK0vPkVw00TuKb%3DZHGYsoDRwkjQ0u97Acgnpf%3DVb-A%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[Andrew Knapp]

After writing several thousand lines of ATS, I'd say there isn't terribly 
much I'd change, honestly. A lot less than when I got started, for sure.

What I would like to see changed:

1. Real module system. MixML might not be a bad source of inspiration, as 
it would essentially be a better version of the ML "modules" you can fake 
with includes, e.g. funmap.hats, and there's an implementation available. 
Doing away with the sigil before module names would be nice.

2. Naming conventions in standard library changed. Less g0ofg1, i2r and so 
on would be nice. I also find the abbreviations you choose to be very 
difficult to read. With a real module system, it would be nice to have 
shorter function names: you could get away with Array.map or A.map instead 
of array_map. This way the user can choose how verbose to be about module 
names.

3. Integrating templates with the module system. BTW embeddable templates 
are my absolute favorite feature of ATS.

4. Accessing flat memory of sum types and some kind of analog of C++ 
placement new. This would make certain things a lot safer and easier.

5. Real macros or very powerful metaprogramming support. I know 
metaprogramming can be abused, but there are many things where I wish I had 
even a customizable version of #codegen2 that I could use. D is probably a 
good source of inspiration for this subject.

6. General cleanup of cruft and making sure features work together.

7. Pretty-printed error messages.

8. REPL, perhaps via atscc2scm and an embedded R7RS-small interpreter?

Anyways, I've found ATS to be a real pleasure to use overall, and I trust 
my code is correct a lot more than in C++.

-- 
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/1b0f9f4f-51c3-46db-94a1-b0c91d1e4f9c%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Hongwei Xi]

Many thanks for your input!

>>perhaps H/M inference alone could go a long way.

That is really my bet :)

>>I suppose I'm about as efficient at ATS2 as I am with C

Yes, one can do C-style coding in ATS. With ATS, my hope is that one
is able to use more functional programming to solve problems that are
normally
solved using C.

On Sun, Mar 18, 2018 at 12:16 PM, M88  wrote:

>
> I thought about this issue as well. One idea I had is to
>> use overloading aggressively.
>>
>
> A thought I had recently -- I'm almost wondering if certain proofs (eg,
> linear proofs) could behave more like value constraints.  That is, they
> could be invoked optionally, and would only be checked when specified.  For
> example, if a variable invoked with type "b" is linear, it could be passed
> to either function  "fun foo ( linear(l) | b l )" or "fn foo ( b )"
> without error.  I suppose it would also be interesting if general proofs
> could be specified in type declarations -- again, analogously to value
> constraints.   I suppose this suggestion would almost imply a "dataprop
> table" associated with every val / var invoked, which may or may not be
> feasible
>
> Speaking of constraints, one thing ATS2 doesn't have are "implementation
> constraints" -- that is, something like typeclasses or traits.  I see how
> specific templates capture 85-90% of the functionality, and honestly I
> don't often miss the former.  Still, such constructs are useful for
> documenting certain dependencies within code (they tell a developer "Hey,
> for this to work for your type, go implement that template" ).  This type
> of thing introduces a structured overloading that might reduce the number
> of tokens in the code a fair bit, too.
>
> Right now the biggest issue with ATS2, as I see is, is that a non-expert
>> user gets tripped everywhere. For such a user, programming in ATS can
>> hardly
>> be an enjoyable experience. ATS3 tries to put joy back into learning
>> functional
>> programming via ATS.
>>
>
> I found the conceptual core of ATS2 pretty easy to grasp, given the
> examples and the *Introduction to ATS. *The difficult part was finding
> the meaning of certain tokens in source code, or even discovering that a
> certain feature exists in the first place.  Also, I suppose I'm about as
> efficient at ATS2 as I am with C -- it can be difficult to justify using
> ATS instead of C (especially when I have to write FFI to C anyway, though
> c2ats has proven quite useful).   I think ATS2 with relatively minor
> usability enhancements would tip my preference more strongly in its favor
> -- better error messages, some information hiding (I guess, syntactic
> sugar) and perhaps H/M inference alone could go a long way.
>
>
> --
> 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/282bc6ea-ebe5-4e86-9b64-1f7db11c7b45%
> 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/CAPPSPLoK7bTs%3Dzi8-nTc9wjGnO48sdCG1gjLjyg6oLHzx8nWNA%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[M88]

> I thought about this issue as well. One idea I had is to
> use overloading aggressively.
>

A thought I had recently -- I'm almost wondering if certain proofs (eg, 
linear proofs) could behave more like value constraints.  That is, they 
could be invoked optionally, and would only be checked when specified.  For 
example, if a variable invoked with type "b" is linear, it could be passed 
to either function  "fun foo ( linear(l) | b l )" or "fn foo ( b )"  
without error.  I suppose it would also be interesting if general proofs 
could be specified in type declarations -- again, analogously to value 
constraints.   I suppose this suggestion would almost imply a "dataprop 
table" associated with every val / var invoked, which may or may not be 
feasible 

Speaking of constraints, one thing ATS2 doesn't have are "implementation 
constraints" -- that is, something like typeclasses or traits.  I see how 
specific templates capture 85-90% of the functionality, and honestly I 
don't often miss the former.  Still, such constructs are useful for 
documenting certain dependencies within code (they tell a developer "Hey, 
for this to work for your type, go implement that template" ).  This type 
of thing introduces a structured overloading that might reduce the number 
of tokens in the code a fair bit, too.  

Right now the biggest issue with ATS2, as I see is, is that a non-expert
> user gets tripped everywhere. For such a user, programming in ATS can 
> hardly
> be an enjoyable experience. ATS3 tries to put joy back into learning 
> functional
> programming via ATS. 
>

I found the conceptual core of ATS2 pretty easy to grasp, given the 
examples and the *Introduction to ATS. *The difficult part was finding the 
meaning of certain tokens in source code, or even discovering that a 
certain feature exists in the first place.  Also, I suppose I'm about as 
efficient at ATS2 as I am with C -- it can be difficult to justify using 
ATS instead of C (especially when I have to write FFI to C anyway, though 
c2ats has proven quite useful).   I think ATS2 with relatively minor 
usability enhancements would tip my preference more strongly in its favor 
-- better error messages, some information hiding (I guess, syntactic 
sugar) and perhaps H/M inference alone could go a long way.
 

-- 
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/282bc6ea-ebe5-4e86-9b64-1f7db11c7b45%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[gmhwxi]

I thought about this issue as well. One idea I had is to
use overloading aggressively.

Right now the biggest issue with ATS2, as I see is, is that a non-expert
user gets tripped everywhere. For such a user, programming in ATS can hardly
be an enjoyable experience. ATS3 tries to put joy back into learning 
functional
programming via ATS.

On Wednesday, March 14, 2018 at 7:36:57 AM UTC-4, M88 wrote:
>
> Not sure if it's feasible or theoretically sound, but it would be nice to 
> see a less stark divide between datatypes and dataviewtypes in ATS3. It 
> would be great to be able to declare a data structure once and use either 
> linear or gc'd versions. 
>
> Maybe this could extend to other types that have a dual linear version (eg 
> strptr / string). It seems there are commonly functions that could operate 
> on either, and at the moment this is achieved by casting. Perhaps there 
> could be a type level attribute for all pointer-based types, like "lin 
> string" / "gc string" , which are both also just "string". 
>
> This may also allow for specifying "linearity" in variable declarations, 
> eg 'let lin val x=Foo(7), y="A linear string" in... '. 
>
> I suppose a similar syntax could make dealing with proof values more 
> concise, too (eg, 'let prf val pa=my_proof_fn(), pb=another_proof_fn(pa) 
> in... '). 
>
>

-- 
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/a77b8e9f-744d-452e-9194-cb8b9cd3df67%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Brandon Barker]

True, an IDE could zoom in on the definition, if it were supported by the
IDE/plugin.

On Tue, Mar 13, 2018 at 4:36 PM, Hongwei Xi  wrote:

> This sounds more like an IDE issue to me.
>
> On Tue, Mar 13, 2018 at 3:20 PM, Brandon Barker 
> wrote:
>
>> Replying to the concise syntax issue in particular: I like concise syntax
>> up to a point, but when it comes to types, explicit syntax is sometimes
>> nice (though it would be great to allow the user to choose). Both to make
>> compilation proceed quicker (possibly), and to make it more obvious what
>> code is doing when you read it.
>>
>> One area where working in ATS  actually seems to prevent this is when
>> implementing a function specified elsewhere. Maybe this is just a user
>> error from me, but I tried last night to *implement main0(argc, argv):
>> void *after looking up the types in the ATS2 sources after grepping for
>> a bit, and was able to do it up to a point: I could do something like
>> implement *main0(argc: int, argv): void*. But then, I wasn't able to
>> figure out how to get it further refined and add *argc: int n *in the
>> implementation view. I guess this is code duplication to a certain extent,
>> so I don't necessarily think it is a great style. On the other hand, it
>> seems a bit inconvenient to have to go look in a sats file to see the
>> specification for a function.
>>
>> On Monday, February 12, 2018 at 1:59:54 PM UTC-5, gmhwxi wrote:
>>>
>>> Thanks.
>>>
>>> Haskell and Idris are definitely on my radar.
>>>
>>> Type inference in ATS is very week (largely due to the support
>>> for dependent types and linear types). To support concise syntax,
>>> type inference in ATS needs to greatly strengthened.
>>>
>>> On Sunday, February 11, 2018 at 8:34:48 PM UTC-5, vamchale wrote:

 I don't have any concrete suggestions, but I would suggest Idris as an
 example to follow. Haskell syntax is relatively popular and concise, and
 Idris' is even more refined.

 I will say I'd prefer syntax that eases functional programming, but
 that might just be me. And I think that replacing - with
 something more concise like -o would be a good decision either way.

 On Friday, February 9, 2018 at 12:15:22 PM UTC-6, 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/ms
>> gid/ats-lang-users/10a34ca2-59dd-423a-887a-da6e25c05fcf%40go
>> oglegroups.com
>> 
>> .
>>
>
> --
> 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/
> topic/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/
> msgid/ats-lang-users/CAPPSPLr1p2cbHyZ12-GYrohMjXJaQ8v7H2rrfPjd8SbsmoXg
> 4w%40mail.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

Re: ATS3: ATS/Xanadu

[Hongwei Xi]

This sounds more like an IDE issue to me.

On Tue, Mar 13, 2018 at 3:20 PM, Brandon Barker 
wrote:

> Replying to the concise syntax issue in particular: I like concise syntax
> up to a point, but when it comes to types, explicit syntax is sometimes
> nice (though it would be great to allow the user to choose). Both to make
> compilation proceed quicker (possibly), and to make it more obvious what
> code is doing when you read it.
>
> One area where working in ATS  actually seems to prevent this is when
> implementing a function specified elsewhere. Maybe this is just a user
> error from me, but I tried last night to *implement main0(argc, argv):
> void *after looking up the types in the ATS2 sources after grepping for a
> bit, and was able to do it up to a point: I could do something like
> implement *main0(argc: int, argv): void*. But then, I wasn't able to
> figure out how to get it further refined and add *argc: int n *in the
> implementation view. I guess this is code duplication to a certain extent,
> so I don't necessarily think it is a great style. On the other hand, it
> seems a bit inconvenient to have to go look in a sats file to see the
> specification for a function.
>
> On Monday, February 12, 2018 at 1:59:54 PM UTC-5, gmhwxi wrote:
>>
>> Thanks.
>>
>> Haskell and Idris are definitely on my radar.
>>
>> Type inference in ATS is very week (largely due to the support
>> for dependent types and linear types). To support concise syntax,
>> type inference in ATS needs to greatly strengthened.
>>
>> On Sunday, February 11, 2018 at 8:34:48 PM UTC-5, vamchale wrote:
>>>
>>> I don't have any concrete suggestions, but I would suggest Idris as an
>>> example to follow. Haskell syntax is relatively popular and concise, and
>>> Idris' is even more refined.
>>>
>>> I will say I'd prefer syntax that eases functional programming, but that
>>> might just be me. And I think that replacing - with something
>>> more concise like -o would be a good decision either way.
>>>
>>> On Friday, February 9, 2018 at 12:15:22 PM UTC-6, 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/10a34ca2-59dd-423a-887a-da6e25c05fcf%
> 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/CAPPSPLr1p2cbHyZ12-GYrohMjXJaQ8v7H2rrfPjd8SbsmoXg4w%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[Brandon Barker]

Replying to the concise syntax issue in particular: I like concise syntax 
up to a point, but when it comes to types, explicit syntax is sometimes 
nice (though it would be great to allow the user to choose). Both to make 
compilation proceed quicker (possibly), and to make it more obvious what 
code is doing when you read it.

One area where working in ATS  actually seems to prevent this is when 
implementing a function specified elsewhere. Maybe this is just a user 
error from me, but I tried last night to *implement main0(argc, argv): void 
*after looking up the types in the ATS2 sources after grepping for a bit, 
and was able to do it up to a point: I could do something like implement 
*main0(argc: 
int, argv): void*. But then, I wasn't able to figure out how to get it 
further refined and add *argc: int n *in the implementation view. I guess 
this is code duplication to a certain extent, so I don't necessarily think 
it is a great style. On the other hand, it seems a bit inconvenient to have 
to go look in a sats file to see the specification for a function.

On Monday, February 12, 2018 at 1:59:54 PM UTC-5, gmhwxi wrote:
>
> Thanks.
>
> Haskell and Idris are definitely on my radar.
>
> Type inference in ATS is very week (largely due to the support
> for dependent types and linear types). To support concise syntax,
> type inference in ATS needs to greatly strengthened.
>
> On Sunday, February 11, 2018 at 8:34:48 PM UTC-5, vamchale wrote:
>>
>> I don't have any concrete suggestions, but I would suggest Idris as an 
>> example to follow. Haskell syntax is relatively popular and concise, and 
>> Idris' is even more refined.
>>
>> I will say I'd prefer syntax that eases functional programming, but that 
>> might just be me. And I think that replacing - with something 
>> more concise like -o would be a good decision either way.
>>
>> On Friday, February 9, 2018 at 12:15:22 PM UTC-6, 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/10a34ca2-59dd-423a-887a-da6e25c05fcf%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Hongwei Xi]

Yes, kind of.

But the supposed selling point of compiling into ATS is that one is able
to take advantage of the advanced typechecking supported by ATS. Say,
you implement a DSL for programming cyptocurrencies; you may want to
compile the DSL into ATS so that you can statically verify certain
invariants
in, say, smart contracts.

On Sat, Mar 10, 2018 at 10:53 AM, Brandon Barker 
wrote:

> I don't know if TASTY  might be of
> help, either in ideas or actual implementation. Some more indepth
> discussion of TAST: https://github.com/twitter/reasonable-scala/issues/21
>
>
>
> On Saturday, March 10, 2018 at 10:00:31 AM UTC-5, gmhwxi wrote:
>>
>> Thanks.
>>
>> These are all very good points.
>>
>> I said many times here that I see ATS as both a source language and
>> a target language. ATS3 will make it a lot easier for people to use it as
>> a
>> target language. I will first use a master design for the syntax of ATS3
>> largely based
>> on that of ATS2. And an interesting party can design his or her syntax
>> that translates
>> into this master design. Stay tuned :)
>>
>>
>> On Sat, Mar 10, 2018 at 9:11 AM, Brandon Barker 
>> wrote:
>>
>>> While jumping back into ATS, a few other minor things (lots of minor
>>> things add up) that might be nicer is string interpolation in the form of
>>> python 3.6 or Scala (both are very similar). Here's a copy paste example
>>> from python 3.6:
>>>
>>> 1.
>>>
>>> name = "Spongebob Squarepants"print(f"Who lives in a Pineapple under the 
>>> sea? {name}.")
>>>
>>>
>>> Scala would look like:
>>>
>>> print(s"Who lives in a Pineapple under the sea? $name.")
>>>
>>>
>>> or if 'name' was a general scala expression instead of just an
>>> identifier:
>>>
>>> print(s"Who lives in a Pineapple under the sea? ${name}.")
>>>
>>>
>>> This could also be useful for supporting things like XML interpolation,
>>> etc, later on (not that it is a very high priority for most, I imagine ;-)).
>>>
>>> I don't know how this might work in ATS yet, since scala relies on
>>> objects' toString methods, and Python objects have something similar (in
>>> both languages, everything is effectively extends object, which I believe
>>> has the toString method - by default, this is just the object's address, so
>>> not too interesting, but Int of course has a sensible override, as do many
>>> objects).
>>>
>>>
>>> 2. OK, maybe this isn't so minor generally. I was using extern in front
>>> of a fun in a dats file (I thought this was actually required, but
>>> eventually realized that my sleep-deprived brain had read about extern last
>>> night and forgot this was only for interfaces, not definitions). This was
>>> the error message:
>>>  128(line=8, offs=38): error(parsing): [s0tring] is needed
>>> Lots of confusion here for a beginner. The user might have to figure out
>>> what s0tring is (I think it is either a non-dependent or non-linear string,
>>> can't recall and didn't check); also it implies something is needed when it
>>> is actually the absence of something that is needed in this particular case
>>> (the extern keyword).
>>>
>>> 3. Simplify ways of defining functions. There seem to be many: fn, fun,
>>> fnx. I'd prefer a longer but easier to remember 'tailrec' prefix keyword in
>>> some cases to make sure the function is tail recursive and tc-eliminated.
>>> Just throwing a quick idea out there, haven't thought about this much, and
>>> i'm sure that there are good reasons for why things are the way they are in
>>> ATS (I just don't recall all of them).
>>>
>>>
>>> I think if ATS3 is to be done, better error messages should be on about
>>> the same priority as improved syntax. On this point, I will say that Scala
>>> error messages seem way better generally than Python thanks to typing: you
>>> are generally looking at stacktraces in Python, which lack types as well
>>> ;-).
>>>
>>> On Saturday, March 10, 2018 at 7:33:04 AM UTC-5, Brandon Barker wrote:

 Implicit parameters get a bit of a bad reputation, but I don't recall
 ever being burned by them in any way even though I use them almost all of
 the time; if you have things like implicit strings or even implicit
 Map[String, something], that is obviously not good programming style, since
 it is relatively easy to add a new implicit in scope (but then you'd get a
 compile error anyway as you can't have more than one implicit of the same
 type in scope) - they usually need to be rather specific types related to
 configuration to make sense.  Granted, I have not used them much in the
 contradictory fashion that I linked above from Miles Sabin - that is a
 rather unusual Scala style, but he hides a lot of that in his Shapeless
 library so you can use the features without being directly exposed to (most
 of) the unpleasantries.

 I get the sense that dotty isn't adding too many "bells and whistles"
 features, and even removing the ones that relate to unsound

Re: ATS3: ATS/Xanadu

[Brandon Barker]

I don't know if TASTY  might be of 
help, either in ideas or actual implementation. Some more indepth 
discussion of TAST: https://github.com/twitter/reasonable-scala/issues/21



On Saturday, March 10, 2018 at 10:00:31 AM UTC-5, gmhwxi wrote:
>
> Thanks.
>
> These are all very good points.
>
> I said many times here that I see ATS as both a source language and
> a target language. ATS3 will make it a lot easier for people to use it as a
> target language. I will first use a master design for the syntax of ATS3 
> largely based
> on that of ATS2. And an interesting party can design his or her syntax 
> that translates
> into this master design. Stay tuned :)
>
>
> On Sat, Mar 10, 2018 at 9:11 AM, Brandon Barker  > wrote:
>
>> While jumping back into ATS, a few other minor things (lots of minor 
>> things add up) that might be nicer is string interpolation in the form of 
>> python 3.6 or Scala (both are very similar). Here's a copy paste example 
>> from python 3.6:
>>
>> 1. 
>>
>> name = "Spongebob Squarepants"print(f"Who lives in a Pineapple under the 
>> sea? {name}.")
>>
>>
>> Scala would look like:
>>
>> print(s"Who lives in a Pineapple under the sea? $name.")
>>
>>
>> or if 'name' was a general scala expression instead of just an identifier:
>>
>> print(s"Who lives in a Pineapple under the sea? ${name}.")
>>
>>
>> This could also be useful for supporting things like XML interpolation, 
>> etc, later on (not that it is a very high priority for most, I imagine ;-)).
>>
>> I don't know how this might work in ATS yet, since scala relies on 
>> objects' toString methods, and Python objects have something similar (in 
>> both languages, everything is effectively extends object, which I believe 
>> has the toString method - by default, this is just the object's address, so 
>> not too interesting, but Int of course has a sensible override, as do many 
>> objects).
>>
>>
>> 2. OK, maybe this isn't so minor generally. I was using extern in front 
>> of a fun in a dats file (I thought this was actually required, but 
>> eventually realized that my sleep-deprived brain had read about extern last 
>> night and forgot this was only for interfaces, not definitions). This was 
>> the error message:
>>  128(line=8, offs=38): error(parsing): [s0tring] is needed 
>> Lots of confusion here for a beginner. The user might have to figure out 
>> what s0tring is (I think it is either a non-dependent or non-linear string, 
>> can't recall and didn't check); also it implies something is needed when it 
>> is actually the absence of something that is needed in this particular case 
>> (the extern keyword).
>>
>> 3. Simplify ways of defining functions. There seem to be many: fn, fun, 
>> fnx. I'd prefer a longer but easier to remember 'tailrec' prefix keyword in 
>> some cases to make sure the function is tail recursive and tc-eliminated. 
>> Just throwing a quick idea out there, haven't thought about this much, and 
>> i'm sure that there are good reasons for why things are the way they are in 
>> ATS (I just don't recall all of them).
>>
>>
>> I think if ATS3 is to be done, better error messages should be on about 
>> the same priority as improved syntax. On this point, I will say that Scala 
>> error messages seem way better generally than Python thanks to typing: you 
>> are generally looking at stacktraces in Python, which lack types as well 
>> ;-).
>>
>> On Saturday, March 10, 2018 at 7:33:04 AM UTC-5, Brandon Barker wrote:
>>>
>>> Implicit parameters get a bit of a bad reputation, but I don't recall 
>>> ever being burned by them in any way even though I use them almost all of 
>>> the time; if you have things like implicit strings or even implicit 
>>> Map[String, something], that is obviously not good programming style, since 
>>> it is relatively easy to add a new implicit in scope (but then you'd get a 
>>> compile error anyway as you can't have more than one implicit of the same 
>>> type in scope) - they usually need to be rather specific types related to 
>>> configuration to make sense.  Granted, I have not used them much in the 
>>> contradictory fashion that I linked above from Miles Sabin - that is a 
>>> rather unusual Scala style, but he hides a lot of that in his Shapeless 
>>> library so you can use the features without being directly exposed to (most 
>>> of) the unpleasantries.
>>>
>>> I get the sense that dotty isn't adding too many "bells and whistles" 
>>> features, and even removing the ones that relate to unsoundness, and making 
>>> other features less suprising, like making the extension order no longer 
>>> matter: A extends B with C will be the same as A extends C with B now. And 
>>> they are adding sensible union types. I believe they are improving 
>>> dependent typing in dotty as well. They are removing XML literals, which 
>>> I'm actually somewhat sad about, but adding in XML string interpolation.  
>>> I've heard there is 0 chance of getting linear 

Re: ATS3: ATS/Xanadu

[Hongwei Xi]

Thanks.

These are all very good points.

I said many times here that I see ATS as both a source language and
a target language. ATS3 will make it a lot easier for people to use it as a
target language. I will first use a master design for the syntax of ATS3
largely based
on that of ATS2. And an interesting party can design his or her syntax that
translates
into this master design. Stay tuned :)


On Sat, Mar 10, 2018 at 9:11 AM, Brandon Barker 
wrote:

> While jumping back into ATS, a few other minor things (lots of minor
> things add up) that might be nicer is string interpolation in the form of
> python 3.6 or Scala (both are very similar). Here's a copy paste example
> from python 3.6:
>
> 1.
>
> name = "Spongebob Squarepants"print(f"Who lives in a Pineapple under the sea? 
> {name}.")
>
>
> Scala would look like:
>
> print(s"Who lives in a Pineapple under the sea? $name.")
>
>
> or if 'name' was a general scala expression instead of just an identifier:
>
> print(s"Who lives in a Pineapple under the sea? ${name}.")
>
>
> This could also be useful for supporting things like XML interpolation,
> etc, later on (not that it is a very high priority for most, I imagine ;-)).
>
> I don't know how this might work in ATS yet, since scala relies on
> objects' toString methods, and Python objects have something similar (in
> both languages, everything is effectively extends object, which I believe
> has the toString method - by default, this is just the object's address, so
> not too interesting, but Int of course has a sensible override, as do many
> objects).
>
>
> 2. OK, maybe this isn't so minor generally. I was using extern in front of
> a fun in a dats file (I thought this was actually required, but eventually
> realized that my sleep-deprived brain had read about extern last night and
> forgot this was only for interfaces, not definitions). This was the error
> message:
>  128(line=8, offs=38): error(parsing): [s0tring] is needed
> Lots of confusion here for a beginner. The user might have to figure out
> what s0tring is (I think it is either a non-dependent or non-linear string,
> can't recall and didn't check); also it implies something is needed when it
> is actually the absence of something that is needed in this particular case
> (the extern keyword).
>
> 3. Simplify ways of defining functions. There seem to be many: fn, fun,
> fnx. I'd prefer a longer but easier to remember 'tailrec' prefix keyword in
> some cases to make sure the function is tail recursive and tc-eliminated.
> Just throwing a quick idea out there, haven't thought about this much, and
> i'm sure that there are good reasons for why things are the way they are in
> ATS (I just don't recall all of them).
>
>
> I think if ATS3 is to be done, better error messages should be on about
> the same priority as improved syntax. On this point, I will say that Scala
> error messages seem way better generally than Python thanks to typing: you
> are generally looking at stacktraces in Python, which lack types as well
> ;-).
>
> On Saturday, March 10, 2018 at 7:33:04 AM UTC-5, Brandon Barker wrote:
>>
>> Implicit parameters get a bit of a bad reputation, but I don't recall
>> ever being burned by them in any way even though I use them almost all of
>> the time; if you have things like implicit strings or even implicit
>> Map[String, something], that is obviously not good programming style, since
>> it is relatively easy to add a new implicit in scope (but then you'd get a
>> compile error anyway as you can't have more than one implicit of the same
>> type in scope) - they usually need to be rather specific types related to
>> configuration to make sense.  Granted, I have not used them much in the
>> contradictory fashion that I linked above from Miles Sabin - that is a
>> rather unusual Scala style, but he hides a lot of that in his Shapeless
>> library so you can use the features without being directly exposed to (most
>> of) the unpleasantries.
>>
>> I get the sense that dotty isn't adding too many "bells and whistles"
>> features, and even removing the ones that relate to unsoundness, and making
>> other features less suprising, like making the extension order no longer
>> matter: A extends B with C will be the same as A extends C with B now. And
>> they are adding sensible union types. I believe they are improving
>> dependent typing in dotty as well. They are removing XML literals, which
>> I'm actually somewhat sad about, but adding in XML string interpolation.
>> I've heard there is 0 chance of getting linear types though. Which is why
>> ATS is really in a good place in terms of features. It has a lot of nice
>> functional things like Scala (even better: ATS has mutual TCO), has better
>> linear types than Rust, and has a proof system, neither of which Rust or
>> Scala has.
>>
>> I don't meant to overly sell Scala here; I just think it has some nice
>> things, and I've been using it a lot, so I wanted to list the things I
>> thought were nic

Re: ATS3: ATS/Xanadu

[Brandon Barker]

While jumping back into ATS, a few other minor things (lots of minor things 
add up) that might be nicer is string interpolation in the form of python 
3.6 or Scala (both are very similar). Here's a copy paste example from 
python 3.6:

1. 

name = "Spongebob Squarepants"print(f"Who lives in a Pineapple under the sea? 
{name}.")


Scala would look like:

print(s"Who lives in a Pineapple under the sea? $name.")


or if 'name' was a general scala expression instead of just an identifier:

print(s"Who lives in a Pineapple under the sea? ${name}.")


This could also be useful for supporting things like XML interpolation, 
etc, later on (not that it is a very high priority for most, I imagine ;-)).

I don't know how this might work in ATS yet, since scala relies on objects' 
toString methods, and Python objects have something similar (in both 
languages, everything is effectively extends object, which I believe has 
the toString method - by default, this is just the object's address, so not 
too interesting, but Int of course has a sensible override, as do many 
objects).


2. OK, maybe this isn't so minor generally. I was using extern in front of 
a fun in a dats file (I thought this was actually required, but eventually 
realized that my sleep-deprived brain had read about extern last night and 
forgot this was only for interfaces, not definitions). This was the error 
message:
 128(line=8, offs=38): error(parsing): [s0tring] is needed 
Lots of confusion here for a beginner. The user might have to figure out 
what s0tring is (I think it is either a non-dependent or non-linear string, 
can't recall and didn't check); also it implies something is needed when it 
is actually the absence of something that is needed in this particular case 
(the extern keyword).

3. Simplify ways of defining functions. There seem to be many: fn, fun, 
fnx. I'd prefer a longer but easier to remember 'tailrec' prefix keyword in 
some cases to make sure the function is tail recursive and tc-eliminated. 
Just throwing a quick idea out there, haven't thought about this much, and 
i'm sure that there are good reasons for why things are the way they are in 
ATS (I just don't recall all of them).


I think if ATS3 is to be done, better error messages should be on about the 
same priority as improved syntax. On this point, I will say that Scala 
error messages seem way better generally than Python thanks to typing: you 
are generally looking at stacktraces in Python, which lack types as well 
;-).

On Saturday, March 10, 2018 at 7:33:04 AM UTC-5, Brandon Barker wrote:
>
> Implicit parameters get a bit of a bad reputation, but I don't recall ever 
> being burned by them in any way even though I use them almost all of the 
> time; if you have things like implicit strings or even implicit Map[String, 
> something], that is obviously not good programming style, since it is 
> relatively easy to add a new implicit in scope (but then you'd get a 
> compile error anyway as you can't have more than one implicit of the same 
> type in scope) - they usually need to be rather specific types related to 
> configuration to make sense.  Granted, I have not used them much in the 
> contradictory fashion that I linked above from Miles Sabin - that is a 
> rather unusual Scala style, but he hides a lot of that in his Shapeless 
> library so you can use the features without being directly exposed to (most 
> of) the unpleasantries.
>
> I get the sense that dotty isn't adding too many "bells and whistles" 
> features, and even removing the ones that relate to unsoundness, and making 
> other features less suprising, like making the extension order no longer 
> matter: A extends B with C will be the same as A extends C with B now. And 
> they are adding sensible union types. I believe they are improving 
> dependent typing in dotty as well. They are removing XML literals, which 
> I'm actually somewhat sad about, but adding in XML string interpolation.  
> I've heard there is 0 chance of getting linear types though. Which is why 
> ATS is really in a good place in terms of features. It has a lot of nice 
> functional things like Scala (even better: ATS has mutual TCO), has better 
> linear types than Rust, and has a proof system, neither of which Rust or 
> Scala has. 
>
> I don't meant to overly sell Scala here; I just think it has some nice 
> things, and I've been using it a lot, so I wanted to list the things I 
> thought were nice. Why I use it: as I and some others like to say, it is a 
> language that gives you types like Java (but better) and concision like 
> python, while basically giving you the same massive and easy-to-use (once 
> you are used to it) JVM ecosystem that Java enjoys. So while it may not 
> have a lot of advanced features compared to some more modern languages, it 
> already seems to be quite an improvement over the most popular languages 
> for many applications. Also I had a lot of JVM-related projects lately ;-).
>
> On Sat, Mar 

Re: ATS3: ATS/Xanadu

[Brandon Barker]

Implicit parameters get a bit of a bad reputation, but I don't recall ever
being burned by them in any way even though I use them almost all of the
time; if you have things like implicit strings or even implicit Map[String,
something], that is obviously not good programming style, since it is
relatively easy to add a new implicit in scope (but then you'd get a
compile error anyway as you can't have more than one implicit of the same
type in scope) - they usually need to be rather specific types related to
configuration to make sense.  Granted, I have not used them much in the
contradictory fashion that I linked above from Miles Sabin - that is a
rather unusual Scala style, but he hides a lot of that in his Shapeless
library so you can use the features without being directly exposed to (most
of) the unpleasantries.

I get the sense that dotty isn't adding too many "bells and whistles"
features, and even removing the ones that relate to unsoundness, and making
other features less suprising, like making the extension order no longer
matter: A extends B with C will be the same as A extends C with B now. And
they are adding sensible union types. I believe they are improving
dependent typing in dotty as well. They are removing XML literals, which
I'm actually somewhat sad about, but adding in XML string interpolation.
I've heard there is 0 chance of getting linear types though. Which is why
ATS is really in a good place in terms of features. It has a lot of nice
functional things like Scala (even better: ATS has mutual TCO), has better
linear types than Rust, and has a proof system, neither of which Rust or
Scala has.

I don't meant to overly sell Scala here; I just think it has some nice
things, and I've been using it a lot, so I wanted to list the things I
thought were nice. Why I use it: as I and some others like to say, it is a
language that gives you types like Java (but better) and concision like
python, while basically giving you the same massive and easy-to-use (once
you are used to it) JVM ecosystem that Java enjoys. So while it may not
have a lot of advanced features compared to some more modern languages, it
already seems to be quite an improvement over the most popular languages
for many applications. Also I had a lot of JVM-related projects lately ;-).

On Sat, Mar 10, 2018 at 7:09 AM, gmhwxi  wrote:

>
> The way in which Scala evolves reminds me of C++: Powerful features
> increase productivity but also make it harder and harder to reason about
> code.
>
>
> On Friday, March 9, 2018 at 3:29:18 PM UTC-5, Brandon Barker wrote:
>>
>> Another Scala feature worth looking into: implicit parameters, values,
>> and function types. Dotty has added implicit function types, and I'm not
>> very familiar with all their benefits as yet: https://www.scala-lang.or
>> g/blog/2016/12/07/implicit-function-types.html
>> However, implicit parameters alone have been great for me, and could
>> probably go a long way towards reducing some verbosity in ATS. They can
>> also be used in clever ways to create contradictions at compile time, by
>> bringing into scope two implicit values of the same type. I'm not sure if
>> ATS would benefit from that feature, but Scala's type system doesn't allow
>> for things like type b = not a. You can achieve that with implicits:
>> https://gist.github.com/milessabin/c9f8befa932d98dcc7a4
>>
>> On Wednesday, March 7, 2018 at 12:01:03 PM UTC-5, Brandon Barker wrote:
>>>
>>> I forgot to mention, I like the idea of adding a level of indirection in
>>> the syntax for ATS3. Hopefully this could allow something like scalafix
>>>  to be developed, which would
>>> not only allow code migration from ATS2 to ATS3, but also ease future code
>>> migration within ATS3.
>>> to be applied to existing sources
>>>
>>> On Wednesday, March 7, 2018 at 11:52:49 AM UTC-5, 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
 mo

Re: ATS3: ATS/Xanadu

[gmhwxi]

The way in which Scala evolves reminds me of C++: Powerful features
increase productivity but also make it harder and harder to reason about
code.

On Friday, March 9, 2018 at 3:29:18 PM UTC-5, Brandon Barker wrote:
>
> Another Scala feature worth looking into: implicit parameters, values, and 
> function types. Dotty has added implicit function types, and I'm not very 
> familiar with all their benefits as yet: 
> https://www.scala-lang.org/blog/2016/12/07/implicit-function-types.html 
> However, implicit parameters alone have been great for me, and could 
> probably go a long way towards reducing some verbosity in ATS. They can 
> also be used in clever ways to create contradictions at compile time, by 
> bringing into scope two implicit values of the same type. I'm not sure if 
> ATS would benefit from that feature, but Scala's type system doesn't allow 
> for things like type b = not a. You can achieve that with implicits: 
> https://gist.github.com/milessabin/c9f8befa932d98dcc7a4
>
> On Wednesday, March 7, 2018 at 12:01:03 PM UTC-5, Brandon Barker wrote:
>>
>> I forgot to mention, I like the idea of adding a level of indirection in 
>> the syntax for ATS3. Hopefully this could allow something like scalafix 
>>  to be developed, which would 
>> not only allow code migration from ATS2 to ATS3, but also ease future code 
>> migration within ATS3.
>> to be applied to existing sources
>>
>> On Wednesday, March 7, 2018 at 11:52:49 AM UTC-5, 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 commu

Re: ATS3: ATS/Xanadu

[Brandon Barker]

Another Scala feature worth looking into: implicit parameters, values, and 
function types. Dotty has added implicit function types, and I'm not very 
familiar with all their benefits as 
yet: https://www.scala-lang.org/blog/2016/12/07/implicit-function-types.html 
However, implicit parameters alone have been great for me, and could 
probably go a long way towards reducing some verbosity in ATS. They can 
also be used in clever ways to create contradictions at compile time, by 
bringing into scope two implicit values of the same type. I'm not sure if 
ATS would benefit from that feature, but Scala's type system doesn't allow 
for things like type b = not a. You can achieve that with 
implicits: https://gist.github.com/milessabin/c9f8befa932d98dcc7a4

On Wednesday, March 7, 2018 at 12:01:03 PM UTC-5, Brandon Barker wrote:
>
> I forgot to mention, I like the idea of adding a level of indirection in 
> the syntax for ATS3. Hopefully this could allow something like scalafix 
>  to be developed, which would 
> not only allow code migration from ATS2 to ATS3, but also ease future code 
> migration within ATS3.
> to be applied to existing sources
>
> On Wednesday, March 7, 2018 at 11:52:49 AM UTC-5, 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 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 

Re: ATS3: ATS/Xanadu

[Brandon Barker]

I forgot to mention, I like the idea of adding a level of indirection in 
the syntax for ATS3. Hopefully this could allow something like scalafix 
 to be developed, which would not 
only allow code migration from ATS2 to ATS3, but also ease future code 
migration within ATS3.
to be applied to existing sources

On Wednesday, March 7, 2018 at 11:52:49 AM UTC-5, 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 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 implementatio

Re: ATS3: ATS/Xanadu

[Brandon Barker]

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 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/aa92ddcb-9a6f-4aa3-a5a9-85dbb666aa9a%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[vamchale]

In reference to the quoted, I will note that I have written a package 
 for dealing with ATS 
syntax in Haskell. The pretty-printer works marvelously, but getting the 
parser right is HARD. The package already has around 1400 lines of code for 
the lexer/parser and it's STILL buggy. I suspect a good part of that is be 
due to me not understanding things correctly, but in general I think a 
simpler syntax would serve ATS much better. There are a lot of things I 
want to be able to do with Haskell/ATS and I suspect the wider community 
will appreciate it for exactly the reasons mentioned by others :)

On Tuesday, February 20, 2018 at 1:00:48 PM UTC-6, aditya siram wrote:
>
> Many here have mentioned syntax as a point of improvement. While I agree, 
> I have no opinions on which variant (ML vs. C vs. Lisp) is more 
> aesthetically appealing. Some things I look for are unambiguous 
> indentation, easy for a machine to format and easy to parse. I think syntax 
> should be designed to be amenable to making an IDE and other source code 
> tooling rather than trying to meet some subjective definition of 
> readability which is only really relevant in the small. As an example, 
> while pretty, the (whitespace significant) version of Haskell syntax is 
> difficult and demoralizing to write tooling for.
>
> I will also say that ATS is currently so little used that now's the time 
> to make pretty big changes, even slashing features ( eg. macros ).
>
> On Tuesday, February 20, 2018 at 9:19:31 AM UTC-6, Artyom Shalkhakov wrote:
>>
>> On Saturday, February 10, 2018 at 12:15:22 AM UTC+6, 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 say what I would like to see:
>>
>> 1. IDE support (especially for the hard parts, i.e. the proofs!)
>> 2. the syntax is very complex (maybe simplify?)
>> 3. better support for flat types (e.g. flat unions, flat unboxed arrays 
>> on stack, etc.)
>> 4. compilation to wasm
>> 5. tools (especially for building, but also package management)
>> 6. some kind of help for implementing various intricately-linked data 
>> structures (doubly-linked lists, doubly-linked trees, etc.)
>> 7. improvements to templates (e.g. templates for indexed type variables, 
>> is that even possible?)
>>  
>> To make ATS viable, we have to make its kind of typeful programming 
>> friendly.
>>
>> 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/2746a848-f1a5-45fa-92c3-9d99ad44ee47%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[aditya siram]

Many here have mentioned syntax as a point of improvement. While I agree, I 
have no opinions on which variant (ML vs. C vs. Lisp) is more aesthetically 
appealing. Some things I look for are unambiguous indentation, easy for a 
machine to format and easy to parse. I think syntax should be designed to 
be amenable to making an IDE and other source code tooling rather than 
trying to meet some subjective definition of readability which is only 
really relevant in the small. As an example, while pretty, the (whitespace 
significant) version of Haskell syntax is difficult and demoralizing to 
write tooling for.

I will also say that ATS is currently so little used that now's the time to 
make pretty big changes, even slashing features ( eg. macros ).

On Tuesday, February 20, 2018 at 9:19:31 AM UTC-6, Artyom Shalkhakov wrote:
>
> On Saturday, February 10, 2018 at 12:15:22 AM UTC+6, 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 say what I would like to see:
>
> 1. IDE support (especially for the hard parts, i.e. the proofs!)
> 2. the syntax is very complex (maybe simplify?)
> 3. better support for flat types (e.g. flat unions, flat unboxed arrays on 
> stack, etc.)
> 4. compilation to wasm
> 5. tools (especially for building, but also package management)
> 6. some kind of help for implementing various intricately-linked data 
> structures (doubly-linked lists, doubly-linked trees, etc.)
> 7. improvements to templates (e.g. templates for indexed type variables, 
> is that even possible?)
>  
> To make ATS viable, we have to make its kind of typeful programming 
> friendly.
>
> 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/496a6b6c-e701-49b8-8b96-0d4be8aad285%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Artyom Shalkhakov]

On Saturday, February 10, 2018 at 12:15:22 AM UTC+6, 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 say what I would like to see:

1. IDE support (especially for the hard parts, i.e. the proofs!)
2. the syntax is very complex (maybe simplify?)
3. better support for flat types (e.g. flat unions, flat unboxed arrays on 
stack, etc.)
4. compilation to wasm
5. tools (especially for building, but also package management)
6. some kind of help for implementing various intricately-linked data 
structures (doubly-linked lists, doubly-linked trees, etc.)
7. improvements to templates (e.g. templates for indexed type variables, is 
that even possible?)
 
To make ATS viable, we have to make its kind of typeful programming 
friendly.

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/eaafa947-433d-4252-b915-41b2df384f03%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[M88]

I have accrued a bit of a wishlist while working with ATS.   Maybe some of 
it is useful or feasible.

Things I would keep the same:

   - I think dependent type / proof syntax is well done, and it feels a bit 
   more natural than Idris.  I'd keep this the same
   - The '~' to free an unfolded view type is a good choice. 
   - I'm also fond of '@' for unboxed types.
   - I like the degree to which it resembles SML. 
   - I like the various language backends.  The JS backend is especially 
   important, I think
   
I really like Idris and Haskell, though maybe SML-like syntax offers more 
flexibility (eg, defining different types of functions).  For 
resource-awareness, distinguishing between C-like lambdas and closures is 
excellent.  Then again, I don't miss the "fun" while working with Haskell 
or Idris. 

One good thing about Idris is that it's somewhat easy to target native / 
JS, and unofficially, the JVM.  A bit odd that the JS backend can be faster 
than the native at times.

Haskell is horrendous to cross-compile, and GHCJS program sizes are 
massive.  I love it for basic native compilation, though.

I think ATS could have a slight edge in the sense of portability -- the JS 
it outputs is tiny and it's dead-simple to cross-compile.   That said, I 
can't integrate the JS very easily into a standard JS toolchain, since it 
doesn't output modules.


Here are syntactic things I think ATS would benefit from:


   - Active whitespace would be a great alternative to "end", and might add 
   some elegance
   - Templates need to be better distinguished from dependent types.
   - As mentioned already, I dislike the '@' signs in types (eg, t@ype).  
   Aliasing also becomes very confusing (it took me a while to figure out what 
   t0p meant, or t0ype for that matter)
   - I found numeric suffixes similarly problematic -- clo1, for instance.  
   The number gives no indication about what the name may mean. 
   - List literals would be awesome in some capacity (eg, ["this", "is", 
   "a", "list"]).  I guess it may be hard to distinguish between types of 
   lists, but I do think $list / $list_v is a bit too verbose.
   - $FOO reads like a shell variable.  Nixing the dollar sign next to 
   modules may be a good choice.
   - I think C might be best banished to .cats files.  Or, maybe the inline 
   code blocks could be assigned a language (eg, %C{  ... %})
   - Multiline strings are useful in any language.
 
   
Technical things I think ATS could use:


   - Some lightweight concurrency primitives would be great -- nothing that 
   would require a runtime, but maybe something to schedule things like green 
   threads.
   - Clearer error messages, ideally aware of the C compilation phase.  C 
   errors can be confusing whenI'm not working in C.
   - Odds and ends -- a build / package manager might be useful. 
   - Lazy "val" might be nice -- like Haskell's "let". 
   - The JS backend is great, but it would help to output modules. ES6 
   would be a fine choice for this, I think.  Node will catch up eventually, 
   and in the meantime, there are tools like Rollup, etc.
   - Possibly, row types?
   

One thing I liked about ATS is that I could port the same library to 
multiple language targets simply by swapping out .hats and .cats files. I 
had attempted to build a web framework / HTML DSL on this principle (though 
time isn't on my side).  I felt that some of my Makefile trickery could be 
better managed by a smart build tool, that knows the library and the 
language targets (C for the server and JS for the client), for example.  I 
don't think it needs to be particularly complex, but there would need to be 
some conventions for directory structure and organization of .cats files in 
different languages.


-- 
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/06909163-6217-437e-b92c-bdaa7c96cf64%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[August Alm]

I have something to add to the wishlist: "better" linear functions.

We had a discussion about this almost a year ago. The issue I raised back 
then is that
there is no real way to free a linear function without applying it. This is 
not a concern 
motivated by category theory or something such, but a practical concern. 
Not being 
able to free functions without applying them simply makes it unnecessary 
difficult to
write code. For example, writing code that depends on runtime data of the 
form

"if data is ... then apply linear function foo and free bar
else apply linear function bar and free foo"
 
becomes a no-no.

Hongwei came up with two alternatives to (lin)cloptr. First:

datavtype
hom(a: vt0p, b:vt0p+) =
  {env: vtype}
  HOM(a, b) of
(env, env -> void, (env, a) -> b)

Secondly:

datavtype
hom(a: vt0p, b: vt0p+) =
  hom(a, b) of
{i: bool} option_vt(a, i) - option_vt(b, i)

The first solution requires all linear functions to have a 
"free method" [env -> void]. The secondly sidesteps the
problem by giving all linear functions a [None_vt()] on 
which we can evaluate them in order to free them.

Both alternatives work, but there is no syntactic sugar and no
library support. (Also, wrapping things in datavtype of datavtype
will, I guess, affect performance, but ought to be possible for the 
compiler to optimize.)

Best wishes,
August

Den fredag 9 februari 2018 kl. 19:15:22 UTC+1 skrev gmhwxi:
>
> 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/30553c1d-7603-4085-bc3f-ef65595c43b0%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[gmhwxi]

Thanks for writing it down.

Hopefully, this does not end up a merely pipe dream :)

I would also put 'type inference' high up there. Some variant
of Hindley-Milner type inference should be a crucial part of ATS3.

On Tuesday, February 13, 2018 at 2:52:29 PM UTC-5, Steinway Wu wrote:
>
> Hi Hongwei, just for the record, let me put down some offline discussions. 
>
> 1. Programmers can decide how a literal is parsed, or even write some 
> plugins to parse some custom literals. For instance, 1 can be interpreted 
> as int, nat, and int(1) etc. Programmers should be able to either turn a 
> knob, or annotate the literal, to switch among interpretations. 
> 2. Some meta-programming supports via templates. E.g. `derive` of Haskell. 
> 3. Formalization of templates.
> 4. Module systems. 
> 5. Session types :)
> 6. Modular design of the whole tool chain. E.g. parsing, type equality, 
> constraints solving, template dispatch, type erasure, etc. 
> 7. Maybe database-based compilations? We can store compiled blocks as a 
> (hash, binary IR) pairs in some file-based databases, for easy reuse. Not 
> sure how feasible it is. 
> 8. Interpreter, REPL, language servers, documentation tools, standard 
> libraries, type inference, etc. 
> 9. More importantly, a process for open source contribution. 
>
> Exciting!
>
> 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/2cc788cc-a31f-4431-9d49-e73545ae36fe%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[gmhwxi]

It is not that I like pan-syntax. What I really like is syntax-independence,
but we are still very far from it :)

When facing uncertainties, I would say that one's natural reaction is to 
keep
the options open.

On Tuesday, February 13, 2018 at 2:24:08 PM UTC-5, August Alm wrote:
>
> I realize it may have sounded as if I like the feature of being able to 
> write the same thing in a multitude of ways. I don't. It's something both 
> Scala and ATS have in common and that I think it's problematic. In both 
> Haskell and C the are many ways of doing things, but not many ways/styles 
> of writing.

-- 
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/865f623a-7b2a-4a6f-9d8f-ae111e95f8a2%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Steinway Wu]

Hi Hongwei, just for the record, let me put down some offline discussions. 

1. Programmers can decide how a literal is parsed, or even write some 
plugins to parse some custom literals. For instance, 1 can be interpreted 
as int, nat, and int(1) etc. Programmers should be able to either turn a 
knob, or annotate the literal, to switch among interpretations. 
2. Some meta-programming supports via templates. E.g. `derive` of Haskell. 
3. Formalization of templates.
4. Module systems. 
5. Session types :)
6. Modular design of the whole tool chain. E.g. parsing, type equality, 
constraints solving, template dispatch, type erasure, etc. 
7. Maybe database-based compilations? We can store compiled blocks as a 
(hash, binary IR) pairs in some file-based databases, for easy reuse. Not 
sure how feasible it is. 
8. Interpreter, REPL, language servers, documentation tools, standard 
libraries, type inference, etc. 
9. More importantly, a process for open source contribution. 

Exciting!

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/73f8357d-fdd7-4949-8515-6cd2abe96e1a%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[August Alm]

I realize it may have sounded as if I like the feature of being able to write 
the same thing in a multitude of ways. I don't. It's something both Scala and 
ATS have in common and that I think it's problematic. In both Haskell and C the 
are many ways of doing things, but not many ways/styles of writing.

-- 
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/76086809-b891-4e96-a9bc-9f0c68ae68f2%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[gmhwxi]

Let's experiment.

My rough plan for now is to have something largely based
on the current syntax of ATS2 (modulo some minor fixes) as
the "ground" syntax. This syntax is going to be explicit and
verbose. There will be an interface for it (e.g., via JSON).

Then we can embrace a "pan-syntax" design. For instance,
Hakell-like syntax can be supported as long as it can be translated
to the ground syntax.

I think that Python-like syntax is a good idea, too. The seemingly
simple idea of using indentation to structure code can go a long way.
It is brilliant!

On Tuesday, February 13, 2018 at 12:11:28 PM UTC-5, August Alm wrote:
>
> Fine by me! As long as the syntax encourages a uniform and readable coding 
> style. Also, I think it would help ATS
> if it looked more (seemingly) familiar to a more widely known language. 
> For example, at the moment we have the
> abbreviated syntax " = {...}" for "= () where {...}", which allows us to 
> write function bodies of void-functions in a style
> that looks C-ish, but there is no nice way, I think, to write functions 
> with a non-void return type in the same way.
>
> Maybe Scala offers a good solution? Functions in Scala have the default 
> form:
>
> def functionName ([list of parameters]) : [return type] = {
>function body
>return [expr]
> }
>
>
> A different way is, e.g.,
>
> val add1: Int => Int = (i) => i + 1
>
>
> My point is that it is always allowed to put curly braces on the body 
> (same goes with 
> if-statements, etc.) so that it is possible to write consistently in a 
> C-ish style.
>
>
> Den tisdag 13 februari 2018 kl. 16:56:52 UTC+1 skrev Artyom Shalkhakov:
>
> If we talk syntax, why not adopt that of C? :-)
>>
>> 13 февр. 2018 г. 8:43 ПП пользователь "August Alm"  
>> написал:
>>
>> I second the preference for Haskell-style "let" and "where", which is to 
>> say no "end"s and no curly braces.
>> Of course, this requires indentation to be syntactic and not just a 
>> matter of aesthetics/readability. I think this
>> is a good thing, not just because it is more concise but maybe even more 
>> so because it enforces readability
>> (non-indented code will not compile) and stylistic uniformity in the 
>> community.
>>
>> As a side-note, Haskell allows curly braces and semi-colons as an 
>> optional form of writing.
>> One may write "foo f = let {x=a; y=b; ...} in ...", etc. Useful for 
>> one-liners or for people who want their code
>> to look like more C-ish.
>>
>>
>> Den måndag 12 februari 2018 kl. 19:59:54 UTC+1 skrev gmhwxi:
>>>
>>> Thanks.
>>>
>>> Haskell and Idris are definitely on my radar.
>>>
>>> Type inference in ATS is very week (largely due to the support
>>> for dependent types and linear types). To support concise syntax,
>>> type inference in ATS needs to greatly strengthened.
>>>
>>> On Sunday, February 11, 2018 at 8:34:48 PM UTC-5, vamchale wrote:

 I don't have any concrete suggestions, but I would suggest Idris as an 
 example to follow. Haskell syntax is relatively popular and concise, and 
 Idris' is even more refined.

 I will say I'd prefer syntax that eases functional programming, but 
 that might just be me. And I think that replacing - with 
 something more concise like -o would be a good decision either way.

 On Friday, February 9, 2018 at 12:15:22 PM UTC-6, 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-user...@googlegroups.com.
>> 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 
>> https://groups.google.com/d/msgid/ats-lang-users/7bf25292-2094-4d32-9d74-6937e298a240%40googlegroups.com
>>  
>> 

Re: ATS3: ATS/Xanadu

[August Alm]

Fine by me! As long as the syntax encourages a uniform and readable coding 
style. Also, I think it would help ATS
if it looked more (seemingly) familiar to a more widely known language. For 
example, at the moment we have the
abbreviated syntax " = {...}" for "= () where {...}", which allows us to 
write function bodies of void-functions in a style
that looks C-ish, but there is no nice way, I think, to write functions 
with a non-void return type in the same way.

Maybe Scala offers a good solution? Functions in Scala have the default 
form:

def functionName ([list of parameters]) : [return type] = {
   function body
   return [expr]
}


A different way is, e.g.,

val add1: Int => Int = (i) => i + 1


My point is that it is always allowed to put curly braces on the body (same 
goes with 
if-statements, etc.) so that it is possible to write consistently in a 
C-ish style.


Den tisdag 13 februari 2018 kl. 16:56:52 UTC+1 skrev Artyom Shalkhakov:

If we talk syntax, why not adopt that of C? :-)
>
> 13 февр. 2018 г. 8:43 ПП пользователь "August Alm"  > написал:
>
> I second the preference for Haskell-style "let" and "where", which is to 
> say no "end"s and no curly braces.
> Of course, this requires indentation to be syntactic and not just a matter 
> of aesthetics/readability. I think this
> is a good thing, not just because it is more concise but maybe even more 
> so because it enforces readability
> (non-indented code will not compile) and stylistic uniformity in the 
> community.
>
> As a side-note, Haskell allows curly braces and semi-colons as an optional 
> form of writing.
> One may write "foo f = let {x=a; y=b; ...} in ...", etc. Useful for 
> one-liners or for people who want their code
> to look like more C-ish.
>
>
> Den måndag 12 februari 2018 kl. 19:59:54 UTC+1 skrev gmhwxi:
>>
>> Thanks.
>>
>> Haskell and Idris are definitely on my radar.
>>
>> Type inference in ATS is very week (largely due to the support
>> for dependent types and linear types). To support concise syntax,
>> type inference in ATS needs to greatly strengthened.
>>
>> On Sunday, February 11, 2018 at 8:34:48 PM UTC-5, vamchale wrote:
>>>
>>> I don't have any concrete suggestions, but I would suggest Idris as an 
>>> example to follow. Haskell syntax is relatively popular and concise, and 
>>> Idris' is even more refined.
>>>
>>> I will say I'd prefer syntax that eases functional programming, but that 
>>> might just be me. And I think that replacing - with something 
>>> more concise like -o would be a good decision either way.
>>>
>>> On Friday, February 9, 2018 at 12:15:22 PM UTC-6, 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-user...@googlegroups.com .
> 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 
> https://groups.google.com/d/msgid/ats-lang-users/7bf25292-2094-4d32-9d74-6937e298a240%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/da6ba929-3070-440d-be9f-1c19a0e637c7%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Artyom Shalkhakov]

If we talk syntax, why not adopt that of C? :-)

13 февр. 2018 г. 8:43 ПП пользователь "August Alm" 
написал:

I second the preference for Haskell-style "let" and "where", which is to
say no "end"s and no curly braces.
Of course, this requires indentation to be syntactic and not just a matter
of aesthetics/readability. I think this
is a good thing, not just because it is more concise but maybe even more so
because it enforces readability
(non-indented code will not compile) and stylistic uniformity in the
community.

As a side-note, Haskell allows curly braces and semi-colons as an optional
form of writing.
One may write "foo f = let {x=a; y=b; ...} in ...", etc. Useful for
one-liners or for people who want their code
to look like more C-ish.


Den måndag 12 februari 2018 kl. 19:59:54 UTC+1 skrev gmhwxi:
>
> Thanks.
>
> Haskell and Idris are definitely on my radar.
>
> Type inference in ATS is very week (largely due to the support
> for dependent types and linear types). To support concise syntax,
> type inference in ATS needs to greatly strengthened.
>
> On Sunday, February 11, 2018 at 8:34:48 PM UTC-5, vamchale wrote:
>>
>> I don't have any concrete suggestions, but I would suggest Idris as an
>> example to follow. Haskell syntax is relatively popular and concise, and
>> Idris' is even more refined.
>>
>> I will say I'd prefer syntax that eases functional programming, but that
>> might just be me. And I think that replacing - with something
>> more concise like -o would be a good decision either way.
>>
>> On Friday, February 9, 2018 at 12:15:22 PM UTC-6, 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/7bf25292-2094-4d32-9d74-6937e298a240%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/CAKO6%3DqitoDCyXydY2ZsnwKtT8RP%2B51mkjNsYt5gyf_YUEN1u3A%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[August Alm]

I second the preference for Haskell-style "let" and "where", which is to 
say no "end"s and no curly braces.
Of course, this requires indentation to be syntactic and not just a matter 
of aesthetics/readability. I think this
is a good thing, not just because it is more concise but maybe even more so 
because it enforces readability
(non-indented code will not compile) and stylistic uniformity in the 
community.

As a side-note, Haskell allows curly braces and semi-colons as an optional 
form of writing.
One may write "foo f = let {x=a; y=b; ...} in ...", etc. Useful for 
one-liners or for people who want their code
to look like more C-ish.

Den måndag 12 februari 2018 kl. 19:59:54 UTC+1 skrev gmhwxi:
>
> Thanks.
>
> Haskell and Idris are definitely on my radar.
>
> Type inference in ATS is very week (largely due to the support
> for dependent types and linear types). To support concise syntax,
> type inference in ATS needs to greatly strengthened.
>
> On Sunday, February 11, 2018 at 8:34:48 PM UTC-5, vamchale wrote:
>>
>> I don't have any concrete suggestions, but I would suggest Idris as an 
>> example to follow. Haskell syntax is relatively popular and concise, and 
>> Idris' is even more refined.
>>
>> I will say I'd prefer syntax that eases functional programming, but that 
>> might just be me. And I think that replacing - with something 
>> more concise like -o would be a good decision either way.
>>
>> On Friday, February 9, 2018 at 12:15:22 PM UTC-6, 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/7bf25292-2094-4d32-9d74-6937e298a240%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[gmhwxi]

Thanks.

Haskell and Idris are definitely on my radar.

Type inference in ATS is very week (largely due to the support
for dependent types and linear types). To support concise syntax,
type inference in ATS needs to greatly strengthened.

On Sunday, February 11, 2018 at 8:34:48 PM UTC-5, vamchale wrote:
>
> I don't have any concrete suggestions, but I would suggest Idris as an 
> example to follow. Haskell syntax is relatively popular and concise, and 
> Idris' is even more refined.
>
> I will say I'd prefer syntax that eases functional programming, but that 
> might just be me. And I think that replacing - with something 
> more concise like -o would be a good decision either way.
>
> On Friday, February 9, 2018 at 12:15:22 PM UTC-6, 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/fc07f6db-d1d3-4001-856f-a1c554ab43f7%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[vamchale]

I don't have any concrete suggestions, but I would suggest Idris as an 
example to follow. Haskell syntax is relatively popular and concise, and 
Idris' is even more refined.

I will say I'd prefer syntax that eases functional programming, but that 
might just be me. And I think that replacing - with something 
more concise like -o would be a good decision either way.

On Friday, February 9, 2018 at 12:15:22 PM UTC-6, 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/b16a4ee6-8243-4fb6-9e05-e47697ef328b%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Hongwei Xi]

This works:

%{
int
ex1[3][4] =
{
{5, 1, 9, 5}
,
{7, 5, 3, 0}
,
{2, 4, 6, 8}
};
%}
val ex1 =
$extval(matrixref(int, 3, 4), "ex1")


On Fri, Feb 9, 2018 at 5:59 PM, Julian Fondren 
wrote:

> (Although this is wrong, and causes a segfault.)
>
> On Friday, February 9, 2018 at 4:44:40 PM UTC-6, Julian Fondren wrote:
>>
>> One might prefer to define the table in the target language, even C:
>>
>> %{
>> int ex1[3][4] = {{5, 1, 9, 5},
>>  {7, 5, 3, 0},
>>  {2, 4, 6, 8}};
>> %}
>> val ex1 = $extval(arrayref(arrayref(int, 4), 3), "ex1")
>>
>>>
>>> --
> 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/41f32d30-77a4-42ef-86e3-87da0647fe35%
> 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/CAPPSPLqO2KmLBOEKG-AKNtNSgVTQT3T%2B2wLLwvnE34b9kjQuiw%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[Julian Fondren]

(Although this is wrong, and causes a segfault.)

On Friday, February 9, 2018 at 4:44:40 PM UTC-6, Julian Fondren wrote:
>
> One might prefer to define the table in the target language, even C:
>
> %{
> int ex1[3][4] = {{5, 1, 9, 5},
>  {7, 5, 3, 0},
>  {2, 4, 6, 8}};
> %}
> val ex1 = $extval(arrayref(arrayref(int, 4), 3), "ex1")
>
>>
>>

-- 
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/41f32d30-77a4-42ef-86e3-87da0647fe35%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Julian Fondren]

ah. also:

val ex1 = (arrayref)$arrpsz{arrayref(int, 4)}(a, b, c) where {
  val a = (arrayref)$arrpsz{int}(5, 1, 9, 5)
  val b = (arrayref)$arrpsz{int}(7, 5, 3, 0)
  val c = (arrayref)$arrpsz{int}(2, 4, 6, 8)
}

is there a nicer way to include a matrix in an ATS2 program than this?

One might prefer to define the table in the target language, even C:

%{
int ex1[3][4] = {{5, 1, 9, 5},
 {7, 5, 3, 0},
 {2, 4, 6, 8}};
%}
val ex1 = $extval(arrayref(arrayref(int, 4), 3), "ex1")


Going as far as having a nice literal syntax for hash tables would fit the 
expectations of a Ruby/JS/&c hacker.

On Friday, February 9, 2018 at 12:15:22 PM UTC-6, 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/f6fd9fb0-97bd-4c11-9f32-6dcc8f223f1e%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Julian Fondren]

Aye, like in https://www.youtube.com/watch?v=zt0OQb1DBko where it's twice 
emphasized that "there are no typos here--this is what ATS looks like". 
Those are the most off-putting.

I would also prefer a more OCaml-like "let val x=1 in (expression)" to the 
existing "let val x=1 in (expression) (expression) ... end". Which would be 
better in ATS than in OCaml since 'let' isn't otherwise used. Mainly 
because there's less to indent:

let cube_round (x, y, z) =
  let round r = floor (r +. 0.5) in
  let rx, ry, rz = round x, round y, round z in
  let xd, yd, zd = abs_float (rx -. x), abs_float (ry -. y), abs_float (rz 
-. z) in
  (* ^-- no indentation changes --v *)
  if xd > yd && xd > zd then
(-. (ry -. rz), ry, rz)
  else if yd > zd then
(rx, (-. (ry -. rz)), rz)
  else
(rx, ry, (-. (rx -. ry)))

OTOH, OCaml is not famously regarded as good-looking. On the contrary 
Facebook gave it a purely syntatic makeover in ReasonML and people seem to 
really like that.

Other than those two I don't have many complaints. Maybe it could be 
emphasized more (in documentation) that there's flexibility to do things 
different ways. You can use (a; b; ignoreat(c); d) instead of a bunch of 
val () =. You can write

datatype rps_move = rock | paper | scissors  // without the parens

, etc.

On Friday, February 9, 2018 at 3:57:11 PM UTC-6, Martin DeMello wrote:
>
> I would love to see t@ype and similar keywords with symbols in the middle 
> replaced by something more pronounceable - the lack of quick mental 
> pronunciation is a surprisingly large annoyance when reading and wirting 
> code.
>
> martin
>
> On Fri, Feb 9, 2018 at 10:15 AM, 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-user...@googlegroups.com .
>> 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 
>> https://groups.google.com/d/msgid/ats-lang-users/8d547585-a0ce-494e-8568-a0657274deb0%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/f1058cf1-13f3-48c5-8a2d-50370505cbb8%40googlegroups.com.

Re: ATS3: ATS/Xanadu

[Hongwei Xi]

This one is already on my mind. Learned my lessons :)

The plan is to use 'abstype' in place of abst@ype.

On Fri, Feb 9, 2018 at 4:57 PM, Martin DeMello 
wrote:

> I would love to see t@ype and similar keywords with symbols in the middle
> replaced by something more pronounceable - the lack of quick mental
> pronunciation is a surprisingly large annoyance when reading and wirting
> code.
>
> martin
>
> On Fri, Feb 9, 2018 at 10:15 AM, 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/ms
>> gid/ats-lang-users/8d547585-a0ce-494e-8568-a0657274deb0%40go
>> oglegroups.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/CAFrFfuEzh8TOrZjeytTasi9zq2EAp
> aQMr5NPm8u76fRbgZOCpA%40mail.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/CAPPSPLpD9C8%2BbnS9a1TkDU0hjmeYuCEZ-B0fGdYjp%2B6g3N-S%2BA%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[Martin DeMello]

I would love to see t@ype and similar keywords with symbols in the middle
replaced by something more pronounceable - the lack of quick mental
pronunciation is a surprisingly large annoyance when reading and wirting
code.

martin

On Fri, Feb 9, 2018 at 10:15 AM, 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/8d547585-a0ce-494e-8568-a0657274deb0%
> 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/CAFrFfuEzh8TOrZjeytTasi9zq2EApaQMr5NPm8u76fRbgZOCpA%40mail.gmail.com.

Re: ATS3: ATS/Xanadu

[gmhwxi]

Of course, if you feel that it is more appropriate to have a private
discussion, please feel free to send your messages to me directly.

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/8dedc57b-7d0e-4883-b5f2-eec5dcc17a78%40googlegroups.com.