Re: [sv-ec] Re: Feedback from Freescale on name resolution issues

Jonathan,

The "item." form was suggested quite a while ago.  I have backed
off of that since it isn't strictly compatible -- there would
be an ambiguity in terms of which rules to follow in cases where
"item" was a field name in the class.  This is a particularly
pedantic concern, but since at the time I was the only one arguing
for a change, I wanted to remove any roadblock so I came up with the
"randomize with (...) {...};" form to remove the compatibility
objection.  The only other concern would be that if you then
had a local declaration "item", you wouldn't be able to name
that in the constraint in some cases.  Since that issue relates
to a single known name "item", I don't consider that to be a
major point of objection.



I would certainly be in favor of a strict "item." rule such
as you are suggesting as long as everyone understands that
there is a minor compatibility issue with such a change.


I've been pushing for a change in this area for a long time --
if we can get some consensus on this, I don't think the actual
change to the LRM is very substantial.


Given the two options:
   1) having the existence of "item." mean "use normal binding
      rules with the 'item' prefix referring to the object"
or
   2) having the "randomize with ( ident_list) {...}" syntax mean
      "use only the identifiers in ident_list as implicitly binding
      into the object"


Would anyone seriously object to either approach?


Given feedback on the reflector and from our customers, I'd
actually prefer to deprecate the current rules completely but
I don't think that is feasible at this point.


Gord.




Jonathan Bromley wrote:
>> I was thinking about the class randomize using the object RNG and
>> std::randomize using the thread RNG. Attached is an example where
>> changing to the thread RNG has a unwanted result. In the example, the
>> random sequences in the two instances become the identical - which is
>> likely not what is wanted.
>>
>> But to me, the real issue is that you (Freescale) see a need 
>> to develop a methodology that doesn't use the class randomize
>> method - because you don't want unexpected behavior. That in
>> itself says to me that the class randomize is broken - and
>> needs to be fixed. 
> 
> A couple of observations, from someone who (note carefully) has
> minimal experience of Vera but who knows 'e' well:
> 
> I was fascinated (horrified?) to see the suggestions from 
> Arturo and others that we use std::randomize if we want 
> different name resolution rules.  I confess that this idea 
> had never before crossed my mind, but it is spectacularly 
> counter-intuitive and confusing that the two forms have 
> such (potentially) widely different behaviour. And, of 
> course, there is the issue about thread stability and 
> seed control.
> 
> The idea that inline constraints should silently favour
> resolution into the target object has always seemed absurd
> to me.  I'm sure that Vera users would disagree, but 
> note that 'e' treats all names in an inline constraint
> in the same way as names in the context in which it appears,
> except that the special name "it" is a handle to the object
> being randomized.  This seems to me to be easier to read and 
> debug, less error-prone, and more natural.  And of course it
> makes it trivially easy to refer to local automatic variables
> from expressions in the constraint.
> 
> Personally, I have always regarded it as a major usability 
> flaw that you can't already use "item." in an inline 
> constraint to malke an explicit reference into the object
> being randomized (and, note, that could perfectly well
> work for std::randomize too, if it were randomizing a
> class object).  And the various suggestions about
> "obj.randomize() with (var1, var2) {constraints}"
> seem to me to be obscure, even though they allow us to
> get backward compatibility.
> 
> Is there any possibility that we could permit the use of
> "item." in inline constraints, and then decree that 
> if "item." appears *anywhere* in the constraint block, 
> the name binding rules change for the *whole* of the 
> constraint block?  That would permit the current form
> to be preserved for backward compatibility and, perhaps,
> for future deprecation.

-- 
--------------------------------------------------------------------
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.