I see there is a lot of misunderstanding, which no doubt can at least
partially be attributed to my limited English and some poor wording. I'll try
to be more elaborate this time.
By no means I appreciate C typing model. One of the languages I use is Ada,
which stresses out the importance of using semantic meaning for variable type
(as opposed to internal representation) to the point where enum values have no
corresponding numbers (ok, in fact they do, but those are really hidden). One
of the things I like about Sather is that it allows creation of quite
extensive type hierarchies that do not get in the way (as it often happens
with Ada), thus allowing modelling on quite abstract level (again - as opposed
to representation level).
However, more often than not, I *have* to interface with C and deal with its
weak typing approach. So if I ask about usage of C_SIZE_T type, it's not
because I'd like to abuse it, but because a C function expects argument of
size_t type and I'd like to satisfy it by providing properly typed argument
from Sather side instead of blindly using INT and hoping for the best.
If I ask about EXT_OB usage in STR::create_from_c_string that's because I'm
concerned with API that speaks about "C string" but takes "reference to memory
location" as argument (especially that there is also create_from_memory_area
which seems to be much better suited for converting memory references).
Your mail was very insightful (btw. what happened to Sather 1.3, as GNU
version is 1.2.3), your programming language quite interesting (although the
link you gave times out). However, it doesn't really answer my biggest
question - how do I convert somewhat larger C data structure (the infamous
char ***listptr) from C to Sather? Your answer "You can do this in the same
sort of way that the Sather 1.3 stuff was done" doesn't tell me much as I
don't know where and what to look for (if you mean that SOCKET class - there
are only trivial C types returned from C calls there).
Yeah, I could rewrite the whole thing in pure Sather, but - given the number
of libraries Sather lacks - I'd rather spend a fraction of that time on one of
them and just wrap a C library that is known to work.
Also, it would be interesting to read some elaborate response on how there are
no storage related entites in your Sky language. Does that mean you intend to
implement everything from scratch and not interface with C at all? Or - if you
want to interface with C after all - how do you deal with pointers?