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

Implicit type override in destructive substitutions #5529

Closed
vicuna opened this issue Mar 8, 2012 · 3 comments
Closed

Implicit type override in destructive substitutions #5529

vicuna opened this issue Mar 8, 2012 · 3 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Mar 8, 2012

Original bug ID: 5529
Reporter: dario
Assigned to: @gasche
Status: closed (set by @xavierleroy on 2015-12-11T18:04:20Z)
Resolution: not a bug
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @hcarty

Bug description

When using 3.12's destructive substitution feature, it often happens that the types being substituted have the same name as a type in the current context. As an example, consider the following signature definition:

module type S =
sig
type t
type u

include FOO with type t := t and type u := u
include BAR with type t := t and type u := u
end

In such cases, it would be nice to avoid the extra typing. Why not introduce a variant of "include" which does automatic substitution for types which also exist in the current context? One could call it "include!", following a similar convention already adopted in other 3.12 features. Example:

module type S =
sig
type t
type u

include! FOO
include! BAR
end

Any thoughts?
(Thanks in advance for your time!)

@vicuna
Copy link
Author

vicuna commented Mar 8, 2012

Comment author: @gasche

"include!" cannot be explained as syntactic sugar anymore, as its expansion depends on the typing context at the point of use: you can't say "(include! Foo) is systematically expanded into (...)". I find it quite distasteful.

Such a dangerous construction would only be justified if it was very useful in return. Can you provide realist use cases where you use signature substitutions a lot, and the sugar would sensibly improve the readability of your program? That would make for a better argument than the toy example above.

(On a lexical point of view, "method!" means "I allow overriding" and has no semantic effect, it only affects warnings. Not at all like your proposed construction: reusing "!" would introduce an inconsistency.)

I believe a more reasonable choice would be to allow type-name punning, in the spirit of record punning: module type S with type t and u
You only have to explain that "type t" in such an equation expands to "type t := t".

But:

  • there is a potential confusion with the "type t" syntax of type declaration (one could assume that this is a syntax to somehow make t abstract in the signature S)
  • there is an arbitrary choice of expanding either into "type t = t" or "type t := t", and I don't see why one would be more right than the other -- you may have arguments for ":=", though, if you have specific use-cases in mind.

Given the uncertainty about how to make things right, the very minimal amount of typing that this saves (but I acknowledge that even small savings have value because conciseness has non-linear benefits; this needs more convincing examples), and the well-known hostility of maintainers towards syntactic changes, I must say that I don't see a bright future for the idea -- but you never know, and I would be glad.

@vicuna
Copy link
Author

vicuna commented Mar 9, 2012

Comment author: dario

Thank you, Gabriel, for your thoughtful reply. You are right that this proposed feature is not without significant (fatal?) drawbacks. Its major selling point is really just avoiding mindless retyping, though I would be hard-pressed to find a real-world example where this would be such a killer feature that it outweighted its disadvantages.

Also, I suggested reusing the "!" marker not because I thought of "include!" as a semantic counterpart to "inherit!" et al, but merely because I needed some way to lexically distinguish it from ordinary "include". But come to think of it, it makes sense for the language to have a policy that non-alphas in keywords must share semantics, in which case a different character would have to be found for this particular case (perhaps this policy is already in place, even if tacitly).

As for the alternative of simply writing "module type S with type t and u", I do agree it would introduce a source of confusion without that much of a practical benefit.

Anyway, given the rising popularity of destructive substitution, I wouldn't be surprised if in the future this issue were to resurface. Nevertheless, a better approach will have to be found. Feel free to close the ticket... :-)

@vicuna
Copy link
Author

vicuna commented Mar 9, 2012

Comment author: @gasche

Well, I do not get the chance to close bugs that often, so I'll jump on the suggestion.

That said, do not hesitate to add further comments in the future if you wake up with a better proposal or encounter important use cases.

(Regarding your comment on "!": yes, it seems like this has become a tacit convention. I don't know if you have seen the monadic-let! discussion on the mailing-list, but that bang was a blocker. Designing new syntax that is coherent, future-proof, is objectively better than all equivalent proposals, and introduces no new keyword, creates no grammatical ambiguity and was not previously valid code is a very, very tricky business -- and it only gets worse over time. That is maybe not so sad, because we don't want that to happen too often.)

Thanks for reporting!

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

No branches or pull requests

2 participants