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

Rename 'open' to 'include', then deprecate 'open' #211

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

elpinal
Copy link
Contributor

@elpinal elpinal commented Jan 5, 2020

Currently, SATySFi has 3 forms of open:

  1. open M: global open
  2. open M in expr: local open
  3. M.(expr): lightweight local open

Only (1) is related to this PR. The other 2 forms are irrelevant.

SATySFi's global open (hereafter, just call open) is similar to OCaml's include, not OCaml's open, because it re-exports the definitions in a module.

open / include in modules, wrap-up:

Standard ML OCaml SATySFi (current) SATySFi (ideal)
re-export open include open include
not re-export open open

In my experience with Standard ML, the absence of OCaml-style open is to some extent painful, even though Standard ML has local ... in ... end, which makes Standard ML-style open a bit more local.

Moreover, we cannot omit module prefixes in signatures (in a natural way) if OCaml-style open is not supported. Compare these (contrived) OCaml programs:

sig
  type s = int * Mod.t
  val v : Mod.t list -> Mod.u option
  val f : Mod.t -> s
end
sig
  open Mod
  type s = int * t
  val v : t list -> u option
  val f : t -> s
end

On the other hand, OCaml-style include is also useful, especially when combined with functors and to extend modules with additional definitions.

So I believe both open and include should be implemented in SATySFi. Since SATySFi has many similarities with OCaml, it would be appropriate to use the same keywords as OCaml. As a first step, this PR adds a keyword include as an alias to open. Furthermore, if a program contains (global) open, SATySFi warns about it, leading the programmer to refrain from using open.

Plan

I propose the following plan.

  • Phase 1: Introduce include, and warn the use of open. (What this PR does.)
  • Phase 2: Remove open.
  • Phase 3: Introduce OCaml-style open.

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

Successfully merging this pull request may close these issues.

None yet

2 participants