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

as per issue https://github.com/agda/agda/issues/426, first cut at tr… #1867

Closed
wants to merge 1 commit into from

Conversation

cartazio
Copy link

…ying out enabling lazy evaluation in emacs agda-mode.

The long term solution is probably expose this choice as a cabal level build configure that then uses CPP in this module or something.

opening this PR as a discussion point for ticket #426

…on in emacs agda-mode.

The long term solution is probably expose this choice as a cabal level build configure that then uses CPP in this module or something.
@UlfNorell
Copy link
Member

The problem with using destructive updates in top-level emacs mode commands is that it has side effects on the state. For instance, if you ask for the normal form of a type and then ask for it non-normalised you'll still get the normal form, since it's been updated destructively.

@UlfNorell UlfNorell closed this Feb 22, 2016
@cartazio
Copy link
Author

Ok. That makes sense. From a user stand point, could that be handled by
having the closure indirection hold both the original expression and the
result? Or by reloading the module of interest ?

On Monday, February 22, 2016, Ulf Norell notifications@github.com wrote:

The problem with using destructive updates in top-level emacs mode
commands is that it has side effects on the state. For instance, if you ask
for the normal form of a type and then ask for it non-normalised you'll
still get the normal form, since it's been updated destructively.


Reply to this email directly or view it on GitHub
#1867 (comment).

@UlfNorell
Copy link
Member

Keeping the original expression in the indirection could be very expensive, and I'm not sure how much effort would be required to make it work. Reloading the module for every top-level command would be problematic for expensive modules.

In any case, the current --sharing implementation is not how we want to implement call-by-need--it's too brittle and error prone--so we won't spend any time improving it at the moment.

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.

None yet

2 participants