Roadmap for the future of ATS?

Ming_Lei · December 17, 2013, 6:27am

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.

Ming_Lei · December 19, 2013, 2:28am

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.

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.
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.
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.
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.
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.
Can we combine atscc and atsopt into one single command? I do not see
the point of keeping them as two separate commands.
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.
The same for exception handling support. It’s useful, but sometimes
you want to disable it in low-leve code.
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.
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?
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.
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.
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.
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.
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.
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.
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:

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.

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.

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.

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.

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

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

gmhwxi · December 19, 2013, 10:56pm

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.

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.

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.

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.

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.

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.

Can we combine atscc and atsopt into one single command? I do
not see the point of keeping them as two separate commands.

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.

The same for exception handling support. It’s useful, but
sometimes you want to disable it in low-leve code.

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.

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?

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

Brandon_Barker · December 30, 2013, 4:04am

It may be worth linking to the wiki on sf.net from
http://www.ats-lang.org since
people are missing it. Alternatively, if people do not like 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 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 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 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.
To post to this group, send email to 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
.

Brandon_Barker · May 15, 2014, 2:53am

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

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.

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.

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.

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.

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.

Can we combine atscc and atsopt into one single command? I do not
see the point of keeping them as two separate commands.

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.

The same for exception handling support. It’s useful, but sometimes
you want to disable it in low-leve code.

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.

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?

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

Ming_Lei · December 21, 2013, 2:37am

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.

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.

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.

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.

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.

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.

Can we combine atscc and atsopt into one single command? I do
not see the point of keeping them as two separate commands.

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.

The same for exception handling support. It’s useful, but
sometimes you want to disable it in low-leve code.

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.

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?

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

gmhwxi · December 17, 2013, 2:34pm

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.

Ming_Lei · December 19, 2013, 8:49pm

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.

Brandon_Barker · May 15, 2014, 1:46pm

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

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

On Thu, May 15, 2014 at 9:29 AM, Yves Dorfsman 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.
To post to this group, send email to ats-lan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/ats-lang-users/5374C130.4090709%40zioup.com.

gmhwxi · December 19, 2013, 5:00pm

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.

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.

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.

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.

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.

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.

Can we combine atscc and atsopt into one single command? I do not
see the point of keeping them as two separate commands.

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.

The same for exception handling support. It’s useful, but
sometimes you want to disable it in low-leve code.

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.

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?

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

Brandon_Barker · May 15, 2014, 1:40pm

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 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.
To post to this group, send email to ats-lan...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/ats-lang-users/5374C130.4090709%40zioup.com.

Ming_Lei · December 17, 2013, 11:11pm

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:

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.
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.
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.
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.
Electronics and hardware/software interface. Device drivers, video
codecs, firmware, embedded/realtime operating systems, they can all benefit
from strong typing and formal proofs.
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:

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

Ming_Lei · December 19, 2013, 4:28am

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.

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.

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.

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.

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.

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.

Can we combine atscc and atsopt into one single command? I do not
see the point of keeping them as two separate commands.

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.

The same for exception handling support. It’s useful, but sometimes
you want to disable it in low-leve code.

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.

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?

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

Ian_Denhardt · December 18, 2013, 4:34am

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

gmhwxi · December 30, 2013, 4:28am

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:

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 from http://www.ats-lang.org since
people are missing it. Alternatively, if people do not like 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 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 <javascript:>

On Tue, Dec 17, 2013 at 11:34 PM, Ian Denhardt <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 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 <javascript:>.
To post to this group, send email to 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
.

gmhwxi · December 19, 2013, 5:03pm

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.

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.

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.

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.

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.

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.

Can we combine atscc and atsopt into one single command? I do not
see the point of keeping them as two separate commands.

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.

The same for exception handling support. It’s useful, but sometimes
you want to disable it in low-leve code.

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.

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?

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

Topic		Replies	Views
Roadmap for the future of ATS Google Group	0	258	December 19, 2013
ATS resources Google Group	3	330	January 12, 2014
A nice (older) video by Guy Steele: Growing a Language Google Group	0	279	May 22, 2014
Would be cool to see an ATS entry Google Group	2	330	January 13, 2015
Formal specification of ATS2 abstract syntax tree (Template ATS2?) Google Group	5	419	November 3, 2014

Roadmap for the future of ATS?

Related Topics