This is in response to Sven's observation in http://lists.wfu.edu/pipermail/gretl-devel/2015-November/006222.html where he pointed out that the second "list" statement fails in the following: <hansl> open denmark list lolo = LRY list lulu = (1==1) ? LRY : LRM </hansl> I initially replied, "This is tricky. In the first case the object being assigned to a list is a named series from the dataset, which is OK. In the second case it's the series product of a calculation, and in general that's not acceptable; for example you cannot say list L = x/3" In fact this reply was a bit off the mark. Looking at the code, I see that gretl is well aware of the case where the ternary operator simply "passes through" one of its operands, without any calculation being required. That's the case with the second list example above, so why wasn't it working? The blockage was a safeguard against "double-freeing" (memory management gets quite complicated in "genr"). When the ternary operator passed through one of its operands unmodified, we made a copy of the result (as if it had been the result of a real calculation). I'm now 99 percent sure that this safeguard is redundant; I think it has been superceded by improved general memory management. So I've commented it out in current git and snapshots. This means that Sven's example above will now work. But if anyone sees a crash when the ternary operator is used, please let me know! (I've thrown as many test cases as I could find at it, without exposing any problem.) Allin