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, we can't directly store a closure (a term and an environment together) into a Nickel AST. One reason is that we only have one AST, and a closure doesn't make any sense at e.g. parsing time, typechecking time and program transformation time. It would be strange to depend on runtime-related definitions for the core AST type.
But, during evaluation, we morally need to store closure (and in fact, thunks, for lazyness) inside expressions (typically, data structures such as arrays and records store thunks). The trick we use is to generate a unique variable, bind the closure in the environment, and store this variable in the term instead. This trick leads to a lot of variable generation and variable lookup, which go through the environment, meaning they incur hashmaps lookup (and, in the worst case, a linear-time lookup, because the environment is more or less a linked list of hashmaps). This is in particular a problem for the share normal form, which, for big terms (large records), might generate a huge load of heading lets binding generated variables, degrading the performance of even just parsing then exporting a Nickel program which is already in normal form (#1428).
The text was updated successfully, but these errors were encountered:
Part of #1484.
Currently, we can't directly store a closure (a term and an environment together) into a Nickel AST. One reason is that we only have one AST, and a closure doesn't make any sense at e.g. parsing time, typechecking time and program transformation time. It would be strange to depend on runtime-related definitions for the core AST type.
But, during evaluation, we morally need to store closure (and in fact, thunks, for lazyness) inside expressions (typically, data structures such as arrays and records store thunks). The trick we use is to generate a unique variable, bind the closure in the environment, and store this variable in the term instead. This trick leads to a lot of variable generation and variable lookup, which go through the environment, meaning they incur hashmaps lookup (and, in the worst case, a linear-time lookup, because the environment is more or less a linked list of hashmaps). This is in particular a problem for the share normal form, which, for big terms (large records), might generate a huge load of heading lets binding generated variables, degrading the performance of even just parsing then exporting a Nickel program which is already in normal form (#1428).
The text was updated successfully, but these errors were encountered: