Subject: RE: [sv-cc] DirectC: passing by name, restrictions
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Feb 26 2003 - 23:18:31 PST
Andrzej, Michael,
Two comments on this debate:
1) Remember, in language definition, it is generally better to
start out overly restrictive, and then later remove restrictions.
Starting out generous and adding restrictions later to fix
problems is always bad.
2) As far as Andrzej's final quandary goes:
> Unfortunately, we seem to have two conflicting guidelines:
> - formal argument names in prototypes are optional and meaningless,
> may be generally ignored for the sake of convenience
> - names of formal arguments shall be unique and consistent,
> in order to avoid confusion
I would be perfectly happy to remove the first guideline.
I think all prototypes should always have named parameters.
Consistency with native SV functions is important.
The "generosity" of allowing unnamed prototype arguments
doesn't really buy users much, and it leads into
confusing debates as evidenced here.
Regards,
Doug
> -----Original Message-----
> From: Andrzej Litwiniuk [mailto:Andrzej.Litwiniuk@synopsys.com]
> Sent: Monday, February 24, 2003 2:44 PM
> To: Michael.Rohleder@motorola.com
> Cc: sv-cc@server.eda.org
> Subject: Re: [sv-cc] DirectC: passing by name, restrictions
>
>
> > > I would recommend more stringent restrictions.
> > > [...]
> > > b) arguments may be passed by name only for the external
> functions that have
> > > all their formal arguments named
> >
> > > c) if multiple external declarations specify the name of
> a formal argument,
> > > than the names must be the same.
> > > In other words, a name is still optional, but if
> specified, it becomes
> > > a part of definition. Repeated declarations must
> either use the same name
> > > or not specify the name.
>
>
> Michael wrote:
> > From what I see the only difference is on b) You require that
> > there is always a name.
> > I propose that we require either a name for an argument OR
> a default value.
>
> So, you would allow a mix: part of parameters have names,
> part of parameters
> have default values (some may have both a name and a default value).
> Something like in the following 4 versions of external declaration?
>
> extern void foo(int); // the simplest case
> extern void foo(int i); // optional name
> extern void foo(int i = 1); // optional name AND a
> default value
> extern void foo(int = 1); // only a default value ????
>
> The last case looks weird ...
>
>
> I don't require that "there is always a name"; I require this
> only for
> a function for which the passing by name is to be used.
> Shortly, I require that naming is consistent and all
> parameters must be named
> in order to allow passing by name for a given function.
> Please note that the above requirements are met by the native
> SV functions!
> All formal parameters are named and names are consistent
> (since there is no way
> to re-name the formals).
>
>
>
>
> Michael wrote:
> > on c) You require that all names for a formal argument
> match or are left
> > unspecified [although think this collides with your rule in b)]
>
> No, there is no collision or contradiction. b) is required
> only for functions
> for which the passing by name is used. If this feature is not
> used for
> a specific function, that the names of formal arguments are
> optional for that
> functions, yet must be consistent in multiple declarations.
>
>
> Michael wrote:
> > I have to admit I didn't think about conflicting names as
> you defined within
> > your example. I still believe that with the restrictions I
> stated already
> > PLUS forbidding to use the same name for different formal
> > parameters, it would be possible to solve this issue. So
> > extern void foo(int count = 13, bit status = 1);
> > extern void foo(int i = 13, bit status = 1);
> // different names
> > is correct and can always be properly solved:
> > foo(status = 0, count = 4); // O.K.
> > foo(status = 0); // ambigous, but the default
> value is the same.
> > It is still the _same_ Direct C function!
> > foo(count = 1); // O.K.
> > foo(i =2); // O.K.
> > foo(); // ambigous, but see above.
>
> Consider the two calls from your example: foo(count = 1); foo(i = 1);
> One may think that they assign 1 to different formal argument
> (and use default
> values for the remaining arguments). Actually both names
> refer to the same
> argument. Isn't it a bit confusing? What do we gain by that
> kind of ambiguity?
>
> Then, what do you mean by "forbidding to use the same name
> for different formal
> parameters"? The same name within a single declaration?
> Within a family of all
> declarations of a function?
>
> IMO all multiple declarations of the same functions shall
> carry the same
> relevant information, so any of the multiple declarations
> could be chosen
> both by the user and by the compiler to guide them.
> Optional formal argument names are irrelevant for passing by
> position and are
> relevant for passing by name.
>
> Unfortunately, we seem to have two conflicting guidelines:
> - formal argument names in prototypes are optional and meaningless,
> may be generally ignored for the sake of convenience
> - names of formal arguments shall be unique and consistent,
> in order to avoid confusion
>
> I'm not happy with either solution.
>
> Regards,
> Andrzej
>
This archive was generated by hypermail 2b28 : Wed Feb 26 2003 - 23:19:11 PST