-
Notifications
You must be signed in to change notification settings - Fork 380
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
Proposal: Remove FC from Elab trees #3421
Comments
Elab trees are there not only for producing code, but also for getting already present code from the compiler. This allows us to fail elaborator scripts pointing at specific parts of hand-written code. This includes involved data declarations and signatures of functions where particular elaborator scripts are used. For example, when some type of argument is not supported, now elaborator scripts can point to this particular argument using I can suggest another alternative -- to make |
Do you have an example of this? I wonder if this is something we could automate instead of making the script writer do it |
Thank you for all those links. It seems to me like there are essentially two kinds of error locations:
Is that right? Or is there something else? |
so to recap, FC come from:
Is that right? If so, it seems like all the places where |
Seems right, yes
Well, maybe, but I don't understand how can this be implemented, since compiler does not hold back-references to original |
I've done some experiments implementing whole new syntax (notably a tactic mode) by having an elaboration script transform a quoted term, and manipulating FCs (for better error reporting, showing the correct type on hover, etc.) was an important part of it. This is an edge case of course, but I wouldn't want it to be impossible. Personally, I see |
Do you have examples of this that we can study? I'm going to update the motivation of the proposal because
Is essentially impossible with an evolving programming language, removing FCs makes a lot more changes easier to do since they won't introduce breaking in all the libraries using elab reflection |
Here's a minified example: https://gist.github.com/elseLuna/23c595bfa59b1235baa7abf82e7c4491 This is a huge hack though, so if there's good reason to remove FCs don't let this stop you. EDIT: Actually, after thinking about it for a bit, even if FCs were removed from |
Given the absolute nightmare that it was to simply keep the elab tree up to date with TTImp I think the only way to move forward is as follows:
This should allow much bigger changes to Elab reflection and remove any source of uncertainty when making breaking changes. Thoughts? |
Summary
When working on elaboration scripts, users are expected to write trees for the programs they wish to generate. Those tress carry around file context information. However, this location is almost always empty.
Motivation
The trees built during elaboration reflection closely match the internal trees of the compiler, including file location information. Because the trees built during elaboration reflection are not written from syntax, they often carry an empty file location. See:
File location is not a necessary part of building trees. And having it produces heavy breaking changes whenever code relating to file location changes. What's more, breaking elaboration can come from unrelated changes to syntax highlighting, or error reporting, which greatly increases code the burden of changes to the compiler, and create code churn for downstream libraries.
The proposal
Remove all FC reference in the
Language/Reflection/TTImp
trees. Replace error reporting fromfailAt : FC -> String -> m a
andwarnAt : FC -> String -> m ()
by functionsfail : TTImp -> String -> m a
andwarn : TTImp -> String -> m ()
Where the
m
monad keeps track of locations for every term. This way users can keep the ability to emit errors and warnings at precise locations, without relying on manually keeping track of file locations.Alternatives considered
We could keep the current state since location information could be used for better error reporting. However, such usage seems to be the exception rather that the rule. Something else we could do is write an engine that will generate appropriate file locations but this is a lot of work, and could be done after the file locations have been removed from the trees.
Conclusion
This change would bring Idris in line with Haskell and Agda that do not expose any location information during elaboration reflection. It will also make changes to
TTImp
easier to perform, and reduce the entry barrier to elaboration reflection.The text was updated successfully, but these errors were encountered: