RE: Default parameter values for methods

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.