From dmytro_sheyko at hotmail.com Mon Nov 12 13:42:27 2007 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Mon, 12 Nov 2007 22:42:27 +0100 Subject: [request for review] 4877954: RFE: Special syntax for core interfaces Message-ID: Hi, This is a request for review of patch to KSL, which partially implements bug#4877954 (using relational operators was mentioned there in passing). http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4877954 4877954: RFE: Special syntax for core interfaces Part: Relational operators (<,<=,>,>=) for classes that implement Comparable General rule: if lhs is expression if type that implements Comparable and rhs is expression of type that extends/implements T, then relational expression lhs op rhs is considered identical to lhs.compareTo((Object) rhs) op 0 where op is one of relational operators (<,<=,>,>=) Special cases: 1. Compile time error occurs if lhs or rhs is null (despite null can be casted to Comparable or to any T). 2. Expressions of boolean type (i.e. boolean or Boolean) are considered comparable so that 'false' is less than 'true'. Both operands are evaluated always. 3. If type of lhs and rhs is numeric type (i.e. any of byte, Byte, short, Short, char, Character, int, Integer, long, Long, float, Float, double, Double), then comparison is performed with unboxing (when necessary) and immediate primitive value comparison rather than boxing and invoking compareTo method. This is necessary to be able compare numbers of any primitive or wrapper type with numbers of any other primitive or wrapper type. Another reason is to preserve backward source compatibility since comparison of primitive floating-point numbers is slightly different than comparison of wrappers using compareTo (in cases of -0.0 and NaN). This change is controlled by command line option -XDcomparable. Attached svn diff. -------------- next part -------------- A non-text attachment was scrubbed... Name: RFE4877954-comp.diff Type: application/octet-stream Size: 8949 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20071112/758a85b6/RFE4877954-comp.diff From forax at univ-mlv.fr Mon Nov 12 14:56:20 2007 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Mon, 12 Nov 2007 23:56:20 +0100 Subject: [request for review] 4877954: RFE: Special syntax for core interfaces In-Reply-To: References: Message-ID: <4738DA14.4060708@univ-mlv.fr> Dmytro Sheyko a ?crit : > Hi, Hi, > > > This is a request for review of patch to KSL, which partially implements > bug#4877954 (using relational operators was mentioned there in passing). > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4877954 > 4877954: RFE: Special syntax for core interfaces > Part: Relational operators (<,<=,>,>=) for classes that implement > Comparable Disclaimer i will not comment if this RFE is usefull or not and i'm not a SUN employee. > > General rule: > if lhs is expression if type that implements Comparable and rhs is > expression of type that extends/implements T, then relational expression > > lhs op rhs > > is considered identical to > > lhs.compareTo((Object) rhs) op 0 > > where op is one of relational operators (<,<=,>,>=) I don't see why you want bypass a possible bridge, i.e. lhs.compareTo((Object) rhs) instead of lhs.compareTo(erasure(rhs)). Does your implementation cope enums ? > > > Special cases: > > 1. Compile time error occurs if lhs or rhs is null (despite null can be > casted to Comparable or to any T). > > 2. Expressions of boolean type (i.e. boolean or Boolean) are considered > comparable so that 'false' is less than 'true'. Both operands are > evaluated > always. It seams that Boolean implement Comparable since 1.5, so i assume it's the same semantic. > > 3. If type of lhs and rhs is numeric type i prefer a type that is a subtype of a numeric type, don't forget type variables and wildcards. > (i.e. any of byte, Byte, short, > Short, char, Character, int, Integer, long, Long, float, Float, double, > Double), then comparison is performed with unboxing (when necessary) and > immediate primitive value comparison rather than boxing and invoking > compareTo method. This is necessary to be able compare numbers of any > primitive or wrapper type with numbers of any other primitive or > wrapper type. Another reason is to preserve backward source compatibility > since comparison of primitive floating-point numbers is slightly > different > than comparison of wrappers using compareTo (in cases of -0.0 and NaN). > > This change is controlled by command line option -XDcomparable. > > Attached svn diff. About your patch: - i don't like the fact the compiler is able to perform constant folding on compareTo. Enum#ordinal() or Enum#name() are not evaluated as constant, i don't see why compareTo is different. - introducing all big*Type in Symtab is an error. they should not be stored in the table like that, they are store as Name and not Type (search the comment "initialize builtin types" in Symtab.java) and unlike your solution are loaded using classreader, take a look to Types.boxedClass() and Types.unboxedType(). So i think Lower.visitBinary should be rewrite using Types.unbox() in order to: works with type parameters and wildcards and reuse the current Symtab infrastructure that deals with boxing/unboxing (Symtab.boxedName). minor comment, why in Attr you change tree.lhs.pos() to tree.pos() ? R?mi From dmytro_sheyko at hotmail.com Tue Nov 13 03:17:52 2007 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Tue, 13 Nov 2007 18:17:52 +0700 Subject: [request for review] 4877954: RFE: Special syntax for core interfaces In-Reply-To: <4738DA14.4060708@univ-mlv.fr> References: <4738DA14.4060708@univ-mlv.fr> Message-ID: Thank you for your comments R?mi,see my answer below > I don't see why you want bypass a possible bridge,> i.e. lhs.compareTo((Object) rhs) instead of lhs.compareTo(erasure(rhs)). This was done in order not to choose wrong 'compareTo' method. Let's look at following sample class A implements Comparable { public int compareTo(A a) { ... } public int compareTo(B b) { ... } } class B extends A {...} B x, y; x < y; // here we have to choose either compareTo(A) or compareTo(Object), but not compareTo(B) Class A has 3 'compareTo' methods: 1. compareTo(A) - genuine comparable method 2. compareTo(Object) - bridge to compareTo(A) 3. compareTo(B) - just overloaded, it pretends to be comparable but it's not Current implementation chooses bridge method (in my opinion it is simplest correct implementation for this case), and I agree we should prefer to choose 'genuine comparable method' rather than bridge. > > 2. Expressions of boolean type (i.e. boolean or Boolean) are considered> > comparable so that 'false' is less than 'true'. Both operands are > > evaluated> > always.> It seams that Boolean implement Comparable since 1.5,> so i assume it's the same semantic. Exactly! I had doubts as to permitting relational operators for booleans; and finally I've decided that it would be more natural to permit them (of course, according to Boolean.compareTo()) than not to do so. > > Attached svn diff. > About your patch:> - i don't like the fact the compiler is able to perform constant > folding on compareTo.> Enum#ordinal() or Enum#name() are not evaluated as constant, i don't see> why compareTo is different. Constant folding was performed for numeric comparison before my change, so it seems to me that constant folding should be performed for strings and booleans as well. Why not? BTW, Constant folding is not performed for enums for now. > minor comment, why in Attr you change tree.lhs.pos() to tree.pos() ? Error message "operator.cant.be.applied" is reported from two places: 1. Resolve.java:1639 (report) - if proper operator has not been found, it says that error is at operator position; 2. Check.java:1967 (checkOperator) - if proper operator has been found but it is marked as error, it says that error is at lhs position; I just made error reporting in the second place consistent with the first place. It is not so essential to human, but for tests it is necessary to have predictable and stable error messages. > - introducing all big*Type in Symtab is an error.> they should not be stored in the table like that, they are store as > Name and> not Type (search the comment "initialize builtin types" in Symtab.java)> and unlike your solution are loaded using classreader,> take a look to Types.boxedClass() and Types.unboxedType().> > So i think Lower.visitBinary should be rewrite using Types.unbox() in > order to:> works with type parameters and wildcards and reuse the current Symtab> infrastructure that deals with boxing/unboxing (Symtab.boxedName). Ok, I will think about it. _________________________________________________________________ Explore the seven wonders of the world http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20071113/a33ae64f/attachment.html From dmytro_sheyko at hotmail.com Tue Nov 13 14:30:31 2007 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Tue, 13 Nov 2007 23:30:31 +0100 Subject: [request for review] 4877954: RFE: Special syntax for core interfaces References: Message-ID: Hi, I've made some changes to patch: 1. big*Type in Symtab were removed and Lower.visitBinary() was rewritten using Types.unboxedType() (as Remi Forax suggested) 2. 'genuine comparable method' is choosen rather than its bridge (Lower.visitBinary). 3. bug fixed: following code was mistakenly rejected by compiler: static > boolean lt1(A a, B b) { return a < b; } I have attached new svn diff and jtreg tests I used. -------------- next part -------------- A non-text attachment was scrubbed... Name: RFE4877954-comp.diff Type: application/octet-stream Size: 8350 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20071113/629d8bd7/RFE4877954-comp.diff -------------- next part -------------- A non-text attachment was scrubbed... Name: tests.jar Type: application/octet-stream Size: 9092 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20071113/629d8bd7/tests.jar From forax at univ-mlv.fr Mon Nov 19 05:39:00 2007 From: forax at univ-mlv.fr (=?KOI8-R?Q?Re=27mi_Forax?=) Date: Mon, 19 Nov 2007 14:39:00 +0100 Subject: [request for review] 4877954: RFE: Special syntax for core interfaces In-Reply-To: References:

Message-ID: <474191F4.1050002@univ-mlv.fr> Dmytro Sheyko a e'crit : > Hi, > > I've made some changes to patch: > > 1. big*Type in Symtab were removed and Lower.visitBinary() was > rewritten using Types.unboxedType() (as Remi Forax suggested) > > 2. 'genuine comparable method' is choosen rather than its bridge > (Lower.visitBinary). > > 3. bug fixed: following code was mistakenly rejected by compiler: > > static > boolean lt1(A a, B b) { > return a < b; > } > > I have attached new svn diff and jtreg tests I used. Hi Dmytro, sorry for the delay, great, job, i have just a small remark In Lower.visitBinary(), acmp is used two times with different meanings, import static and local variable, i think the local variable could be renamed. Futhermore, unboxedComparison can be inlined in visiBinary() because it is used only once and the if/else will be more balanced. cheers, Re'mi From Jonathan.Gibbons at Sun.COM Mon Nov 19 14:38:16 2007 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Mon, 19 Nov 2007 14:38:16 -0800 Subject: [request for review] 4877954: RFE: Special syntax for core interfaces In-Reply-To: References:

Message-ID: <47421058.3030008@sun.com> Dymytro, I have read both versions of your request for a review. The most obvious error seems to be in ConstFold, where you are comparing the string value of the constants, which seems unlikely to yield the correct result. In Lower.visitBinary, it seems wrong to drop this code in at the head of the method. If nothing else, I would think you should translate the lhs and rhs first. Then in line 2785, the asymmetry of taking the primitiveType from then lhs seems incorrect, unless you can demonstrate that the lhs and rhs will have the same type. In the tests, you use a relative small set of expressions on either side of the comparables -- for example, I didn't see any expressions either side (other that variables and function calls). Separately, Christian Plesner Hansen is proposing a standardized way of enabling language extensions based on a new -L switch. That seems like a good idea, and it would be nice to standardize on that, rather than using the -XD space which is more for the hidden options we don't really want users to know about :-) -- Jon Dmytro Sheyko wrote: > Hi, > > I've made some changes to patch: > > 1. big*Type in Symtab were removed and Lower.visitBinary() was > rewritten using Types.unboxedType() (as Remi Forax suggested) > > 2. 'genuine comparable method' is choosen rather than its bridge > (Lower.visitBinary). > > 3. bug fixed: following code was mistakenly rejected by compiler: > > static > boolean lt1(A a, B b) { > return a < b; > } > > I have attached new svn diff and jtreg tests I used. From dmytro_sheyko at hotmail.com Tue Nov 20 01:10:59 2007 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Tue, 20 Nov 2007 16:10:59 +0700 Subject: [request for review] 4877954: RFE: Special syntax for core interfaces In-Reply-To: <47421058.3030008@sun.com> References:

<47421058.3030008@sun.com> Message-ID: Thank you, Jonathan and Remi, for your comments.I will send new patch as soon as I prepare it. _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20071120/9f0aad5e/attachment.html From dmytro_sheyko at hotmail.com Thu Nov 22 08:39:15 2007 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Thu, 22 Nov 2007 23:39:15 +0700 Subject: [request for review] 4877954: RFE: Special syntax for core interfaces In-Reply-To: References:

<47421058.3030008@sun.com> Message-ID: Hi, I am presenting new version of the patch, where I was trying to take into account all remarks. Well, see my answer below. In Lower.visitBinary(), acmp is used two times with different meanings,import static and local variable, i think the local variable could be renamed. done. Futhermore, unboxedComparison can be inlined in visiBinary() because it is used only once and the if/else will be more balanced. done. The most obvious error seems to be in ConstFold, where you are comparing the string value of the constants, which seems unlikely to yield the correct result. done. New static method stringValue (like intValue, doubleValue and so on) was added and used. In Lower.visitBinary, it seems wrong to drop this code in at the head of the method. If nothing else, I would think you should translate the lhs and rhs first. I think we shouldn't; lhs and rhs are to be translated recursively after reducing "comparable binary" to "ordinary binary". If we translate lhs and rhs first, they will be translated twice. However, in order to make code a little bit clearer I have divided Lower.visitBinary into visitOrdinaryBinary and visitComparableBinary. Then in line 2785, the asymmetry of taking the primitiveType from then lhs seems incorrect, unless you can demonstrate that the lhs and rhs will have the same type. added assertion. In the tests, you use a relative small set of expressions on either side of the comparables -- for example, I didn't see any expressions either side (other that variables and function calls). added test NestedExpr, however you comments are still welcome how to make test set more complete. Separately, Christian Plesner Hansen is proposing a standardized way of enabling language extensions based on a new -L switch. That seems like a good idea, and it would be nice to standardize on that, rather than using the -XD space which is more for the hidden options we don't really want users to know about :-) not now. I think it has to be separate patch/commit specially for -L switch. _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20071122/d324c43b/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RFE4877954-comp.diff Url: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20071122/d324c43b/RFE4877954-comp.diff -------------- next part -------------- A non-text attachment was scrubbed... Name: tests.jar Type: application/x-zip-compressed Size: 9409 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20071122/d324c43b/tests.jar From dmytro_sheyko at hotmail.com Tue Nov 27 01:38:18 2007 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Tue, 27 Nov 2007 16:38:18 +0700 Subject: [request for review] 4877954: RFE: Special syntax for core interfaces In-Reply-To: References:

