by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
matt rice
@ratmice
Well, let me know if this is something you believe worth investigating more.
Brendan Zabarauskas
@brendanzab
Yeah - we might need to play around with the API a bit - I guess I'm just finding it hard to visualise a solution.
Like, I was thinking maybe we could investigate other ways to build up a diagnostic. Like maybe we could have some way of building up a tree, like:
Diagnostic::error()
    FileLabel::primary(file_id, range)
    FileLabel::secondary(file_id, range)
    FileLabel::secondary(file_id, range)
FileDiagnostic::error(file_id)
    Label::primary(range)
    Label::secondary(range)
    FileLabel::secondary(file_id, range)
matt rice
@ratmice
Well, trying with MaybeUninit isn't working either because Label<FileId>, and AnonLabel<FileId> which differ only by the file_id: FileId vs file_id:MaybeUninit<FileId> still aren't guaranteed to be the same size, since they could have different field order which changes alignment I guess
Brendan Zabarauskas
@brendanzab
tbh MaybeUninit<FileId> seems rather heavy handed?
I'd rather avoid unsafe in codespan if I can help it :sweat_smile:
matt rice
@ratmice
yeah tend to agree was mostly curious if it couldn't be made to work, and if it did might be a reason to include since it's more efficient or something -- as it is what I have there is no advantage for bringing it in beyond convenience of not having to declare it yourself (which I guess is something).
Brendan Zabarauskas
@brendanzab
ahh righto
Brendan Zabarauskas
@brendanzab
added some more test cases for overlapping stuff
matt rice
@ratmice
Well, I did get a MaybeUninit variation working (essentially by making Label a newtype around AnonLabel) -- then immediately realized godbolt wasn't by default adding optimizations here, so the actual cost of the wrapper struct isn't actually so bad... Anyhow going to stop messing with that, as it didn't seem worth it really
Brendan Zabarauskas
@brendanzab
heh, can be nice to play around to see what happens though!
Brendan Zabarauskas
@brendanzab
Screen Shot 2020-05-17 at 12.30.09 pm.png
making some amount of progress
Brendan Zabarauskas
@brendanzab
Screen Shot 2020-05-17 at 4.14.52 pm.png
matt rice
@ratmice
I Imagine there probably isn't any characters which implement these edge crossing notches bridges
Brendan Zabarauskas
@brendanzab
yeah that would be so neat
need to bug the unicode consortium
matt rice
@ratmice
yeah, if u292b & c were just orthogonal/not rotated they would work too
segeljakt
@segeljakt
@brendanzab have you thought about writing a paper or something about this? many programming languages could benefit from this quality of error messages
Brendan Zabarauskas
@brendanzab
hehe, I dunno - it's more just implementation work - not sure what is significant research wise :/
segeljakt
@segeljakt
Really interesting...
I see the potential for an experiment or case study haha
Brendan Zabarauskas
@brendanzab
hehe :)
Brendan Zabarauskas
@brendanzab
Screen Shot 2020-05-17 at 11.24.24 pm.png
^ after a bunch of hacky hacks on hacks
Screen Shot 2020-05-17 at 11.26.48 pm.png
^ also
now to clean up...
segeljakt
@segeljakt
neat 👍
do you have any insights about whether error messages differ between languages?
like, imperative vs functional 🤔
Brendan Zabarauskas
@brendanzab
not sure
I just know many compilers neglect them
well, at least historically
I don't think it really matters what the dominant paradigm is
But fp langs have tended to rely on whole program type inference in the past, which can make good, localised errors more challenging to implement
But I don't think that's an FP thing - more a 'whole program type inference' thing
Currying can make good errors harder I think?
segeljakt
@segeljakt
It makes sense
Maybe, it get harder when the languages become higher order but I don't know
matt rice
@ratmice
one thing i've been thinking of is producing more of an annotated source with errors than a stream of errors, including inference in the margin
Brendan Zabarauskas
@brendanzab
The single line rendering improvements are done woohooo brendanzab/codespan#241
Folks are welcome to review if they want
matt rice
@ratmice
So, I tried to read through nothing jumped out at me in particular, but left a comment
besides that I think they look make these cases much more readable!
Brendan Zabarauskas
@brendanzab
Thanks for the comment and review
Hopefully it wasn't too convoluted - it was pretty ugly in some of the intermediate stages as I was figuring stuff out!
Brendan Zabarauskas
@brendanzab
@ratmice ok, updated with some more explanation
Brendan Zabarauskas
@brendanzab
Ok, new version is now published!