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:
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.
On Sun, Jul 26, 2020 at 8:57 PM Matthias Wolff
<[email protected] <mailto:[email protected]>> wrote:
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:
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.
On Wednesday, July 1, 2020 at 9:29:58 PM UTC-4, matthias wrote:
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 <http://git.bejocama.org>. It's totally
open. Finally Thanks.
Regards Matthias
--
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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/23923286-cf2a-4a8f-96b5-be5396840b13o%40googlegroups.com
<https://groups.google.com/d/msgid/ats-lang-users/23923286-cf2a-4a8f-96b5-be5396840b13o%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/a6d6a6ce-c162-6524-c17d-302abb2586d9%40bejocama.de
<https://groups.google.com/d/msgid/ats-lang-users/a6d6a6ce-c162-6524-c17d-302abb2586d9%40bejocama.de?utm_medium=email&utm_source=footer>.
--
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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/CAPPSPLqfnwgeATUsx11Bdroz6h7ygtPjW-nuOZjYVS841TBRSQ%40mail.gmail.com
<https://groups.google.com/d/msgid/ats-lang-users/CAPPSPLqfnwgeATUsx11Bdroz6h7ygtPjW-nuOZjYVS841TBRSQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/944fceb0-1b83-980a-4b94-e03d5d6741d0%40bejocama.de.
