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
Currently, the JavaScriptLifter is fairly "greedy" about its inlining decisions and mostly inlines expressions whenever possible:
There is a single use of the produced value (or if the expression is pure)
There is no other effectful operation between the operation that produced the expression and the operation using the value (otherwise, inlining would change the semantics of the program)
However, this can lead to somewhat hard to read code. For example things such as
print((new X).a);
or
("1234").foobar();
Currently we manually try to avoid some of these patterns, for example by forcing the constructor value to be an identifier for a construct call. However it could be the case that a simple heuristic would also work here instead of a manual "denylist": we avoid inlining if we would require additional brackets (such as in the examples above). Maybe for arithmetic operations we allow adding brackets, but forbid them for other expressions and instead force the creation of a new variable. Ideally, we would design the new algorithm in a way that also allows us to remove the somewhat awkward logic for expression un-inlining.
I think it would be worth experimenting with such a heuristic to see how the generated samples look like.
The text was updated successfully, but these errors were encountered:
Currently, the JavaScriptLifter is fairly "greedy" about its inlining decisions and mostly inlines expressions whenever possible:
However, this can lead to somewhat hard to read code. For example things such as
or
Currently we manually try to avoid some of these patterns, for example by forcing the constructor value to be an identifier for a construct call. However it could be the case that a simple heuristic would also work here instead of a manual "denylist": we avoid inlining if we would require additional brackets (such as in the examples above). Maybe for arithmetic operations we allow adding brackets, but forbid them for other expressions and instead force the creation of a new variable. Ideally, we would design the new algorithm in a way that also allows us to remove the somewhat awkward logic for expression un-inlining.
I think it would be worth experimenting with such a heuristic to see how the generated samples look like.
The text was updated successfully, but these errors were encountered: