It's good to get releases out in a timely fashion. However, if common use cases of major new features are hopelessly broken, and easy fixes are available, I'd argue that the delay is better for PR than the alternative.
On Sat, Nov 10, 2012 at 11:09 AM, Rex Kerr <ich...@gmail.com> wrote:
It's good to get releases out in a timely fashion. However, if common use cases of major new features are hopelessly broken, and easy fixes are available, I'd argue that the delay is better for PR than the alternative.
Maybe it's my skewed perspective, but to me the fact that it doesn't work is of small importance compared to the fact that we would be shipping what seem to be pretty disastrous semantics, which we would then have to be compatible with afterward.
"""I have a long string with a bunch of stuff in it, maybe even a \windows\path\to\foo"""Let's say that string goes on for pages. Oh, I'd like to use string interpolation now.s"""I have a long string with $stuff in it, maybe even a \windows\path\to\foo"""
Right now, s, not the lexer/parser, does the parsing of escape characters. So x"\nHi" actually gets sent as a raw string ""\nHi""" to the x method (including the s method). At that point, s has no idea whether it was s"""\nHi""" or s"\nHi". This is what Paul is suggesting that we change (and I agree).
--RexOn Sat, Nov 10, 2012 at 2:20 PM, Erik Osheim <er...@plastic-idolatry.com> wrote:
On Sat, Nov 10, 2012 at 12:10:26PM -0700, Paul Phillips wrote:I'm probably just confused, but it seems like there's a subtext that we
> It seems like we could achieve a lot more uniformity if we informed the
> interpolator whether the literal was single or triple quoted.
can't just have s"""...""" ignore escapes while doing interpolation. To
me it seems like the question of whether \ and $ have special effects
seem orthogonal. Maybe I'm wrong?
"$$foo\tar$duh" (\t is tab)
"""$$foo\tar$duh""" (no special behavior)
s"$$foo\tar$duh" ($$ is literal $, \t is tab, $duh interpolated)
s"""$$foo\tar$duh""" ($$ is literal $, $duh interpolated)
Is there something that makes this behavior inconsistent?
-- Erik
On Sat, Nov 10, 2012 at 5:36 PM, Rex Kerr <ich...@gmail.com> wrote:
Right now, s, not the lexer/parser, does the parsing of escape characters. So x"\nHi" actually gets sent as a raw string ""\nHi""" to the x method (including the s method). At that point, s has no idea whether it was s"""\nHi""" or s"\nHi". This is what Paul is suggesting that we change (and I agree).Letting s and f know whether it was single line or multiline would work. Escaping before passing would *NOT* work, as it would break use for things that are not strings (such as regular expressions).I think the present solution works best, but I did raise this point during the SIP -- meaning it was there for anyone to see, and with a comment flagging it down.
But that can be fixed later in a backwards-compatible way. All I think should be done now is to fix enough bugs so that there is some hope of using string interpolation on Windows paths, as it looks sloppy to have a main new feature trip on such a common use-case (esp. since it admits a trivial fix)
Of course, standard unicode escaping *always* happens earlier, which presents another pitfall:
I don't think you should escape before passing, but I do think you should be able to know whether it was triple-quoted or not so you can mimic the standard " vs """ behavior if you want to. Whether you pass a boolean or a default parser or call different methods or something else is not really the main point; the indistinguishability is.
But that can be fixed later in a backwards-compatible way.
--Rex
If only one could make that trade.
scala> raw"""c:\users"""
On Sat, Nov 10, 2012 at 11:09 AM, Rex Kerr <ich...@gmail.com> wrote:
It's good to get releases out in a timely fashion. However, if common use cases of major new features are hopelessly broken, and easy fixes are available, I'd argue that the delay is better for PR than the alternative.
Maybe it's my skewed perspective, but to me the fact that it doesn't work is of small importance compared to the fact that we would be shipping what seem to be pretty disastrous semantics, which we would then have to be compatible with afterward."""I have a long string with a bunch of stuff in it, maybe even a \windows\path\to\foo"""Let's say that string goes on for pages. Oh, I'd like to use string interpolation now.s"""I have a long string with $stuff in it, maybe even a \windows\path\to\foo"""
Now my string has form feeds and tabs in it. I didn't touch that part! And I have to habitually use triple-quoted strings for everything now, because otherwise I am constantly having to convert to triple quotes anyway, because there's no way to include a single quote in a single quoted interpolated string. Unfortunately at least half my strings have single quotes in them.
It was clear, and I think it's a fair discussion point whether we should fix the bugs you outlined before or after 2.10.0.
On Sun, Nov 11, 2012 at 9:43 PM, Rex Kerr <ich...@gmail.com> wrote:
Since I chose the title, I should point out that I never meant to imply that SIP-11 shouldn't be in Scala 2.10. I think it's one of the best low-entry-barrier additions. Instead, I meant to imply that it was worth fixing because its appeal will likely lead people to rapidly collide with bugs and be grumpy instead of elated (in a platform-dependent manner).