You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After examination, here's what it looks like to me is causing problems:
add.lj: For equality checks between an int and a double, type inference is not unifying the int to a double
counterexample.lj: Not instantiating functions properly when objects are involved as parameters
list_remove.lj: Java's ArrayList has a method for remove that can take either an index or an element to be removed. It looks like LJ assumes the call is to the method that takes the actual element, so giving it an index instead breaks it. An interesting note is that for Integer lists, the method for removing the given element rather than the element at the given index will always be selected since LJ represents all ints as Integers in the java code.
primative-numbers.lj: Two problems here. One is the same equality problem as add.lj, and the other is a floating point issue that cannot be avoided.
z.lj: The compiler doesn't like having a function called with an argument of a variable whose name is the same as its parameter, but I'm not sure exactly why yet. Interestingly, adding 0 to the argument makes it work again.
On closer inspection I see that LJList has a removeAt method that removes an element at an index. There's a discrepancy between the compiler and the java source for LJList though. The compiler expects removeAt to return something, but the implementation doesn't return anything. Changing
b = a.remove(0)
to
b = a.get(0)
b.removeAt(0)
makes the program run as intended. This problem is also a static analysis problem, since static analysis should catch that a.remove would expect a String for the parameter instead of an Integer.
Activity
hinescd commentedon Oct 3, 2019
After examination, here's what it looks like to me is causing problems:
add.lj: For equality checks between an int and a double, type inference is not unifying the int to a double
counterexample.lj: Not instantiating functions properly when objects are involved as parameters
list_remove.lj: Java's ArrayList has a method for remove that can take either an index or an element to be removed. It looks like LJ assumes the call is to the method that takes the actual element, so giving it an index instead breaks it. An interesting note is that for Integer lists, the method for removing the given element rather than the element at the given index will always be selected since LJ represents all ints as Integers in the java code.
primative-numbers.lj: Two problems here. One is the same equality problem as add.lj, and the other is a floating point issue that cannot be avoided.
z.lj: The compiler doesn't like having a function called with an argument of a variable whose name is the same as its parameter, but I'm not sure exactly why yet. Interestingly, adding 0 to the argument makes it work again.
hinescd commentedon Oct 3, 2019
Amendment to list_remove:
On closer inspection I see that LJList has a removeAt method that removes an element at an index. There's a discrepancy between the compiler and the java source for LJList though. The compiler expects removeAt to return something, but the implementation doesn't return anything. Changing
to
makes the program run as intended. This problem is also a static analysis problem, since static analysis should catch that a.remove would expect a String for the parameter instead of an Integer.
lam2mo commentedon Feb 26, 2020
Fixed by 31556a8.