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

[Jay]

 > sysutils needed it. I don't see what m3core does.
I see. "fixing".
 
 - Jay



From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 07:32:13 +0000

I didn't slow it back down yet, but I changed to a relative path instead of ROOT.All the scripts define ROOT and my config files ferry environment variable CM3_ROOT to ROOT.(ROOT is too generic for an environment variable.)oh -- m3core or sysytils?sysutils needed it. I don't see what m3core does.  - Jay



From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3devel at elegosoft.comSubject: RE: [M3devel] declaring a type's existance but not enough to instantiate it?Date: Mon, 12 Jan 2009 07:27:09 +0000

Huh..that's what I was saying about the way m3overrides work -- the directory structure IS duplicated /everywhere/.. I don't know what choice there is, if quake code is to be shared across packages. m3tests does the same sort of thing, also to me. Ok, hold, I'll slow sysutils back down.  - Jay



From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 18:24:43 +1100CC: m3devel at elegosoft.comSubject: Re: [M3devel] declaring a type's existance but not enough to instantiate it?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.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 12:32:15 +1100CC: m3devel at elegosoft.comSubject: 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, 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/82020f01/attachment-0002.html>