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

[Tony Hosking]

Jay,

What the hell is the ROOT variable supposed to do now.  I can't build  
m3core with a compiler that doesn't define ROOT.  And why does the  
m3makefile that includes Uwaitpid.quake expect a hardwired cm3  
directory hierarchy.  Surely, I should be able to build m3core as a  
separate package, regardless of the structure in which it appears.   
You are doing damage to the package structures here too, by hardwiring  
these paths into the m3makefile.

-- Tony

On 12 Jan 2009, at 17:58, Jay wrote:

> We have conflicting goals.
>
> Keeping things as fast as possible and with as little C as possible,  
> vs. keeping things more portable, more easily ported, more obviously  
> correct.
>
> I want to drastically reduce the header cloning, or, the work of  
> porting.
>   It is already reduced, but I want to keep going.
>   I think having to make any changes at all in m3-libs/m3core/src/ 
> unix can be removed, other than adding the platform to the list of  
> platforms that uses the "portable" stuff.
> Porting would devolve to:
>     update the lists of platforms -- including some in m3makefiles
>     update Target.m3
>     clone/edit Csetjmp.i3
>     add the GNU platform to m3cc/src/makefile
>
> and maybe nothing else.
>
> It is likely even that the IR is now portable, for "Posix" systems.
> Pick word size, pick endian, generate 4 versions of IR, pick the  
> right one for your platform.
> Except for the OSConfigPosix that sometimes returns the platform  
> name and cm3's defining "HOST".
>
> A variable isn't great, but it is faster and more source compatible  
> than a function call, at least.
> And the C variable really will generally be read only. Writes to it  
> should fault.
>
>  > In this particular case, you are wanting to use a Modula-3  
> parameter
>  > passing mechanism on something that is not declared in Modula-3.
>
> Isn't this just a variation on what is done all the time? -- having  
> Modula-3 call C and sometimes vice versa?
> C code calls Modula-3 signal handlers, with data created in the C  
> code. The Modula-3 code can then pass them on. I don't see the line  
> really.
>
>  - Jay
>
>
>
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Mon, 12 Jan 2009 12:32:15 +1100
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] declaring a type's existance but not enough  
> to instantiate it?
>
>
> 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, but
> I 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 named
> types to refer to the external variables.
>
>  - Jay
>
>
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Mon, 12 Jan 2009 11:13:00 +1100
> CC: m3devel at elegosoft.com
> Subject: 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/7a9b7262/attachment-0002.html>