[M3devel] declaring a type's existance but not enough to instantiate it?

[Jay]

This is what you "have to" chose between.
Header cloning or C code (and C headers).
 
CONST or VAR (or functions?)
 
I'm going to likely make the Uerror change tonight.
You can still veto it (er, vote against it :) )
 
Possibly some convuluted C (enum/#undef), or splitting the Modula-3
at boundaries that weren't previously believed "natural".
(See how SetupHandlers is ~two lines in Modula-3 and the rest in C;
this is partly out of ignorance. I don't know how to write those
two lines in C; and laziness, I didn't look into how).
 
 
 
Remember I'm still staying away from mainstream platforms,
so the value isn't what it might appear to be, but it is "stage setting",
and the show might go on. :)
 
 
Also, the dilemna does get more difficult now, with the little C header cloning that remains.
 
For example, look at Upthreads.i3.
Mainly, look at function prototypes.
Constants and types are "known problems".
Prototypes are gray. They actually tend to be portable.
 
For example:
 
TYPE pid_t = INTEGER;
<*EXTERNAL "m3_getpid*> PROCEDURE getpid():pid_t;
 
or leave it alone?
getpid is probably the worst example.
It is so very portable declared in Modula-3.
But still, imagine pid_t might be 16bits or 32 or 64.
Writing a wrapper is more portable -- as long as the pid isn't stuff into some record that the system defines.
 
 
Again, Upthreads.i3.
Would you like to see it reduced, or left alone?
Only deal with the types and initializers, or also the prototypes?
You know, I could write a little portable layer, where all the types are pointers, always null initialized.
It would buy /some/ portability, and cost some.
 
 
Do you like the sem_t change? Partly? Not at all?
There is one sem_t in the system. So I moved it to be in C code.
Or, as I had it before, declared as the max size/align of all the platforms -- getting that right is the same work as getting it right "the old way", except if you make a mistake, odds are still good of it being ok.
 
 
Should the line be drawn at generating the remaining headers, rather than eliminating them?
Uerror.i3 is easily generated. Good enough?
 
Upthread.i3's types can be generated generally as records with opaque arrays with the right size and alignment.
 
Other stuff can be generated or at least checked.
e.g. to check that getpid is declared correctly, you can assign it to a function pointer and see if that compiles.
 
Perf on Uerror arguably doesn't matter.
Is it only error handling code?Or do sockets often go down "error" paths, because they are slow and you are waiting for more data?
 
Anyway, point is, I agree for sure this is valuable, but I might be hitting the "tail" of the approach and should switch, I'm not sure. I keep saying that though, and then press further.
 
 
 - Jay



From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 19:24:50 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?


Point taken.  We live in a C universe and so need to interact.  I do think your work with the headers is useful, and I want it to continue.  Especially in simplifying ports.


On 12 Jan 2009, at 19:18, Jay wrote:

I don't think a development system without C headers is interesting.. Is it really? The transform I apply at times is wherever there is interaction with C code that is described by system-dependent headers, or perhaps even fairly system-independent headers outside the Modula-3 tree, either write wrapper functions for the functionality in the headers (e.g. stat, waitpid), which can be done in a system-independent way, or move the Modula-3<->C transition higher, which is also usually system-independent, e.g. ThreadPThreadC_SetupHandlers. It is either that or clone the headers, which seems like the worse evil. There is always going to be a Modula-3<->C transition, it is just a matter of where it occurs.  - Jay

CC: m3devel at elegosoft.comFrom: hosking at cs.purdue.eduTo: jay.krell at cornell.eduSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 12:32:15 +1100


Jay, I really think you are bending over backwards too far just to be able to shoe-horn things into C.  I *like* having the transpar of C header files expressed in Modula-3, *particularly* for system calls, where you might even be trying to build on a system that does not have the C header files installed, even though the libraries exist and can be linked to.  Fundamentally, I think anytime the Modula-3 code is made less transparent you should think hard about what you are doing.  The same with the change of constants to variables.

I am getting very nervous that the changes you are making are destroying the clarity of the Modula-3 run-time code.

In this particular case, you are wanting to use a Modula-3 parameter passing mechanism on something that is not declared in Modula-3.  Seems kind of dubious to me.  Also, I really don't like the idea of accessing external variables in C.

-- Tony

On 12 Jan 2009, at 11:55, Jay wrote:

I considered ADDRESS.However I think it still doesn't satisfy. I want to be able to do this: TYPE Foo_t = something;<* EXTERNAL *> VAR Foo1, Foo2:Foo_t;<* EXTERNAL *> PROCEDURE UseFoo(READONLY (* or VAR *) foo:Foo_t); (* Modula-3, not external *)PROCEDURE x()=BEGIN  UseFoo(Foo1);  UseFoo(Foo2);END x; AND I want any use of:VAR Foo3:Foo3_t; (* Modula-3, not external *)to error. This is sem_t and sigset_t in particular. Possibly renaming is the thing.They used to be declared in Modula-3, system-dependently, butI moved them to portable C. I could remove the types entirely and change UseFoo to take an address,and declare mask and ackSem to be integers or I guess.<*EXTERNAL> VAR ackSem : RECORD END; That would satisfy but I thought it might be nicer to still provide the namedtypes to refer to the external variables.  - Jay

From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 11:13:00 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?What's wrong with using ADDRESS for references to opaque values?  If sigset_t is never instantiated in Modula-3, then why do you need it declared there?



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 12 Jan 2009, at 01:44, Jay wrote:

Is there a way in Modula-3 to declare that a type exists, and there are <*external*> instances of it, without "fully" declaring it, so that no Modula-3 can instantiate it? I have done this for sigset_t and sem_t, but they could erroneously be instantiated by Modula-3 and I'd like to remove that ability to mess up so easily. (* This type is not declared correctly. It is only instantiated in C code. *)  sigset_t = RECORD END;(* This type is not declared correctly. It is only instantiated in C code. *)  sem_t = RECORD END;In C I believe you can do this, like:  typedef struct foo foo_t;    extern foo_t foo;    void UseFoo(foo_t*);   foo_t* GetFoo(void);  Thanks, - Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20090112/f3ffe5c8/attachment-0002.html>