Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!decwrl!nsc!taux01!avi
From: avi@taux01.UUCP (Avi Bloch)
Newsgroups: comp.lang.modula2
Subject: Re: Modula2 front end for gcc?
Message-ID: <2175@taux01.UUCP>
Date: 16 Jul 89 08:21:19 GMT
References: <8728@pyr.gatech.EDU> <7894@cs.Buffalo.EDU> <944@gould.doc.ic.ac.uk> <7943@cs.Buffalo.EDU>
Reply-To: avi@taux01.UUCP (Avi Bloch)
Organization: National Semiconductor (IC) Ltd, Israel
Lines: 34

In article <7943@cs.Buffalo.EDU> bowen@sunybcs.UUCP (Devon E Bowen) writes:
>In article <944@gould.doc.ic.ac.uk> dcw@doc.ic.ac.uk (Duncan C White) writes:
>>>	2) variable number of parameters passed to a function.
>>
>>Presumably when you pass a variable no of parameters to a function, type-
>>checking goes out of the window?
>
>Right. This is being included to take advantage of the variable parameter
>C I/O like printf, etc. The cleanest way to do this is to define a new
>procedure type (maybe "cprocedure") that tells the system to just accept
>any parameters with no type checking. This still leaves it as an extension
>that will not break the standard language.
>
Another approach that we used here was to define a pseudo-module, i.e. a module
that doesn't actually exist but is built into the compiler (like module SYSTEM).
All objects imported from this module have the following properties:

	i.	The object must be a procedure.
	ii.	No type checking is performed on parameters.
	iii.	The procedure can receive any number of parameters.
	iv.	The procedures can be called either as a procedure or as a
		function.
	v.	Values returned by such procedures are of type WORD, i.e. can be
		coerced to any type of the same size.

Cheers,
Avi Bloch
National Semiconductor (Israel)
avi%taux01@nsc
-- 
	Avi Bloch
National Semiconductor (Israel)
6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel		Tel: (972) 52-522263
avi%taux01@nsc