|Anonymous | Login | Signup for a new account||2015-11-27 21:56 CET|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005529||OCaml||OCaml general||public||2012-03-08 17:48||2012-03-09 17:09|
|Status||resolved||Resolution||no change required|
|Target Version||Fixed in Version|
|Summary||0005529: Implicit type override in destructive substitutions|
|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 =
include FOO with type t := t and type u := u
include BAR with type t := t and type u := u
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 =
(Thanks in advance for your time!)
|Tags||No tags attached.|
"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".
- 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.
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... :-)
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!
|2012-03-08 17:48||dario||New Issue|
|2012-03-08 19:00||gasche||Note Added: 0007024|
|2012-03-09 16:06||dario||Note Added: 0007032|
|2012-03-09 17:09||gasche||Note Added: 0007034|
|2012-03-09 17:09||gasche||Status||new => resolved|
|2012-03-09 17:09||gasche||Resolution||open => no change required|
|2012-03-09 17:09||gasche||Assigned To||=> gasche|
|Copyright © 2000 - 2011 MantisBT Group|