RE: [sv-ec] Mantis 2279 (randomize syntax feedback)

Jonathan, 

> > 1. If all three are the same construct and the A.8.2 BNF is 
> changed as 
> > in the proposal, then I don't see why the two syntax boxes 
> in Clause 
> > 17 should be inventing new non-terminals with new names and saying 
> > that they are not in Annex A.
> 
> Fair enough, but that is not an artifact of 1858; it's been 
> in the LRM for some time.  We could take this opportunity to fix it.

Agreed.


> > It's true that the scope_randomize in Syntax 17-10 is a 
> reduced form 
> > that omits all the non-relevant parts, but the 
> > inline_constraint_declaration in Syntax 17-9 seems exactly the same 
> > except for the prefixed class_variable_identifier. I don't 
> think that 
> > justifies a new syntax and a new name for the non-terminal.
> 
> I think I agree.  It would probably be better to duplicate 
> the relevant syntax from A.8.2 and G.4 rather than rewriting it.
> 
> > 2. The scope_randomize in Syntax 17-10 allows [std::]. The BNF in 
> > A.8.2 does not seem to allow it with the prefix, only if 
> you prefix it 
> > with [package_scope ] as tf_call allows you to do, but not via 
> > randomize_call.
> 
> I had overlooked the fact that package_scope cannot be 
> applied to randomize_call.
> 
> I suppose that the original writers of the BNF thought that 
> the description in Annex G is sufficient to cover scope 
> randomize, and the randomize_call production in A.8.2 was 
> intended only to apply to object.randomize.

randomize_call is allowed in the BNF as a general expression as

subroutine_call ::=
  tf_call
| system_tf_call
| method_call
| randomize_call

Originally in the BNF, it was only for object randomize and then it was
widen to scope randomize as well.

I suspect that when it was incorporated into the BNF, someone just
forgot that it could be prefixed by std::. I guess this could be fixed
by changing this line in subroutine_call to "| [std::] randomize_call". 


>  But I don't 
> think this is good enough.  The syntax of std::randomize 
> cannot be explained-away as a function prototype, because of 
> its "with{}" syntax.  So I would be far happier to have Annex 
> G appeal to the randomize_call production in some way.
> I know that is somewhat outside the spirit of std:: as a 
> package; but, until users can write their own subprograms 
> that have a with{} construct, it is disingenuous to pretend 
> that std::randomize() is simply a function prototype that can 
> be isolated in Annex G.
> 
> > 3. The description of std::randomize() appears also in G.4 with yet 
> > another syntax:
> ...
> > I'd like to see the syntax be consistent throughout.
> > Note that scope_randomize in Syntax 17-10 also allows an empty 
> > variable_identifier_list whereas this syntax does not.
> 
> Clearly it should, because - as you say -
> 
> > 17.12 says, "If
> > the scope randomize function is called with no arguments, then it 
> > behaves as a checker and simply returns status." What does 
> "behave as 
> > a checker" mean? What status does it return?
> 
> Presumably it tests all its with{} constraints and returns a 
> true/false result?

I think the LRM needs to be clearer here.


>  For consistency with object.randomize it 
> would make sense to permit a "null" argument here.
>  
> > The syntax in G.4 also should not end in a semicolon, I think.
> 
> OK.  Again it's nothing to do with 1858, but this seems a 
> good moment to fix such things.
>  
> > 4. I think the two footnotes in the BNF in the proposal should be 
> > combined into a single footnote at the end of the production.
> 
> If you prefer it, that's fine by me - I thought it was easier 
> to describe them if the footnote markers were attached to the 
> bit of syntax they affect, but it's easy to change.
> 
> I'll upload an alternative proposal in the next few hours.
> I'm concerned that we are widening the scope of 2279 and it 
> may take longer than anticipated to reach a conclusion.

Yes.

Let's do what we reasonably can with a consensus in the little time we
have and file a new Mantis on what ever remains.

Thanks for handling this.

Regards,
Shalom
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


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