Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 06 2018 15:12
    @scalabot banned @fommil
  • Apr 19 2016 20:35
    @SethTisue banned @urmila007
Ichoran
@Ichoran
Anyway, now I have to uncatch my train :P
Seth Tisue
@SethTisue
to be clear, I think the talk is only about removing infix syntax unless something was explicitly declared @infix?
Ghost
@ghost~54f4b69115522ed4b3dcb16d
The sbt example has me commenting lines in my "scratch" project. I remember putting junit at the bottom so it would always be last. I edit build.sbt with vi, not an IDE. I insert // or occasionally delete a line dd. Why is it unreasonable to expect sbt/scalac to understand trailing comma? OK, maybe for the use case, it is sbt's burden, who knows. I agree that it's tools all the way down. But if scalac can handle it without further ado, why not do so? Because I remember having to edit foo.sbt twice because of trailing comma, just because scalac is dumb. I want those thirty seconds of my life back, plus the time to switch contexts mentally.
libraryDependencies ++= Seq(
    "com.github.alexarchambault" %% "argonaut-shapeless_6.1" % "1.0.0-RC1",
  //"com.github.maqicode" %% "regextractor" % "0.1",
  //"com.typesafe" % "config" % "1.3.0",
  //"com.typesafe.akka" %% "akka-actor" % "2.3.11",
  //"org.testng" % "testng" % "6.1.1",
  "org.scala-lang" % "scala-compiler" % scalaVersion.value,
  "org.scala-lang" % "scala-reflect" % scalaVersion.value,
  "com.chuusai" %% "shapeless" % "2.3.0",
  //"org.scalaz" %% "scalaz-core" % "7.2.0",
  //"org.scalaz" %% "scalaz-core" % "7.0.3"
  //"com.github.som-snytt" %% "expecty" % "0.9" % "test",
  //"org.scalatest" % "scalatest_2.10" % "2.0" % "test",
  //"org.scalatest" %% "scalatest" % "2.0.1-SNAP4",
  "com.novocode" % "junit-interface" % "0.10" % "test",
  "junit" % "junit" % "4.10" % "test"
)
eugene yokota
@eed3si9n
it might be interesting to consider allowing semicolons as vararg separator, and thereby allowing them to be infered as @Ichoran is suggesting
Ichoran
@Ichoran
@SethTisue - That robs the feature of most of its usefulness, I think. Either people end up putting @infix all over like candy (hello, Java public!), or it's basically a non-feature. And you still don't get to use it on Java libraries.
@som-snytt - Why not use :: as your separator and terminate with Nil?
@eed3si9n - Why not allow semicolon inference in positions where multiple expressions are not allowed to convert to commas instead?

If I have

Seq(
  a
  b
  c
)

there is no way that semicolons are allowed. So it's either the method call a.b(c), or it's supposed to be commas.

