Re: [Help-jel] JEL 2.1.0

[Mark Taylor]

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/