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

open should be forgotten at the end of a module #521

Open
andrejbauer opened this issue Feb 18, 2020 · 3 comments
Open

open should be forgotten at the end of a module #521

andrejbauer opened this issue Feb 18, 2020 · 3 comments

Comments

@andrejbauer
Copy link
Member

An open statement works forever for printing. It should only have an effect until the end of the module in which it appears.

@andrejbauer
Copy link
Member Author

As it turns out, there are more problems than just printing:

  1. Forbidden bound variable names are also remembered forever.
  2. If a module raises an exception or runs an unhandled operation, then its effects (adding rules to nucleus, definitions of types, etc.) are forgotten, but not any changes it made to references.

We need to think about the top-level monad and the interaction between various effects.

@andrejbauer
Copy link
Member Author

Following OCaml, if a module raises an exception, it should be undefined.

@andrejbauer
Copy link
Member Author

The following top-level interaction is a bit worrisome:

# let secret = ref ML.None ;;
val secret :> ref (ML.option _α) = ref ML.None
# exception Die ;;
Exception Die is declared.
# module M = struct rule A type ;; secret := ML.Some A ;; raise Die ;; end ;;
Processing module M
Rule M.A is postulated.
- :> mlunit = ()
File "?", line 2, characters 57-65:
Runtime error: uncaught exception Die
# M.A ;;
File "?", line 2, characters 1-3:
Type error: unknown name M.A
# let (ML.Some ?illegal) = !secret ;;
val illegal :> _α = ⊢ M.A type
# illegal ;;
- :> _α = ⊢ M.A type

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant