kosmikus / lhs2tex

Preprocessor for typesetting Haskell sources with LaTeX
Other
99 stars 28 forks source link

lhs2tex 1.19 hangs on (what I believe to be) innocuous input #64

Closed jegi closed 6 years ago

jegi commented 6 years ago

For me, this short input file causes lhs2tex to consume huge amounts of memory (2GB+) and run indefinitely. It's necessary to have both the %format and the {code} block to tickle the problem. (I was trying to format an infix operator. I guess my syntax is wrong - you can't specify the arguments like this so as to reorder them - but still, my error should be more gracefully handled.)

%include lhs2TeX.fmt
%format x `exp` (y) = x "^{" y "}"
\begin{code}
f x = x
\end{code}
jegi commented 6 years ago

Oh, it only happens in "newcode" mode, not in "poly" mode.

kosmikus commented 6 years ago

@jegi lhs2tex does not support defining infix formatting directives in this way. This is actually interpreted as a format directive for x, which then immediately expands to x again, causing an infinite loop when x is encountered in the code block. Because there's extra stuff on the rhs, it additionally causes memory to be consumed.

I admit that the docs are insufficient in stating what's really supported by lhs2tex and what is not, but I can't see myself having the time to improve that situation anytime soon.

You can define a formatting directive for back-ticked operators in isolation:

%format `exp` = ...

or you can make it prefix instead

%format exp x (y) = ...

but then you also have to use it prefix (but can use different formatting directives depending on poly or newcode style being active).

jegi commented 6 years ago

I accept that what I was trying to do was wrong, and I wasn't expecting that you would make it right. But would it be possible to yield a quick "invalid definition" error message rather than bringing my computer to its knees? (Without first solving the Halting Problem, of course.)

kosmikus commented 6 years ago

My explanation does not seem to be quite correct anyway. I'll look into this a bit more.

kosmikus commented 6 years ago

Sorry, at a closer look, this turns out to be an actual bug in the parser after all. The string `exp` is not a valid identifier to use in place of a parameter. However, the parser currently incorrectly accepts a formatting directive if only a prefix of the line is valid. And %format x alone turns out to be valid.

With 818c9d6f09b7be3e947c15a73fa0913dccb25a10, your input now produces:

syntax error in directive
 x `exp` (y) = x {-"^{"-} y {-"}"-}

Thanks for persisting.

jegi commented 6 years ago

Great - thanks!