ATS Linux - A Feedback

[matthia...@bejocama.de]

Hi,

After half a year of experiencing ats (as a c++ developer) I changed my point of view in how  to go forward in using ats. Comparing ats with other "modern" languages is not very satisfying. Always having a position in the middle - for the logical prove oriented people we have linear logic (finally get control over resources, while the garbage collector solved before such problems), for the machine programming oriented people linear logic is like c-programming (nothing new, while garbage collection or intelligent resource management may also solve serious problems) - is difficult. Personally I Iike to have both - I can compare - cool. To come to a point. I learned very much from this list and from the very good documentation of the ats language. I started to change the linux kernel as a private self teaching project. Looking from the viewpoint of a c-programmer in direction to ats or alternatively to c++ is for me of interest, For that, a minimal linux system of about 630 objects consists now on 595 ats-dats files, may help to understand more. Sure, I haven't migrated 595 c-files to real ats code. The integration is a first step using the %{...%} pattern. The real migration must be done, one after the other, by hand. It's a kind of training. If someone else has a personal interest on linux kernel coding take my approach from git.bejocama.org. It's totally open. Finally Thanks.

Regards Matthias

[Kiwamu Okabe]

Wow! It seems great! But...

[INFO ] Installing pass-2 core C gcc compiler: done in 681.98s (at 46:49)
[INFO ] =================================================================
[INFO ] Installing C library
[INFO ] =================================================================
[INFO ] Building for multilib 1/1: ''
[EXTRA] Cleaning up start files
[EXTRA] Configuring C library
[EXTRA] Building C library
[ERROR] make[3]: *** [Makefile:129:
/home/kiwamu/src/ats-linux-setup/builds/crosstool_build/.build/x86_64-unknown-linux-gnu/build/build-libc-final/multilib/intl/msgs.h]
Error 2
[ERROR] make[3]: *** Waiting for unfinished jobs....
[ERROR] make[2]: *** [Makefile:470: intl/subdir_lib] Error 2
[ERROR] make[1]: *** [Makefile:9: all] Error 2
[ERROR]
[ERROR] >>
[ERROR] >> Build failed in step 'Building for multilib 1/1: '''
[ERROR] >> called in step 'Installing C library'
[ERROR] >> called in step '(top-level)'
[ERROR] >>
[ERROR] >> Error happened in: CT_DoExecLog[scripts/functions@376]
[ERROR] >> called from:
glibc_backend_once[scripts/build/libc/glibc.sh@398]
[ERROR] >> called from: CT_IterateMultilibs[scripts/functions@1608]
[ERROR] >> called from: glibc_backend[scripts/build/libc/glibc.sh@74]
[ERROR] >> called from: glibc_main[scripts/build/libc/glibc.sh@44]
[ERROR] >> called from: do_libc_main[scripts/build/libc.sh@33]
[ERROR] >> called from: main[scripts/crosstool-NG.sh@695]
[ERROR] >>
[ERROR] >> For more info on this error, look at the file: 'build.log'
[ERROR] >> There is a list of known issues, some with workarounds, in:
[ERROR] >> https://crosstool-ng.github.io/docs/known-issues/
[ERROR] >>
[ERROR] >> If you feel this is a bug in crosstool-NG, report it at:
[ERROR] >> https://github.com/crosstool-ng/crosstool-ng/issues/
[ERROR] >>
[ERROR] >> Make sure your report includes all the information
pertinent to this issue.
[ERROR] >> Read the bug reporting guidelines here:
[ERROR] >> http://crosstool-ng.github.io/support/

Is it a problem on crosstool-ng? Do you know how to fix it?
I'm using Debian GNU/Linux sid amd64.

Best regards,
--
Kiwamu Okabe

[gmhwxi]

Hi Matthias,

Today I took a glance at your ats-linux project. Here are a few thoughts

that I would like to share.

1. Please do not use the current library of ATS2. Instead, you should build

a library of your own specifically for this project. Of course, you could use ATS2

library at the beginning and then gradually replace the ATS library code with your

own.

2. Please try to avoid using dependent types at the beginning. I would not until

after I have got a running system. Think of dependent types as a way for you to

do (static) debugging later.

3. Try to use abstract types a lot! Here is some code I wrote to show off the idea:

https://github.com/xanadu-lang/xinterp/blob/master/srcgen/TEST/xatslib_githwxi/test-2020-07-26.dats

For instance, argv is just an array of strings. But you can make it abstract. If you really need to make use

of the fact that argv is an array of strings, you could just do a cast. Yes, this is unsafe but can be fixed later

without much effort at all.

4. Try to use templates a lot! Probably you could study the code in ATS-Temptory (but don't use ATS-Temptory

for your project as it is a quick experiment done and over at this point).

Good luck!

--Hongwei

PS: Don't feel that I have time to contribute to your project at this moment. But I will be happy to make suggestions

on translating C code into ATS.

[Matthias Wolff]

Hi Hongwei,

thanks for the feedback. Point 2 I perhaps misunderstand.
I think the system is running with working ats code - respecting
big endian, 32 bit coding, and memory alignment stuff. Between
my mail and your response I wrote about 1300 lines of ats code.
Working and running code. But for what I'm doing this. I can only
express it with the name Schönfinkel, pure phantasy - or reality? 

Am 26.07.20 um 21:30 schrieb gmhwxi:

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/23923286-cf2a-4a8f-96b5-be5396840b13o%40googlegroups.com.

[Hongwei Xi]

I read some of your code in lib/string.dats. I suppose that you would soon find that

handling structs can be a big challenge.

Even without using linear types, you could potentially find bugs involving dereferencing

NULL pointers. For example, in the following code, pde_subdir_find obviously assumes that

its argument 'dir' is not NULL. But is this assumption really met at all the call sites of pde_subdir_find?

static struct proc_dir_entry *pde_subdir_find(struct proc_dir_entry *dir,
					      const char *name,
					      unsigned int len)
{
	struct rb_node *node = dir->subdir.rb_node; // dir could potentially be NULL
        ...

}

I would not be surprised if bugs of this kind are uncovered with some easy dependent type checking.

Furthermore, things can turn out to be more interesting if linear types are used. For example, hidden
bugs potentially causing resource leaks can be uncovered with linear type checking.

If you use linear types, handling structs can be quite a challenge. Maybe it is a good idea to avoid using linear
types for now.

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/a6d6a6ce-c162-6524-c17d-302abb2586d9%40bejocama.de.

[Matthias Wolff]

OK, you are talking about boundary problems. At the moment every ATS function
is an island. So there are many risks in dealing with the stuff coming from outside
and also giving things back to the outside. It looks like a forgetful functor topic.
Such problems may occur and a lot more. I will follow your advice and write my
own library. If I really migrate 500000 lines of c code (including comments) I don't
know. I fear the moment I'm thinking - I'm ready. Some change management
aspects are of interest in general. Let's see.   

Am 27.07.20 um 07:53 schrieb Hongwei Xi:

To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/CAPPSPLqfnwgeATUsx11Bdroz6h7ygtPjW-nuOZjYVS841TBRSQ%40mail.gmail.com.