Skip to content
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

[ elab ] Support limited file operations in elab scripts, e.g. enable type providers #3099

Merged
merged 1 commit into from
Oct 13, 2023

Conversation

buzden
Copy link
Contributor

@buzden buzden commented Oct 11, 2023

Description

Idris 1 used to have type providers, facilities that allowed pretty arbitrary code to be additionally executed at the compile time allowing to provide particular values based on whatever stuff. But this approach is very fragile and unsafe, since arbitrary effects can break a lot and generally seems to be undesired.

Seemingly, most important feature was a file access. This allowed to implement the principle of a single source of truth in a higher level and typesafe manner. Say, your code interacts with some other code with some well-defined typed interface and if you can generate a type declaration from this description automatically during compile time, you've solved a problem of synchronisation: each time the common description updates, your types update too. If the change was incompatible, you code stopped compiling.

The vice-versa situation is possible -- one may want to define types in Idris but to be able to export some data in a well-defined format to couterparties and to have them be synchonised well automatically.

What I propose is to make elaborator scripts to be able to access files in the project dir with a simple interface allowing type providers stuff without allowing arbitrary IO at compile time. You can see an example of primitive limited type provider in the added test.

An additional action called idrisDir is also proposed to be added. It allows returning paths of project dirs. This can be useful for nicer error messages (see the test for example). Also, I have at least one more nice use case for it, it is not trivial, but I'll explain it if there is a need.

Should this change go in the CHANGELOG?

  • If this is a fix, user-facing change, a compiler change, or a new paper
    implementation, I have updated CHANGELOG.md (and potentially also
    CONTRIBUTORS.md).

@gallais gallais merged commit 6815aef into idris-lang:main Oct 13, 2023
22 checks passed
@buzden buzden deleted the file-io-in-elab branch October 13, 2023 12:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants