RE: Default parameter values for methods

I'm thinking that I'm probably against named parameters. I'd like to see e
maintain a more C/C++ look-n-feel rather than lean more towards a verilog/SV
one.

 

But it is a matter of coding style -- can't argue for the technical merits
independently.

 

Cheers,

 

-Stylianos.

 

 

From: owner-ieee1647@server.eda.org [mailto:owner-ieee1647@server.eda.org]
On Behalf Of Matan Vax
Sent: Monday, June 15, 2009 4:09 AM
To: Srinivasan Venkataramanan; ieee1647@server.eda.org; Uwe Simm
Subject: RE: Default parameter values for methods

 

Hey Srini,

 

Thanks for this comment. I'm ashamed to admit I wasn't even aware that SV
supports named parameter syntax inside function calls. This is more elegant
IMO than the empty expression placeholder. It's especially important when
there are many parameters, many of which have defaults (but I don't think
this happens too often).

 

One problem here is that in e (like in C++, Java, etc.) parameter names are
not considered part of the method signature. In other words, when you
override a method you must restate the number and types of the parameters,
but you don't have to give them the same name as in the initial declaration.
I guess we could restrict the named parameter reference to names given in
the declaration. Having done that, we may choose to relax the requirement to
designate defaults to all rightmost parameters.

 

By the way, named parameters can be emulated with the following simple
design pattern: declare a class that wraps all parameters of the method, and
assign them their default values in construction (init() method). So an
actual call may look like:

 

   my_struct.foo(new with { .a = FALSE; .c = TRUE; }); // use default for
parameter b

 

Obviously this involves some memory allocation overhead, but in most cases
it is negligible. You can even use a macro to make the syntax look more like
SV...

 

I'm not sure how important this is. What do you think?

 

Matan.

 

  _____  

From: Srinivasan Venkataramanan [mailto:svenka3@gmail.com] 
Sent: Friday, June 12, 2009 2:27 PM
To: Matan Vax
Cc: Uwe Simm; ieee1647@eda.org
Subject: Re: Default parameter values for methods

 

Matan et al.,

   I certainly see a good need for this "default values for
arguments/parameters" in e. So I support this inclusion. As far Uwe's
example goes, how about adding "named association" for the method
parameters? In that case the example could be:

 

>> Instead of: foo(,,,TRUE)

 

foo(.param_to_override(TRUE )); // Not necessarily exact syntax, but
indicative

 

BTW, Verilog/SV allows both the above styles, not to say e should or
shouldn't, just a data point.

 

Thanks

Srini

www.cvcblr.com

 

 

On Thu, Jun 11, 2009 at 3:30 PM, Matan Vax <matan@cadence.com> wrote:

Hey Uwe,

Thanks for these questions. Here is a first take:

Default values must be compile-time constants so there is no specific
scope for their evaluation. This restrictive semantics is inline with
other languages and easily covers most applications (variable defaults
can often be emulated procedurally once a constant default has been
designated).

It complicates the syntax of the language if we introduce empty
expressions as in "foo(,,,TRUE)". I see no reason to go beyond other
languages on this one. It's typically natural to order parameters of a
method in such a way that the ones with defaults are at the end in
descending order of likelihood for overriding.

Hope this makes sense to you.

Matan.

>-----Original Message-----
>From: Uwe Simm
>Sent: Thursday, June 11, 2009 12:34 PM
>To: Matan Vax
>Subject: FW: Default parameter values for methods
>
>hi matan,
>
>other important questions with default args are:
>
>- in what scope are expressions for default args computed ?
>
>- what are legal expressions for default args? are they compile time
>constants, "elab" time const, instance const, fields?
>
>- do you also want default args supported in other position other than
in
>the tail of function args?
>  something like "foo(,,,TRUE)" ?
>
>btw: i didnt post this one to the reflector but feel free to forward
>
>regards
>/uwe

