How can I best help

[rodol]

I really like ATS. I've been learning for quite a while now and trying to spread

awareness, and get more people to learn it.

I've seen Hongwei Xi calling for concerted community efforts. I want to help,

but I still suck at ATS. I'm currently figuring out Temptory and plan to start

fiddling with Xanadu and xjsonize soon after.

I don't think I am capable enough to develop anything of use in ATS yet, and

writing docs for something I'm unfamiliar with seems like a daunting task.

I think I've got dependent types, templates, and theorem proving partially

figured out, I'm just starting out with linear views.

Any advice or instruction is welcome!

[gmhwxi]

Thanks for your interest and your willingness to help.

Opportunities should arise once I am able to get ATS3 to a point where

it can actually be used by others.

Cheers!

[froyo]

I've been trying to package ATS for my distro and from an outsider's point of view, there needs to be heavy work on docs, both on the language itself and how the build environment behaves precisely.

The only manpages I've found ere short descriptions of the tools by the debian packager Matthew Danish
If anything I think this is where I'd personally try to help if I'm as acquainted with the language as you are.

[Richard]

Hi froyo,

True, good documentation is very important!

Have you seen the documentation here?
http://www.ats-lang.org/Documents.html

For building ats from scratch, (i.e. bootstrapping ats2 from ats1) the documentation is indeed limited.

[froyo]

I have, actually. But I quickly put them on the backlog because they appeared to me as a programming manual rather than source tree documentation.
I've been following breadcrumbs from your source repos across sf and github, sf webpage, and the .org domain, as well as debian's package recipe, over last night.
To me there wasn't an immediately apparent path to where's the newest (or most supported) things are.

I do understand that I'm an outsider to the semantics built around the project, but I can't recall ever being so confused over a project I'm an outsider of, while just trying to package it.

For example,
- You have the main repo's contrib, and a contrib repo.
- There's a silent runtime dependency on bdw-gc that's from what I understand used for linear types, but I only knew it exists because the debian package depends on it. It wasn't mentioned on any of the install guides I've read, I think not even in the source tree itself? I don't remember where exactly but I think I've read it on the website.
- The instructions themselves seem to be scattered, some go back to before 2014 If something is old and unused I'd consider deprecating it, otherwise it's more comforting to see a recent date.
- I don't think config vars like LIBDIR and CFLAGS are considered in the build process.. That's according to mr. Matthew's patches. When I tried to do a plain build indeed everything was under one directory under /usr/lib (even though I specified LIBDIR as lib64 during configuration). This makes painless package splitting and translation to the FHS model impossible.
- additionally to the previous point, it is not immediately apparent which header files in the ats libs created after an install are needed for a working compiler vs only for compiling ats software
- I'm not quite sure what the empty dirs that only have a .keeper file are used for. Not sure if trimming them would cause issues if discarded

Please excuse my ignorance.. I am not familiar with your work enough yet.. But perhaps a first-timer's point of view can help alleviate that curve for next first-timers.

[froyo]

- I don't think config vars like LIBDIR and CFLAGS are considered in the build process..

s/LIBDIR and CFLAGS/--libdir and --datadir/
I think CFLAGS are fine, that was a mistype

also should I include myatscc? Seems like all the compile work is done on patscc