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

Escape characters in strings not handled correctly #79

Closed
balsoft opened this issue Oct 27, 2022 · 2 comments
Closed

Escape characters in strings not handled correctly #79

balsoft opened this issue Oct 27, 2022 · 2 comments
Assignees
Labels
backends Anything related to a given backend (which is currently just Axel->Haskell). bug A bona fide implementation mistake. critical This issue is a showstopper and needs immediate attention. syntax Anything related to Axel's surface syntax.

Comments

@balsoft
Copy link

balsoft commented Oct 27, 2022

This axel file:

(module Main)

(= example "This should be a quotation mark: \"")

(= main (print example))

Transpiles to the following Haskell code:

module Main where
import Axel
import qualified Prelude as GHCPrelude
import qualified Axel.Parse.AST as AST
example  = "This should be a quotation mark: ""
main  = (print example)

Which, for obvious reasons, does not compile.

Is this expected? I couldn't find anything specific about the way Axel is supposed to be treating escapes in the documentation, but the String literals section gives an example which includes an escape sequence.

@jgrosso jgrosso self-assigned this Oct 27, 2022
@jgrosso jgrosso added bug A bona fide implementation mistake. syntax Anything related to Axel's surface syntax. backends Anything related to a given backend (which is currently just Axel->Haskell). labels Oct 27, 2022
@jgrosso
Copy link
Collaborator

jgrosso commented Oct 28, 2022

This is rather embarrassing: Turns out, \t (and other escape sequences in general) are also being output inappropriately. In theory, I had golden tests which should've caught this issue. But, apparently, I only ever visually confirmed that the files looked like valid Haskell, instead of actually trying to run them in GHC. Among other things, this meant I couldn't easily tell when inappropriate whitespace like \t snuck in.

Action items for me:

Thank you so much for catching this!

@jgrosso
Copy link
Collaborator

jgrosso commented Oct 31, 2022

Next is for me to finish #80 and #81, and then I'll push a new release. Thanks again!

@jgrosso jgrosso added the critical This issue is a showstopper and needs immediate attention. label Oct 31, 2022
jgrosso added a commit that referenced this issue Dec 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backends Anything related to a given backend (which is currently just Axel->Haskell). bug A bona fide implementation mistake. critical This issue is a showstopper and needs immediate attention. syntax Anything related to Axel's surface syntax.
Projects
None yet
Development

No branches or pull requests

2 participants