Conversation

re. github.com/jonsterling/dr, have you considered how error reporting might work with the refiner? Seems like a really neat approach - but just a little worried about providing a nice diagnostics about the surface syntax and supporting error recovery, etc.

github.com

GitHub - jonsterling/dreamtt: A pedagogic implementation of abstract bidirectional elaboration for...

A pedagogic implementation of abstract bidirectional elaboration for dependent type theory. - GitHub - jonsterling/dreamtt: A pedagogic implementation of abstract bidirectional elaboration for depe...

You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more

Brendan Zabarauskas

@brendanzab

Apr 12, 2021

Idea is that you don't want your type checker to stop at the first error. You'd prefer it if it could continue type checking, giving you more than one error.

Brendan Zabarauskas

@brendanzab

Apr 12, 2021

I do this in a bit of a bodgy way with an 'error' variant in my ASTs, but you run into issues where error sentinels pop up in type errors if you aren't careful. Leading to the fun of Rusts 'error: expected `type error` found `type error`' back in the day 😂

Replying to

and

I think most of those bugs have been squished though. But yeah, I'd prefer it if it was a bit more thought out - like something like exceptional type theory perhaps?

12:16 PM · Apr 12, 2021Twitter Web App

Replying to

and

But yeah, I'd like to be able to run my programs even if they have type errors in them - I just accept that if I do they'll crash if they run into ill-typed code fragments. But then on a release build I want to be sure all code paths are well-typed.

Brendan Zabarauskas

@brendanzab

Apr 12, 2021

But yeah, that's going a bit beyond error recovery, but could be part of the same thing I think.