Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistency between textfile and stextfile #273

Open
Gabriella439 opened this issue Feb 9, 2023 · 2 comments
Open

Inconsistency between textfile and stextfile #273

Gabriella439 opened this issue Feb 9, 2023 · 2 comments

Comments

@Gabriella439
Copy link

textfile uses the URL renderer (i.e. justVarInterpolation = False) whereas stextfile disables the URL renderer (i.e. justVarInterpolation = True). This seems odd because based on their names it seems like textfile and stextfile should behave almost the same except that textfile generates lazy Text whereas stextfile generates strict Text.

However, they don't behave the same, because textfile generates a Haskell expression that expects an additional argument (the render function) whereas stextfile doesn't, so if you were to switch between the two you'd suddenly add or remove a function argument, which is unexpected.

Unfortunately, unifying the two to behave in the same way would be a breaking change, but I wanted to check if (A) this inconsistency was intentional and (B) if it was unintentional, would the maintainers be receptive to a breaking change to textfile to set justVarInterpolation = True?

@snoyberg
Copy link
Member

I think it was historically intentionally, but I'm honestly not sure. The first usage of s as the prefix was in Hamlet, where s was for "simple Hamlet" and was entirely about dropping the URL rendering. It actually seems a bit strange to me that we return two different data types from these two functions, as opposed to the difference in behavior around URL handling which I'd expect.

@Gabriella439
Copy link
Author

Oh, for some reason I thought the s stood for strict. In that case, the difference in behavior is less surprising to me. Maybe it just needs a documentation comment

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants