Skip to content
This repository has been archived by the owner on Sep 1, 2020. It is now read-only.

Write down source compatibility guidelines between Scala dialects #14

Open
Blaisorblade opened this issue Sep 4, 2014 · 19 comments
Open

Comments

@Blaisorblade
Copy link

Again and again, we want to merge pull requests which change the Scala source language.

We should evolve precise guidelines for how to handle them and where to draw the line.
I think changing the source language is the point of the exercise, but of course we need good changes.

Guidelines to decide what's in and what's out are hard, that's why I say "evolve"; but already now we should have some guidelines on how to do the breaking changes we want.

  1. We should require good documentation for users, possibly of better quality than the existing Scalac documentation. I wouldn't rule out altogether forking the spec, though that's probably a hard sell unless somebody volunteers for that.
  2. Of course, we should check for compatibility with the community build. Over time, we'll have to figure out what kind of breakage we accept.
@puffnfresh
Copy link

Here's the first guideline, from the blog post:

Other fixes, whilst affecting semantics, would do so only in a conservative way – programs which are valid when compiled with the Typesafe Scala compiler would have the same meaning and binary representation when compiled with the fixes in place.

@djspiewak
Copy link
Member

Proposed generic informal goals:

  1. Any project source that compiles and runs under scalac should compile and run under tlc with the same set of flags. Two differences are allowed: warnings issued, and classpath (e.g. tlc may require some classpath entries that scalac does not, or vice versa)
  2. Sources that compile under both scalac and tlc with the same flags should have the same semantics.
  3. Any project binaries produced by tlc should load cleanly from a scalac project and should be callable without FFI. In other words, tlc should produce Scala APIs. The exact bytecode metadata may be distinct, so long as it is compatible.

The first and second items should be easily testable just using projects in the Scala community (similar to what Typesafe does with its compatibility tests). The third item is somewhat harder and may require specific tests, but probably eased through the same sort of mass continuous integration.

@non
Copy link

non commented Sep 4, 2014

It's possible that (1) is slightly too conservative. For example, consider the following valid Scala program:

\u006f\u0062\u006a\u0065\u0063\u0074\u0020\u004d\u0061\u0069\u006e\u0020\u007b
\u0020\u0020\u0064\u0065\u0066\u0020\u006d\u0061\u0069\u006e\u0028\u0061\u0072\u0067\u0073\u003a\u0020\u0041\u0072\u0072\u0061\u0079\u005b\u0053\u0074\u0072\u0069\u006e\u0067\u005d\u0029\u0020\u007b
\u0020\u0020\u0020\u0020\u0070\u0072\u0069\u006e\u0074\u006c\u006e\u0028\u0022\u0068\u0065\u006c\u006c\u006f\u0020\u0077\u006f\u0072\u006c\u0064\u0022\u0029
\u0020\u0020\u007d
\u007d

My proposed change to unicode escaping (#7) would make this currently valid Scala program fail to compile.

@puffnfresh
Copy link

@djspiewak @non well, now I'm conflicted.

@djspiewak
Copy link
Member

@non For this reason, your Unicode stuff should be behind a flag. That is
implicit in my proposed restrictions.

@non
Copy link

non commented Sep 4, 2014

Sure, possibly -Zsafe-unicode-escapes or similar.

@puffnfresh
Copy link

@non is it actually easy to preserve both behaviours?

@non
Copy link

non commented Sep 4, 2014

Yes. In fact, my original patch does preserve both behaviors since we need to keep using it when parsing Java sources. If you look at the commit (sorry don't have a link) you'll see that I add a flag about whether to do pre-parse escaping or not.

@non
Copy link

non commented Sep 4, 2014

(Of course, the patch would have to be updated to ensure that we don't "double parse" \uXXXX escapes before parsing and also during string parsing. But that's just work.)

@Blaisorblade
Copy link
Author

So, we can still do anything sensible violating those guidelines, as long as it's behind a flag? I'd be happy with that, as long as we get -Zdefault and -Zall.

BTW, calling -Zdefault -Ztypelevel would be risky, because we might well end up with some feature for type-level computation some day.

Of course, the patch would have to be updated to ensure that we don't "double parse" \uXXXX escapes before parsing and also during string parsing. But that's just work.)

Generally speaking, we'll have to weight the maintenance overhead. Especially since we're keeping merge compatibility, so we can't go and simplify other stuff.

@non
Copy link

non commented Sep 4, 2014

Right. Features that follow the "spirit" of these rules (expected to work widely with realistic Scala sources but break on edge cases or dysfunctional code) might be grouped into a -Zomnibus flag.

(Came up with the name on #typelevel but I'm sort of enamored with it now.)

@non
Copy link

non commented Sep 4, 2014

One thing to add though is that as @milessabin said the fork is intended to be conservative.

The goal is not to add a ton of flags to create a totally different language. But rather, to use flags in cases where we can't quite meet our compatibility requirements but want to accept a benign change that meets the spirit of them.

@aloiscochard
Copy link

Indeed, It would be kind of ironic if compiling scalaz/shapeless/spire with the fork would require a complex combination of flags.

@non
Copy link

non commented Sep 5, 2014

One other thing to note, in the rules above, rule (2) should probably be amended to rule out reflection.

Otherwise, it will be impossible to even add annotations to the stdlib (since that would change the behavior of valid code that gets all the annotations for a class).

This is relevant due to #17.

@Blaisorblade
Copy link
Author

Otherwise, it will be impossible to even add annotations to the stdlib (since that would change the behavior of valid code that gets all the annotations for a class).

Since that's about adding something to a library, this reminds me: What about forward compatibility guarantees between Typelevel Scala minor releases? What's the binary version of Typelevel Scala releases?

aloiscochard pushed a commit to aloiscochard/scala that referenced this issue Sep 5, 2014
Add support for Java 8 in filtered check feature.
@milessabin
Copy link
Member

@aloiscochard actually, I wouldn't be at all surprised if shapeless or Scalaz were the first to break ... but that should be fine if we're prepared to branch those projects to support tlc (we are, that's kinda the point).

@Blaisorblade
Copy link
Author

The discussion moved to https://github.com/typelevel/scala/wiki/Typelevel-Scala-Compatibility-Guide & https://groups.google.com/d/msg/typelevel/bCJhQvIhqG4/6y4nf5kFpJMJ.
The issue should be closed (IMHO) when the policy is in place.

@puffnfresh
Copy link

I've started documenting our features on the wiki: https://github.com/typelevel/scala/wiki/Differences

@propensive
Copy link

I also added a page called "Roadmap". It basically says we don't have one
(beyond what Miles published in his original announcement), though a couple
of people have asked me about our roadmap, so I thought I'd put it into
words...

https://github.com/typelevel/scala/wiki/Roadmap

That said, it would be good to open the discussion on what we should expect
to see in the first (and maybe later) releases of Typelevel Scala.
Thoughts, anyone?

Jon

On 6 October 2014 16:29, Brian McKenna [email protected] wrote:

I've started documenting our features on the wiki:
https://github.com/typelevel/scala/wiki/Differences


Reply to this email directly or view it on GitHub
#14 (comment).

Jon Pretty | @propensive

@milessabin milessabin added this to the 2.12.0-RC1 milestone Aug 12, 2016
@milessabin milessabin removed this from the 2.12.0-RC1 milestone Oct 25, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants