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 MailScanner, and is
believed to be clean.