Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005529OCamlOCaml generalpublic2012-03-08 17:482012-03-09 17:09
Reporterdario 
Assigned Togasche 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusresolvedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0005529: Implicit type override in destructive substitutions
DescriptionWhen 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!)
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0007024)
gasche (developer)
2012-03-08 19:00

"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.
(0007032)
dario (reporter)
2012-03-09 16:06

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... :-)
(0007034)
gasche (developer)
2012-03-09 17:09

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!

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker