Re: [Help-jel] JEL 2.1.0

[Konstantin L. Metlov]

Dear Mark,

OK, I'll have a look at these.

For now I can say the following: 1) is due to me trying to reduce the
compiler size. I guess nowadays with the fast Internet connections we all
have this is not such a pressing concern. I will add the separate error
messages for numbers. 2) was also mentioned by Philip in his letter to me.
Currently JEL can convert between double and java.lang.Double, but it does
not try to cast primitives into java.lang.Number or java,lang.Object
classes. I can certainly add this. If I remember well, the primitive type
wrapping/unwrapping was implemented in JEL prior to Java, that's why it
does not conform to the current JLS as it should.

The automatic conversion of large constants to long has the potential to
break things when dealing with integers on the border of their value
ranges (e.g. 0xffffffff is -1 or 4294967295L ?). I think I'd better stick
with JLS here.

With the best regards,
                           Konstantin.

> Dear Konstantin,
>
> On Sat, 2 Jan 2016, Konstantin L. Metlov wrote:
>
>> JEL 2.1.0 is released. You can get it from
>> http://www.gnu.org/software/jel/ .
>>
>> The new features are:
>>
>> * Support for methods with variable number of arguments.
>> * Warnings cleanup (introduces a minor incompatible API change, hence
>> the
>>   more significant version bump).
>> * Deprecated gnu.jel.Library constructors removal.
>
> This is great, many thanks.  The variable argument support will make
> it possible for my users to do some things they couldn't do before,
> and much more convenient to do some others.  I'm in the process
> of incorporating it into my application.
>
> I have a couple of queries (bug reports?) to make:
>
> 1. It looks like auto-boxing doesn't work on primitive arguments
>    of vararg methods.  That's not necessarily a JEL bug (maybe it's
>    not supposed to do that), but it seems to behave differently than
>    the Java language.  Here is an example:
>
>       import gnu.jel.Evaluator;
>       import gnu.jel.Library;
>
>       public class VarBox {
>
>           static Object eval( String expr ) throws Throwable {
>               Library lib = new Library( new Class[] { VarBox.class },
>                                          null, null, null, null );
>               return Evaluator.compile( expr, lib ).evaluate( null );
>           }
>
>           public static String concat( Object... args ) {
>               StringBuffer sbuf = new StringBuffer();
>               for ( Object o : args ) {
>                   sbuf.append( o );
>               }
>               return sbuf.toString();
>           }
>
>           public static void main( String[] args ) throws Throwable {
>               System.out.println( concat(1,2,3) );  // succeeds
>               System.out.println( eval( "concat(1,2,3)" ) );  // fails
>           }
>       }
>
>    The evaluation fails with:
>
>       Exception in thread "main" gnu.jel.CompilationException: Function
> "concat" exists but parameters "concat(byte,byte,byte)" can not be
> accepted by it.
>             at gnu.jel.Library.getMember(Library.java:303)
>             ...
>
> 2. If you call the Library.markStateDependent() method for a method
>    that doesn't exist, e.g.:
>
>       new Library(new Class[0],null,null,null,null)
>      .markStateDependent("not_a_method",new Class[0]);
>
>    it reports an assertion failure:
>
>       Exception in thread "main" java.lang.Throwable: Assertion failed.
>            at gnu.jel.debug.Debug.check(Debug.java:85)
>            ...
>
>    as well as the CompilationException.  This doesn't cause me trouble,
>    but it looks like it shouldn't happen.
>
> Finally, I have one minor (I hope) enhancement request.
> When JEL encounters a numeric literal that looks like an integer
> but exceeds the 32-bit capacity, it generates a CompilationException
> with a message like (for instance) "Encountered unexpected end of
> expression" or "Encountered unexpected character".  Of course I
> understand why it's doing this, and from a parsing point of view
> it makes perfect sense.  However, from the point of view of my
> users (astronomers, definitely not java language experts) it's
> very hard to understand what they've done wrong and how to fix it
> (append an 'L' to the literal).  It would be great if the
> CompilationException message could report something like
> "integer literal 3000000000 too long, try appending 'L'".
> It would be even better if it could just silently interpret
> such oversize integer-like literals as legal longs rather
> than failed ints - however, that would depart from java language
> syntax, so I'd understand if you don't want to do that.
>
> Again, thanks for your work, and happy new year.
>
> Mark
>
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> address@hidden +44-117-9288776  http://www.star.bris.ac.uk/~mbt/
>