Formatting error (run-together identifiers) #67

Closed
opened 2017-11-27 19:06:15 +01:00 by eschnett · 4 comments
eschnett commented 2017-11-27 19:06:15 +01:00 (Migrated from github.com)

Using brittany on this fragment introduces an error.

Input:

fmapuv :: U.Unbox a => (a -> b) -> U.Vector a -> V.Vector b
fmapuv f xs = G.generate (G.length xs) (f . (xs G.!))

Output:

fmapuv :: U.Unbox a => (a -> b) -> U.Vector a -> V.Vector b
fmapuv f xs = G.generate (G.length xs) (f . (xsG.!))

The expression xs G.! (apply operator ! imported from module G) gets mis-printed as xsG.! (operator ! from module xsG), i.e. a space is missing.

I just updated Brittany from Github:

$ brittany --version
brittany version 0.8.0.3
Using `brittany` on this fragment introduces an error. Input: ``` fmapuv :: U.Unbox a => (a -> b) -> U.Vector a -> V.Vector b fmapuv f xs = G.generate (G.length xs) (f . (xs G.!)) ``` Output: ``` fmapuv :: U.Unbox a => (a -> b) -> U.Vector a -> V.Vector b fmapuv f xs = G.generate (G.length xs) (f . (xsG.!)) ``` The expression `xs G.!` (apply operator `!` imported from module `G`) gets mis-printed as `xsG.!` (operator `!` from module `xsG`), i.e. a space is missing. I just updated Brittany from Github: ``` $ brittany --version brittany version 0.8.0.3 ```
lspitzner commented 2017-11-27 23:23:01 +01:00 (Migrated from github.com)

Right. Is anyone opposed to changing whitespace handling in sections to always insert whitespace between argument and operator? I think this would be a more established default. Some use exceptions for (:) and arithmetic operators, but I could do without exceptions.

Right. Is anyone opposed to changing whitespace handling in sections to always insert whitespace between argument and operator? I think this would be a more established default. Some use exceptions for (:) and arithmetic operators, but I could do without exceptions.
eschnett commented 2017-11-28 03:08:30 +01:00 (Migrated from github.com)

I could do without exceptions.

I thought that Brittany had internal fail-safes to prevent misprints like this, i.e. that the emitted code parses back to the same syntax tree. How did this fail in this case?

I could do without exceptions. I thought that Brittany had internal fail-safes to prevent misprints like this, i.e. that the emitted code parses back to the same syntax tree. How did this fail in this case?
lspitzner commented 2017-11-28 13:08:07 +01:00 (Migrated from github.com)

That's a good point. The current failsafe only tests that the output is syntactically valid, which it is in this case. Checking that the (not location-dependent parts of the) syntaxtrees remain equal is a good idea. I'll open a new ticket for that.

That's a good point. The current failsafe only tests that the output is syntactically valid, which it is in this case. Checking that the (not location-dependent parts of the) syntaxtrees remain equal is a good idea. I'll open a new ticket for that.
lspitzner commented 2017-11-28 17:59:38 +01:00 (Migrated from github.com)

thanks for reporting!

thanks for reporting!
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: hexagoxel/brittany#67
There is no content yet.