[M3devel] naming conventions for split/composed interfaces?

[Jay]

What cost are you willing to pay?
It is EASY to write one simple Ustat.i3 and UstatC.c that is correct for all platforms, totally portable, simple, efficient enough etc. The cost of avoiding the wrapper is pain, uncertainty, much higher risk of the implementation being wrong or becoming silently wrong, though...
 
Well, how about this suggestion?
How about we start writing some C code that asserts the correctness of the .i3 files?Or even having the compiler output such C code? Just make sure it compiles?
 
Ustat.i3 would get some directive LIKE:
 
<* PRAGMA C-derived "#include sys/stat.h", "struct stat" *>
struct_stat = RECORD ... END
 
The second parameter is the type that the record should "match".
 
This would generate and a compile a file something like:
#include <sys/stat.h>
#define size(a,b,c) (sizeof((a)(a*)0)->b == c)
#define field(a,b) ((a*)0)->b)
#define offset(a,b) ((size_t)a)
 
type_size_size(struct stat, 0x123)
size(struct stat, st_dev, 8)
size(field(struct stat, st_dev), 8)
size(field(struct stat, st_ino), 8)
offset(field(struct stat, st_dev), 0)
offset(field(struct stat, st_ino), 8)
etc.
 
where all the numbers on the right are what the compiler computes.
 
This way, the transcription of C into Modula-3 is checked for correctness.
 
It can be optional -- like for cross builds that might have a C compiler or headers/libs.
I have to admit, there is an aspect of avoiding C that I really like -- the idea of building one tool for all targets, all in one, no need to get a cross compiler or headers/libs. To me that is a potential big upside to avoiding wrappers.
I would even suggest -- can the dtoa.c and hand.c be rewritten in Modula-3.
dtoa.c was very very gnarly last I looked. Could be they dropped support for IBM/Cray/VAX and it's simpler now, I don't know. While I like the idea, I would be reluctant because I don't understand the code much.
hand.c though, I strongly suspect can be written in perfectly portable efficient Modula-3.
It may or MIGHT not compiler down as efficiently, just if the compiler doesn't do a good job, but I don't think, like, "there any layers in the model" that prevent it, like you wouldn't have to do extra heap allocs or copies. You might get some extra array bounds checks, that would be good to avoid introducing.
 
Well, I'm too busy right now, but:
 
1) I'll maybe the errno wrapper in NT386. As long as you avoid the thread-unsafe library, this area has been stable forever.
And building in a dependency on thread safety is a good thing.
 
2) I'll see about rewriting hand.c in Modula-3 and see if I can convince myself there's no perf loss.
 
3) I look at gtoa.c to confirm it is still way to gnarly to consider changing.
 
4) Eventually see about building in this checking. It removes the upside of not having a compiler/headers, that's why optional.
 
5) Wonder about automating generation of the Modula-3 in the first place? Something like SWIG? I don't know.
Problem with #4 and #5 is special cases. Coming up with some mechanized translation that actually exists and works.
 
Gotta run,
 - Jay


CC: wagner at elegosoft.com; m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jayk123 at hotmail.comSubject: Re: [M3devel] naming conventions for split/composed interfaces?Date: Thu, 24 Apr 2008 08:44:57 -0400


Please, avoid C wrappers wherever possible.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484


On Apr 24, 2008, at 6:58 AM, Jay wrote:

Um..I have spent quite some time reading stat.h. At least 5 minutes. :)I must say, I really really really like the copyout method.Obviously, it goes something like this: struct_stat = RECORD   st_dev : uint64_t;   st_ino : uint64_t;   st_mode : uint64_t;   st_nlink : uint64_t;   st_uid : uint64_t;   st_gid : uint64_t;   st_rdev : uint64_t;   st_size : uint64_t;   st_blksize: uint64_t;   st_blocks : uint64_t;   st_atime : uint64_t;   st_mtime : uint64_t;   st_ctime : uint64_t; END; struct_stat_star = UNTRACED REF struct_stat;void copyout(const stat_t* s, m3_stat_t* m){   m->st_ctime = s.st_stime;   ...}int m3_stat(const char* path, m3_stat_t* m){   int result;   struct stat s;   result = m3_stat(path, &s);   copyout(&s, m);   return result;}and this one type definition and wrapper function is, like, arbitrarily portable to all systems.Quite simple. A little inefficient -- but it's not like the stat call itself won't dwarf the copying.I think I agree merging the files into Umachine.i3.However consider the part of Ustat.i3 other than the struct.The bit masks are probably identical across ALL platforms.The function declarations are.Actually even the struct can often be factored just by giving types like gid_t, ino_t, but I don't think that's worth it.I'd rather uint16_t, uint32_t, uint64_t.So I think moving just the struct into its own file, or using copyout, not a bad idea.Ustat.i3 is not quite the best example.I think a much better one is Upthread.i3.The file is very large and basically I think varies by 3-5 lines per variation.Lastly, you know, I do work to generate the headers kind of, and/or to derive them somewhat automatically.This work should probably be fully automated, at least for test cases, so assert the correctness.You know, write Modula-3 and C code to print field offsets and sizes and verify they are identical.This should aid maintenability. I assert the current system, no matter how the files are laid out, is overly fragile.I assert that transcribing .h files into .i3 files is a very dubious practise.It has an upside of easier cross building -- don't need the platform-specific headers.And it has the upside of not needing to worry about parsing .h files.But it is obviously bad maintainability.Better would be do wrappers like the above, except where perf is critical.Or at least actively (daily) assert the sizes/offsets.
Another argument to keep the structure is that is has proven to be
easily portable; and we should be very careful to change it.I think the current structure has proven easily copied around and then not fixed and bugs lurking..This is not really my original point, but I have to harp a bit, it's been simmering in my brain a long time.Any time I see header cloning I cringe significantly. Visual Basic and C# have this same problem.- Jay
Date: Wed, 23 Apr 2008 23:32:43 +0200
From: wagner at elegosoft.com
To: m3devel at elegosoft.com
Subject: Re: [M3devel] naming conventions for split/composed interfaces?

Quoting Tony Hosking <hosking at cs.purdue.edu>:


Basically, I hate the idea of tangling together multiple machine-

dependent systems in the same files.  Yes, it is verbose with

duplicated functionality, but it *is* separable.  I can delete one set

of files without breaking builds on other targets.  I hate the idea of

C wrappers even more!



So, my position remains that while it is verbose having separate

target-specific directories, at least they are independent and isolated
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080425/d568688a/attachment-0002.html>