Add the minutes of meeting in September 2016 #578
Conversation
jvican
force-pushed
the
minutes-september-2016
branch
3 times, most recently
from
4814de9 to
ac319be
Compare
| Native implements unsigned integer in a different way. | ||
|
|
||
| **Outcome**: The proposal is rejected by majority (Heather is the only Committee | ||
| member voting against, 5 to 1). |
There was a problem hiding this comment.
I could swear I voted reject.
There was a problem hiding this comment.
Whoops, sorry. There has been a misunderstanding, Iulian and Seth voted with "negative" symbols, and when you said "in favor" I didn't realise you were answering my original question, but thought you wanted more work on the proposal. Updating.
There was a problem hiding this comment.
Ah, I thought I said "not in favor". It was either a connectivity issue or a brainslip.
jvican
force-pushed
the
minutes-september-2016
branch
from
ac319be to
41ef570
Compare
|
|
||
| Sébastien points out that it's a good compromise, he personally likes it. He | ||
| compares trailing commas to the semantics of semicolons in Scala. Martin is not | ||
| convinced but the specialized version and makes the points that trailing commas |
There was a problem hiding this comment.
I'm so confused by GitHub's review comments not collapsing, but this is still pending.
| when the equivalent in trailing commas should emit an error. Martin thinks that | ||
| it messes with another abstract of the language and doesn't think it deserves to | ||
| drop all the fundamental ideas for good language design. He proposes that | ||
| trailing commas should be implemented in the SBT parser if they are so important |
|
|
||
| Heather is starting to see the IDE argument more favorably, and she is on the | ||
| fence about the proposal. She invites Dale to interject about the "IDE" argument | ||
| (namely, that IDEs should make easier to deal with trailing commas. Dale thinks |
|
|
||
| Attendees Present: | ||
|
|
||
| * Martin Odersky ([@odersky](github.com/odersky)), EPFL |
There was a problem hiding this comment.
I think you'll need the https:// on this and the rest of the github.com URLs
There was a problem hiding this comment.
I don't, surprisingly Jekyll is smart enough! 😄 Thanks for the feedback!
There was a problem hiding this comment.
This is correct. The https:// is needed.
There was a problem hiding this comment.
It is not needed. Check the minutes and their markdown files in this repository.
There was a problem hiding this comment.
That page works because I already fixed the mistake. I also had to fix your other minutes file.
The changes got merged in about 9 hours ago.
There was a problem hiding this comment.
True, you're right, didn't realise you change it. Thanks!
| parts separately would be ideal. Sébastien is not sure that they can be | ||
| reorganized to be completely orthogonal. Eugene confirms that the dependency | ||
| between inline and meta is very big. For him, studying them separately is a | ||
| concern because there could be a point where meta cannot happens because of the |
| way inline was designed. | ||
|
|
||
| Seth asks for further information on the interdependency. Sébastien argues that, | ||
| conventionally, metaprogramming has relied on the eager execution of the formal |
There was a problem hiding this comment.
I think this transcription is inaccurate. What I think I said is that "the definition of inline (in non-meta cases) specifies the eager execution of the formal parameters (as is the case for non-inline, non-meta functions).
There was a problem hiding this comment.
I agree that the wording of this transcription is incorrect. From what I recall, you mentioned that the to-be-deprecated macro defs could only see the eagerly-executed formal parameters, unlike the meta proposal. I failed to explain this faithfully, sorry @sjrd! Will update tomorrow.
There was a problem hiding this comment.
If I said such a thing, it was downright wrong. Existing scala.reflect macro only ever see the non eagerly-executed actual arguments, since they see their Trees instead.
There was a problem hiding this comment.
No, actually it's my fault. Listening to the video again made me realise I understood it incorrectly. Thanks!
| * Changing the underlying implementation of byte and short ints. | ||
| * Making the super class of unsigned integer extend *java.lang.Number* | ||
|
|
||
| The second option is not feasible because some numbers are AnyVals, and they can |
| * Making the super class of unsigned integer extend *java.lang.Number* | ||
|
|
||
| The second option is not feasible because some numbers are AnyVals, and they can | ||
| only extend objects. Working around this in the backend is, in Sébastien's |
| work has been great and that the problem he tries to solve is real. | ||
|
|
||
| Jorge, seeing everyone's reactions, proposes to vote on the proposal. In his | ||
| view, it doesn't make sense to give it another iteration and make everyone's |
| spend more time on it. At this point, the Committee doesn't have more meaningful | ||
| feedback to improve the proposal, and decisions need to be made. | ||
|
|
||
| 4 people of the Committee votes yes, 2 no (Martin and Seth). Martin leaves the |
jvican
force-pushed
the
minutes-september-2016
branch
2 times, most recently
from
dac6171 to
061b380
Compare
jvican
force-pushed
the
minutes-september-2016
branch
from
061b380 to
72c65e2
Compare
|
@jvican will there also be a blog post on scala-lang.org? wondering if I should tweet the minutes directly from scala_lang, or wait for a blog post |
|
Wait for the blog post 👍 There's a PR in scala-lang that we're merging tomorrow! |
No description provided.