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

[Jay]

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/8ac0eb5c/attachment-0002.html>