>
>
>-----Original Message-----
>From: owner-ieee1647@eda.org on behalf of Matan Vax
>Sent: Thu 2009-06-11 09:28
>To: darren.galpin@infineon.com; ieee1647@eda.org
>Subject: RE: Default parameter values for methods
>
>Hey Darren,
>
>
>
>What I propose is simply to adopt the standard approach to default
>parameters. The values provided in the method call get associated with
>parameters simply in order from left to right. The types of the
>expressions do not affect this strict in-order correlation (so a
>parameter type mismatch is reported in the usual way). There is no way
>to provide in a method call a value for a parameter without providing
>values for all parameters preceding it. Similarly in a method
>declaration if a parameter with default is followed by a parameter
>without default a compile time error is issued.
>
>
>
>Following your code example:
>
>
>
>extend sys {
>
>    // this is the syntax I have in mind, similar to other languages
>
>   my_method(a: bool = TRUE, b: bool = FALSE) is {
>
>      // ...
>
>   };
>
>
>
>   run() is also {
>
>      my_method(); // the two defaults are used
>
>      my_method(FALSE); // the default for the first parameter is
>overridden, the second is still used
>
>      my_method(FALSE,TRUE); // both defaults are overridden
>
>   };
>
>};
>
>
>
>Hope this clarifies things.
>
>Matan.
>
>
>
>________________________________
>
>From: darren.galpin@infineon.com [mailto:darren.galpin@infineon.com]
>Sent: Thursday, June 11, 2009 9:47 AM
>To: Matan Vax; ieee1647@eda.org
>Subject: RE: Default parameter values for methods
>
>
>
>Hi Matan,
>
>
>
>It seems like a good idea, but I have a few questions about this, as I
>may be misunderstanding a few things.
>
>
>
>Firstly, you have a method, such as:-
>
>
>
>a: default=TRUE; -- An example, syntax will obviously be different
>
>b: default=FALE; -- As above.
>
>my_method(a: bool, b: bool) {
>
>};
>
>
>
>Normally you would then call the method as follows:-
>
>
>
>my_method(TRUE, FALSE);
>
>
>
>Which is fine, but if you do not provide all of the parameters, then
>what happens in the following case:-
>
>
>
>my_method(FALSE);
>
>
>
>Which of the two boolean parameters have I set, and which of the two
>have I missed? It isn't clear to me from the description how this would
>operate.
>
>
>
>Perhaps others could comment? Should we include it?
>
>
>
>Cheers,
>
>
>
>Darren
>
>
>
>________________________________
>
>From: owner-ieee1647@server.eda.org
>[mailto:owner-ieee1647@server.eda.org] On Behalf Of Matan Vax
>Sent: Wednesday, June 10, 2009 6:54 PM
>To: ieee1647@server.eda.org
>Subject: Default parameter values for methods
>
>Hello all,
>
>
>
>As you probably know, many object-oriented languages allow declaring
>default values for method parameters. Specifically in our domain both
>SystemC (C++) and SystemVerilog support it. The principle is simple -
if
>a default value is designated for some parameter in the method
>declaration providing the parameter in the call becomes optional. If
>provided, the user's parameter overrides the default, and otherwise the
>default is passed to the method body. Upon method call parameters are
>resolved in order, so all parameters with defaults must be placed at
the
>end of the parameter list.
>
>
>
>This mechanism can be used to simplify functional APIs of core
>libraries, verification IPs, and other packages. When introducing some
>operation, library designers often face the dilemma of either defining
a
>single method and forcing the user to provide all possible parameters,
>including trivial ones (NULL, UNDEF, 0, or whatever the natural default
>happens to be), or defining multiple method variants with different
>parameter sets, each with its own name. Both obscure the natural
>semantics of the operation. Note that method overloading may have
>similar impact, but is much more complicated to define and implement.
>
>
>
>So I propose we consider adding this capability to the e standard (and
>obviously implement it in tools, Specman in particular). Defining it
>formally is relatively straightforward and I volunteer to do it if I
get
>green light from this forum.
>
>
>
>What do you say?
>
>Matan.
>
>
>
>
>--
>This message has been scanned for viruses and

>dangerous content by MailScanner <http://www.mailscanner.info/> , and

is
>
>believed to be clean.
>
>
>--
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
>
>
>


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

 


-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.