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 <matthias.wo...@bejocama.de>
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.
>> 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 ats-lang-users+unsubscr...@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
> <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 ats-lang-users+unsubscr...@googlegroups.com.
> 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 ats-lang-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/CAPPSPLqfnwgeATUsx11Bdroz6h7ygtPjW-nuOZjYVS841TBRSQ%40mail.gmail.com.