Ichoran
@Ichoran
It gets it as a.b(c) now, whereas the equivalent thing in braces doesn't compile, but to allow point-free notation to span lines like that is kind of horrific anyway.
Ichoran
@Ichoran
@lihaoyi - Didn't you work on comma inference in Scalite? Did you run into any serious issues?
Ghost
@ghost~54f4b69115522ed4b3dcb16d
@Ichoran Why doesn't the world? For scalac options I use "-deprecation -Xlint".split("\\s+").toSeq or similar, why doesn't everyone, instead of awkward Seq("-deprecation", "-Xlint")? But I agree that just as sbt might absorb some parsing hits, style tweaks can target tool-specific expressions, as you suggest.
Li Haoyi
@lihaoyi
@Ichoran no I did not work on comma inference with Scalite, yes I ran into lots of issues anyway
the whole thing is a crazy hack; have you seen the internals??? :D :D :D
it pre-dates any of my later scala-parser work; in theory it could be re-written in that stuff pretty easily, but as a 20-hour hack I never bothered
getting it to work with missing curlies was already pushing the envelope of it's technical hole...
also
if you're willing to drop the "Scalite" part
we use Coffeescript at work and run into tons of issues with comma-inference
no commas and no curlies and no parens makes trying to figure out what's a multi-statement block and what's a multi-arg multi-line function absolute hell
basically everything you write will compile, but people's mind-parsers are forever confused and it was a distinct sticking point in our internal web-engineer happiness survey
Ichoran
@Ichoran
@som-snytt - Maybe the world doesn't use list notation for SBT because the SBT docs use Seq. Now that I realized that I ought to be able to use List, I think I'm going to do that from now on. My SBT mindset is usually "don't touch ANYthing or it might stop working".
@lihaoyi - But we aren't dropping everything and turning it into Python without commas. The only change I'm proposing is that where it's already syntactically obvious that you must have commas, because you're directly inside parens and you can never do anything but have a single expression or multiple expressions separated by commas, that comma inference use the semicolon inference rules that already work when the parens are braces.
Thanks for the info about Scalite. I had remembered not seeing much punctuation, but wasn't sure if you'd tried comma inference.
Li Haoyi
@lihaoyi
you asked about Scalite, which is dropping everything and turning it into Python :P
Ichoran
@Ichoran
Yes, I'm just pointing out that my proposal is less ambitious.
There's a feature we already use in one context that should work equally well in another, and the two contexts are disambiguated perfectly already as far as I can tell.
Li Haoyi
@lihaoyi
yeah I understand that
I bring up coffeescript just to say
it is possible for this to go too far
not sure if this is the case here - I haven't read all the way up - but it's a real concern
Ichoran
@Ichoran
Yeah. I have the same problem with Haskell. I get that you want to have brief punctuation for things you use often, but no punctuation whatsoever is kind of hard to read. I thought we worked this out in the 17th century or whatever.
Li Haoyi
@lihaoyi
FWIW my position is mildly positive on trailing commas (like it, don't care that much), and very positive on using .foo() notation on anything without some @infix annotation (that's the style I use myself and obviously everyone else should do the same thing)
at work, Coffeescript also allows you to leave off ()s when calling arbitrary functions, and the general consensus was DON'T DO THAT, with lots of strong feelings
for similar reasons why people didn't like inferred commas: even as an experienced engineer working with the code for a year, you'd still have trouble parsing it in your head
eugene yokota
@eed3si9n
I started out being indifferent about trailing commas, but I'm surprised to learn that most modern languages secretly allow them for array and map literals - https://github.com/scala/scala.github.com/pull/533#issuecomment-239039006
David Dudson
@DavidDudson
I agree with @infix seems like one of the best ideas I've heard proposed, my colleagues are extremely happy with this too. I've seen many new Scala developers think that "Scala supports infix, so why don't we just use it!"
You then get confronted with horrible code. Although I do like infix syntax for simple one declaration "FP operators" such as map and foreach(But I wouldn’t be too fussed if it went away). eg someList foreach println
I do not like chaining them (Unless the operator is symbolic) eg. a map b map c filter d
Ichoran
@Ichoran
You don't think that in practice the difference between having to opt in with @infix and not having infix notation at all would be minimal?
Li Haoyi
@lihaoyi
I view it like use-site vs declaration-site variance
Ichoran
@Ichoran
I view it like public access modifiers.
Or like const declarations in C++.
Li Haoyi
@lihaoyi
I actually prefer needing to explicitly public things like I had to in C#
rather than having it automatic in Scala
Ichoran
@Ichoran
It adds a lot of boilerplate to a lot of code.
Li Haoyi
@lihaoyi
it takes away a lot of boilerplate to an equally large amount of code :P
Ichoran
@Ichoran
I generally view a lot of private stuff as a code smell.
I do wish private[this] was called my, though.
Li Haoyi
@lihaoyi
no idea why you don't like private
Ichoran
@Ichoran
It disguises poor APIs and prevents reuse.
David Dudson
@DavidDudson
@Ichoran I think in practice a lot of libraries will depend on infix notation (scalatest, sbt, scalaz). I think it is a necessity in a lot of cases.
Ichoran
@Ichoran
Sometimes you have to do this, but I try to make them the exception, not the rule.