Re: [sv-bc] mantis 2549 - ommiting parenthesis in f-call

From: Gordon Vreugdenhil <gordonv_at_.....>
Date: Fri Jun 19 2009 - 06:46:44 PDT
Daniel Mlynek wrote:
> Thank you Steven.
> 
> I assume that the answer for my last question:  
> "4. Should the same rules be valid for randomize_call where BNF defined that
> for std::randomize () are obligatory, and for randomize method can be
> ommited - which rules take precedence?" 
> is that the same rules as for usual function/method calls should be in power
> when talking about randomize_call.
> 
> DANiel
> 
> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com] 
> Sent: 18 czerwca 2009 20:20
> To: sv-bc@eda.org; daniel.mlynek@aldec.com
> Subject: Re: [sv-bc] mantis 2549 - ommiting parenthesis in f-call
> 
> 
>> From: "Daniel Mlynek" <daniel.mlynek@aldec.com>
> 
>> 1. As I understand in call to task,  "void function", "void method
> function"
>> parenthesis can be ommited ( am I right?)
> 
> This is correct.  The reason is that there is no possible ambiguity.  An
> identifier used as a statement must be a call to a task (or void function).
> 
> 
>> 2. What if "nonvoid function" or "non-void function method" is called 
>> like a task - return value is discarded
> 
> Technically, the LRM defines it by what you are calling, not by how it is
> called.  However, the same reasoning applies here as in the void function
> case, so I don't see a reason it could not be allowed.


Steven, the reason that was not allowed (intentionally!) was for
things like vcd related systf routines which for historical reasons
allowed task/function scope names as args.  If you then had a
bare function name you would either have to make an explicit
exception for those routines or have legacy compatibility issues.


Gord

> 
>> 3. For "nonvoid-function  method" behaviour is desribed but what about 
>> "nonvoid function" the behaviour should be the same as for method or 
>> parenthesis cannot be ommited at all?
> 
> For a non-void non-method function, the parentheses cannot be omitted.
> 
> 
> Steven Sharp
> sharp@cadence.com
> 
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Jun 19 06:50:35 2009

This archive was generated by hypermail 2.1.8 : Fri Jun 19 2009 - 06:51:26 PDT