Roadmap for the future of ATS?

[Ming Lei]

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]

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?

[Ming Lei]

Chairman Mao once said,

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

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

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

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

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

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

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

All of these are non-technical ideas. I will summarize some of my thoughts on the technical side in another post.

[Chris Double]

On Tue, Dec 17, 2013 at 7:27 PM, Ming Lei <640...@gmail.com> wrote:
> 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?

I've been using it in the 'real world'. I use ATS/Anairiats in the
back end of a web application for doing a bunch of data submission
verification and management of inputs from multiple network daemons.
The use of linear types and dependent types have saved me from errors
a lot.

[Ian Denhardt]

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

[Ming Lei]

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

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

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

[Ming Lei]

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.

[gmhwxi]

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.

[gmhwxi]

Thanks a lot for your thoughtful comments and suggestions!

I try to address some of the issues raised below in separate postings.

[Ming Lei]

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.

[gmhwxi]

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

[Ming Lei]

You are right. It's more practical in this way.

[Brandon Barker]

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

--
You received this message because you are subscribed to the Google Groups "ats-lang-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-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.

[gmhwxi]

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:

https://sourceforge.net/projects/ats2-lang/

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

Cheers,

--Hongwei

[Brandon Barker]

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.

[Yves Dorfsman]

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.

[Brandon Barker]

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

--
You received this message because you are subscribed to the Google Groups "ats-lang-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ats-lang-users+unsubscribe@googlegroups.com.
To post to this group, send email to ats-lang-users@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/5374C130.4090709%40zioup.com.

[Brandon Barker]

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

[Yves Dorfsman]

On 2014-05-15 07:46, Brandon Barker wrote:
> 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.

I have a good background in C and python, but none in ML, and when trying to
learn ATS, I was asking and struggling with questions that are addressed in ML
basic materials. My understanding is that ATS is closer to SML and OCaml, but
decided to play with the latter for its practicality.

--
Yves.

[Yves Dorfsman]

I meant: ATS is closer to SML *than* OCaml
--
Yves.