Your proposed 'without (thing)' case still gives me the willies. For one, as you mention it does break backwards compatibility in that simple names in an inline constraint will no longer bind locally. This will make the name binding rules clearer, but the expense of trashing everyone's existing inline constraints I think is too much (I do believe it's common to expect mixed object and local scope binding of simple names). Second, it doesn't address the issue of what prefix to use when we want to bind to a local automatic, such as a function formal. So far, I'm thinking that the right thing to do is to just leave the 'without (thing)' case as it is today. I am, however, liking more and more the 'with (thing)' case, particularly with the stipulation that identifiers without the "thing" prefix _must_ bind normally (i.e., starting in the innermost local lexical scope and searching out from there in the normal way, no looking into 'obj' at all). This allows exactly what I've been after - a pure extension (no breaking of backwards compatibility) that allows us to unambiguously specify which direction we want things to bind with minimal syntactic goofing around. By the way, I hadn't considered the problem of an "obj.<whatever>" reference to a missing field going off through the hierarchy (Arturo's "desperate binding"). I agree that that's no good and needs more syntax to avoid. --Mike Rich, Dave wrote: > That's easy to deal with for the 'without (thing)' case. Just make > another exception to the prefix rules (prefix with obj. except if > prefixed with :: or this.) > > For the 'with (thing)' case, you are being explicit that 'this' refers > to 'obj'. If you are doing > > this.randomize with (this) {this.x < this.y} > > That would be equivalent to > > randomize with {x < y} > > But now you could do > > randomize with (this) {this.x < this.y + z} > > and you would be explicit that z binds locally. > > > Dave > > > >> -----Original Message----- >> From: Neil.Korpusik@Sun.COM [mailto:Neil.Korpusik@Sun.COM] >> Sent: Tuesday, October 23, 2007 6:35 PM >> To: Rich, Dave >> Cc: Michael Burns; sv-ec@eda.org >> Subject: Re: [sv-ec] Re: Feedback from Freescale on name resolution > issues >> Hi Dave, >> >> I had also considered using 'this' but came to the conclusion that it >> would >> lead to possible confusion. Consider the following example: >> >> class A; >> rand int x; >> rand int y; >> endclass >> >> class B; >> rand int x; >> rand int y; >> A obj; >> function f1(); >> obj.randomize with {this.x < this.y}; <---- which x and y? >> endfunction >> endclass >> >> Neil >> >> >> Rich, Dave wrote On 10/23/07 06:19 PM,: >>> Mike, >>> >>> You've come full circle, so maybe you seen the world now. >>> >>> The problem has always been that if the compiler also expects to > bind >>> into the object, wouldn't the user expect to get an error message if > it >>> didn't find it, and not start searching upwards for some irrelevant >>> variable? >>> >>> Here is a possible compromise to suggestion (7) that might have the >>> least backwards compatibility issues. >>> >>> Without (thing), >>> >>> obj.randomize with {x < y}; >>> >>> This prefixes x and y with obj. (or this.) except if they are > already >>> prefixed by name::. That means that if x or y were not in obj, it > would >>> be an error. >>> >>> With (thing) >>> >>> obj.randomize with (thing) {x < thing.y}; >>> >>> This assumes x will be searched with standard name binding rules >>> (whenever we finish that) and that y is inside obj. I hope that > 'thing' >>> would allow 'this' or 'obj'. >>> >>> Dave >>> >>> >>> >>>> -----Original Message----- >>>> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] >>> On >>> >>>> Behalf Of Michael Burns >>>> Sent: Tuesday, October 23, 2007 5:13 PM >>>> To: Burns Michael-RA4884 >>>> Cc: Vreugdenhil, Gordon; Neil.Korpusik@Sun.com; Jonathan Bromley; > sv- >>>> ec@server.eda.org >>>> Subject: Re: [sv-ec] Re: Feedback from Freescale on name resolution >>> issues >>> >>>> Following on to my own message, I should reiterate that our users >>> _expect_ >>> >>>> to >>>> bind preferentially into the object. They like the way things work >>> today; >>> >>>> they >>>> just want a way, when writing reusable VIP with type parameters or >>> other >>> >>>> kind of >>>> opaque types, to "bulletproof" the VIP so that it's impossible to > get >>> any >>> >>>> unintended binding. Note that the problematic case is pretty narrow; >>> the >>> >>>> vast >>>> majority of our inline constraint usage today and in the so-called >>>> foreseeable >>>> future is not problematic. >>>> >>>> I'm also less enamored of the std::randomize() approach than I was >>> last >>> >>>> week; >>>> we've put a lot of effort into managing our random stability and I >>> don't >>> >>>> want to >>>> mess it up. Plus, there's no reason why our need for disambiguation >>> should >>> >>>> be >>>> indivisibly bound with how random seeds are managed (thread vs > object) >>> - >>> >>>> the two >>>> should be orthogonal. >>>> >>>> --Mike >>>> >>>> Burns Michael-RA4884 wrote: >>>> >>>>> Hi folks, >>>>> >>>>> In our methodology, I think it would be quite rare to have a >>> cumbersome >>> >>>>> select >>>>> prefix - we're going to do our inline constraining in some kind of >>>>> testcase-specific driver object and the object we're randomizing >>> will be >>> >>>>> a local >>>>> data member of that driver class or a function automatic which we >>> access >>> >>>>> using a >>>>> simple name. Our testbench people expect to use Neil's syntax, and >>> don't >>> >>>>> see a >>>>> problem with it. >>>>> >>>>> The real issue I'm concerned about is not how to explicitly specify >>>>> binding into >>>>> the object, but how to explicitly specify binding into the local >>> lexical >>> >>>>> scope. >>>>> I think that's where we need the enhancement. >>>>> >>>>> --Mike >>>>> >>>>> Gordon Vreugdenhil wrote: >>>>>> >>>>>> Neil Korpusik wrote: >>>>>>> Jonathan Bromley wrote On 10/23/07 01:45 AM,: >>>>>>>> (7) In a modification of suggestion (2): instead of putting >>>>>>>> a list of names in the parens, provide just one > identifier, >>>>>>>> freely chosen by the programmer, which is to be treated as >>>>>>>> an alias for the object being randomized: >>>>>>>> obj.randomize() with (thing) {thing.x < thing.y + x;}; >>>>>>>> >>>>>>> Perhaps I am missing something here. >>>>>>> >>>>>>> Why can't we just use the following? Since obj is the thing >>>>>>> being randomized, why can't we just use 'obj.' when we need to >>>>>>> specify that the variables used in the with clause are within >>> obj? >>> >>>>>>> obj.randomize() with {obj.x < obj.y + x;}; >>>>>> Neil, I think that this would effectively remove the current >>>>>> special rules. In addition, this is painful if "obj" is a >>> general >>> >>>>>> select prefix -- users would want/need to create a temporary >>> handle >>> >>>>>> of the appropriate type to have manageable constraints. >>>>>> >>>>>> Gord. >>>>>> >>>>>> >>>>>> >>>> -- >>>> This message has been scanned for viruses and >>>> dangerous content by MailScanner, and is >>>> believed to be clean. >>> >>> >> -- >> --------------------------------------------------------------------- >> Neil Korpusik Tel: 408-276-6385 >> Frontend Technologies (FTAP) Fax: 408-276-5092 >> Sun Microsystems email: neil.korpusik@sun.com >> --------------------------------------------------------------------- > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Oct 24 20:21:15 2007
This archive was generated by hypermail 2.1.8 : Wed Oct 24 2007 - 20:21:41 PDT