Working on a minimal XML parser which does both build a data structure and remember its nodes’ source origin, I discarded the second part of a two-tuple by not requiring anything to be present. Yet instead of informing me that a mapping cannot be deconstructed, GHC 8.10.4 gave me an obscure error message:
Thankfully I sometimes adhere to a mindfully incremental approach and was not as bewilderingly disoriented as I could have been — after all, a there is an error message possesses little more value than solely stating an executable cannot be built.
Inspecting the probable location I had intelligence on, I managed to extract a seven long byte sequence which triggers a <no location info> compilation error:
j(0,)=0
Yet compilers are squeamish and shapeshifting entities — especially with regards to diagnostic capabilities. Whilst j(0,)=0 cannot be traced, j(,0)=0 induces the expected and appropriate error. As such, I tested the phenomenon using varying GHC versions:
To my surprise, I seemed to have found a GHC regression — triggered by only seven bytes.
Alas, this regression is a known one: Another <no location info> error (Tuple section in pattern context) has been opened on the 8th of March 2021, with its comments identifying it as a regression. Yet the fix outlined and performed is as much resolving an aspect of the issue as is it making a stylistic decision — myself facing the same problem of source location corseness, I am leaning further and further towards the approach of less pedantically accurate reporting allowing for a more minimal implementation.
Following digital excavation efforts at my disk’s deep directories, I stumbled upon a collection of colorful pseudo-random walk graphics. Since they are dated September of 2015 and were generated using unidiomatic slow snake script, their only property of note is a visually jolly aura; the following three possess a particularly vibrant one:
