# Roadmap for the future of ATS?

**URL:** <https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55>\
**Category:** Google Group\
**Created:** [December 17, 2013, 6:27am UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55 "2013-12-17T06:27:11Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ming\_Lei](https://avatars.discourse-cdn.com/v4/letter/m/df705f/32.png) [@Ming\_Lei](https://discourse.ats-lang.org/u/Ming_Lei)\
**Post date:** [December 17, 2013, 6:27am UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55/1 "2013-12-17T06:27:11Z")

</div>

This question is for Professor Xi, but it’s probably also for everyone here.

I like ATS, but where is ATS heading to?

Will it remain in ivory tower as a teaching/thesis-generating tool forever,  
or will it ever grow up to be a real industrial language?

Every time I look at the very much incomplete documentation, every time I  
see Professor Xi himself updating some libraries in /contrib on GitHub, I  
want to ask these questions.

If the language’s creator just want it to remain to be an academic toy, so  
be it and it’s fine, as he has all the rights in the world.

Otherwise, we should all face the cold, hard reality and get some real work  
done.

---

<div class="post-metadata">

**Author:** ![Ming\_Lei](https://avatars.discourse-cdn.com/v4/letter/m/df705f/32.png) [@Ming\_Lei](https://discourse.ats-lang.org/u/Ming_Lei)\
**Post date:** [December 19, 2013, 2:28am UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55/2 "2013-12-19T02:28:26Z")

</div>

Thanks for bearing with me. I have only about two weeks of experience with  
ATS, but I’ll speak from my beginner’s point of view anyway, and hopefully  
more experienced people will join me.

1. The type system. I’m no expert in type systems, but to me it’s just  
the best in any practical programming languages available today. Not only  
does it help me detect bugs, it also forces me to think as clearly as  
possible. If you can make a stupid computer understand the idea of your  
program, by writing the proofs in a highly logical way, the chance of bugs  
is little. I have nothing to complain for now. I just want to see more  
examples on how to deal with heterogeneous lists, variadic arguments and  
other difficult things such as the Y combinator. It’s not like I’ll use any  
of them in everyday programming, but it would be good to know where the  
limit of ATS’s ability is.
2. The overall syntax. Syntax is a more personal thing, but I do like  
ATS’s syntax a lot. Part of it might be that I hate languages using curly  
braces as code block delimiters (e.g. C/C++/Java/Go). “begin” and “end”  
stand out more visibly than those thin curly braces, and it’s easier to see  
if they are aligned or not. One thing which beginners may find confusing is  
that the same symbol may have very different meanings, for example “” and  
“{}”. In future versions of the programming guide we may want to emphasis  
on how to easily distinguish the different uses.
3. The compiling process. As I said before, compiling to C is a big  
selling point. The generated C code is vastly clearer than what I can get  
from Haskell or Chicken Scheme. That said, I still think it could be made  
even more readable. Ideally, an ATS program written in imperative style  
should generate virtually identical C code. Currently the C code use a lot  
of inline functions to express (I think) the virtual instruction set of the  
compiler’s backend. It would be great if we could eliminate this layer and  
just output plain, boring C. Those inline functions are less readable, and  
they may be more troublesome to work with in a debugger. Although if you  
look at the final assembly code, they are tight enough, just looking at the  
C code and get an idea of how it works is much easier. The generated code  
also have a lot of extra comments. They are useful in large projects, but  
beginners usually start from writing small programs, so keeping it lean and  
mean in simple cases will be helpful.
4. Another one of my wishes is a command line option to generate a  
standalone C program in source form, independent of any object files or  
libraries. I know there is a way to achieve that by including all the  
needed dynamic sources, but that’s too much work, not to mention you have  
to know which files to include. Pure C sources are more portable,  
especially if you need to embed the generated C code in places where  
linking user land libraries is prohibited (e.g. OS kernels, device  
drivers). Combined with point 3, it can also show those doubtful C  
programmers that there really is no magic nor dirty tricks. It would be a  
big win.
5. Those relocation strings embedded in the object files, they are long  
and unreadable Sometimes they cause problems in the building process. I  
wonder if there is a better way to do that.
6. Can we combine atscc and atsopt into one single command? I do not see  
the point of keeping them as two separate commands.
7. GMP is nice, but it’s also a heavy weight dependency. I personally  
would like to see the support of infinite precision arithmetic as a  
library, not a built-in, and keep the basic data types isometric to C’s.  
Otherwise, I’d like to know how to avoid using its functionalities in my  
own code, so that at least the generated C code can run in environments  
where GMP is not available.
8. The same for exception handling support. It’s useful, but sometimes  
you want to disable it in low-leve code.
9. Now, back to the fine points of the syntax. My starting point is, if  
we really want to win the imperative programmers’ hearts, we have to make  
the syntax easy for them. If we also want to teach them to write  
correctness proofs, we’ll need to make that part’s syntax easy, too.
10. I understand why tail-recursion is great, and ATS can compile them  
into loops if you write them in the right way, but creating nested  
functions just to express a simple loop is pedantic. You need to invent new  
names for the nested functions, and you also need to declare their types  
and parameters, and repeat the parameter list again when you call them.  
It’s way too verbose, for little benefit. Simply saying writing programs  
this way fits well into ATS’s big picture is just not convincing enough. If  
one of the major causes of verbosity in real life ATS code. I don’t know  
how difficult it will be, but can we make the compiler smart enough to  
compile imperative for/while better? Can we figure out a way to attach  
termination metrics to for/while loops and do not lose the theorem proving  
power? If we can convert from tail-calls to loops, why can’t we work  
backwards? Can we have goto?
11. Most, if not all, examples in the programming guide, and all the ATS  
programs I can find in the Computer Language Benchmarks Game are  
deliberately written in a very verbose way. I know it’s meant to show more  
features of ATS and to teach beginners, and I know they can be much shorter  
if you want, but new comers do not know. I’ve heard people saying that they  
find ATS promising but are scared away by its “verbosity”. Well, if that  
were the most concise form of ATS programs, I’d be driven away, too.  
Working programmers hate verbosity. I agree a reasonable amount of  
verbosity if good, but there should be a limit. People hate ADA or Java for  
a reason. It’s nothing wrong to reveal the concise style to beginners  
gradually, but we have to at least show them several concise examples  
first, so that they can know there is a heaven and they can eventually get  
there. If God only shows us the Inferno, nobody will follow him. We need to  
make code examples short.
12. One big reason I like ATS is that it’s not as dogmatic as some other  
functional programming languages. Its syntax is both inclusive and  
flexible. However, after all those nice additions, at some point we may  
want to take some time to re-examine the whole syntax, and see if there is  
something rarely used that we can remove. For example, I think some ML  
derived syntax can be removed or at least deprecated. Our goal is to win  
over C/C++ programmers, so “&&” makes sense and “andalso” does not. Maybe  
we can even remove “begin”, as in Ocaml (but not “;;”). I personally also  
do not like the “(\* comment \*)” syntax. Not that there is anything wrong in  
itself, but they are too similar to "()"s, especially when you write code  
like “nil of ((_nothing_))”. Syntax-highighting text editors do help, but  
still it’s some legacy from ATS’s ML root. But that’s just my personal  
preference. I’d like to hear what other C programmers would say.
13. There are other minor points where I think readability/usability can  
be improved. I don’t like the “+” in “case+”. Small, single character  
symbols like “+” and “-” are just too small to be seen clearly, and if you  
make a typo, it’s harder to detect. I suggest we get some statistics on  
which kind of case clauses is more useful in real world code, make it the  
default, and give the unpopular one a more verbose name. Another one is the  
dereference operator “!”. It’s too thin and too similar to “1” and “i”. C’s  
“\*” is way more readable. Also “fnx”. The “x” is too small and too easy to  
mistype. I personally have no problem with the “@” in “t@ype”, although  
“@type” might be easier to type. Of course, these fine points are all  
cosmetic inconveniences, I can just live with them.
14. A big topic would be the statics/theorem proving syntax. The current  
model is technically simple and straightforward, probably more familiar to  
former Prolog programmers, but hard to use. If we want people to write more  
proofs, we must make it easy. If you look at those successful theorem  
provers, for example Coq or Mizar, you don’t need to write “MUL(m,n,p)”,  
just something like “m\*n=p”. Learning to write proofs is already difficult  
enough for most programmers, and if the syntax is inhuman, they may just  
run from it. The goal of ATS is to let programmers write programs and  
proofs together, but that doesn’t mean they have to be written in the same  
language. Mixing the two things together, we are risking to make both tasks  
more difficult than necessary. Currently, I think some syntax sugar for  
statics might be helpful. My understanding is that ATS already has enough  
flexibility to do this, with macros and operator overloading/fixity  
declaration. If so, we can build up a layer of nice syntax and make it  
default in prelude, so that people do not need to deal with low-level,  
Prolog-like propositions directly. Well, even Prolog let you do this.
15. We may also consider making theorem proving related keywords more  
clear. For example simply use “lemma” for “prfun”, “axiom” for “praxi”,  
etc. For someone smart enough to learn ATS, these words shouldn’t be too  
strange to them, yet they are more readable and indicating their purposes  
better. I’d like to hear more input from other users on this.
16. Enough ranting on syntax. I want to emphasis that all that said,  
ATS’s syntax is still my personal single favorite among all the programming  
languages I know (I do know a lot of them). The design is very beautiful  
and tasteful. It’s a piece of art.
17. Can we combine .sats and .dats files? I’m not sure if that’s  
feasible, but I find cross-referencing between two files is tiring, even if  
with help from tagging systems. A combined .ats file format will be simpler  
and easier to organize.

That’s about all I want to say so far, given my limited experience with the  
language. Finally I want to thank Professor Xi for creating such a  
beautiful programming language. As I said I know a lot of programming  
languages. ATS is unique. Compared with ATS, Haskell is at least 10 years  
behind, and C++ is about 30 years behind. Had Bjarne Stroustrup created not  
C++ but ATS in the 1980s, our industry would have been a totally different  
world. I can see a future of C++ being swiped away by ATS, and that future  
is nigh. Let’s start to work.On Tuesday, December 17, 2013 5:11:10 PM UTC-6, Ming Lei wrote:

> Chairman Mao once said,
> 
> “Who are our enemies? Who are our friends? This is a question of the  
> first importance for the revolution.”
> 
> ATS is a revolution, but a programming language lives and dies with its  
> community. A weak language with a strong community wins over a strong  
> language with a weak community every time. Where is our community? How can  
> we grow it? Technical works aside, I’d say building up a community is our  
> top priority.
> 
> We don’t have many ATS programmers around, yet. The best source of new  
> blood for this community shall be its target users. “Expert programmers who  
> want to become more productive in writing high-quality code” is still too  
> general. I don’t think a Web developer using Ruby on Rails is ATS’s target  
> user, at least not in near future. ATS is good for low-level,  
> high-performance programming tasks where correctness must be ensured. This  
> may include:
> 
> 1. Scientific computing. Numerical stability and logical soundness are  
> important. I have friends working on computational biological problems,  
> using Haskell. The majority of this industry is still using C/C++ or  
> FORTRAN.
> 2. Financial computing. A bug can cost millions of dollars. Several  
> firms in this industry is already adopting Haskell or Ocaml, although C++  
> is still dominating, especially in the HFT section, obviously for  
> performance reasons.
> 3. Security and cryptography. Formal methods are getting popular, but  
> there is a huge gap between their formal proofs and high-performance C  
> code. We see trivial overflow bugs everyday.
> 4. Game development. Modern games are too complex. They also need to  
> deal with tricky concurrent/parallel programming problems. John Carmack is  
> trying Haskell, but ATS should be a much better choice.
> 5. Electronics and hardware/software interface. Device drivers, video  
> codecs, firmware, embedded/realtime operating systems, they can all benefit  
> from strong typing and formal proofs.
> 6. Military, medical, these I’m not familiar with, but they all use  
> old fashioned imperative languages.
> 
> Unfortunately, people in these fields are more conservative and skeptical.  
> They will not believe you unless you show them undeniable hard evidence.  
> They also hate to learn new languages. However, compared to languages like  
> Haskell or Ocaml, ATS not only has a much more powerful type system, but  
> also can be compiled to straightforward C code. This is our big selling  
> point.
> 
> We can not just wait for them to come and learn ATS. We need to actively  
> reach out, show them who great ATS is, listen to their concerns and improve  
> ATS accordingly. We need to reduce the difficulty for them to enter this  
> new world. Specifically, I have several ideas in mind:
> 
> 1. Professor Xi needs to communicate his big ideas and roadmap to the  
> community. If they only stay in his head, other people can not help. What’s  
> the difference between ATS 1 and 2? What new features can we expect? People  
> need to know the big picture.
> 2. Make a formal specification of ATS’s entire grammar. It needn’t to  
> be as readable as the Haskell 98 language report. Even as simple as an EBNF  
> can be hugely helpful. The language guide is far from completed yet, so a  
> formal grammar would be the only way for new comers to learn the whole  
> language, except reading the source code. Undocumented syntax wastes  
> everyone’s time. With a specification, we can try test cases, know which  
> works and which not, we can even contribute some fixes to the core  
> language. Without it we don’t even know where to start.
> 3. Finish the outline of the language guide ASAP. List all the  
> chapters to be written, write a brief summary for each one. Give people a  
> easy way to contribute to the documentation, so that they can fill it up.
> 4. People who can hack the compiler should stop spending too much time  
> on contributed libraries. Their energy is too valuable and they should  
> focus on the fundamentals. Nobody wants to write libraries with an  
> unreliable compiler. Please let other people write the libraries. They have  
> more domain knowledge and they can learn the language in the process.
> 5. Update the language’s official Web site. It’s too shabby now.  
> People do judge a language by its face. ATS is at least 30 years ahead of  
> mainstream languages, but its Web site looks to be 30 years behind. Make it  
> pretty, usable and informative, update it timely. Bonus point for writing  
> its backend in ATS.
> 6. Migrate all the remaining source code and downloadable stuff away  
> from SourceForge. SourceForge’s reputation is not good, and its usability  
> is worse. People may think ATS is dying with SourceForge. We can just move  
> ATS1’s source code to GitHub and move the downloadable packages to the Web  
> site.
> 7. Fix the trivial bugs in the build system and make it work well on  
> all the supported platforms. Encourage Linux distribution packagers / Mac  
> OS X ports maintainers to include ATS in their releases.
> 8. Separate the contribution libraries from the compiler itself. Make  
> a real online libraries repository similar to CPAN, RubyForge or NPM, so  
> people can freely share useful libraries with each other. Such a repository  
> is invaluable for a programming language. It’s an online presence, a social  
> place, and a place to demonstrate how the language works in real life to  
> curious lookers. This is very important.
> 9. Then we can use all our connections in the industry to advocate  
> ATS, ask our friends to try it, and eventually build one or two killer  
> applications with it, which is how every successful programming language  
> grows up.
> 
> All of these are non-technical ideas. I will summarize some of my thoughts  
> on the technical side in another post.
> 
> On Tuesday, December 17, 2013 8:34:47 AM UTC-6, gmhwxi wrote:
> 
> > First, I would really like to see that ATS gets used by more and more  
> > programmers, and I welcome suggestions of all sorts on making this a  
> > reality.
> > 
> > I do not see ATS as a programming language for the general public.  
> > Instead,  
> > it targets expert programmers who want to become more productive in  
> > writing  
> > high-quality code.
> > 
> > Compilation of templates in ATS2 is not yet finished. It is my first  
> > priority  
> > to get template compilation done properly.
> > 
> > As always, documentation needs to be added and improved. I need a lot of  
> > help for this.
> > 
> > I really want to see other people working on ATS-contrib besides me alone.
> > 
> > > > Otherwise, we should all face the cold, hard reality and get some real  
> > > > work done.
> > 
> > What kind work do you have in mind?
> > 
> > On Tuesday, December 17, 2013 1:27:11 AM UTC-5, Ming Lei wrote:
> > 
> > > This question is for Professor Xi, but it’s probably also for everyone  
> > > here.
> > > 
> > > I like ATS, but where is ATS heading to?
> > > 
> > > Will it remain in ivory tower as a teaching/thesis-generating tool  
> > > forever, or will it ever grow up to be a real industrial language?
> > > 
> > > Every time I look at the very much incomplete documentation, every time  
> > > I see Professor Xi himself updating some libraries in /contrib on GitHub, I  
> > > want to ask these questions.
> > > 
> > > If the language’s creator just want it to remain to be an academic toy,  
> > > so be it and it’s fine, as he has all the rights in the world.
> > > 
> > > Otherwise, we should all face the cold, hard reality and get some real  
> > > work done.

---

<div class="post-metadata">

**Author:** ![gmhwxi](https://avatars.discourse-cdn.com/v4/letter/g/67e7ee/32.png) [@gmhwxi](https://discourse.ats-lang.org/u/gmhwxi)\
**Post date:** [December 19, 2013, 10:56pm UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55/3 "2013-12-19T22:56:00Z")

</div>

Maybe we were thinking along different lines.

What I had in mind was using ‘gcc -E’ to preprocess C-header files.  
As long as gcc can find a header file, h2sats (the name of the tool)  
should be able to turn it into a corresponding SATS file. Lines like the  
following one can be put in a Makefile:

stdio.sats : ; h2sats [flags] stdio.hOn Thursday, December 19, 2013 3:49:06 PM UTC-5, Ming Lei wrote:

> On Thursday, December 19, 2013 11:00:13 AM UTC-6, gmhwxi wrote:
> 
> > Semantically, ATS and C are the same.
> > 
> > However, syntactically, I think that ATS and C should be kept very  
> > distinct from each other.
> 
> I fully agree. There is no way to fit ATS into C’s tiny shoes anyway.  
> That’s why there should still be "%{…%}"s to isolate the C code. ATS  
> should never support the full C syntax natively.
> 
> > 
> 
> One possibility to support what you said is to write a tool that can
> 
> > automatically turn C header files into SATS files in ATS.
> 
> Haskell has such tools, but they never work as flawlessly as C++'s extern  
> “C” statement. As far as I can remember, you still need to do a lot of  
> manual work to make sure the output is correct. But they have good reasons,  
> for Haskell is semantically very different from C.
> 
> The disadvantage of this kind of tools is that they not only add an extra  
> layer of work, they also increase chances for compatibility bugs.
> 
> If the C header files to be included are bundled with the ATS source code,  
> then a simple Makefile rule can solve the problem. If they are out of scope  
> of the ATS source code, for example let’s say I want to include OS X’s  
> system OpenGL header files. They are located at strange places, and Apple  
> has the habit of moving them around with system updates. You can’t hardcode  
> their paths in Makefile. You can not bundle the generated SATS with the  
> other ATS source code either, because a system update may change some  
> declarations in the C header files and make the generated SATS files out of  
> sync. The same problems also exist in Linux systems, where package updates  
> are more reckless.
> 
> Moreover, if we could make such a translation tool, and it could work  
> flawlessly on C code, what prevents us from just embed this tool inside the  
> ATS compiler? It shouldn’t be too big if we only need to parse the  
> declarations.
> 
> > 
> 
> > 
> 
> > On Wednesday, December 18, 2013 11:28:48 PM UTC-5, Ming Lei wrote:
> > 
> > > It turns out, I forgot one important thing.
> > > 
> > > ```
> > > 0. Make mixing ATS and C code as easy as possible. That means, 
> > > 
> > > ```
> > > 
> > > no more “#ext” and “#mac”. Just “%{ #include \<stdio.h\> }%” or something  
> > > like that, and you can start to use the C definitions in ATS. Just like  
> > > C++, ATS shares the native data types with C. If C++ can do it, ATS can do  
> > > it too. Technically, that may mean embedding a C front end for parsing, but  
> > > it’s totally worth the efforts. Potically, both ATS and GCC are licensed  
> > > under GPLv3, so there is no problem either. As far as I know, none of the  
> > > functional programming languages (except C++11, if you count it as a  
> > > functional language) can do that, because they either use boxed/tagged data  
> > > types by default (e.g. Ocaml, Common Lisp/Scheme, Haskell), or has poor  
> > > support for imperative programming at machine level (e.g. Haskell, Scala).  
> > > Not surprisingly, they all suffer from insufficient library support. ATS  
> > > has the unique position of having the best from both worlds (functional,  
> > > imperative, logic). With all the C libraries at its disposal, it’s destined  
> > > to win.
> > > 
> > > On Wednesday, December 18, 2013 8:28:26 PM UTC-6, Ming Lei wrote:
> > > 
> > > > Thanks for bearing with me. I have only about two weeks of experience  
> > > > with ATS, but I’ll speak from my beginner’s point of view anyway, and  
> > > > hopefully more experienced people will join me.
> > > > 
> > > > 1. The type system. I’m no expert in type systems, but to me it’s  
> > > > just the best in any practical programming languages available today. Not  
> > > > only does it help me detect bugs, it also forces me to think as clearly as  
> > > > possible. If you can make a stupid computer understand the idea of your  
> > > > program, by writing the proofs in a highly logical way, the chance of bugs  
> > > > is little. I have nothing to complain for now. I just want to see more  
> > > > examples on how to deal with heterogeneous lists, variadic arguments and  
> > > > other difficult things such as the Y combinator. It’s not like I’ll use any  
> > > > of them in everyday programming, but it would be good to know where the  
> > > > limit of ATS’s ability is.
> > > > 2. The overall syntax. Syntax is a more personal thing, but I do  
> > > > like ATS’s syntax a lot. Part of it might be that I hate languages using  
> > > > curly braces as code block delimiters (e.g. C/C++/Java/Go). “begin” and  
> > > > “end” stand out more visibly than those thin curly braces, and it’s easier  
> > > > to see if they are aligned or not. One thing which beginners may find  
> > > > confusing is that the same symbol may have very different meanings, for  
> > > > example “” and “{}”. In future versions of the programming guide we may  
> > > > want to emphasis on how to easily distinguish the different uses.
> > > > 3. The compiling process. As I said before, compiling to C is a big  
> > > > selling point. The generated C code is vastly clearer than what I can get  
> > > > from Haskell or Chicken Scheme. That said, I still think it could be made  
> > > > even more readable. Ideally, an ATS program written in imperative style  
> > > > should generate virtually identical C code. Currently the C code use a lot  
> > > > of inline functions to express (I think) the virtual instruction set of the  
> > > > compiler’s backend. It would be great if we could eliminate this layer and  
> > > > just output plain, boring C. Those inline functions are less readable, and  
> > > > they may be more troublesome to work with in a debugger. Although if you  
> > > > look at the final assembly code, they are tight enough, just looking at the  
> > > > C code and get an idea of how it works is much easier. The generated code  
> > > > also have a lot of extra comments. They are useful in large projects, but  
> > > > beginners usually start from writing small programs, so keeping it lean and  
> > > > mean in simple cases will be helpful.
> > > > 4. Another one of my wishes is a command line option to generate a  
> > > > standalone C program in source form, independent of any object files or  
> > > > libraries. I know there is a way to achieve that by including all the  
> > > > needed dynamic sources, but that’s too much work, not to mention you have  
> > > > to know which files to include. Pure C sources are more portable,  
> > > > especially if you need to embed the generated C code in places where  
> > > > linking user land libraries is prohibited (e.g. OS kernels, device  
> > > > drivers). Combined with point 3, it can also show those doubtful C  
> > > > programmers that there really is no magic nor dirty tricks. It would be a  
> > > > big win.
> > > > 5. Those relocation strings embedded in the object files, they are  
> > > > long and unreadable Sometimes they cause problems in the building process.  
> > > > I wonder if there is a better way to do that.
> > > > 6. Can we combine atscc and atsopt into one single command? I do  
> > > > not see the point of keeping them as two separate commands.
> > > > 7. GMP is nice, but it’s also a heavy weight dependency. I  
> > > > personally would like to see the support of infinite precision arithmetic  
> > > > as a library, not a built-in, and keep the basic data types isometric to  
> > > > C’s. Otherwise, I’d like to know how to avoid using its functionalities in  
> > > > my own code, so that at least the generated C code can run in environments  
> > > > where GMP is not available.
> > > > 8. The same for exception handling support. It’s useful, but  
> > > > sometimes you want to disable it in low-leve code.
> > > > 9. Now, back to the fine points of the syntax. My starting point  
> > > > is, if we really want to win the imperative programmers’ hearts, we have to  
> > > > make the syntax easy for them. If we also want to teach them to write  
> > > > correctness proofs, we’ll need to make that part’s syntax easy, too.
> > > > 10. I understand why tail-recursion is great, and ATS can compile  
> > > > them into loops if you write them in the right way, but creating nested  
> > > > functions just to express a simple loop is pedantic. You need to invent new  
> > > > names for the nested functions, and you also need to declare their types  
> > > > and parameters, and repeat the parameter list again when you call them.  
> > > > It’s way too verbose, for little benefit. Simply saying writing programs  
> > > > this way fits well into ATS’s big picture is just not convincing enough. If  
> > > > one of the major causes of verbosity in real life ATS code. I don’t know  
> > > > how difficult it will be, but can we make the compiler smart enough to  
> > > > compile imperative for/while better? Can we figure out a way to attach  
> > > > termination metrics to for/while loops and do not lose the theorem proving  
> > > > power? If we can convert from tail-calls to loops, why can’t we work  
> > > > backwards? Can we have goto?
> > > > 11. Most, if not all, examples in the programming guide, and all  
> > > > the ATS programs I can find in the Computer Language Benchmarks Game are  
> > > > deliberately written in a very verbose way. I know it’s meant to show more  
> > > > features of ATS and to teach beginners, and I know they can be much shorter  
> > > > if you want, but new comers do not know. I’ve heard people saying that they  
> > > > find ATS promising but are scared away by its “verbosity”. Well, if that  
> > > > were the most concise form of ATS programs, I’d be driven away, too.  
> > > > Working programmers hate verbosity. I agree a reasonable amount of  
> > > > verbosity if good, but there should be a limit. People hate ADA or Java for  
> > > > a reason. It’s nothing wrong to reveal the concise style to beginners  
> > > > gradually, but we have to at least show them several concise examples  
> > > > first, so that they can know there is a heaven and they can eventually get  
> > > > there. If God only shows us the Inferno, nobody will follow him. We need to  
> > > > make code examples short.
> > > > 12. One big reason I like ATS is that it’s not as dogmatic as some  
> > > > other functional programming languages. Its syntax is both inclusive and  
> > > > flexible. However, after all those nice additions, at some point we may  
> > > > want to take some time to re-examine the whole syntax, and see if there is  
> > > > something rarely used that we can remove. For example, I think some ML  
> > > > derived syntax can be removed or at least deprecated. Our goal is to win  
> > > > over C/C++ programmers, so “&&” makes sense and “andalso” does not. Maybe  
> > > > we can even remove “begin”, as in Ocaml (but not “;;”). I personally also  
> > > > do not like the “(\* comment \*)” syntax. Not that there is anything wrong in  
> > > > itself, but they are too similar to "()"s, especially when you write code  
> > > > like “nil of ((_nothing_))”. Syntax-highighting text editors do help, but  
> > > > still it’s some legacy from ATS’s ML root. But that’s just my personal  
> > > > preference. I’d like to hear what other C programmers would say.
> > > > 13. There are other minor points where I think  
> > > > readability/usability can be improved. I don’t like the “+” in “case+”.  
> > > > Small, single character symbols like “+” and “-” are just too small to be  
> > > > seen clearly, and if you make a typo, it’s harder to detect. I suggest we  
> > > > get some statistics on which kind of case clauses is more useful in real  
> > > > world code, make it the default, and give the unpopular one a more verbose  
> > > > name. Another one is the dereference operator “!”. It’s too thin and too  
> > > > similar to “1” and “i”. C’s “\*” is way more readable. Also “fnx”. The “x”  
> > > > is too small and too easy to mistype. I personally have no problem with the  
> > > > “@” in “t@ype”, although “@type” might be easier to type. Of course, these  
> > > > fine points are all cosmetic inconveniences, I can just live with them.
> > > > 14. A big topic would be the statics/theorem proving syntax. The  
> > > > current model is technically simple and straightforward, probably more  
> > > > familiar to former Prolog programmers, but hard to use. If we want people  
> > > > to write more proofs, we must make it easy. If you look at those successful  
> > > > theorem provers, for example Coq or Mizar, you don’t need to write  
> > > > “MUL(m,n,p)”, just something like “m\*n=p”. Learning to write proofs is  
> > > > already difficult enough for most programmers, and if the syntax is  
> > > > inhuman, they may just run from it. The goal of ATS is to let programmers  
> > > > write programs and proofs together, but that doesn’t mean they have to be  
> > > > written in the same language. Mixing the two things together, we are  
> > > > risking to make both tasks more difficult than necessary. Currently, I  
> > > > think some syntax sugar for statics might be helpful. My understanding is  
> > > > that ATS already has enough flexibility to do this, with macros and  
> > > > operator overloading/fixity declaration. If so, we can build up a layer of  
> > > > nice syntax and make it default in prelude, so that people do not need to  
> > > > deal with low-level, Prolog-like propositions directly. Well, even Prolog  
> > > > let you do this.
> > > > 15. We may also consider making theorem proving related keywords  
> > > > more clear. For example simply use “lemma” for “prfun”, “axiom” for  
> > > > “praxi”, etc. For someone smart enough to learn ATS, these words shouldn’t  
> > > > be too strange to them, yet they are more readable and indicating their  
> > > > purposes better. I’d like to hear more input from other users on this.
> > > > 16. Enough ranting on syntax. I want to emphasis that all that  
> > > > said, ATS’s syntax is still my personal single favorite among all the  
> > > > programming languages I know (I do know a lot of them). The design is very  
> > > > beautiful and tasteful. It’s a piece of art.
> > > > 17. Can we combine .sats and .dats files? I’m not sure if that’s  
> > > > feasible, but I find cross-referencing between two files is tiring, even if  
> > > > with help from tagging systems. A combined .ats file format will be simpler  
> > > > and easier to organize.
> > > > 
> > > > That’s about all I want to say so far, given my limited experience with  
> > > > the language. Finally I want to thank Professor Xi for creating such a  
> > > > beautiful programming language. As I said I know a lot of programming  
> > > > languages. ATS is unique. Compared with ATS, Haskell is at least 10 years  
> > > > behind, and C++ is about 30 years behind. Had Bjarne Stroustrup created not  
> > > > C++ but ATS in the 1980s, our industry would have been a totally different  
> > > > world. I can see a future of C++ being swiped away by ATS, and that future  
> > > > is nigh. Let’s start to work.
> > > > 
> > > > On Tuesday, December 17, 2013 5:11:10 PM UTC-6, Ming Lei wrote:
> > > > 
> > > > > Chairman Mao once said,
> > > > > 
> > > > > “Who are our enemies? Who are our friends? This is a question of the  
> > > > > first importance for the revolution.”
> > > > > 
> > > > > ATS is a revolution, but a programming language lives and dies with  
> > > > > its community. A weak language with a strong community wins over a strong  
> > > > > language with a weak community every time. Where is our community? How can  
> > > > > we grow it? Technical works aside, I’d say building up a community is our  
> > > > > top priority.
> > > > > 
> > > > > We don’t have many ATS programmers around, yet. The best source of new  
> > > > > blood for this community shall be its target users. “Expert programmers who  
> > > > > want to become more productive in writing high-quality code” is still too  
> > > > > general. I don’t think a Web developer using Ruby on Rails is ATS’s target  
> > > > > user, at least not in near future. ATS is good for low-level,  
> > > > > high-performance programming tasks where correctness must be ensured. This  
> > > > > may include:
> > > > > 
> > > > > 1. Scientific computing. Numerical stability and logical soundness  
> > > > > are important. I have friends working on computational biological problems,  
> > > > > using Haskell. The majority of this industry is still using C/C++ or  
> > > > > FORTRAN.
> > > > > 2. Financial computing. A bug can cost millions of dollars.  
> > > > > Several firms in this industry is already adopting Haskell or Ocaml,  
> > > > > although C++ is still dominating, especially in the HFT section, obviously  
> > > > > for performance reasons.
> > > > > 3. Security and cryptography. Formal methods are getting popular,  
> > > > > but there is a huge gap between their formal proofs and high-performance C  
> > > > > code. We see trivial overflow bugs everyday.
> > > > > 4. Game development. Modern games are too complex. They also need  
> > > > > to deal with tricky concurrent/parallel programming problems. John Carmack  
> > > > > is trying Haskell, but ATS should be a much better choice.
> > > > > 5. Electronics and hardware/software interface. Device drivers,  
> > > > > video codecs, firmware, embedded/realtime operating systems, they can all  
> > > > > benefit from strong typing and formal proofs.
> > > > > 6. Military, medical, these I’m not familiar with, but they all  
> > > > > use old fashioned imperative languages.
> > > > > 
> > > > > Unfortunately, people in these fields are more conservative and  
> > > > > skeptical. They will not believe you unless you show them undeniable hard  
> > > > > evidence. They also hate to learn new languages. However, compared to  
> > > > > languages like Haskell or Ocaml, ATS not only has a much more powerful type  
> > > > > system, but also can be compiled to straightforward C code. This is our big  
> > > > > selling point.
> > > > > 
> > > > > We can not just wait for them to come and learn ATS. We need to  
> > > > > actively reach out, show them who great ATS is, listen to their concerns  
> > > > > and improve ATS accordingly. We need to reduce the difficulty for them to  
> > > > > enter this new world. Specifically, I have several ideas in mind:
> > > > > 
> > > > > 1. Professor Xi needs to communicate his big ideas and roadmap to  
> > > > > the community. If they only stay in his head, other people can not help.  
> > > > > What’s the difference between ATS 1 and 2? What new features can we expect?  
> > > > > People need to know the big picture.
> > > > > 2. Make a formal specification of ATS’s entire grammar. It needn’t  
> > > > > to be as readable as the Haskell 98 language report. Even as simple as an  
> > > > > EBNF can be hugely helpful. The language guide is far from completed yet,  
> > > > > so a formal grammar would be the only way for new comers to learn the whole  
> > > > > language, except reading the source code. Undocumented syntax wastes  
> > > > > everyone’s time. With a specification, we can try test cases, know which  
> > > > > works and which not, we can even contribute some fixes to the core  
> > > > > language. Without it we don’t even know where to start.
> > > > > 3. Finish the outline of the language guide ASAP. List all the  
> > > > > chapters to be written, write a brief summary for each one. Give people a  
> > > > > easy way to contribute to the documentation, so that they can fill it up.
> > > > > 4. People who can hack the compiler should stop spending too much  
> > > > > time on contributed libraries. Their energy is too valuable and they should  
> > > > > focus on the fundamentals. Nobody wants to write libraries with an  
> > > > > unreliable compiler. Please let other people write the libraries. They have  
> > > > > more domain knowledge and they can learn the language in the process.
> > > > > 5. Update the language’s official Web site. It’s too shabby now.  
> > > > > People do judge a language by its face. ATS is at least 30 years ahead of  
> > > > > mainstream languages, but its Web site looks to be 30 years behind. Make it  
> > > > > pretty, usable and informative, update it timely. Bonus point for writing  
> > > > > its backend in ATS.
> > > > > 6. Migrate all the remaining source code and downloadable stuff  
> > > > > away from SourceForge. SourceForge’s reputation is not good, and its  
> > > > > usability is worse. People may think ATS is dying with SourceForge. We can  
> > > > > just move ATS1’s source code to GitHub and move the downloadable packages  
> > > > > to the Web site.
> > > > > 7. Fix the trivial bugs in the build system and make it work well  
> > > > > on all the supported platforms. Encourage Linux distribution packagers /  
> > > > > Mac OS X ports maintainers to include ATS in their releases.
> > > > > 8. Separate the contribution libraries from the compiler itself.  
> > > > > Make a real online libraries repository similar to CPAN, RubyForge or NPM,  
> > > > > so people can freely share useful libraries with each other. Such a  
> > > > > repository is invaluable for a programming language. It’s an online  
> > > > > presence, a social place, and a place to demonstrate how the language works  
> > > > > in real life to curious lookers. This is very important.
> > > > > 9. Then we can use all our connections in the industry to advocate  
> > > > > ATS, ask our friends to try it, and eventually build one or two killer  
> > > > > applications with it, which is how every successful programming language  
> > > > > grows up.
> > > > > 
> > > > > All of these are non-technical ideas. I will summarize some of my  
> > > > > thoughts on the technical side in another post.
> > > > > 
> > > > > On Tuesday, December 17, 2013 8:34:47 AM UTC-6, gmhwxi wrote:
> > > > > 
> > > > > > First, I would really like to see that ATS gets used by more and more  
> > > > > > programmers, and I welcome suggestions of all sorts on making this a  
> > > > > > reality.
> > > > > > 
> > > > > > I do not see ATS as a programming language for the general public.  
> > > > > > Instead,  
> > > > > > it targets expert programmers who want to become more productive in  
> > > > > > writing  
> > > > > > high-quality code.
> > > > > > 
> > > > > > Compilation of templates in ATS2 is not yet finished. It is my first  
> > > > > > priority  
> > > > > > to get template compilation done properly.
> > > > > > 
> > > > > > As always, documentation needs to be added and improved. I need a lot  
> > > > > > of  
> > > > > > help for this.
> > > > > > 
> > > > > > I really want to see other people working on ATS-contrib besides me  
> > > > > > alone.
> > > > > > 
> > > > > > > > Otherwise, we should all face the cold, hard reality and get some  
> > > > > > > > real work done.
> > > > > > 
> > > > > > What kind work do you have in mind?
> > > > > > 
> > > > > > On Tuesday, December 17, 2013 1:27:11 AM UTC-5, Ming Lei wrote:
> > > > > > 
> > > > > > > This question is for Professor Xi, but it’s probably also for  
> > > > > > > everyone here.
> > > > > > > 
> > > > > > > I like ATS, but where is ATS heading to?
> > > > > > > 
> > > > > > > Will it remain in ivory tower as a teaching/thesis-generating tool  
> > > > > > > forever, or will it ever grow up to be a real industrial language?
> > > > > > > 
> > > > > > > Every time I look at the very much incomplete documentation, every  
> > > > > > > time I see Professor Xi himself updating some libraries in /contrib on  
> > > > > > > GitHub, I want to ask these questions.
> > > > > > > 
> > > > > > > If the language’s creator just want it to remain to be an academic  
> > > > > > > toy, so be it and it’s fine, as he has all the rights in the world.
> > > > > > > 
> > > > > > > Otherwise, we should all face the cold, hard reality and get some  
> > > > > > > real work done.

---

<div class="post-metadata">

**Author:** ![Brandon\_Barker](https://sea1.discourse-cdn.com/flex019/user_avatar/discourse.ats-lang.org/brandon_barker/32/61_2.png) [@Brandon\_Barker](https://discourse.ats-lang.org/u/Brandon_Barker)\
**Post date:** [December 30, 2013, 4:04am UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55/4 "2013-12-30T04:04:47Z")

</div>

It may be worth linking to the wiki on [sf.net](http://sf.net) from  
[http://www.ats-lang.org](http://www.ats-lang.org) since  
people are missing it. Alternatively, if people do not like [sf.net](http://sf.net) (or its  
wiki), maybe an installation of media-wiki would be a better place for  
users to contribute code snippets and explanations. Much of what is on the  
[sf.net](http://sf.net) wiki could be easily copied over, though much of it would be best  
updated to strictly talk about ATS2 unless explicitly noted.

Brandon Barker  
brandon…@gmail.comOn Tue, Dec 17, 2013 at 11:34 PM, Ian Denhardt [i...@zenhack.net](mailto:i...@zenhack.net) wrote:

> Great post. There’s a lot of good stuff here. Specific comments are inline.
> 
> Quoting Ming Lei (2013-12-17 18:11:10)
> 
> > ```
> > 5. Electronics and hardware/software interface. Device drivers, video
> > codecs, firmware, embedded/realtime operating systems, they can
> > 
> > ```
> 
> all
> 
> > ```
> > benefit from strong typing and formal proofs.
> > 
> > ```
> 
> I would add to this the more general cateogry of systems software - not  
> just drivers and embedded operating systems, but operating systems more  
> broadly, as well as high performance network servers, language  
> runtimes…
> 
> > ```
> > 2. Make a formal specification of ATSs entire grammar. It neednt to
> > 
> > ```
> 
> be
> 
> > ```
> > as readable as the Haskell 98 language report. Even as simple as
> > 
> > ```
> 
> an
> 
> > ```
> > EBNF can be hugely helpful. The language guide is far from
> > completed yet, so a formal grammar would be the only way for new
> > comers to learn the whole language, except reading the source
> > 
> > ```
> 
> code.
> 
> Yes. I can’t stress this enough: having key parts of how the language  
> is used not written down anywhere is unacceptable.
> 
> There’s a heading somewhere on [ats-lang.org](http://ats-lang.org) re: a formal grammar, but  
> the section isn’t actually there…
> 
> > ```
> > 5. Update the languages official Web site. Its too shabby now. People
> > do judge a language by its face. ATS is at least 30 years ahead of
> > mainstream languages, but its Web site looks to be 30 years
> > 
> > ```
> 
> behind.
> 
> Irrespective of design, it’s often less than helpful. Apparently there’s  
> a wiki that some people have contributed to. I found out a bout this  
> when someone mentioned it on this list; the website doesn’t even mention  
> it! There needs to be more attention paid to making sure the first page  
> people land on gets them where they need to go.
> 
> I actually think we should offload most of that sort of thing to a wiki  
> somewhere. There’s too much overhead in contributing to this sort of  
> thing right now. Better documentation is a must, but it’s also a big  
> job. We need to use tools that make it easy for people to help out.
> 
> > ```
> > Make it pretty, usable and informative, update it timely. Bonus
> > point for writing its backend in ATS.
> > 
> > ```
> 
> It’s pretty much static html now, and I think that’s actually the way to  
> go; not much backend to be had (web servers and operating systems I  
> suppose, but that’s orthogonal to this one site).
> 
> > ```
> > 6. Migrate all the remaining source code and downloadable stuff away
> > from SourceForge. SourceForges reputation is not good, and its
> > usability is worse. People may think ATS is dying with
> > 
> > ```
> 
> SourceForge.
> 
> > ```
> > We can just move ATS1s source code to GitHub and move the
> > downloadable packages to the Web site.
> > 
> > ```
> 
> Might still be acceptable for downloading tarballs, but that’s about all  
> I see most people using it for these days, and with good reason.
> 
> > ```
> > 7. Fix the trivial bugs in the build system and make it work well on
> > all the supported platforms. Encourage Linux distribution
> > 
> > ```
> 
> packagers
> 
> > ```
> > / Mac OS X ports maintainers to include ATS in their releases.
> > 
> > ```
> 
> Specific recommendation: choose names for the tarballs and folders that  
> agree with package naming guidelines in major distributions. This  
> usually means no uppercase letters at the very least. It’s not something  
> that’s ever stopped me from packaging something, but it’s a pet peeve.
> 
> > ```
> > 8. Separate the contribution libraries from the compiler itself. Make
> > a real online libraries repository similar to CPAN, RubyForge or
> > NPM, so people can freely share useful libraries with each other.
> > 
> > ```
> 
> Absolutely. I’d also point out that having a standard build system for  
> things written in ATS would make this a lot easier. It’s also something  
> that needs attention on its own. We don’t need another language where  
> build systems are as messy as they are for C/C++.
> 
> * * *
> 
> One additional comment, not immediately related to anything Ming Lei  
> mentioned: a mailing list is not a bug tracker. There’s a lot of  
> improvements to make to ATS, and for anyone but Prof. Xi to try to  
> tackle them, we need a more organized way of managing them. We need a  
> real bug tracker.
> 
> I’d propose, as a start, make an organization on github, move the  
> existing git repos and the wiki to it, and start using the bug tracker.
> 
> -Ian
> 
> –  
> 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](mailto:ats-lang-user...@googlegroups.com).  
> To post to this group, send email to [ats-lan...@googlegroups.com](mailto:ats-lan...@googlegroups.com).  
> To view this discussion on the web visit  
> [https://groups.google.com/d/msgid/ats-lang-users/20131218043450.2622.94760%40nomad](https://groups.google.com/d/msgid/ats-lang-users/20131218043450.2622.94760%40nomad)  
> .

---

<div class="post-metadata">

**Author:** ![Brandon\_Barker](https://sea1.discourse-cdn.com/flex019/user_avatar/discourse.ats-lang.org/brandon_barker/32/61_2.png) [@Brandon\_Barker](https://discourse.ats-lang.org/u/Brandon_Barker)\
**Post date:** [May 15, 2014, 2:53am UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55/5 "2014-05-15T02:53:36Z")

</div>

I feel that I’ve been programming in ATS for a while now - not as much as I  
would like admittedly. I agree with most of Ming’s points regarding  
clarity, so I just want to emphasize a couple of the ones that I feel most  
strongly about and most confident that something could be done without  
impinging on the spirit and core implementation of ATS.

The language is difficult for many reasons, and perhaps it must be. So we  
should focus on what can be made less difficult: which of the biggest gaps  
in difficulty can be closed.

Aside from teaching materials, lack of documentation has been brought up  
many times. If you do enough grepping, you are likely to get what you need  
in terms of documentation. I’m starting to feel documentation is adequate  
in many ways, though there are some gaps. However, unlike in C, I would  
argue that the types in the ATS standard library are far more abundant.  
There are many types for integers (and I don’t mean int(n) versus int(n+1).  
This coupled with not knowing what types we are looking for makes the  
process much slower than going to [cplusplus.com](http://cplusplus.com) and checking out how to  
call atoi (or typing “convert char to int” in google and clicking the first  
stack overflow post).

To get around this problem, it might be nice to have software (possibly  
relying on atsopt) that can find a path from one type to another  
(preferably the shortest path), and then output the function composition  
required for such a type conversion. This process might be at the core, but  
you could also have an open ended type conversion: for instance, using the  
available ATS packages on your system, what types can you get to from an  
“int” in 1, 2, or 3 function applications? This could be integrated into an  
IDE in a simpler way - just look at all adjacent types. Eclipse and other  
IDEs (even IPython) let you tab-complete the field name of an object. Has  
anyone done similar for functional programming: tab-complete a type to list  
possible function applications (again, possibly narrowed by the destination  
type).

Maybe I’m crazy and too nitpicky with this, or maybe this is really hard.  
Or maybe people have already done this for other systems. ATS has tons of  
types, and I feel like we need to get a grip on them somehow.

Along these lines, a related issue that could be mitigated by renaming:  
many types’ names in ATS are encoded g1int, g0int, string0, string1  
(string2?), etc. ATS is already a verbose language so I completely  
understand the desire to keep names somewhat short, but I have to wonder if  
more thought on this point might be warranted, as name encoding is another  
layer of difficulty added to an already potentially rather larger learning  
hurdle. I don’t think the C standardlibrary functions are very well named  
at all (strtok? atoi? yeah once you know what they are, you can remember  
them), but there simply seems to be far fewer C functions we need to know  
than ATS functions, so this is a limiting factor in learning, amplified by  
having many similar functions for slightly different types.

In summary, I think a priority is that our dev/autodoc tools need to catch  
up to ATS. I don’t have much experience in this area for other programming  
languages, so it will be nice to hear seasoned developers chime in as well.

And I say all of this from my relatively limited software engineering  
experience and with the hope of starting some discussion and maybe projects  
for ATS development. So if I’m missing the mark somewhere, please say so.On Wednesday, December 18, 2013 9:28:26 PM UTC-5, Ming Lei wrote:

> Thanks for bearing with me. I have only about two weeks of experience with  
> ATS, but I’ll speak from my beginner’s point of view anyway, and hopefully  
> more experienced people will join me.
> 
> 1. The type system. I’m no expert in type systems, but to me it’s just  
> the best in any practical programming languages available today. Not only  
> does it help me detect bugs, it also forces me to think as clearly as  
> possible. If you can make a stupid computer understand the idea of your  
> program, by writing the proofs in a highly logical way, the chance of bugs  
> is little. I have nothing to complain for now. I just want to see more  
> examples on how to deal with heterogeneous lists, variadic arguments and  
> other difficult things such as the Y combinator. It’s not like I’ll use any  
> of them in everyday programming, but it would be good to know where the  
> limit of ATS’s ability is.
> 2. The overall syntax. Syntax is a more personal thing, but I do like  
> ATS’s syntax a lot. Part of it might be that I hate languages using curly  
> braces as code block delimiters (e.g. C/C++/Java/Go). “begin” and “end”  
> stand out more visibly than those thin curly braces, and it’s easier to see  
> if they are aligned or not. One thing which beginners may find confusing is  
> that the same symbol may have very different meanings, for example “” and  
> “{}”. In future versions of the programming guide we may want to emphasis  
> on how to easily distinguish the different uses.
> 3. The compiling process. As I said before, compiling to C is a big  
> selling point. The generated C code is vastly clearer than what I can get  
> from Haskell or Chicken Scheme. That said, I still think it could be made  
> even more readable. Ideally, an ATS program written in imperative style  
> should generate virtually identical C code. Currently the C code use a lot  
> of inline functions to express (I think) the virtual instruction set of the  
> compiler’s backend. It would be great if we could eliminate this layer and  
> just output plain, boring C. Those inline functions are less readable, and  
> they may be more troublesome to work with in a debugger. Although if you  
> look at the final assembly code, they are tight enough, just looking at the  
> C code and get an idea of how it works is much easier. The generated code  
> also have a lot of extra comments. They are useful in large projects, but  
> beginners usually start from writing small programs, so keeping it lean and  
> mean in simple cases will be helpful.
> 4. Another one of my wishes is a command line option to generate a  
> standalone C program in source form, independent of any object files or  
> libraries. I know there is a way to achieve that by including all the  
> needed dynamic sources, but that’s too much work, not to mention you have  
> to know which files to include. Pure C sources are more portable,  
> especially if you need to embed the generated C code in places where  
> linking user land libraries is prohibited (e.g. OS kernels, device  
> drivers). Combined with point 3, it can also show those doubtful C  
> programmers that there really is no magic nor dirty tricks. It would be a  
> big win.
> 5. Those relocation strings embedded in the object files, they are  
> long and unreadable Sometimes they cause problems in the building process.  
> I wonder if there is a better way to do that.
> 6. Can we combine atscc and atsopt into one single command? I do not  
> see the point of keeping them as two separate commands.
> 7. GMP is nice, but it’s also a heavy weight dependency. I personally  
> would like to see the support of infinite precision arithmetic as a  
> library, not a built-in, and keep the basic data types isometric to C’s.  
> Otherwise, I’d like to know how to avoid using its functionalities in my  
> own code, so that at least the generated C code can run in environments  
> where GMP is not available.
> 8. The same for exception handling support. It’s useful, but sometimes  
> you want to disable it in low-leve code.
> 9. Now, back to the fine points of the syntax. My starting point is,  
> if we really want to win the imperative programmers’ hearts, we have to  
> make the syntax easy for them. If we also want to teach them to write  
> correctness proofs, we’ll need to make that part’s syntax easy, too.
> 10. I understand why tail-recursion is great, and ATS can compile them  
> into loops if you write them in the right way, but creating nested  
> functions just to express a simple loop is pedantic. You need to invent new  
> names for the nested functions, and you also need to declare their types  
> and parameters, and repeat the parameter list again when you call them.  
> It’s way too verbose, for little benefit. Simply saying writing programs  
> this way fits well into ATS’s big picture is just not convincing enough. If  
> one of the major causes of verbosity in real life ATS code. I don’t know  
> how difficult it will be, but can we make the compiler smart enough to  
> compile imperative for/while better? Can we figure out a way to attach  
> termination metrics to for/while loops and do not lose the theorem proving  
> power? If we can convert from tail-calls to loops, why can’t we work  
> backwards? Can we have goto?
> 11. Most, if not all, examples in the programming guide, and all the  
> ATS programs I can find in the Computer Language Benchmarks Game are  
> deliberately written in a very verbose way. I know it’s meant to show more  
> features of ATS and to teach beginners, and I know they can be much shorter  
> if you want, but new comers do not know. I’ve heard people saying that they  
> find ATS promising but are scared away by its “verbosity”. Well, if that  
> were the most concise form of ATS programs, I’d be driven away, too.  
> Working programmers hate verbosity. I agree a reasonable amount of  
> verbosity if good, but there should be a limit. People hate ADA or Java for  
> a reason. It’s nothing wrong to reveal the concise style to beginners  
> gradually, but we have to at least show them several concise examples  
> first, so that they can know there is a heaven and they can eventually get  
> there. If God only shows us the Inferno, nobody will follow him. We need to  
> make code examples short.
> 12. One big reason I like ATS is that it’s not as dogmatic as some  
> other functional programming languages. Its syntax is both inclusive and  
> flexible. However, after all those nice additions, at some point we may  
> want to take some time to re-examine the whole syntax, and see if there is  
> something rarely used that we can remove. For example, I think some ML  
> derived syntax can be removed or at least deprecated. Our goal is to win  
> over C/C++ programmers, so “&&” makes sense and “andalso” does not. Maybe  
> we can even remove “begin”, as in Ocaml (but not “;;”). I personally also  
> do not like the “(\* comment \*)” syntax. Not that there is anything wrong in  
> itself, but they are too similar to "()"s, especially when you write code  
> like “nil of ((_nothing_))”. Syntax-highighting text editors do help, but  
> still it’s some legacy from ATS’s ML root. But that’s just my personal  
> preference. I’d like to hear what other C programmers would say.
> 13. There are other minor points where I think readability/usability  
> can be improved. I don’t like the “+” in “case+”. Small, single character  
> symbols like “+” and “-” are just too small to be seen clearly, and if you  
> make a typo, it’s harder to detect. I suggest we get some statistics on  
> which kind of case clauses is more useful in real world code, make it the  
> default, and give the unpopular one a more verbose name. Another one is the  
> dereference operator “!”. It’s too thin and too similar to “1” and “i”. C’s  
> “\*” is way more readable. Also “fnx”. The “x” is too small and too easy to  
> mistype. I personally have no problem with the “@” in “t@ype”, although  
> “@type” might be easier to type. Of course, these fine points are all  
> cosmetic inconveniences, I can just live with them.
> 14. A big topic would be the statics/theorem proving syntax. The  
> current model is technically simple and straightforward, probably more  
> familiar to former Prolog programmers, but hard to use. If we want people  
> to write more proofs, we must make it easy. If you look at those successful  
> theorem provers, for example Coq or Mizar, you don’t need to write  
> “MUL(m,n,p)”, just something like “m\*n=p”. Learning to write proofs is  
> already difficult enough for most programmers, and if the syntax is  
> inhuman, they may just run from it. The goal of ATS is to let programmers  
> write programs and proofs together, but that doesn’t mean they have to be  
> written in the same language. Mixing the two things together, we are  
> risking to make both tasks more difficult than necessary. Currently, I  
> think some syntax sugar for statics might be helpful. My understanding is  
> that ATS already has enough flexibility to do this, with macros and  
> operator overloading/fixity declaration. If so, we can build up a layer of  
> nice syntax and make it default in prelude, so that people do not need to  
> deal with low-level, Prolog-like propositions directly. Well, even Prolog  
> let you do this.
> 15. We may also consider making theorem proving related keywords more  
> clear. For example simply use “lemma” for “prfun”, “axiom” for “praxi”,  
> etc. For someone smart enough to learn ATS, these words shouldn’t be too  
> strange to them, yet they are more readable and indicating their purposes  
> better. I’d like to hear more input from other users on this.
> 16. Enough ranting on syntax. I want to emphasis that all that said,  
> ATS’s syntax is still my personal single favorite among all the programming  
> languages I know (I do know a lot of them). The design is very beautiful  
> and tasteful. It’s a piece of art.
> 17. Can we combine .sats and .dats files? I’m not sure if that’s  
> feasible, but I find cross-referencing between two files is tiring, even if  
> with help from tagging systems. A combined .ats file format will be simpler  
> and easier to organize.
> 
> That’s about all I want to say so far, given my limited experience with  
> the language. Finally I want to thank Professor Xi for creating such a  
> beautiful programming language. As I said I know a lot of programming  
> languages. ATS is unique. Compared with ATS, Haskell is at least 10 years  
> behind, and C++ is about 30 years behind. Had Bjarne Stroustrup created not  
> C++ but ATS in the 1980s, our industry would have been a totally different  
> world. I can see a future of C++ being swiped away by ATS, and that future  
> is nigh. Let’s start to work.
> 
> On Tuesday, December 17, 2013 5:11:10 PM UTC-6, Ming Lei wrote:
> 
> > Chairman Mao once said,
> > 
> > “Who are our enemies? Who are our friends? This is a question of the  
> > first importance for the revolution.”
> > 
> > ATS is a revolution, but a programming language lives and dies with its  
> > community. A weak language with a strong community wins over a strong  
> > language with a weak community every time. Where is our community? How can  
> > we grow it? Technical works aside, I’d say building up a community is our  
> > top priority.
> > 
> > We don’t have many ATS programmers around, yet. The best source of new  
> > blood for this community shall be its target users. “Expert programmers who  
> > want to become more productive in writing high-quality code” is still too  
> > general. I don’t think a Web developer using Ruby on Rails is ATS’s target  
> > user, at least not in near future. ATS is good for low-level,  
> > high-performance programming tasks where correctness must be ensured. This  
> > may include:
> > 
> > 1. Scientific computing. Numerical stability and logical soundness  
> > are important. I have friends working on computational biological problems,  
> > using Haskell. The majority of this industry is still using C/C++ or  
> > FORTRAN.
> > 2. Financial computing. A bug can cost millions of dollars. Several  
> > firms in this industry is already adopting Haskell or Ocaml, although C++  
> > is still dominating, especially in the HFT section, obviously for  
> > performance reasons.
> > 3. Security and cryptography. Formal methods are getting popular, but  
> > there is a huge gap between their formal proofs and high-performance C  
> > code. We see trivial overflow bugs everyday.
> > 4. Game development. Modern games are too complex. They also need to  
> > deal with tricky concurrent/parallel programming problems. John Carmack is  
> > trying Haskell, but ATS should be a much better choice.
> > 5. Electronics and hardware/software interface. Device drivers, video  
> > codecs, firmware, embedded/realtime operating systems, they can all benefit  
> > from strong typing and formal proofs.
> > 6. Military, medical, these I’m not familiar with, but they all use  
> > old fashioned imperative languages.
> > 
> > Unfortunately, people in these fields are more conservative and  
> > skeptical. They will not believe you unless you show them undeniable hard  
> > evidence. They also hate to learn new languages. However, compared to  
> > languages like Haskell or Ocaml, ATS not only has a much more powerful type  
> > system, but also can be compiled to straightforward C code. This is our big  
> > selling point.
> > 
> > We can not just wait for them to come and learn ATS. We need to actively  
> > reach out, show them who great ATS is, listen to their concerns and improve  
> > ATS accordingly. We need to reduce the difficulty for them to enter this  
> > new world. Specifically, I have several ideas in mind:
> > 
> > 1. Professor Xi needs to communicate his big ideas and roadmap to the  
> > community. If they only stay in his head, other people can not help. What’s  
> > the difference between ATS 1 and 2? What new features can we expect? People  
> > need to know the big picture.
> > 2. Make a formal specification of ATS’s entire grammar. It needn’t to  
> > be as readable as the Haskell 98 language report. Even as simple as an EBNF  
> > can be hugely helpful. The language guide is far from completed yet, so a  
> > formal grammar would be the only way for new comers to learn the whole  
> > language, except reading the source code. Undocumented syntax wastes  
> > everyone’s time. With a specification, we can try test cases, know which  
> > works and which not, we can even contribute some fixes to the core  
> > language. Without it we don’t even know where to start.
> > 3. Finish the outline of the language guide ASAP. List all the  
> > chapters to be written, write a brief summary for each one. Give people a  
> > easy way to contribute to the documentation, so that they can fill it up.
> > 4. People who can hack the compiler should stop spending too much  
> > time on contributed libraries. Their energy is too valuable and they should  
> > focus on the fundamentals. Nobody wants to write libraries with an  
> > unreliable compiler. Please let other people write the libraries. They have  
> > more domain knowledge and they can learn the language in the process.
> > 5. Update the language’s official Web site. It’s too shabby now.  
> > People do judge a language by its face. ATS is at least 30 years ahead of  
> > mainstream languages, but its Web site looks to be 30 years behind. Make it  
> > pretty, usable and informative, update it timely. Bonus point for writing  
> > its backend in ATS.
> > 6. Migrate all the remaining source code and downloadable stuff away  
> > from SourceForge. SourceForge’s reputation is not good, and its usability  
> > is worse. People may think ATS is dying with SourceForge. We can just move  
> > ATS1’s source code to GitHub and move the downloadable packages to the Web  
> > site.
> > 7. Fix the trivial bugs in the build system and make it work well on  
> > all the supported platforms. Encourage Linux distribution packagers / Mac  
> > OS X ports maintainers to include ATS in their releases.
> > 8. Separate the contribution libraries from the compiler itself. Make  
> > a real online libraries repository similar to CPAN, RubyForge or NPM, so  
> > people can freely share useful libraries with each other. Such a repository  
> > is invaluable for a programming language. It’s an online presence, a social  
> > place, and a place to demonstrate how the language works in real life to  
> > curious lookers. This is very important.
> > 9. Then we can use all our connections in the industry to advocate  
> > ATS, ask our friends to try it, and eventually build one or two killer  
> > applications with it, which is how every successful programming language  
> > grows up.
> > 
> > All of these are non-technical ideas. I will summarize some of my  
> > thoughts on the technical side in another post.
> > 
> > On Tuesday, December 17, 2013 8:34:47 AM UTC-6, gmhwxi wrote:
> > 
> > > First, I would really like to see that ATS gets used by more and more  
> > > programmers, and I welcome suggestions of all sorts on making this a  
> > > reality.
> > > 
> > > I do not see ATS as a programming language for the general public.  
> > > Instead,  
> > > it targets expert programmers who want to become more productive in  
> > > writing  
> > > high-quality code.
> > > 
> > > Compilation of templates in ATS2 is not yet finished. It is my first  
> > > priority  
> > > to get template compilation done properly.
> > > 
> > > As always, documentation needs to be added and improved. I need a lot of  
> > > help for this.
> > > 
> > > I really want to see other people working on ATS-contrib besides me  
> > > alone.
> > > 
> > > > > Otherwise, we should all face the cold, hard reality and get some real  
> > > > > work done.
> > > 
> > > What kind work do you have in mind?
> > > 
> > > On Tuesday, December 17, 2013 1:27:11 AM UTC-5, Ming Lei wrote:
> > > 
> > > > This question is for Professor Xi, but it’s probably also for everyone  
> > > > here.
> > > > 
> > > > I like ATS, but where is ATS heading to?
> > > > 
> > > > Will it remain in ivory tower as a teaching/thesis-generating tool  
> > > > forever, or will it ever grow up to be a real industrial language?
> > > > 
> > > > Every time I look at the very much incomplete documentation, every time  
> > > > I see Professor Xi himself updating some libraries in /contrib on GitHub, I  
> > > > want to ask these questions.
> > > > 
> > > > If the language’s creator just want it to remain to be an academic toy,  
> > > > so be it and it’s fine, as he has all the rights in the world.
> > > > 
> > > > Otherwise, we should all face the cold, hard reality and get some real  
> > > > work done.

---

<div class="post-metadata">

**Author:** ![Ming\_Lei](https://avatars.discourse-cdn.com/v4/letter/m/df705f/32.png) [@Ming\_Lei](https://discourse.ats-lang.org/u/Ming_Lei)\
**Post date:** [December 21, 2013, 2:37am UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55/6 "2013-12-21T02:37:19Z")

</div>

You are right. It’s more practical in this way.On Thursday, December 19, 2013 4:56:00 PM UTC-6, gmhwxi wrote:

> Maybe we were thinking along different lines.
> 
> What I had in mind was using ‘gcc -E’ to preprocess C-header files.  
> As long as gcc can find a header file, h2sats (the name of the tool)  
> should be able to turn it into a corresponding SATS file. Lines like the  
> following one can be put in a Makefile:
> 
> stdio.sats : ; h2sats [flags] stdio.h
> 
> On Thursday, December 19, 2013 3:49:06 PM UTC-5, Ming Lei wrote:
> 
> > On Thursday, December 19, 2013 11:00:13 AM UTC-6, gmhwxi wrote:
> > 
> > > Semantically, ATS and C are the same.
> > > 
> > > However, syntactically, I think that ATS and C should be kept very  
> > > distinct from each other.
> > 
> > I fully agree. There is no way to fit ATS into C’s tiny shoes anyway.  
> > That’s why there should still be "%{…%}"s to isolate the C code. ATS  
> > should never support the full C syntax natively.
> > 
> > > 
> > 
> > One possibility to support what you said is to write a tool that can
> > 
> > > automatically turn C header files into SATS files in ATS.
> > 
> > Haskell has such tools, but they never work as flawlessly as C++'s extern  
> > “C” statement. As far as I can remember, you still need to do a lot of  
> > manual work to make sure the output is correct. But they have good reasons,  
> > for Haskell is semantically very different from C.
> > 
> > The disadvantage of this kind of tools is that they not only add an extra  
> > layer of work, they also increase chances for compatibility bugs.
> > 
> > If the C header files to be included are bundled with the ATS source  
> > code, then a simple Makefile rule can solve the problem. If they are out of  
> > scope of the ATS source code, for example let’s say I want to include OS  
> > X’s system OpenGL header files. They are located at strange places, and  
> > Apple has the habit of moving them around with system updates. You can’t  
> > hardcode their paths in Makefile. You can not bundle the generated SATS  
> > with the other ATS source code either, because a system update may change  
> > some declarations in the C header files and make the generated SATS files  
> > out of sync. The same problems also exist in Linux systems, where package  
> > updates are more reckless.
> > 
> > Moreover, if we could make such a translation tool, and it could work  
> > flawlessly on C code, what prevents us from just embed this tool inside the  
> > ATS compiler? It shouldn’t be too big if we only need to parse the  
> > declarations.
> > 
> > > 
> > 
> > > 
> > 
> > > On Wednesday, December 18, 2013 11:28:48 PM UTC-5, Ming Lei wrote:
> > > 
> > > > It turns out, I forgot one important thing.
> > > > 
> > > > ```
> > > > 0. Make mixing ATS and C code as easy as possible. That means, 
> > > > 
> > > > ```
> > > > 
> > > > no more “#ext” and “#mac”. Just “%{ #include \<stdio.h\> }%” or something  
> > > > like that, and you can start to use the C definitions in ATS. Just like  
> > > > C++, ATS shares the native data types with C. If C++ can do it, ATS can do  
> > > > it too. Technically, that may mean embedding a C front end for parsing, but  
> > > > it’s totally worth the efforts. Potically, both ATS and GCC are licensed  
> > > > under GPLv3, so there is no problem either. As far as I know, none of the  
> > > > functional programming languages (except C++11, if you count it as a  
> > > > functional language) can do that, because they either use boxed/tagged data  
> > > > types by default (e.g. Ocaml, Common Lisp/Scheme, Haskell), or has poor  
> > > > support for imperative programming at machine level (e.g. Haskell, Scala).  
> > > > Not surprisingly, they all suffer from insufficient library support. ATS  
> > > > has the unique position of having the best from both worlds (functional,  
> > > > imperative, logic). With all the C libraries at its disposal, it’s destined  
> > > > to win.
> > > > 
> > > > On Wednesday, December 18, 2013 8:28:26 PM UTC-6, Ming Lei wrote:
> > > > 
> > > > > Thanks for bearing with me. I have only about two weeks of experience  
> > > > > with ATS, but I’ll speak from my beginner’s point of view anyway, and  
> > > > > hopefully more experienced people will join me.
> > > > > 
> > > > > 1. The type system. I’m no expert in type systems, but to me it’s  
> > > > > just the best in any practical programming languages available today. Not  
> > > > > only does it help me detect bugs, it also forces me to think as clearly as  
> > > > > possible. If you can make a stupid computer understand the idea of your  
> > > > > program, by writing the proofs in a highly logical way, the chance of bugs  
> > > > > is little. I have nothing to complain for now. I just want to see more  
> > > > > examples on how to deal with heterogeneous lists, variadic arguments and  
> > > > > other difficult things such as the Y combinator. It’s not like I’ll use any  
> > > > > of them in everyday programming, but it would be good to know where the  
> > > > > limit of ATS’s ability is.
> > > > > 2. The overall syntax. Syntax is a more personal thing, but I do  
> > > > > like ATS’s syntax a lot. Part of it might be that I hate languages using  
> > > > > curly braces as code block delimiters (e.g. C/C++/Java/Go). “begin” and  
> > > > > “end” stand out more visibly than those thin curly braces, and it’s easier  
> > > > > to see if they are aligned or not. One thing which beginners may find  
> > > > > confusing is that the same symbol may have very different meanings, for  
> > > > > example “” and “{}”. In future versions of the programming guide we may  
> > > > > want to emphasis on how to easily distinguish the different uses.
> > > > > 3. The compiling process. As I said before, compiling to C is a  
> > > > > big selling point. The generated C code is vastly clearer than what I can  
> > > > > get from Haskell or Chicken Scheme. That said, I still think it could be  
> > > > > made even more readable. Ideally, an ATS program written in imperative  
> > > > > style should generate virtually identical C code. Currently the C code use  
> > > > > a lot of inline functions to express (I think) the virtual instruction set  
> > > > > of the compiler’s backend. It would be great if we could eliminate this  
> > > > > layer and just output plain, boring C. Those inline functions are less  
> > > > > readable, and they may be more troublesome to work with in a debugger.  
> > > > > Although if you look at the final assembly code, they are tight enough,  
> > > > > just looking at the C code and get an idea of how it works is much easier.  
> > > > > The generated code also have a lot of extra comments. They are useful in  
> > > > > large projects, but beginners usually start from writing small programs, so  
> > > > > keeping it lean and mean in simple cases will be helpful.
> > > > > 4. Another one of my wishes is a command line option to generate a  
> > > > > standalone C program in source form, independent of any object files or  
> > > > > libraries. I know there is a way to achieve that by including all the  
> > > > > needed dynamic sources, but that’s too much work, not to mention you have  
> > > > > to know which files to include. Pure C sources are more portable,  
> > > > > especially if you need to embed the generated C code in places where  
> > > > > linking user land libraries is prohibited (e.g. OS kernels, device  
> > > > > drivers). Combined with point 3, it can also show those doubtful C  
> > > > > programmers that there really is no magic nor dirty tricks. It would be a  
> > > > > big win.
> > > > > 5. Those relocation strings embedded in the object files, they are  
> > > > > long and unreadable Sometimes they cause problems in the building process.  
> > > > > I wonder if there is a better way to do that.
> > > > > 6. Can we combine atscc and atsopt into one single command? I do  
> > > > > not see the point of keeping them as two separate commands.
> > > > > 7. GMP is nice, but it’s also a heavy weight dependency. I  
> > > > > personally would like to see the support of infinite precision arithmetic  
> > > > > as a library, not a built-in, and keep the basic data types isometric to  
> > > > > C’s. Otherwise, I’d like to know how to avoid using its functionalities in  
> > > > > my own code, so that at least the generated C code can run in environments  
> > > > > where GMP is not available.
> > > > > 8. The same for exception handling support. It’s useful, but  
> > > > > sometimes you want to disable it in low-leve code.
> > > > > 9. Now, back to the fine points of the syntax. My starting point  
> > > > > is, if we really want to win the imperative programmers’ hearts, we have to  
> > > > > make the syntax easy for them. If we also want to teach them to write  
> > > > > correctness proofs, we’ll need to make that part’s syntax easy, too.
> > > > > 10. I understand why tail-recursion is great, and ATS can compile  
> > > > > them into loops if you write them in the right way, but creating nested  
> > > > > functions just to express a simple loop is pedantic. You need to invent new  
> > > > > names for the nested functions, and you also need to declare their types  
> > > > > and parameters, and repeat the parameter list again when you call them.  
> > > > > It’s way too verbose, for little benefit. Simply saying writing programs  
> > > > > this way fits well into ATS’s big picture is just not convincing enough. If  
> > > > > one of the major causes of verbosity in real life ATS code. I don’t know  
> > > > > how difficult it will be, but can we make the compiler smart enough to  
> > > > > compile imperative for/while better? Can we figure out a way to attach  
> > > > > termination metrics to for/while loops and do not lose the theorem proving  
> > > > > power? If we can convert from tail-calls to loops, why can’t we work  
> > > > > backwards? Can we have goto?
> > > > > 11. Most, if not all, examples in the programming guide, and all  
> > > > > the ATS programs I can find in the Computer Language Benchmarks Game are  
> > > > > deliberately written in a very verbose way. I know it’s meant to show more  
> > > > > features of ATS and to teach beginners, and I know they can be much shorter  
> > > > > if you want, but new comers do not know. I’ve heard people saying that they  
> > > > > find ATS promising but are scared away by its “verbosity”. Well, if that  
> > > > > were the most concise form of ATS programs, I’d be driven away, too.  
> > > > > Working programmers hate verbosity. I agree a reasonable amount of  
> > > > > verbosity if good, but there should be a limit. People hate ADA or Java for  
> > > > > a reason. It’s nothing wrong to reveal the concise style to beginners  
> > > > > gradually, but we have to at least show them several concise examples  
> > > > > first, so that they can know there is a heaven and they can eventually get  
> > > > > there. If God only shows us the Inferno, nobody will follow him. We need to  
> > > > > make code examples short.
> > > > > 12. One big reason I like ATS is that it’s not as dogmatic as some  
> > > > > other functional programming languages. Its syntax is both inclusive and  
> > > > > flexible. However, after all those nice additions, at some point we may  
> > > > > want to take some time to re-examine the whole syntax, and see if there is  
> > > > > something rarely used that we can remove. For example, I think some ML  
> > > > > derived syntax can be removed or at least deprecated. Our goal is to win  
> > > > > over C/C++ programmers, so “&&” makes sense and “andalso” does not. Maybe  
> > > > > we can even remove “begin”, as in Ocaml (but not “;;”). I personally also  
> > > > > do not like the “(\* comment \*)” syntax. Not that there is anything wrong in  
> > > > > itself, but they are too similar to "()"s, especially when you write code  
> > > > > like “nil of ((_nothing_))”. Syntax-highighting text editors do help, but  
> > > > > still it’s some legacy from ATS’s ML root. But that’s just my personal  
> > > > > preference. I’d like to hear what other C programmers would say.
> > > > > 13. There are other minor points where I think  
> > > > > readability/usability can be improved. I don’t like the “+” in “case+”.  
> > > > > Small, single character symbols like “+” and “-” are just too small to be  
> > > > > seen clearly, and if you make a typo, it’s harder to detect. I suggest we  
> > > > > get some statistics on which kind of case clauses is more useful in real  
> > > > > world code, make it the default, and give the unpopular one a more verbose  
> > > > > name. Another one is the dereference operator “!”. It’s too thin and too  
> > > > > similar to “1” and “i”. C’s “\*” is way more readable. Also “fnx”. The “x”  
> > > > > is too small and too easy to mistype. I personally have no problem with the  
> > > > > “@” in “t@ype”, although “@type” might be easier to type. Of course, these  
> > > > > fine points are all cosmetic inconveniences, I can just live with them.
> > > > > 14. A big topic would be the statics/theorem proving syntax. The  
> > > > > current model is technically simple and straightforward, probably more  
> > > > > familiar to former Prolog programmers, but hard to use. If we want people  
> > > > > to write more proofs, we must make it easy. If you look at those successful  
> > > > > theorem provers, for example Coq or Mizar, you don’t need to write  
> > > > > “MUL(m,n,p)”, just something like “m\*n=p”. Learning to write proofs is  
> > > > > already difficult enough for most programmers, and if the syntax is  
> > > > > inhuman, they may just run from it. The goal of ATS is to let programmers  
> > > > > write programs and proofs together, but that doesn’t mean they have to be  
> > > > > written in the same language. Mixing the two things together, we are  
> > > > > risking to make both tasks more difficult than necessary. Currently, I  
> > > > > think some syntax sugar for statics might be helpful. My understanding is  
> > > > > that ATS already has enough flexibility to do this, with macros and  
> > > > > operator overloading/fixity declaration. If so, we can build up a layer of  
> > > > > nice syntax and make it default in prelude, so that people do not need to  
> > > > > deal with low-level, Prolog-like propositions directly. Well, even Prolog  
> > > > > let you do this.
> > > > > 15. We may also consider making theorem proving related keywords  
> > > > > more clear. For example simply use “lemma” for “prfun”, “axiom” for  
> > > > > “praxi”, etc. For someone smart enough to learn ATS, these words shouldn’t  
> > > > > be too strange to them, yet they are more readable and indicating their  
> > > > > purposes better. I’d like to hear more input from other users on this.
> > > > > 16. Enough ranting on syntax. I want to emphasis that all that  
> > > > > said, ATS’s syntax is still my personal single favorite among all the  
> > > > > programming languages I know (I do know a lot of them). The design is very  
> > > > > beautiful and tasteful. It’s a piece of art.
> > > > > 17. Can we combine .sats and .dats files? I’m not sure if that’s  
> > > > > feasible, but I find cross-referencing between two files is tiring, even if  
> > > > > with help from tagging systems. A combined .ats file format will be simpler  
> > > > > and easier to organize.
> > > > > 
> > > > > That’s about all I want to say so far, given my limited experience  
> > > > > with the language. Finally I want to thank Professor Xi for creating such a  
> > > > > beautiful programming language. As I said I know a lot of programming  
> > > > > languages. ATS is unique. Compared with ATS, Haskell is at least 10 years  
> > > > > behind, and C++ is about 30 years behind. Had Bjarne Stroustrup created not  
> > > > > C++ but ATS in the 1980s, our industry would have been a totally different  
> > > > > world. I can see a future of C++ being swiped away by ATS, and that future  
> > > > > is nigh. Let’s start to work.
> > > > > 
> > > > > On Tuesday, December 17, 2013 5:11:10 PM UTC-6, Ming Lei wrote:
> > > > > 
> > > > > > Chairman Mao once said,
> > > > > > 
> > > > > > “Who are our enemies? Who are our friends? This is a question of  
> > > > > > the first importance for the revolution.”
> > > > > > 
> > > > > > ATS is a revolution, but a programming language lives and dies with  
> > > > > > its community. A weak language with a strong community wins over a strong  
> > > > > > language with a weak community every time. Where is our community? How can  
> > > > > > we grow it? Technical works aside, I’d say building up a community is our  
> > > > > > top priority.
> > > > > > 
> > > > > > We don’t have many ATS programmers around, yet. The best source of  
> > > > > > new blood for this community shall be its target users. “Expert programmers  
> > > > > > who want to become more productive in writing high-quality code” is still  
> > > > > > too general. I don’t think a Web developer using Ruby on Rails is ATS’s  
> > > > > > target user, at least not in near future. ATS is good for low-level,  
> > > > > > high-performance programming tasks where correctness must be ensured. This  
> > > > > > may include:
> > > > > > 
> > > > > > 1. Scientific computing. Numerical stability and logical  
> > > > > > soundness are important. I have friends working on computational biological  
> > > > > > problems, using Haskell. The majority of this industry is still using C/C++  
> > > > > > or FORTRAN.
> > > > > > 2. Financial computing. A bug can cost millions of dollars.  
> > > > > > Several firms in this industry is already adopting Haskell or Ocaml,  
> > > > > > although C++ is still dominating, especially in the HFT section, obviously  
> > > > > > for performance reasons.
> > > > > > 3. Security and cryptography. Formal methods are getting popular,  
> > > > > > but there is a huge gap between their formal proofs and high-performance C  
> > > > > > code. We see trivial overflow bugs everyday.
> > > > > > 4. Game development. Modern games are too complex. They also need  
> > > > > > to deal with tricky concurrent/parallel programming problems. John Carmack  
> > > > > > is trying Haskell, but ATS should be a much better choice.
> > > > > > 5. Electronics and hardware/software interface. Device drivers,  
> > > > > > video codecs, firmware, embedded/realtime operating systems, they can all  
> > > > > > benefit from strong typing and formal proofs.
> > > > > > 6. Military, medical, these I’m not familiar with, but they all  
> > > > > > use old fashioned imperative languages.
> > > > > > 
> > > > > > Unfortunately, people in these fields are more conservative and  
> > > > > > skeptical. They will not believe you unless you show them undeniable hard  
> > > > > > evidence. They also hate to learn new languages. However, compared to  
> > > > > > languages like Haskell or Ocaml, ATS not only has a much more powerful type  
> > > > > > system, but also can be compiled to straightforward C code. This is our big  
> > > > > > selling point.
> > > > > > 
> > > > > > We can not just wait for them to come and learn ATS. We need to  
> > > > > > actively reach out, show them who great ATS is, listen to their concerns  
> > > > > > and improve ATS accordingly. We need to reduce the difficulty for them to  
> > > > > > enter this new world. Specifically, I have several ideas in mind:
> > > > > > 
> > > > > > 1. Professor Xi needs to communicate his big ideas and roadmap to  
> > > > > > the community. If they only stay in his head, other people can not help.  
> > > > > > What’s the difference between ATS 1 and 2? What new features can we expect?  
> > > > > > People need to know the big picture.
> > > > > > 2. Make a formal specification of ATS’s entire grammar. It  
> > > > > > needn’t to be as readable as the Haskell 98 language report. Even as simple  
> > > > > > as an EBNF can be hugely helpful. The language guide is far from completed  
> > > > > > yet, so a formal grammar would be the only way for new comers to learn the  
> > > > > > whole language, except reading the source code. Undocumented syntax wastes  
> > > > > > everyone’s time. With a specification, we can try test cases, know which  
> > > > > > works and which not, we can even contribute some fixes to the core  
> > > > > > language. Without it we don’t even know where to start.
> > > > > > 3. Finish the outline of the language guide ASAP. List all the  
> > > > > > chapters to be written, write a brief summary for each one. Give people a  
> > > > > > easy way to contribute to the documentation, so that they can fill it up.
> > > > > > 4. People who can hack the compiler should stop spending too much  
> > > > > > time on contributed libraries. Their energy is too valuable and they should  
> > > > > > focus on the fundamentals. Nobody wants to write libraries with an  
> > > > > > unreliable compiler. Please let other people write the libraries. They have  
> > > > > > more domain knowledge and they can learn the language in the process.
> > > > > > 5. Update the language’s official Web site. It’s too shabby now.  
> > > > > > People do judge a language by its face. ATS is at least 30 years ahead of  
> > > > > > mainstream languages, but its Web site looks to be 30 years behind. Make it  
> > > > > > pretty, usable and informative, update it timely. Bonus point for writing  
> > > > > > its backend in ATS.
> > > > > > 6. Migrate all the remaining source code and downloadable stuff  
> > > > > > away from SourceForge. SourceForge’s reputation is not good, and its  
> > > > > > usability is worse. People may think ATS is dying with SourceForge. We can  
> > > > > > just move ATS1’s source code to GitHub and move the downloadable packages  
> > > > > > to the Web site.
> > > > > > 7. Fix the trivial bugs in the build system and make it work well  
> > > > > > on all the supported platforms. Encourage Linux distribution packagers /  
> > > > > > Mac OS X ports maintainers to include ATS in their releases.
> > > > > > 8. Separate the contribution libraries from the compiler itself.  
> > > > > > Make a real online libraries repository similar to CPAN, RubyForge or NPM,  
> > > > > > so people can freely share useful libraries with each other. Such a  
> > > > > > repository is invaluable for a programming language. It’s an online  
> > > > > > presence, a social place, and a place to demonstrate how the language works  
> > > > > > in real life to curious lookers. This is very important.
> > > > > > 9. Then we can use all our connections in the industry to  
> > > > > > advocate ATS, ask our friends to try it, and eventually build one or two  
> > > > > > killer applications with it, which is how every successful programming  
> > > > > > language grows up.
> > > > > > 
> > > > > > All of these are non-technical ideas. I will summarize some of my  
> > > > > > thoughts on the technical side in another post.
> > > > > > 
> > > > > > On Tuesday, December 17, 2013 8:34:47 AM UTC-6, gmhwxi wrote:
> > > > > > 
> > > > > > > First, I would really like to see that ATS gets used by more and more  
> > > > > > > programmers, and I welcome suggestions of all sorts on making this a  
> > > > > > > reality.
> > > > > > > 
> > > > > > > I do not see ATS as a programming language for the general public.  
> > > > > > > Instead,  
> > > > > > > it targets expert programmers who want to become more productive in  
> > > > > > > writing  
> > > > > > > high-quality code.
> > > > > > > 
> > > > > > > Compilation of templates in ATS2 is not yet finished. It is my first  
> > > > > > > priority  
> > > > > > > to get template compilation done properly.
> > > > > > > 
> > > > > > > As always, documentation needs to be added and improved. I need a  
> > > > > > > lot of  
> > > > > > > help for this.
> > > > > > > 
> > > > > > > I really want to see other people working on ATS-contrib besides me  
> > > > > > > alone.
> > > > > > > 
> > > > > > > > > Otherwise, we should all face the cold, hard reality and get some  
> > > > > > > > > real work done.
> > > > > > > 
> > > > > > > What kind work do you have in mind?
> > > > > > > 
> > > > > > > On Tuesday, December 17, 2013 1:27:11 AM UTC-5, Ming Lei wrote:
> > > > > > > 
> > > > > > > > This question is for Professor Xi, but it’s probably also for  
> > > > > > > > everyone here.
> > > > > > > > 
> > > > > > > > I like ATS, but where is ATS heading to?
> > > > > > > > 
> > > > > > > > Will it remain in ivory tower as a teaching/thesis-generating tool  
> > > > > > > > forever, or will it ever grow up to be a real industrial language?
> > > > > > > > 
> > > > > > > > Every time I look at the very much incomplete documentation, every  
> > > > > > > > time I see Professor Xi himself updating some libraries in /contrib on  
> > > > > > > > GitHub, I want to ask these questions.
> > > > > > > > 
> > > > > > > > If the language’s creator just want it to remain to be an academic  
> > > > > > > > toy, so be it and it’s fine, as he has all the rights in the world.
> > > > > > > > 
> > > > > > > > Otherwise, we should all face the cold, hard reality and get some  
> > > > > > > > real work done.

---

<div class="post-metadata">

**Author:** ![gmhwxi](https://avatars.discourse-cdn.com/v4/letter/g/67e7ee/32.png) [@gmhwxi](https://discourse.ats-lang.org/u/gmhwxi)\
**Post date:** [December 17, 2013, 2:34pm UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55/7 "2013-12-17T14:34:47Z")

</div>

First, I would really like to see that ATS gets used by more and more  
programmers, and I welcome suggestions of all sorts on making this a  
reality.

I do not see ATS as a programming language for the general public. Instead,  
it targets expert programmers who want to become more productive in writing  
high-quality code.

Compilation of templates in ATS2 is not yet finished. It is my first  
priority  
to get template compilation done properly.

As always, documentation needs to be added and improved. I need a lot of  
help for this.

I really want to see other people working on ATS-contrib besides me alone.

> > Otherwise, we should all face the cold, hard reality and get some real  
> > work done.

What kind work do you have in mind?On Tuesday, December 17, 2013 1:27:11 AM UTC-5, Ming Lei wrote:

> This question is for Professor Xi, but it’s probably also for everyone  
> here.
> 
> I like ATS, but where is ATS heading to?
> 
> Will it remain in ivory tower as a teaching/thesis-generating tool  
> forever, or will it ever grow up to be a real industrial language?
> 
> Every time I look at the very much incomplete documentation, every time I  
> see Professor Xi himself updating some libraries in /contrib on GitHub, I  
> want to ask these questions.
> 
> If the language’s creator just want it to remain to be an academic toy, so  
> be it and it’s fine, as he has all the rights in the world.
> 
> Otherwise, we should all face the cold, hard reality and get some real  
> work done.

---

<div class="post-metadata">

**Author:** ![Ming\_Lei](https://avatars.discourse-cdn.com/v4/letter/m/df705f/32.png) [@Ming\_Lei](https://discourse.ats-lang.org/u/Ming_Lei)\
**Post date:** [December 19, 2013, 8:49pm UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55/8 "2013-12-19T20:49:06Z")

</div>

> Semantically, ATS and C are the same.
> 
> However, syntactically, I think that ATS and C should be kept very  
> distinct from each other.

I fully agree. There is no way to fit ATS into C’s tiny shoes anyway.  
That’s why there should still be "%{…%}"s to isolate the C code. ATS  
should never support the full C syntax natively.

> 

One possibility to support what you said is to write a tool that can

> automatically turn C header files into SATS files in ATS.

Haskell has such tools, but they never work as flawlessly as C++'s extern  
“C” statement. As far as I can remember, you still need to do a lot of  
manual work to make sure the output is correct. But they have good reasons,  
for Haskell is semantically very different from C.

The disadvantage of this kind of tools is that they not only add an extra  
layer of work, they also increase chances for compatibility bugs.

If the C header files to be included are bundled with the ATS source code,  
then a simple Makefile rule can solve the problem. If they are out of scope  
of the ATS source code, for example let’s say I want to include OS X’s  
system OpenGL header files. They are located at strange places, and Apple  
has the habit of moving them around with system updates. You can’t hardcode  
their paths in Makefile. You can not bundle the generated SATS with the  
other ATS source code either, because a system update may change some  
declarations in the C header files and make the generated SATS files out of  
sync. The same problems also exist in Linux systems, where package updates  
are more reckless.

Moreover, if we could make such a translation tool, and it could work  
flawlessly on C code, what prevents us from just embed this tool inside the  
ATS compiler? It shouldn’t be too big if we only need to parse the  
declarations.

---

<div class="post-metadata">

**Author:** ![Brandon\_Barker](https://sea1.discourse-cdn.com/flex019/user_avatar/discourse.ats-lang.org/brandon_barker/32/61_2.png) [@Brandon\_Barker](https://discourse.ats-lang.org/u/Brandon_Barker)\
**Post date:** [May 15, 2014, 1:46pm UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55/9 "2014-05-15T13:46:19Z")

</div>

It is easier to learn one thing in relative isolation than learn many  
techniques at once - though to learn something well may require using it  
varied domains (which ATS is no doubt very good at facilitating). So  
ideally someone coming to ATS should already have experience in an ML  
language and C.

Brandon Barker  
brandon…@gmail.comOn Thu, May 15, 2014 at 9:40 AM, Brandon Barker [brandon...@gmail.com](mailto:brandon...@gmail.com)wrote:

> I think it is a good idea; I probably should have done something similar  
> as well, at least for a few weeks, before jumping in to ATS.
> 
> Brandon Barker  
> [brandon...@gmail.com](mailto:brandon...@gmail.com)
> 
> On Thu, May 15, 2014 at 9:29 AM, Yves Dorfsman [yv...@zioup.com](mailto:yv...@zioup.com) wrote:
> 
> > On 2014-05-14 20:53, Brandon Barker wrote:
> > 
> > > The language is difficult for many reasons, and perhaps it must be. So we  
> > > should focus on what can be made less difficult: which of the biggest  
> > > gaps in  
> > > difficulty can be closed.
> > > 
> > > Aside from teaching materials, lack of documentation has been brought up  
> > > many  
> > > times. If you do enough grepping, you are likely to get what you need in  
> > > terms  
> > > of documentation. I’m starting to feel documentation is adequate in many  
> > > ways,  
> > > though there are some gaps. However, unlike in C, I would argue that the  
> > > types
> > 
> > As a data point, I had no background in any ML language and found the  
> > learning curve for ATS, with the current available material, too steep. I  
> > have decided to first go through some ocaml material addressed to beginners.
> > 
> > –  
> > Yves.
> > 
> > –  
> > 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](mailto:ats-lang-user...@googlegroups.com).  
> > To post to this group, send email to [ats-lan...@googlegroups.com](mailto:ats-lan...@googlegroups.com).  
> > To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/)  
> > msgid/ats-lang-users/5374C130.4090709%[40zioup.com](http://40zioup.com).

---

<div class="post-metadata">

**Author:** ![gmhwxi](https://avatars.discourse-cdn.com/v4/letter/g/67e7ee/32.png) [@gmhwxi](https://discourse.ats-lang.org/u/gmhwxi)\
**Post date:** [December 19, 2013, 5:00pm UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55/10 "2013-12-19T17:00:13Z")

</div>

Semantically, ATS and C are the same.

However, syntactically, I think that ATS and C should be kept very distinct  
from each other.

One possibility to support what you said is to write a tool that can  
automatically turn C header files into SATS files in ATS.On Wednesday, December 18, 2013 11:28:48 PM UTC-5, Ming Lei wrote:

> It turns out, I forgot one important thing.
> 
> ```
> 0. Make mixing ATS and C code as easy as possible. That means, no 
> 
> ```
> 
> more “#ext” and “#mac”. Just “%{ #include \<stdio.h\> }%” or something like  
> that, and you can start to use the C definitions in ATS. Just like C++, ATS  
> shares the native data types with C. If C++ can do it, ATS can do it too.  
> Technically, that may mean embedding a C front end for parsing, but it’s  
> totally worth the efforts. Potically, both ATS and GCC are licensed under  
> GPLv3, so there is no problem either. As far as I know, none of the  
> functional programming languages (except C++11, if you count it as a  
> functional language) can do that, because they either use boxed/tagged data  
> types by default (e.g. Ocaml, Common Lisp/Scheme, Haskell), or has poor  
> support for imperative programming at machine level (e.g. Haskell, Scala).  
> Not surprisingly, they all suffer from insufficient library support. ATS  
> has the unique position of having the best from both worlds (functional,  
> imperative, logic). With all the C libraries at its disposal, it’s destined  
> to win.
> 
> On Wednesday, December 18, 2013 8:28:26 PM UTC-6, Ming Lei wrote:
> 
> > Thanks for bearing with me. I have only about two weeks of experience  
> > with ATS, but I’ll speak from my beginner’s point of view anyway, and  
> > hopefully more experienced people will join me.
> > 
> > 1. The type system. I’m no expert in type systems, but to me it’s  
> > just the best in any practical programming languages available today. Not  
> > only does it help me detect bugs, it also forces me to think as clearly as  
> > possible. If you can make a stupid computer understand the idea of your  
> > program, by writing the proofs in a highly logical way, the chance of bugs  
> > is little. I have nothing to complain for now. I just want to see more  
> > examples on how to deal with heterogeneous lists, variadic arguments and  
> > other difficult things such as the Y combinator. It’s not like I’ll use any  
> > of them in everyday programming, but it would be good to know where the  
> > limit of ATS’s ability is.
> > 2. The overall syntax. Syntax is a more personal thing, but I do like  
> > ATS’s syntax a lot. Part of it might be that I hate languages using curly  
> > braces as code block delimiters (e.g. C/C++/Java/Go). “begin” and “end”  
> > stand out more visibly than those thin curly braces, and it’s easier to see  
> > if they are aligned or not. One thing which beginners may find confusing is  
> > that the same symbol may have very different meanings, for example “” and  
> > “{}”. In future versions of the programming guide we may want to emphasis  
> > on how to easily distinguish the different uses.
> > 3. The compiling process. As I said before, compiling to C is a big  
> > selling point. The generated C code is vastly clearer than what I can get  
> > from Haskell or Chicken Scheme. That said, I still think it could be made  
> > even more readable. Ideally, an ATS program written in imperative style  
> > should generate virtually identical C code. Currently the C code use a lot  
> > of inline functions to express (I think) the virtual instruction set of the  
> > compiler’s backend. It would be great if we could eliminate this layer and  
> > just output plain, boring C. Those inline functions are less readable, and  
> > they may be more troublesome to work with in a debugger. Although if you  
> > look at the final assembly code, they are tight enough, just looking at the  
> > C code and get an idea of how it works is much easier. The generated code  
> > also have a lot of extra comments. They are useful in large projects, but  
> > beginners usually start from writing small programs, so keeping it lean and  
> > mean in simple cases will be helpful.
> > 4. Another one of my wishes is a command line option to generate a  
> > standalone C program in source form, independent of any object files or  
> > libraries. I know there is a way to achieve that by including all the  
> > needed dynamic sources, but that’s too much work, not to mention you have  
> > to know which files to include. Pure C sources are more portable,  
> > especially if you need to embed the generated C code in places where  
> > linking user land libraries is prohibited (e.g. OS kernels, device  
> > drivers). Combined with point 3, it can also show those doubtful C  
> > programmers that there really is no magic nor dirty tricks. It would be a  
> > big win.
> > 5. Those relocation strings embedded in the object files, they are  
> > long and unreadable Sometimes they cause problems in the building process.  
> > I wonder if there is a better way to do that.
> > 6. Can we combine atscc and atsopt into one single command? I do not  
> > see the point of keeping them as two separate commands.
> > 7. GMP is nice, but it’s also a heavy weight dependency. I personally  
> > would like to see the support of infinite precision arithmetic as a  
> > library, not a built-in, and keep the basic data types isometric to C’s.  
> > Otherwise, I’d like to know how to avoid using its functionalities in my  
> > own code, so that at least the generated C code can run in environments  
> > where GMP is not available.
> > 8. The same for exception handling support. It’s useful, but  
> > sometimes you want to disable it in low-leve code.
> > 9. Now, back to the fine points of the syntax. My starting point is,  
> > if we really want to win the imperative programmers’ hearts, we have to  
> > make the syntax easy for them. If we also want to teach them to write  
> > correctness proofs, we’ll need to make that part’s syntax easy, too.
> > 10. I understand why tail-recursion is great, and ATS can compile  
> > them into loops if you write them in the right way, but creating nested  
> > functions just to express a simple loop is pedantic. You need to invent new  
> > names for the nested functions, and you also need to declare their types  
> > and parameters, and repeat the parameter list again when you call them.  
> > It’s way too verbose, for little benefit. Simply saying writing programs  
> > this way fits well into ATS’s big picture is just not convincing enough. If  
> > one of the major causes of verbosity in real life ATS code. I don’t know  
> > how difficult it will be, but can we make the compiler smart enough to  
> > compile imperative for/while better? Can we figure out a way to attach  
> > termination metrics to for/while loops and do not lose the theorem proving  
> > power? If we can convert from tail-calls to loops, why can’t we work  
> > backwards? Can we have goto?
> > 11. Most, if not all, examples in the programming guide, and all the  
> > ATS programs I can find in the Computer Language Benchmarks Game are  
> > deliberately written in a very verbose way. I know it’s meant to show more  
> > features of ATS and to teach beginners, and I know they can be much shorter  
> > if you want, but new comers do not know. I’ve heard people saying that they  
> > find ATS promising but are scared away by its “verbosity”. Well, if that  
> > were the most concise form of ATS programs, I’d be driven away, too.  
> > Working programmers hate verbosity. I agree a reasonable amount of  
> > verbosity if good, but there should be a limit. People hate ADA or Java for  
> > a reason. It’s nothing wrong to reveal the concise style to beginners  
> > gradually, but we have to at least show them several concise examples  
> > first, so that they can know there is a heaven and they can eventually get  
> > there. If God only shows us the Inferno, nobody will follow him. We need to  
> > make code examples short.
> > 12. One big reason I like ATS is that it’s not as dogmatic as some  
> > other functional programming languages. Its syntax is both inclusive and  
> > flexible. However, after all those nice additions, at some point we may  
> > want to take some time to re-examine the whole syntax, and see if there is  
> > something rarely used that we can remove. For example, I think some ML  
> > derived syntax can be removed or at least deprecated. Our goal is to win  
> > over C/C++ programmers, so “&&” makes sense and “andalso” does not. Maybe  
> > we can even remove “begin”, as in Ocaml (but not “;;”). I personally also  
> > do not like the “(\* comment \*)” syntax. Not that there is anything wrong in  
> > itself, but they are too similar to "()"s, especially when you write code  
> > like “nil of ((_nothing_))”. Syntax-highighting text editors do help, but  
> > still it’s some legacy from ATS’s ML root. But that’s just my personal  
> > preference. I’d like to hear what other C programmers would say.
> > 13. There are other minor points where I think readability/usability  
> > can be improved. I don’t like the “+” in “case+”. Small, single character  
> > symbols like “+” and “-” are just too small to be seen clearly, and if you  
> > make a typo, it’s harder to detect. I suggest we get some statistics on  
> > which kind of case clauses is more useful in real world code, make it the  
> > default, and give the unpopular one a more verbose name. Another one is the  
> > dereference operator “!”. It’s too thin and too similar to “1” and “i”. C’s  
> > “\*” is way more readable. Also “fnx”. The “x” is too small and too easy to  
> > mistype. I personally have no problem with the “@” in “t@ype”, although  
> > “@type” might be easier to type. Of course, these fine points are all  
> > cosmetic inconveniences, I can just live with them.
> > 14. A big topic would be the statics/theorem proving syntax. The  
> > current model is technically simple and straightforward, probably more  
> > familiar to former Prolog programmers, but hard to use. If we want people  
> > to write more proofs, we must make it easy. If you look at those successful  
> > theorem provers, for example Coq or Mizar, you don’t need to write  
> > “MUL(m,n,p)”, just something like “m\*n=p”. Learning to write proofs is  
> > already difficult enough for most programmers, and if the syntax is  
> > inhuman, they may just run from it. The goal of ATS is to let programmers  
> > write programs and proofs together, but that doesn’t mean they have to be  
> > written in the same language. Mixing the two things together, we are  
> > risking to make both tasks more difficult than necessary. Currently, I  
> > think some syntax sugar for statics might be helpful. My understanding is  
> > that ATS already has enough flexibility to do this, with macros and  
> > operator overloading/fixity declaration. If so, we can build up a layer of  
> > nice syntax and make it default in prelude, so that people do not need to  
> > deal with low-level, Prolog-like propositions directly. Well, even Prolog  
> > let you do this.
> > 15. We may also consider making theorem proving related keywords more  
> > clear. For example simply use “lemma” for “prfun”, “axiom” for “praxi”,  
> > etc. For someone smart enough to learn ATS, these words shouldn’t be too  
> > strange to them, yet they are more readable and indicating their purposes  
> > better. I’d like to hear more input from other users on this.
> > 16. Enough ranting on syntax. I want to emphasis that all that said,  
> > ATS’s syntax is still my personal single favorite among all the programming  
> > languages I know (I do know a lot of them). The design is very beautiful  
> > and tasteful. It’s a piece of art.
> > 17. Can we combine .sats and .dats files? I’m not sure if that’s  
> > feasible, but I find cross-referencing between two files is tiring, even if  
> > with help from tagging systems. A combined .ats file format will be simpler  
> > and easier to organize.
> > 
> > That’s about all I want to say so far, given my limited experience with  
> > the language. Finally I want to thank Professor Xi for creating such a  
> > beautiful programming language. As I said I know a lot of programming  
> > languages. ATS is unique. Compared with ATS, Haskell is at least 10 years  
> > behind, and C++ is about 30 years behind. Had Bjarne Stroustrup created not  
> > C++ but ATS in the 1980s, our industry would have been a totally different  
> > world. I can see a future of C++ being swiped away by ATS, and that future  
> > is nigh. Let’s start to work.
> > 
> > On Tuesday, December 17, 2013 5:11:10 PM UTC-6, Ming Lei wrote:
> > 
> > > Chairman Mao once said,
> > > 
> > > “Who are our enemies? Who are our friends? This is a question of the  
> > > first importance for the revolution.”
> > > 
> > > ATS is a revolution, but a programming language lives and dies with its  
> > > community. A weak language with a strong community wins over a strong  
> > > language with a weak community every time. Where is our community? How can  
> > > we grow it? Technical works aside, I’d say building up a community is our  
> > > top priority.
> > > 
> > > We don’t have many ATS programmers around, yet. The best source of new  
> > > blood for this community shall be its target users. “Expert programmers who  
> > > want to become more productive in writing high-quality code” is still too  
> > > general. I don’t think a Web developer using Ruby on Rails is ATS’s target  
> > > user, at least not in near future. ATS is good for low-level,  
> > > high-performance programming tasks where correctness must be ensured. This  
> > > may include:
> > > 
> > > 1. Scientific computing. Numerical stability and logical soundness  
> > > are important. I have friends working on computational biological problems,  
> > > using Haskell. The majority of this industry is still using C/C++ or  
> > > FORTRAN.
> > > 2. Financial computing. A bug can cost millions of dollars. Several  
> > > firms in this industry is already adopting Haskell or Ocaml, although C++  
> > > is still dominating, especially in the HFT section, obviously for  
> > > performance reasons.
> > > 3. Security and cryptography. Formal methods are getting popular,  
> > > but there is a huge gap between their formal proofs and high-performance C  
> > > code. We see trivial overflow bugs everyday.
> > > 4. Game development. Modern games are too complex. They also need to  
> > > deal with tricky concurrent/parallel programming problems. John Carmack is  
> > > trying Haskell, but ATS should be a much better choice.
> > > 5. Electronics and hardware/software interface. Device drivers,  
> > > video codecs, firmware, embedded/realtime operating systems, they can all  
> > > benefit from strong typing and formal proofs.
> > > 6. Military, medical, these I’m not familiar with, but they all use  
> > > old fashioned imperative languages.
> > > 
> > > Unfortunately, people in these fields are more conservative and  
> > > skeptical. They will not believe you unless you show them undeniable hard  
> > > evidence. They also hate to learn new languages. However, compared to  
> > > languages like Haskell or Ocaml, ATS not only has a much more powerful type  
> > > system, but also can be compiled to straightforward C code. This is our big  
> > > selling point.
> > > 
> > > We can not just wait for them to come and learn ATS. We need to actively  
> > > reach out, show them who great ATS is, listen to their concerns and improve  
> > > ATS accordingly. We need to reduce the difficulty for them to enter this  
> > > new world. Specifically, I have several ideas in mind:
> > > 
> > > 1. Professor Xi needs to communicate his big ideas and roadmap to  
> > > the community. If they only stay in his head, other people can not help.  
> > > What’s the difference between ATS 1 and 2? What new features can we expect?  
> > > People need to know the big picture.
> > > 2. Make a formal specification of ATS’s entire grammar. It needn’t  
> > > to be as readable as the Haskell 98 language report. Even as simple as an  
> > > EBNF can be hugely helpful. The language guide is far from completed yet,  
> > > so a formal grammar would be the only way for new comers to learn the whole  
> > > language, except reading the source code. Undocumented syntax wastes  
> > > everyone’s time. With a specification, we can try test cases, know which  
> > > works and which not, we can even contribute some fixes to the core  
> > > language. Without it we don’t even know where to start.
> > > 3. Finish the outline of the language guide ASAP. List all the  
> > > chapters to be written, write a brief summary for each one. Give people a  
> > > easy way to contribute to the documentation, so that they can fill it up.
> > > 4. People who can hack the compiler should stop spending too much  
> > > time on contributed libraries. Their energy is too valuable and they should  
> > > focus on the fundamentals. Nobody wants to write libraries with an  
> > > unreliable compiler. Please let other people write the libraries. They have  
> > > more domain knowledge and they can learn the language in the process.
> > > 5. Update the language’s official Web site. It’s too shabby now.  
> > > People do judge a language by its face. ATS is at least 30 years ahead of  
> > > mainstream languages, but its Web site looks to be 30 years behind. Make it  
> > > pretty, usable and informative, update it timely. Bonus point for writing  
> > > its backend in ATS.
> > > 6. Migrate all the remaining source code and downloadable stuff away  
> > > from SourceForge. SourceForge’s reputation is not good, and its usability  
> > > is worse. People may think ATS is dying with SourceForge. We can just move  
> > > ATS1’s source code to GitHub and move the downloadable packages to the Web  
> > > site.
> > > 7. Fix the trivial bugs in the build system and make it work well on  
> > > all the supported platforms. Encourage Linux distribution packagers / Mac  
> > > OS X ports maintainers to include ATS in their releases.
> > > 8. Separate the contribution libraries from the compiler itself.  
> > > Make a real online libraries repository similar to CPAN, RubyForge or NPM,  
> > > so people can freely share useful libraries with each other. Such a  
> > > repository is invaluable for a programming language. It’s an online  
> > > presence, a social place, and a place to demonstrate how the language works  
> > > in real life to curious lookers. This is very important.
> > > 9. Then we can use all our connections in the industry to advocate  
> > > ATS, ask our friends to try it, and eventually build one or two killer  
> > > applications with it, which is how every successful programming language  
> > > grows up.
> > > 
> > > All of these are non-technical ideas. I will summarize some of my  
> > > thoughts on the technical side in another post.
> > > 
> > > On Tuesday, December 17, 2013 8:34:47 AM UTC-6, gmhwxi wrote:
> > > 
> > > > First, I would really like to see that ATS gets used by more and more  
> > > > programmers, and I welcome suggestions of all sorts on making this a  
> > > > reality.
> > > > 
> > > > I do not see ATS as a programming language for the general public.  
> > > > Instead,  
> > > > it targets expert programmers who want to become more productive in  
> > > > writing  
> > > > high-quality code.
> > > > 
> > > > Compilation of templates in ATS2 is not yet finished. It is my first  
> > > > priority  
> > > > to get template compilation done properly.
> > > > 
> > > > As always, documentation needs to be added and improved. I need a lot of  
> > > > help for this.
> > > > 
> > > > I really want to see other people working on ATS-contrib besides me  
> > > > alone.
> > > > 
> > > > > > Otherwise, we should all face the cold, hard reality and get some  
> > > > > > real work done.
> > > > 
> > > > What kind work do you have in mind?
> > > > 
> > > > On Tuesday, December 17, 2013 1:27:11 AM UTC-5, Ming Lei wrote:
> > > > 
> > > > > This question is for Professor Xi, but it’s probably also for everyone  
> > > > > here.
> > > > > 
> > > > > I like ATS, but where is ATS heading to?
> > > > > 
> > > > > Will it remain in ivory tower as a teaching/thesis-generating tool  
> > > > > forever, or will it ever grow up to be a real industrial language?
> > > > > 
> > > > > Every time I look at the very much incomplete documentation, every  
> > > > > time I see Professor Xi himself updating some libraries in /contrib on  
> > > > > GitHub, I want to ask these questions.
> > > > > 
> > > > > If the language’s creator just want it to remain to be an academic  
> > > > > toy, so be it and it’s fine, as he has all the rights in the world.
> > > > > 
> > > > > Otherwise, we should all face the cold, hard reality and get some real  
> > > > > work done.

---

<div class="post-metadata">

**Author:** ![Brandon\_Barker](https://sea1.discourse-cdn.com/flex019/user_avatar/discourse.ats-lang.org/brandon_barker/32/61_2.png) [@Brandon\_Barker](https://discourse.ats-lang.org/u/Brandon_Barker)\
**Post date:** [May 15, 2014, 1:40pm UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55/11 "2014-05-15T13:40:05Z")

</div>

I think it is a good idea; I probably should have done something similar as  
well, at least for a few weeks, before jumping in to ATS.

Brandon Barker  
brandon…@gmail.comOn Thu, May 15, 2014 at 9:29 AM, Yves Dorfsman [yv...@zioup.com](mailto:yv...@zioup.com) wrote:

> On 2014-05-14 20:53, Brandon Barker wrote:
> 
> > The language is difficult for many reasons, and perhaps it must be. So we  
> > should focus on what can be made less difficult: which of the biggest  
> > gaps in  
> > difficulty can be closed.
> > 
> > Aside from teaching materials, lack of documentation has been brought up  
> > many  
> > times. If you do enough grepping, you are likely to get what you need in  
> > terms  
> > of documentation. I’m starting to feel documentation is adequate in many  
> > ways,  
> > though there are some gaps. However, unlike in C, I would argue that the  
> > types
> 
> As a data point, I had no background in any ML language and found the  
> learning curve for ATS, with the current available material, too steep. I  
> have decided to first go through some ocaml material addressed to beginners.
> 
> –  
> Yves.
> 
> –  
> 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](mailto:ats-lang-user...@googlegroups.com).  
> To post to this group, send email to [ats-lan...@googlegroups.com](mailto:ats-lan...@googlegroups.com).  
> To view this discussion on the web visit [https://groups.google.com/d/](https://groups.google.com/d/)  
> msgid/ats-lang-users/5374C130.4090709%[40zioup.com](http://40zioup.com).

---

<div class="post-metadata">

**Author:** ![Ming\_Lei](https://avatars.discourse-cdn.com/v4/letter/m/df705f/32.png) [@Ming\_Lei](https://discourse.ats-lang.org/u/Ming_Lei)\
**Post date:** [December 17, 2013, 11:11pm UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55/12 "2013-12-17T23:11:10Z")

</div>

Chairman Mao once said,

“Who are our enemies? Who are our friends? This is a question of the first  
importance for the revolution.”

ATS is a revolution, but a programming language lives and dies with its  
community. A weak language with a strong community wins over a strong  
language with a weak community every time. Where is our community? How can  
we grow it? Technical works aside, I’d say building up a community is our  
top priority.

We don’t have many ATS programmers around, yet. The best source of new  
blood for this community shall be its target users. “Expert programmers who  
want to become more productive in writing high-quality code” is still too  
general. I don’t think a Web developer using Ruby on Rails is ATS’s target  
user, at least not in near future. ATS is good for low-level,  
high-performance programming tasks where correctness must be ensured. This  
may include:

1. Scientific computing. Numerical stability and logical soundness are  
important. I have friends working on computational biological problems,  
using Haskell. The majority of this industry is still using C/C++ or  
FORTRAN.
2. Financial computing. A bug can cost millions of dollars. Several  
firms in this industry is already adopting Haskell or Ocaml, although C++  
is still dominating, especially in the HFT section, obviously for  
performance reasons.
3. Security and cryptography. Formal methods are getting popular, but  
there is a huge gap between their formal proofs and high-performance C  
code. We see trivial overflow bugs everyday.
4. Game development. Modern games are too complex. They also need to  
deal with tricky concurrent/parallel programming problems. John Carmack is  
trying Haskell, but ATS should be a much better choice.
5. Electronics and hardware/software interface. Device drivers, video  
codecs, firmware, embedded/realtime operating systems, they can all benefit  
from strong typing and formal proofs.
6. Military, medical, these I’m not familiar with, but they all use old  
fashioned imperative languages.

Unfortunately, people in these fields are more conservative and skeptical.  
They will not believe you unless you show them undeniable hard evidence.  
They also hate to learn new languages. However, compared to languages like  
Haskell or Ocaml, ATS not only has a much more powerful type system, but  
also can be compiled to straightforward C code. This is our big selling  
point.

We can not just wait for them to come and learn ATS. We need to actively  
reach out, show them who great ATS is, listen to their concerns and improve  
ATS accordingly. We need to reduce the difficulty for them to enter this  
new world. Specifically, I have several ideas in mind:

1. Professor Xi needs to communicate his big ideas and roadmap to the  
community. If they only stay in his head, other people can not help. What’s  
the difference between ATS 1 and 2? What new features can we expect? People  
need to know the big picture.
2. Make a formal specification of ATS’s entire grammar. It needn’t to be  
as readable as the Haskell 98 language report. Even as simple as an EBNF  
can be hugely helpful. The language guide is far from completed yet, so a  
formal grammar would be the only way for new comers to learn the whole  
language, except reading the source code. Undocumented syntax wastes  
everyone’s time. With a specification, we can try test cases, know which  
works and which not, we can even contribute some fixes to the core  
language. Without it we don’t even know where to start.
3. Finish the outline of the language guide ASAP. List all the chapters  
to be written, write a brief summary for each one. Give people a easy way  
to contribute to the documentation, so that they can fill it up.
4. People who can hack the compiler should stop spending too much time  
on contributed libraries. Their energy is too valuable and they should  
focus on the fundamentals. Nobody wants to write libraries with an  
unreliable compiler. Please let other people write the libraries. They have  
more domain knowledge and they can learn the language in the process.
5. Update the language’s official Web site. It’s too shabby now. People  
do judge a language by its face. ATS is at least 30 years ahead of  
mainstream languages, but its Web site looks to be 30 years behind. Make it  
pretty, usable and informative, update it timely. Bonus point for writing  
its backend in ATS.
6. Migrate all the remaining source code and downloadable stuff away  
from SourceForge. SourceForge’s reputation is not good, and its usability  
is worse. People may think ATS is dying with SourceForge. We can just move  
ATS1’s source code to GitHub and move the downloadable packages to the Web  
site.
7. Fix the trivial bugs in the build system and make it work well on all  
the supported platforms. Encourage Linux distribution packagers / Mac OS X  
ports maintainers to include ATS in their releases.
8. Separate the contribution libraries from the compiler itself. Make a  
real online libraries repository similar to CPAN, RubyForge or NPM, so  
people can freely share useful libraries with each other. Such a repository  
is invaluable for a programming language. It’s an online presence, a social  
place, and a place to demonstrate how the language works in real life to  
curious lookers. This is very important.
9. Then we can use all our connections in the industry to advocate ATS,  
ask our friends to try it, and eventually build one or two killer  
applications with it, which is how every successful programming language  
grows up.

All of these are non-technical ideas. I will summarize some of my thoughts  
on the technical side in another post.On Tuesday, December 17, 2013 8:34:47 AM UTC-6, gmhwxi wrote:

> First, I would really like to see that ATS gets used by more and more  
> programmers, and I welcome suggestions of all sorts on making this a  
> reality.
> 
> I do not see ATS as a programming language for the general public. Instead,  
> it targets expert programmers who want to become more productive in writing  
> high-quality code.
> 
> Compilation of templates in ATS2 is not yet finished. It is my first  
> priority  
> to get template compilation done properly.
> 
> As always, documentation needs to be added and improved. I need a lot of  
> help for this.
> 
> I really want to see other people working on ATS-contrib besides me alone.
> 
> > > Otherwise, we should all face the cold, hard reality and get some real  
> > > work done.
> 
> What kind work do you have in mind?
> 
> On Tuesday, December 17, 2013 1:27:11 AM UTC-5, Ming Lei wrote:
> 
> > This question is for Professor Xi, but it’s probably also for everyone  
> > here.
> > 
> > I like ATS, but where is ATS heading to?
> > 
> > Will it remain in ivory tower as a teaching/thesis-generating tool  
> > forever, or will it ever grow up to be a real industrial language?
> > 
> > Every time I look at the very much incomplete documentation, every time I  
> > see Professor Xi himself updating some libraries in /contrib on GitHub, I  
> > want to ask these questions.
> > 
> > If the language’s creator just want it to remain to be an academic toy,  
> > so be it and it’s fine, as he has all the rights in the world.
> > 
> > Otherwise, we should all face the cold, hard reality and get some real  
> > work done.

---

<div class="post-metadata">

**Author:** ![Ming\_Lei](https://avatars.discourse-cdn.com/v4/letter/m/df705f/32.png) [@Ming\_Lei](https://discourse.ats-lang.org/u/Ming_Lei)\
**Post date:** [December 19, 2013, 4:28am UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55/13 "2013-12-19T04:28:48Z")

</div>

It turns out, I forgot one important thing.

```
    0. Make mixing ATS and C code as easy as possible. That means, no 

```

more “#ext” and “#mac”. Just “%{ #include \<stdio.h\> }%” or something like  
that, and you can start to use the C definitions in ATS. Just like C++, ATS  
shares the native data types with C. If C++ can do it, ATS can do it too.  
Technically, that may mean embedding a C front end for parsing, but it’s  
totally worth the efforts. Potically, both ATS and GCC are licensed under  
GPLv3, so there is no problem either. As far as I know, none of the  
functional programming languages (except C++11, if you count it as a  
functional language) can do that, because they either use boxed/tagged data  
types by default (e.g. Ocaml, Common Lisp/Scheme, Haskell), or has poor  
support for imperative programming at machine level (e.g. Haskell, Scala).  
Not surprisingly, they all suffer from insufficient library support. ATS  
has the unique position of having the best from both worlds (functional,  
imperative, logic). With all the C libraries at its disposal, it’s destined  
to win.On Wednesday, December 18, 2013 8:28:26 PM UTC-6, Ming Lei wrote:

> Thanks for bearing with me. I have only about two weeks of experience with  
> ATS, but I’ll speak from my beginner’s point of view anyway, and hopefully  
> more experienced people will join me.
> 
> 1. The type system. I’m no expert in type systems, but to me it’s just  
> the best in any practical programming languages available today. Not only  
> does it help me detect bugs, it also forces me to think as clearly as  
> possible. If you can make a stupid computer understand the idea of your  
> program, by writing the proofs in a highly logical way, the chance of bugs  
> is little. I have nothing to complain for now. I just want to see more  
> examples on how to deal with heterogeneous lists, variadic arguments and  
> other difficult things such as the Y combinator. It’s not like I’ll use any  
> of them in everyday programming, but it would be good to know where the  
> limit of ATS’s ability is.
> 2. The overall syntax. Syntax is a more personal thing, but I do like  
> ATS’s syntax a lot. Part of it might be that I hate languages using curly  
> braces as code block delimiters (e.g. C/C++/Java/Go). “begin” and “end”  
> stand out more visibly than those thin curly braces, and it’s easier to see  
> if they are aligned or not. One thing which beginners may find confusing is  
> that the same symbol may have very different meanings, for example “” and  
> “{}”. In future versions of the programming guide we may want to emphasis  
> on how to easily distinguish the different uses.
> 3. The compiling process. As I said before, compiling to C is a big  
> selling point. The generated C code is vastly clearer than what I can get  
> from Haskell or Chicken Scheme. That said, I still think it could be made  
> even more readable. Ideally, an ATS program written in imperative style  
> should generate virtually identical C code. Currently the C code use a lot  
> of inline functions to express (I think) the virtual instruction set of the  
> compiler’s backend. It would be great if we could eliminate this layer and  
> just output plain, boring C. Those inline functions are less readable, and  
> they may be more troublesome to work with in a debugger. Although if you  
> look at the final assembly code, they are tight enough, just looking at the  
> C code and get an idea of how it works is much easier. The generated code  
> also have a lot of extra comments. They are useful in large projects, but  
> beginners usually start from writing small programs, so keeping it lean and  
> mean in simple cases will be helpful.
> 4. Another one of my wishes is a command line option to generate a  
> standalone C program in source form, independent of any object files or  
> libraries. I know there is a way to achieve that by including all the  
> needed dynamic sources, but that’s too much work, not to mention you have  
> to know which files to include. Pure C sources are more portable,  
> especially if you need to embed the generated C code in places where  
> linking user land libraries is prohibited (e.g. OS kernels, device  
> drivers). Combined with point 3, it can also show those doubtful C  
> programmers that there really is no magic nor dirty tricks. It would be a  
> big win.
> 5. Those relocation strings embedded in the object files, they are  
> long and unreadable Sometimes they cause problems in the building process.  
> I wonder if there is a better way to do that.
> 6. Can we combine atscc and atsopt into one single command? I do not  
> see the point of keeping them as two separate commands.
> 7. GMP is nice, but it’s also a heavy weight dependency. I personally  
> would like to see the support of infinite precision arithmetic as a  
> library, not a built-in, and keep the basic data types isometric to C’s.  
> Otherwise, I’d like to know how to avoid using its functionalities in my  
> own code, so that at least the generated C code can run in environments  
> where GMP is not available.
> 8. The same for exception handling support. It’s useful, but sometimes  
> you want to disable it in low-leve code.
> 9. Now, back to the fine points of the syntax. My starting point is,  
> if we really want to win the imperative programmers’ hearts, we have to  
> make the syntax easy for them. If we also want to teach them to write  
> correctness proofs, we’ll need to make that part’s syntax easy, too.
> 10. I understand why tail-recursion is great, and ATS can compile them  
> into loops if you write them in the right way, but creating nested  
> functions just to express a simple loop is pedantic. You need to invent new  
> names for the nested functions, and you also need to declare their types  
> and parameters, and repeat the parameter list again when you call them.  
> It’s way too verbose, for little benefit. Simply saying writing programs  
> this way fits well into ATS’s big picture is just not convincing enough. If  
> one of the major causes of verbosity in real life ATS code. I don’t know  
> how difficult it will be, but can we make the compiler smart enough to  
> compile imperative for/while better? Can we figure out a way to attach  
> termination metrics to for/while loops and do not lose the theorem proving  
> power? If we can convert from tail-calls to loops, why can’t we work  
> backwards? Can we have goto?
> 11. Most, if not all, examples in the programming guide, and all the  
> ATS programs I can find in the Computer Language Benchmarks Game are  
> deliberately written in a very verbose way. I know it’s meant to show more  
> features of ATS and to teach beginners, and I know they can be much shorter  
> if you want, but new comers do not know. I’ve heard people saying that they  
> find ATS promising but are scared away by its “verbosity”. Well, if that  
> were the most concise form of ATS programs, I’d be driven away, too.  
> Working programmers hate verbosity. I agree a reasonable amount of  
> verbosity if good, but there should be a limit. People hate ADA or Java for  
> a reason. It’s nothing wrong to reveal the concise style to beginners  
> gradually, but we have to at least show them several concise examples  
> first, so that they can know there is a heaven and they can eventually get  
> there. If God only shows us the Inferno, nobody will follow him. We need to  
> make code examples short.
> 12. One big reason I like ATS is that it’s not as dogmatic as some  
> other functional programming languages. Its syntax is both inclusive and  
> flexible. However, after all those nice additions, at some point we may  
> want to take some time to re-examine the whole syntax, and see if there is  
> something rarely used that we can remove. For example, I think some ML  
> derived syntax can be removed or at least deprecated. Our goal is to win  
> over C/C++ programmers, so “&&” makes sense and “andalso” does not. Maybe  
> we can even remove “begin”, as in Ocaml (but not “;;”). I personally also  
> do not like the “(\* comment \*)” syntax. Not that there is anything wrong in  
> itself, but they are too similar to "()"s, especially when you write code  
> like “nil of ((_nothing_))”. Syntax-highighting text editors do help, but  
> still it’s some legacy from ATS’s ML root. But that’s just my personal  
> preference. I’d like to hear what other C programmers would say.
> 13. There are other minor points where I think readability/usability  
> can be improved. I don’t like the “+” in “case+”. Small, single character  
> symbols like “+” and “-” are just too small to be seen clearly, and if you  
> make a typo, it’s harder to detect. I suggest we get some statistics on  
> which kind of case clauses is more useful in real world code, make it the  
> default, and give the unpopular one a more verbose name. Another one is the  
> dereference operator “!”. It’s too thin and too similar to “1” and “i”. C’s  
> “\*” is way more readable. Also “fnx”. The “x” is too small and too easy to  
> mistype. I personally have no problem with the “@” in “t@ype”, although  
> “@type” might be easier to type. Of course, these fine points are all  
> cosmetic inconveniences, I can just live with them.
> 14. A big topic would be the statics/theorem proving syntax. The  
> current model is technically simple and straightforward, probably more  
> familiar to former Prolog programmers, but hard to use. If we want people  
> to write more proofs, we must make it easy. If you look at those successful  
> theorem provers, for example Coq or Mizar, you don’t need to write  
> “MUL(m,n,p)”, just something like “m\*n=p”. Learning to write proofs is  
> already difficult enough for most programmers, and if the syntax is  
> inhuman, they may just run from it. The goal of ATS is to let programmers  
> write programs and proofs together, but that doesn’t mean they have to be  
> written in the same language. Mixing the two things together, we are  
> risking to make both tasks more difficult than necessary. Currently, I  
> think some syntax sugar for statics might be helpful. My understanding is  
> that ATS already has enough flexibility to do this, with macros and  
> operator overloading/fixity declaration. If so, we can build up a layer of  
> nice syntax and make it default in prelude, so that people do not need to  
> deal with low-level, Prolog-like propositions directly. Well, even Prolog  
> let you do this.
> 15. We may also consider making theorem proving related keywords more  
> clear. For example simply use “lemma” for “prfun”, “axiom” for “praxi”,  
> etc. For someone smart enough to learn ATS, these words shouldn’t be too  
> strange to them, yet they are more readable and indicating their purposes  
> better. I’d like to hear more input from other users on this.
> 16. Enough ranting on syntax. I want to emphasis that all that said,  
> ATS’s syntax is still my personal single favorite among all the programming  
> languages I know (I do know a lot of them). The design is very beautiful  
> and tasteful. It’s a piece of art.
> 17. Can we combine .sats and .dats files? I’m not sure if that’s  
> feasible, but I find cross-referencing between two files is tiring, even if  
> with help from tagging systems. A combined .ats file format will be simpler  
> and easier to organize.
> 
> That’s about all I want to say so far, given my limited experience with  
> the language. Finally I want to thank Professor Xi for creating such a  
> beautiful programming language. As I said I know a lot of programming  
> languages. ATS is unique. Compared with ATS, Haskell is at least 10 years  
> behind, and C++ is about 30 years behind. Had Bjarne Stroustrup created not  
> C++ but ATS in the 1980s, our industry would have been a totally different  
> world. I can see a future of C++ being swiped away by ATS, and that future  
> is nigh. Let’s start to work.
> 
> On Tuesday, December 17, 2013 5:11:10 PM UTC-6, Ming Lei wrote:
> 
> > Chairman Mao once said,
> > 
> > “Who are our enemies? Who are our friends? This is a question of the  
> > first importance for the revolution.”
> > 
> > ATS is a revolution, but a programming language lives and dies with its  
> > community. A weak language with a strong community wins over a strong  
> > language with a weak community every time. Where is our community? How can  
> > we grow it? Technical works aside, I’d say building up a community is our  
> > top priority.
> > 
> > We don’t have many ATS programmers around, yet. The best source of new  
> > blood for this community shall be its target users. “Expert programmers who  
> > want to become more productive in writing high-quality code” is still too  
> > general. I don’t think a Web developer using Ruby on Rails is ATS’s target  
> > user, at least not in near future. ATS is good for low-level,  
> > high-performance programming tasks where correctness must be ensured. This  
> > may include:
> > 
> > 1. Scientific computing. Numerical stability and logical soundness  
> > are important. I have friends working on computational biological problems,  
> > using Haskell. The majority of this industry is still using C/C++ or  
> > FORTRAN.
> > 2. Financial computing. A bug can cost millions of dollars. Several  
> > firms in this industry is already adopting Haskell or Ocaml, although C++  
> > is still dominating, especially in the HFT section, obviously for  
> > performance reasons.
> > 3. Security and cryptography. Formal methods are getting popular, but  
> > there is a huge gap between their formal proofs and high-performance C  
> > code. We see trivial overflow bugs everyday.
> > 4. Game development. Modern games are too complex. They also need to  
> > deal with tricky concurrent/parallel programming problems. John Carmack is  
> > trying Haskell, but ATS should be a much better choice.
> > 5. Electronics and hardware/software interface. Device drivers, video  
> > codecs, firmware, embedded/realtime operating systems, they can all benefit  
> > from strong typing and formal proofs.
> > 6. Military, medical, these I’m not familiar with, but they all use  
> > old fashioned imperative languages.
> > 
> > Unfortunately, people in these fields are more conservative and  
> > skeptical. They will not believe you unless you show them undeniable hard  
> > evidence. They also hate to learn new languages. However, compared to  
> > languages like Haskell or Ocaml, ATS not only has a much more powerful type  
> > system, but also can be compiled to straightforward C code. This is our big  
> > selling point.
> > 
> > We can not just wait for them to come and learn ATS. We need to actively  
> > reach out, show them who great ATS is, listen to their concerns and improve  
> > ATS accordingly. We need to reduce the difficulty for them to enter this  
> > new world. Specifically, I have several ideas in mind:
> > 
> > 1. Professor Xi needs to communicate his big ideas and roadmap to the  
> > community. If they only stay in his head, other people can not help. What’s  
> > the difference between ATS 1 and 2? What new features can we expect? People  
> > need to know the big picture.
> > 2. Make a formal specification of ATS’s entire grammar. It needn’t to  
> > be as readable as the Haskell 98 language report. Even as simple as an EBNF  
> > can be hugely helpful. The language guide is far from completed yet, so a  
> > formal grammar would be the only way for new comers to learn the whole  
> > language, except reading the source code. Undocumented syntax wastes  
> > everyone’s time. With a specification, we can try test cases, know which  
> > works and which not, we can even contribute some fixes to the core  
> > language. Without it we don’t even know where to start.
> > 3. Finish the outline of the language guide ASAP. List all the  
> > chapters to be written, write a brief summary for each one. Give people a  
> > easy way to contribute to the documentation, so that they can fill it up.
> > 4. People who can hack the compiler should stop spending too much  
> > time on contributed libraries. Their energy is too valuable and they should  
> > focus on the fundamentals. Nobody wants to write libraries with an  
> > unreliable compiler. Please let other people write the libraries. They have  
> > more domain knowledge and they can learn the language in the process.
> > 5. Update the language’s official Web site. It’s too shabby now.  
> > People do judge a language by its face. ATS is at least 30 years ahead of  
> > mainstream languages, but its Web site looks to be 30 years behind. Make it  
> > pretty, usable and informative, update it timely. Bonus point for writing  
> > its backend in ATS.
> > 6. Migrate all the remaining source code and downloadable stuff away  
> > from SourceForge. SourceForge’s reputation is not good, and its usability  
> > is worse. People may think ATS is dying with SourceForge. We can just move  
> > ATS1’s source code to GitHub and move the downloadable packages to the Web  
> > site.
> > 7. Fix the trivial bugs in the build system and make it work well on  
> > all the supported platforms. Encourage Linux distribution packagers / Mac  
> > OS X ports maintainers to include ATS in their releases.
> > 8. Separate the contribution libraries from the compiler itself. Make  
> > a real online libraries repository similar to CPAN, RubyForge or NPM, so  
> > people can freely share useful libraries with each other. Such a repository  
> > is invaluable for a programming language. It’s an online presence, a social  
> > place, and a place to demonstrate how the language works in real life to  
> > curious lookers. This is very important.
> > 9. Then we can use all our connections in the industry to advocate  
> > ATS, ask our friends to try it, and eventually build one or two killer  
> > applications with it, which is how every successful programming language  
> > grows up.
> > 
> > All of these are non-technical ideas. I will summarize some of my  
> > thoughts on the technical side in another post.
> > 
> > On Tuesday, December 17, 2013 8:34:47 AM UTC-6, gmhwxi wrote:
> > 
> > > First, I would really like to see that ATS gets used by more and more  
> > > programmers, and I welcome suggestions of all sorts on making this a  
> > > reality.
> > > 
> > > I do not see ATS as a programming language for the general public.  
> > > Instead,  
> > > it targets expert programmers who want to become more productive in  
> > > writing  
> > > high-quality code.
> > > 
> > > Compilation of templates in ATS2 is not yet finished. It is my first  
> > > priority  
> > > to get template compilation done properly.
> > > 
> > > As always, documentation needs to be added and improved. I need a lot of  
> > > help for this.
> > > 
> > > I really want to see other people working on ATS-contrib besides me  
> > > alone.
> > > 
> > > > > Otherwise, we should all face the cold, hard reality and get some real  
> > > > > work done.
> > > 
> > > What kind work do you have in mind?
> > > 
> > > On Tuesday, December 17, 2013 1:27:11 AM UTC-5, Ming Lei wrote:
> > > 
> > > > This question is for Professor Xi, but it’s probably also for everyone  
> > > > here.
> > > > 
> > > > I like ATS, but where is ATS heading to?
> > > > 
> > > > Will it remain in ivory tower as a teaching/thesis-generating tool  
> > > > forever, or will it ever grow up to be a real industrial language?
> > > > 
> > > > Every time I look at the very much incomplete documentation, every time  
> > > > I see Professor Xi himself updating some libraries in /contrib on GitHub, I  
> > > > want to ask these questions.
> > > > 
> > > > If the language’s creator just want it to remain to be an academic toy,  
> > > > so be it and it’s fine, as he has all the rights in the world.
> > > > 
> > > > Otherwise, we should all face the cold, hard reality and get some real  
> > > > work done.

---

<div class="post-metadata">

**Author:** ![Ian\_Denhardt](https://avatars.discourse-cdn.com/v4/letter/i/7feea3/32.png) [@Ian\_Denhardt](https://discourse.ats-lang.org/u/Ian_Denhardt)\
**Post date:** [December 18, 2013, 4:34am UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55/14 "2013-12-18T04:34:50Z")

</div>

Great post. There’s a lot of good stuff here. Specific comments are inline.

Quoting Ming Lei (2013-12-17 18:11:10)

> ```
> 5. Electronics and hardware/software interface. Device drivers, video
> codecs, firmware, embedded/realtime operating systems, they can all
> benefit from strong typing and formal proofs.
> 
> ```

I would add to this the more general cateogry of systems software - not  
just drivers and embedded operating systems, but operating systems more  
broadly, as well as high performance network servers, language  
runtimes…

> ```
> 2. Make a formal specification of ATSs entire grammar. It neednt to be
> as readable as the Haskell 98 language report. Even as simple as an
> EBNF can be hugely helpful. The language guide is far from
> completed yet, so a formal grammar would be the only way for new
> comers to learn the whole language, except reading the source code.
> 
> ```

Yes. I can’t stress this enough: having key parts of how the language  
is used not written down anywhere is unacceptable.

There’s a heading somewhere on [ats-lang.org](http://ats-lang.org) re: a formal grammar, but  
the section isn’t actually there…

> ```
> 5. Update the languages official Web site. Its too shabby now. People
> do judge a language by its face. ATS is at least 30 years ahead of
> mainstream languages, but its Web site looks to be 30 years behind.
> 
> ```

Irrespective of design, it’s often less than helpful. Apparently there’s  
a wiki that some people have contributed to. I found out a bout this  
when someone mentioned it on this list; the website doesn’t even mention  
it! There needs to be more attention paid to making sure the first page  
people land on gets them where they need to go.

I actually think we should offload most of that sort of thing to a wiki  
somewhere. There’s too much overhead in contributing to this sort of  
thing right now. Better documentation is a must, but it’s also a big  
job. We need to use tools that make it easy for people to help out.

> ```
> Make it pretty, usable and informative, update it timely. Bonus
> point for writing its backend in ATS.
> 
> ```

It’s pretty much static html now, and I think that’s actually the way to  
go; not much backend to be had (web servers and operating systems I  
suppose, but that’s orthogonal to this one site).

> ```
> 6. Migrate all the remaining source code and downloadable stuff away
> from SourceForge. SourceForges reputation is not good, and its
> usability is worse. People may think ATS is dying with SourceForge.
> We can just move ATS1s source code to GitHub and move the
> downloadable packages to the Web site.
> 
> ```

Might still be acceptable for downloading tarballs, but that’s about all  
I see most people using it for these days, and with good reason.

> ```
> 7. Fix the trivial bugs in the build system and make it work well on
> all the supported platforms. Encourage Linux distribution packagers
> / Mac OS X ports maintainers to include ATS in their releases.
> 
> ```

Specific recommendation: choose names for the tarballs and folders that  
agree with package naming guidelines in major distributions. This  
usually means no uppercase letters at the very least. It’s not something  
that’s ever stopped me from packaging something, but it’s a pet peeve.

> ```
> 8. Separate the contribution libraries from the compiler itself. Make
> a real online libraries repository similar to CPAN, RubyForge or
> NPM, so people can freely share useful libraries with each other.
> 
> ```

Absolutely. I’d also point out that having a standard build system for  
things written in ATS would make this a lot easier. It’s also something  
that needs attention on its own. We don’t need another language where  
build systems are as messy as they are for C/C++.

One additional comment, not immediately related to anything Ming Lei  
mentioned: a mailing list is not a bug tracker. There’s a lot of  
improvements to make to ATS, and for anyone but Prof. Xi to try to  
tackle them, we need a more organized way of managing them. We need a  
real bug tracker.

I’d propose, as a start, make an organization on github, move the  
existing git repos and the wiki to it, and start using the bug tracker.

-Ian

---

<div class="post-metadata">

**Author:** ![gmhwxi](https://avatars.discourse-cdn.com/v4/letter/g/67e7ee/32.png) [@gmhwxi](https://discourse.ats-lang.org/u/gmhwxi)\
**Post date:** [December 30, 2013, 4:28am UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55/15 "2013-12-30T04:28:58Z")

</div>

Hi Brandon,

I think sf wiki is good enough for now. If needed  
we could always move the content to somewhere else later.

I added you to the following project as a developer:

> **[ats2-lang](https://sourceforge.net/projects/ats2-lang/)**
>
> Download ats2-lang for free. ATS2: Unleashing the potentials of types and templates. ATS is a statically typed programming language that unifies implementation with formal specification. It is equipped with a highly expressive type system rooted in...

Could you start a wiki page for ATS2? If you do, I will add a link to it on  
the ATS homepage.

Cheers,

–HongweiOn Sunday, December 29, 2013 11:04:47 PM UTC-5, Brandon Barker wrote:

> It may be worth linking to the wiki on [sf.net](http://sf.net) from [http://www.ats-lang.org](http://www.ats-lang.org) since  
> people are missing it. Alternatively, if people do not like [sf.net](http://sf.net) (or  
> its wiki), maybe an installation of media-wiki would be a better place for  
> users to contribute code snippets and explanations. Much of what is on the  
> [sf.net](http://sf.net) wiki could be easily copied over, though much of it would be best  
> updated to strictly talk about ATS2 unless explicitly noted.
> 
> Brandon Barker  
> [brand...@gmail.com](mailto:brand...@gmail.com) \<javascript:\>
> 
> On Tue, Dec 17, 2013 at 11:34 PM, Ian Denhardt \<[i....@zenhack.net](mailto:i....@zenhack.net)\<javascript:\> wrote:
> 
> > Great post. There’s a lot of good stuff here. Specific comments are  
> > inline.
> > 
> > Quoting Ming Lei (2013-12-17 18:11:10)
> > 
> > > ```
> > > 5. Electronics and hardware/software interface. Device drivers, 
> > > 
> > > ```
> > 
> > video
> > 
> > > ```
> > > codecs, firmware, embedded/realtime operating systems, they can 
> > > 
> > > ```
> > 
> > all
> > 
> > > ```
> > > benefit from strong typing and formal proofs.
> > > 
> > > ```
> > 
> > I would add to this the more general cateogry of systems software - not  
> > just drivers and embedded operating systems, but operating systems more  
> > broadly, as well as high performance network servers, language  
> > runtimes…
> > 
> > > ```
> > > 2. Make a formal specification of ATSs entire grammar. It neednt to 
> > > 
> > > ```
> > 
> > be
> > 
> > > ```
> > > as readable as the Haskell 98 language report. Even as simple as 
> > > 
> > > ```
> > 
> > an
> > 
> > > ```
> > > EBNF can be hugely helpful. The language guide is far from
> > > completed yet, so a formal grammar would be the only way for new
> > > comers to learn the whole language, except reading the source 
> > > 
> > > ```
> > 
> > code.
> > 
> > Yes. I can’t stress this enough: having key parts of how the language  
> > is used not written down anywhere is unacceptable.
> > 
> > There’s a heading somewhere on [ats-lang.org](http://ats-lang.org) re: a formal grammar, but  
> > the section isn’t actually there…
> > 
> > > ```
> > > 5. Update the languages official Web site. Its too shabby now. 
> > > 
> > > ```
> > 
> > People
> > 
> > > ```
> > > do judge a language by its face. ATS is at least 30 years ahead 
> > > 
> > > ```
> > 
> > of
> > 
> > > ```
> > > mainstream languages, but its Web site looks to be 30 years 
> > > 
> > > ```
> > 
> > behind.
> > 
> > Irrespective of design, it’s often less than helpful. Apparently there’s  
> > a wiki that some people have contributed to. I found out a bout this  
> > when someone mentioned it on this list; the website doesn’t even mention  
> > it! There needs to be more attention paid to making sure the first page  
> > people land on gets them where they need to go.
> > 
> > I actually think we should offload most of that sort of thing to a wiki  
> > somewhere. There’s too much overhead in contributing to this sort of  
> > thing right now. Better documentation is a must, but it’s also a big  
> > job. We need to use tools that make it easy for people to help out.
> > 
> > > ```
> > > Make it pretty, usable and informative, update it timely. Bonus
> > > point for writing its backend in ATS.
> > > 
> > > ```
> > 
> > It’s pretty much static html now, and I think that’s actually the way to  
> > go; not much backend to be had (web servers and operating systems I  
> > suppose, but that’s orthogonal to this one site).
> > 
> > > ```
> > > 6. Migrate all the remaining source code and downloadable stuff away
> > > from SourceForge. SourceForges reputation is not good, and its
> > > usability is worse. People may think ATS is dying with 
> > > 
> > > ```
> > 
> > SourceForge.
> > 
> > > ```
> > > We can just move ATS1s source code to GitHub and move the
> > > downloadable packages to the Web site.
> > > 
> > > ```
> > 
> > Might still be acceptable for downloading tarballs, but that’s about all  
> > I see most people using it for these days, and with good reason.
> > 
> > > ```
> > > 7. Fix the trivial bugs in the build system and make it work well on
> > > all the supported platforms. Encourage Linux distribution 
> > > 
> > > ```
> > 
> > packagers
> > 
> > > ```
> > > / Mac OS X ports maintainers to include ATS in their releases.
> > > 
> > > ```
> > 
> > Specific recommendation: choose names for the tarballs and folders that  
> > agree with package naming guidelines in major distributions. This  
> > usually means no uppercase letters at the very least. It’s not something  
> > that’s ever stopped me from packaging something, but it’s a pet peeve.
> > 
> > > ```
> > > 8. Separate the contribution libraries from the compiler itself. 
> > > 
> > > ```
> > 
> > Make
> > 
> > > ```
> > > a real online libraries repository similar to CPAN, RubyForge or
> > > NPM, so people can freely share useful libraries with each other.
> > > 
> > > ```
> > 
> > Absolutely. I’d also point out that having a standard build system for  
> > things written in ATS would make this a lot easier. It’s also something  
> > that needs attention on its own. We don’t need another language where  
> > build systems are as messy as they are for C/C++.
> > 
> > * * *
> > 
> > One additional comment, not immediately related to anything Ming Lei  
> > mentioned: a mailing list is not a bug tracker. There’s a lot of  
> > improvements to make to ATS, and for anyone but Prof. Xi to try to  
> > tackle them, we need a more organized way of managing them. We need a  
> > real bug tracker.
> > 
> > I’d propose, as a start, make an organization on github, move the  
> > existing git repos and the wiki to it, and start using the bug tracker.
> > 
> > -Ian
> > 
> > –  
> > 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...@googlegroups.com](mailto:ats-lang...@googlegroups.com) \<javascript:\>.  
> > To post to this group, send email to [ats-l...@googlegroups.com](mailto:ats-l...@googlegroups.com)\<javascript:\>  
> > .  
> > To view this discussion on the web visit  
> > [https://groups.google.com/d/msgid/ats-lang-users/20131218043450.2622.94760%40nomad](https://groups.google.com/d/msgid/ats-lang-users/20131218043450.2622.94760%40nomad)  
> > .

---

<div class="post-metadata">

**Author:** ![gmhwxi](https://avatars.discourse-cdn.com/v4/letter/g/67e7ee/32.png) [@gmhwxi](https://discourse.ats-lang.org/u/gmhwxi)\
**Post date:** [December 19, 2013, 5:03pm UTC](https://discourse.ats-lang.org/t/roadmap-for-the-future-of-ats/55/16 "2013-12-19T17:03:34Z")

</div>

Thanks a lot for your thoughtful comments and suggestions!

I try to address some of the issues raised below in separate postings.On Wednesday, December 18, 2013 9:28:26 PM UTC-5, Ming Lei wrote:

> Thanks for bearing with me. I have only about two weeks of experience with  
> ATS, but I’ll speak from my beginner’s point of view anyway, and hopefully  
> more experienced people will join me.
> 
> 1. The type system. I’m no expert in type systems, but to me it’s just  
> the best in any practical programming languages available today. Not only  
> does it help me detect bugs, it also forces me to think as clearly as  
> possible. If you can make a stupid computer understand the idea of your  
> program, by writing the proofs in a highly logical way, the chance of bugs  
> is little. I have nothing to complain for now. I just want to see more  
> examples on how to deal with heterogeneous lists, variadic arguments and  
> other difficult things such as the Y combinator. It’s not like I’ll use any  
> of them in everyday programming, but it would be good to know where the  
> limit of ATS’s ability is.
> 2. The overall syntax. Syntax is a more personal thing, but I do like  
> ATS’s syntax a lot. Part of it might be that I hate languages using curly  
> braces as code block delimiters (e.g. C/C++/Java/Go). “begin” and “end”  
> stand out more visibly than those thin curly braces, and it’s easier to see  
> if they are aligned or not. One thing which beginners may find confusing is  
> that the same symbol may have very different meanings, for example “” and  
> “{}”. In future versions of the programming guide we may want to emphasis  
> on how to easily distinguish the different uses.
> 3. The compiling process. As I said before, compiling to C is a big  
> selling point. The generated C code is vastly clearer than what I can get  
> from Haskell or Chicken Scheme. That said, I still think it could be made  
> even more readable. Ideally, an ATS program written in imperative style  
> should generate virtually identical C code. Currently the C code use a lot  
> of inline functions to express (I think) the virtual instruction set of the  
> compiler’s backend. It would be great if we could eliminate this layer and  
> just output plain, boring C. Those inline functions are less readable, and  
> they may be more troublesome to work with in a debugger. Although if you  
> look at the final assembly code, they are tight enough, just looking at the  
> C code and get an idea of how it works is much easier. The generated code  
> also have a lot of extra comments. They are useful in large projects, but  
> beginners usually start from writing small programs, so keeping it lean and  
> mean in simple cases will be helpful.
> 4. Another one of my wishes is a command line option to generate a  
> standalone C program in source form, independent of any object files or  
> libraries. I know there is a way to achieve that by including all the  
> needed dynamic sources, but that’s too much work, not to mention you have  
> to know which files to include. Pure C sources are more portable,  
> especially if you need to embed the generated C code in places where  
> linking user land libraries is prohibited (e.g. OS kernels, device  
> drivers). Combined with point 3, it can also show those doubtful C  
> programmers that there really is no magic nor dirty tricks. It would be a  
> big win.
> 5. Those relocation strings embedded in the object files, they are  
> long and unreadable Sometimes they cause problems in the building process.  
> I wonder if there is a better way to do that.
> 6. Can we combine atscc and atsopt into one single command? I do not  
> see the point of keeping them as two separate commands.
> 7. GMP is nice, but it’s also a heavy weight dependency. I personally  
> would like to see the support of infinite precision arithmetic as a  
> library, not a built-in, and keep the basic data types isometric to C’s.  
> Otherwise, I’d like to know how to avoid using its functionalities in my  
> own code, so that at least the generated C code can run in environments  
> where GMP is not available.
> 8. The same for exception handling support. It’s useful, but sometimes  
> you want to disable it in low-leve code.
> 9. Now, back to the fine points of the syntax. My starting point is,  
> if we really want to win the imperative programmers’ hearts, we have to  
> make the syntax easy for them. If we also want to teach them to write  
> correctness proofs, we’ll need to make that part’s syntax easy, too.
> 10. I understand why tail-recursion is great, and ATS can compile them  
> into loops if you write them in the right way, but creating nested  
> functions just to express a simple loop is pedantic. You need to invent new  
> names for the nested functions, and you also need to declare their types  
> and parameters, and repeat the parameter list again when you call them.  
> It’s way too verbose, for little benefit. Simply saying writing programs  
> this way fits well into ATS’s big picture is just not convincing enough. If  
> one of the major causes of verbosity in real life ATS code. I don’t know  
> how difficult it will be, but can we make the compiler smart enough to  
> compile imperative for/while better? Can we figure out a way to attach  
> termination metrics to for/while loops and do not lose the theorem proving  
> power? If we can convert from tail-calls to loops, why can’t we work  
> backwards? Can we have goto?
> 11. Most, if not all, examples in the programming guide, and all the  
> ATS programs I can find in the Computer Language Benchmarks Game are  
> deliberately written in a very verbose way. I know it’s meant to show more  
> features of ATS and to teach beginners, and I know they can be much shorter  
> if you want, but new comers do not know. I’ve heard people saying that they  
> find ATS promising but are scared away by its “verbosity”. Well, if that  
> were the most concise form of ATS programs, I’d be driven away, too.  
> Working programmers hate verbosity. I agree a reasonable amount of  
> verbosity if good, but there should be a limit. People hate ADA or Java for  
> a reason. It’s nothing wrong to reveal the concise style to beginners  
> gradually, but we have to at least show them several concise examples  
> first, so that they can know there is a heaven and they can eventually get  
> there. If God only shows us the Inferno, nobody will follow him. We need to  
> make code examples short.
> 12. One big reason I like ATS is that it’s not as dogmatic as some  
> other functional programming languages. Its syntax is both inclusive and  
> flexible. However, after all those nice additions, at some point we may  
> want to take some time to re-examine the whole syntax, and see if there is  
> something rarely used that we can remove. For example, I think some ML  
> derived syntax can be removed or at least deprecated. Our goal is to win  
> over C/C++ programmers, so “&&” makes sense and “andalso” does not. Maybe  
> we can even remove “begin”, as in Ocaml (but not “;;”). I personally also  
> do not like the “(\* comment \*)” syntax. Not that there is anything wrong in  
> itself, but they are too similar to "()"s, especially when you write code  
> like “nil of ((_nothing_))”. Syntax-highighting text editors do help, but  
> still it’s some legacy from ATS’s ML root. But that’s just my personal  
> preference. I’d like to hear what other C programmers would say.
> 13. There are other minor points where I think readability/usability  
> can be improved. I don’t like the “+” in “case+”. Small, single character  
> symbols like “+” and “-” are just too small to be seen clearly, and if you  
> make a typo, it’s harder to detect. I suggest we get some statistics on  
> which kind of case clauses is more useful in real world code, make it the  
> default, and give the unpopular one a more verbose name. Another one is the  
> dereference operator “!”. It’s too thin and too similar to “1” and “i”. C’s  
> “\*” is way more readable. Also “fnx”. The “x” is too small and too easy to  
> mistype. I personally have no problem with the “@” in “t@ype”, although  
> “@type” might be easier to type. Of course, these fine points are all  
> cosmetic inconveniences, I can just live with them.
> 14. A big topic would be the statics/theorem proving syntax. The  
> current model is technically simple and straightforward, probably more  
> familiar to former Prolog programmers, but hard to use. If we want people  
> to write more proofs, we must make it easy. If you look at those successful  
> theorem provers, for example Coq or Mizar, you don’t need to write  
> “MUL(m,n,p)”, just something like “m\*n=p”. Learning to write proofs is  
> already difficult enough for most programmers, and if the syntax is  
> inhuman, they may just run from it. The goal of ATS is to let programmers  
> write programs and proofs together, but that doesn’t mean they have to be  
> written in the same language. Mixing the two things together, we are  
> risking to make both tasks more difficult than necessary. Currently, I  
> think some syntax sugar for statics might be helpful. My understanding is  
> that ATS already has enough flexibility to do this, with macros and  
> operator overloading/fixity declaration. If so, we can build up a layer of  
> nice syntax and make it default in prelude, so that people do not need to  
> deal with low-level, Prolog-like propositions directly. Well, even Prolog  
> let you do this.
> 15. We may also consider making theorem proving related keywords more  
> clear. For example simply use “lemma” for “prfun”, “axiom” for “praxi”,  
> etc. For someone smart enough to learn ATS, these words shouldn’t be too  
> strange to them, yet they are more readable and indicating their purposes  
> better. I’d like to hear more input from other users on this.
> 16. Enough ranting on syntax. I want to emphasis that all that said,  
> ATS’s syntax is still my personal single favorite among all the programming  
> languages I know (I do know a lot of them). The design is very beautiful  
> and tasteful. It’s a piece of art.
> 17. Can we combine .sats and .dats files? I’m not sure if that’s  
> feasible, but I find cross-referencing between two files is tiring, even if  
> with help from tagging systems. A combined .ats file format will be simpler  
> and easier to organize.
> 
> That’s about all I want to say so far, given my limited experience with  
> the language. Finally I want to thank Professor Xi for creating such a  
> beautiful programming language. As I said I know a lot of programming  
> languages. ATS is unique. Compared with ATS, Haskell is at least 10 years  
> behind, and C++ is about 30 years behind. Had Bjarne Stroustrup created not  
> C++ but ATS in the 1980s, our industry would have been a totally different  
> world. I can see a future of C++ being swiped away by ATS, and that future  
> is nigh. Let’s start to work.
> 
> On Tuesday, December 17, 2013 5:11:10 PM UTC-6, Ming Lei wrote:
> 
> > Chairman Mao once said,
> > 
> > “Who are our enemies? Who are our friends? This is a question of the  
> > first importance for the revolution.”
> > 
> > ATS is a revolution, but a programming language lives and dies with its  
> > community. A weak language with a strong community wins over a strong  
> > language with a weak community every time. Where is our community? How can  
> > we grow it? Technical works aside, I’d say building up a community is our  
> > top priority.
> > 
> > We don’t have many ATS programmers around, yet. The best source of new  
> > blood for this community shall be its target users. “Expert programmers who  
> > want to become more productive in writing high-quality code” is still too  
> > general. I don’t think a Web developer using Ruby on Rails is ATS’s target  
> > user, at least not in near future. ATS is good for low-level,  
> > high-performance programming tasks where correctness must be ensured. This  
> > may include:
> > 
> > 1. Scientific computing. Numerical stability and logical soundness  
> > are important. I have friends working on computational biological problems,  
> > using Haskell. The majority of this industry is still using C/C++ or  
> > FORTRAN.
> > 2. Financial computing. A bug can cost millions of dollars. Several  
> > firms in this industry is already adopting Haskell or Ocaml, although C++  
> > is still dominating, especially in the HFT section, obviously for  
> > performance reasons.
> > 3. Security and cryptography. Formal methods are getting popular, but  
> > there is a huge gap between their formal proofs and high-performance C  
> > code. We see trivial overflow bugs everyday.
> > 4. Game development. Modern games are too complex. They also need to  
> > deal with tricky concurrent/parallel programming problems. John Carmack is  
> > trying Haskell, but ATS should be a much better choice.
> > 5. Electronics and hardware/software interface. Device drivers, video  
> > codecs, firmware, embedded/realtime operating systems, they can all benefit  
> > from strong typing and formal proofs.
> > 6. Military, medical, these I’m not familiar with, but they all use  
> > old fashioned imperative languages.
> > 
> > Unfortunately, people in these fields are more conservative and  
> > skeptical. They will not believe you unless you show them undeniable hard  
> > evidence. They also hate to learn new languages. However, compared to  
> > languages like Haskell or Ocaml, ATS not only has a much more powerful type  
> > system, but also can be compiled to straightforward C code. This is our big  
> > selling point.
> > 
> > We can not just wait for them to come and learn ATS. We need to actively  
> > reach out, show them who great ATS is, listen to their concerns and improve  
> > ATS accordingly. We need to reduce the difficulty for them to enter this  
> > new world. Specifically, I have several ideas in mind:
> > 
> > 1. Professor Xi needs to communicate his big ideas and roadmap to the  
> > community. If they only stay in his head, other people can not help. What’s  
> > the difference between ATS 1 and 2? What new features can we expect? People  
> > need to know the big picture.
> > 2. Make a formal specification of ATS’s entire grammar. It needn’t to  
> > be as readable as the Haskell 98 language report. Even as simple as an EBNF  
> > can be hugely helpful. The language guide is far from completed yet, so a  
> > formal grammar would be the only way for new comers to learn the whole  
> > language, except reading the source code. Undocumented syntax wastes  
> > everyone’s time. With a specification, we can try test cases, know which  
> > works and which not, we can even contribute some fixes to the core  
> > language. Without it we don’t even know where to start.
> > 3. Finish the outline of the language guide ASAP. List all the  
> > chapters to be written, write a brief summary for each one. Give people a  
> > easy way to contribute to the documentation, so that they can fill it up.
> > 4. People who can hack the compiler should stop spending too much  
> > time on contributed libraries. Their energy is too valuable and they should  
> > focus on the fundamentals. Nobody wants to write libraries with an  
> > unreliable compiler. Please let other people write the libraries. They have  
> > more domain knowledge and they can learn the language in the process.
> > 5. Update the language’s official Web site. It’s too shabby now.  
> > People do judge a language by its face. ATS is at least 30 years ahead of  
> > mainstream languages, but its Web site looks to be 30 years behind. Make it  
> > pretty, usable and informative, update it timely. Bonus point for writing  
> > its backend in ATS.
> > 6. Migrate all the remaining source code and downloadable stuff away  
> > from SourceForge. SourceForge’s reputation is not good, and its usability  
> > is worse. People may think ATS is dying with SourceForge. We can just move  
> > ATS1’s source code to GitHub and move the downloadable packages to the Web  
> > site.
> > 7. Fix the trivial bugs in the build system and make it work well on  
> > all the supported platforms. Encourage Linux distribution packagers / Mac  
> > OS X ports maintainers to include ATS in their releases.
> > 8. Separate the contribution libraries from the compiler itself. Make  
> > a real online libraries repository similar to CPAN, RubyForge or NPM, so  
> > people can freely share useful libraries with each other. Such a repository  
> > is invaluable for a programming language. It’s an online presence, a social  
> > place, and a place to demonstrate how the language works in real life to  
> > curious lookers. This is very important.
> > 9. Then we can use all our connections in the industry to advocate  
> > ATS, ask our friends to try it, and eventually build one or two killer  
> > applications with it, which is how every successful programming language  
> > grows up.
> > 
> > All of these are non-technical ideas. I will summarize some of my  
> > thoughts on the technical side in another post.
> > 
> > On Tuesday, December 17, 2013 8:34:47 AM UTC-6, gmhwxi wrote:
> > 
> > > First, I would really like to see that ATS gets used by more and more  
> > > programmers, and I welcome suggestions of all sorts on making this a  
> > > reality.
> > > 
> > > I do not see ATS as a programming language for the general public.  
> > > Instead,  
> > > it targets expert programmers who want to become more productive in  
> > > writing  
> > > high-quality code.
> > > 
> > > Compilation of templates in ATS2 is not yet finished. It is my first  
> > > priority  
> > > to get template compilation done properly.
> > > 
> > > As always, documentation needs to be added and improved. I need a lot of  
> > > help for this.
> > > 
> > > I really want to see other people working on ATS-contrib besides me  
> > > alone.
> > > 
> > > > > Otherwise, we should all face the cold, hard reality and get some real  
> > > > > work done.
> > > 
> > > What kind work do you have in mind?
> > > 
> > > On Tuesday, December 17, 2013 1:27:11 AM UTC-5, Ming Lei wrote:
> > > 
> > > > This question is for Professor Xi, but it’s probably also for everyone  
> > > > here.
> > > > 
> > > > I like ATS, but where is ATS heading to?
> > > > 
> > > > Will it remain in ivory tower as a teaching/thesis-generating tool  
> > > > forever, or will it ever grow up to be a real industrial language?
> > > > 
> > > > Every time I look at the very much incomplete documentation, every time  
> > > > I see Professor Xi himself updating some libraries in /contrib on GitHub, I  
> > > > want to ask these questions.
> > > > 
> > > > If the language’s creator just want it to remain to be an academic toy,  
> > > > so be it and it’s fine, as he has all the rights in the world.
> > > > 
> > > > Otherwise, we should all face the cold, hard reality and get some real  
> > > > work done.