<47421058.3030008@sun.com>

Message-ID: Added -L switch From: dmytro_sheyko at hotmail.comTo: compiler-dev at openjdk.java.netSubject: RE: [request for review] 4877954: RFE: Special syntax for core interfacesDate: Thu, 22 Nov 2007 23:39:15 +0700 Hi, I am presenting new version of the patch, where I was trying to take into account all remarks. Well, see my answer below.In Lower.visitBinary(), acmp is used two times with different meanings,import static and local variable, i think the local variable could be renamed. done. Futhermore, unboxedComparison can be inlined in visiBinary() because it is used only once and the if/else will be more balanced. done. The most obvious error seems to be in ConstFold, where you are comparing the string value of the constants, which seems unlikely to yield the correct result. done. New static method stringValue (like intValue, doubleValue and so on) was added and used. In Lower.visitBinary, it seems wrong to drop this code in at the head of the method. If nothing else, I would think you should translate the lhs and rhs first. I think we shouldn't; lhs and rhs are to be translated recursively after reducing "comparable binary" to "ordinary binary". If we translate lhs and rhs first, they will be translated twice. However, in order to make code a little bit clearer I have divided Lower.visitBinary into visitOrdinaryBinary and visitComparableBinary. Then in line 2785, the asymmetry of taking the primitiveType from then lhs seems incorrect, unless you can demonstrate that the lhs and rhs will have the same type. added assertion. In the tests, you use a relative small set of expressions on either side of the comparables -- for example, I didn't see any expressions either side (other that variables and function calls). added test NestedExpr, however you comments are still welcome how to make test set more complete. Separately, Christian Plesner Hansen is proposing a standardized way of enabling language extensions based on a new -L switch. That seems like a good idea, and it would be nice to standardize on that, rather than using the -XD space which is more for the hidden options we don't really want users to know about :-) not now. I think it has to be separate patch/commit specially for -L switch. Get news, entertainment and everything you care about at Live.com. Check it out! _________________________________________________________________ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20071127/31381ab8/attachment.html -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: RFE4877954-comp.diff Url: http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20071127/31381ab8/RFE4877954-comp.diff -------------- next part -------------- A non-text attachment was scrubbed... Name: tests.jar Type: application/x-zip-compressed Size: 9141 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20071127/31381ab8/tests.jar