I think you need to try it on a realistic example in order to get a sense as to how it works in practice. My suspicion is that the at-view style may not be adequate for a "complex" struct. I would go with the aptr-style, which allows you to take advantage of the support for overloading in ATS.
On Wednesday, August 31, 2016 at 11:33:44 PM UTC-4, Kiwamu Okabe wrote: > > Hi Hongwei, > > On Thu, Sep 1, 2016 at 12:51 AM, gmhwxi <...> wrote: > > 1. Translating each struct in C into an abstract type in ATS and > generating > > a generic programming interface for this abstract type. For > instance, > > the > > style involving aptr I showed is a reasonable way to get started. > > > > 2. For a particular C struct (say, inode). you can adapt/adjust the > generic > > interface > > to make it better suited for capturing programming invariants. For > > instance, you > > may need to introduce abstract views to properly handle reference > > counting. > > You mean I should not choose "at-view style" for this purpose. > The style is not good for re-design after re-written. > > > Given the complexity of the C code you are to re-write, it is only > realistic > > to expect > > that you need to make use of unsafe features. The objective here is to > > minimize the > > use of such features. > > Yes. I can agree. < minimized unsafe things at re-writing state > > Thanks a lot, > -- > Kiwamu Okabe at METASEPI DESIGN > -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/ats-lang-users. To view this discussion on the web visit https://groups.google.com/d/msgid/ats-lang-users/f8357488-41eb-4326-9b11-5b050d72784a%40googlegroups.com.
