the val does not evaluate to (), the compiler actually adds the () after the val definition. It's a workaround for situation where you assign to a value in a code block. It removes the need for () at the end of an expression that does so.
(I know I'm late on this conversation). - Josh On Fri, Sep 17, 2010 at 12:31 PM, Kevin Wright <[email protected]>wrote: > precedence rules are catching you out here, you need the braces: > def x = { val y = 5 } > > It also works just fine in compiled code > > > On 17 September 2010 17:19, Ricky Clarkson <[email protected]>wrote: > >> That's an interpreter illusion; a variable declaration is not actually a >> value, otherwise you would be able to write: >> >> def x = val y = 5 >> >> On Fri, Sep 17, 2010 at 4:50 PM, Kevin Wright >> <[email protected]>wrote: >> >>> >>> >>> >>> >>> On 17 September 2010 16:18, Reinier Zwitserloot <[email protected]>wrote: >>> >>>> Correction: In java, as in scala, all expressions "return" a value >>>> (not really the right term, that. Expressions *have* a value is closer >>>> to the mark). It's just that in scala more things are expressions. >>>> Like "if": Expression in scala, statement in java. Not ALL things in >>>> scala are expressions. Variable declarations aren't, for example. >>>> >>> >>> Hot from the Scala REPL: >>> >>> scala> val x = { val y = 32 } >>> x: Unit = () >>> >>> So even variable assignments evaluate to a value. >>> >>> >>>> In any java library that isn't completely worthless, the code is >>>> "getField()". If you get annoyed at writing out the accessor, use >>>> lombok. Claiming that as a benefit to scala seems like you're grasping >>>> for reasons. >>>> >>> >>> It's a major benefit: >>> >>> trait X { >>> def property : Int >>> } >>> >>> class Y extends X { >>> val property = 32 >>> } >>> >>> When I use `property` from an object of type X, it really doesn't matter >>> if it's implemented via a field of if it's computed. >>> That freedom from having to know (or care) is a simplification to me. >>> >>> >>>> A useful definition for "higher level" is that it makes invisible / >>>> automated whatever's trivial detail. This is a double-edged knife, >>>> though: Whether or not a detail is trivial depends on the problem. For >>>> example, C conveniently abstracts away the concept of stack, but in >>>> the process of doing so, removes the ability to store stacks. The JVM >>>> abstracts away memory management, but in the process of doing so >>>> introduces non-determinism due to gc runs. >>>> >>>> However, with that definition scala isn't much higher than java. There >>>> aren't many things that you can no longer do in scala but which you >>>> can do in java, and on the flipside, there aren't many things that are >>>> orders of magnitude simpler in scala than java because something has >>>> been abstracted away. Scala is more a sideways step: It's operating at >>>> the same general level of abstraction as java, but with a different >>>> syntax, which includes more emphasis on function objects (something >>>> java CAN do, but not with particularly nice syntax), as well as a less >>>> rigid syntax structure, and a general more functional outlook. >>> >>> >>> Function objects are just a tiny part of it, not only does Scala have >>> functions that are objects, but also any arbitrary object can be made into a >>> function. >>> On top of this there's pattern matching, implicits (which allow for type >>> classes), higher-kinded types and by-name params. >>> Closures alone don't make a language higher level than Java, but Scala >>> really isn't about just closures... >>> >>> Just compare the implementation of a heterogenous list in both languages: >>> >>> http://apocalisp.wordpress.com/2008/10/23/heterogeneous-lists-and-the-limits-of-the-java-type-system/ >>> >>> http://apocalisp.wordpress.com/2010/07/06/type-level-programming-in-scala-part-6a-heterogeneous-list%C2%A0basics/ >>> >>> >>> >>>> On Sep 17, 3:28 pm, Kevin Wright <[email protected]> wrote: >>>> > I'm recently taking the position that it's impossible to state which >>>> of two >>>> > languages is "simpler", the term is just too heavily overloaded. >>>> > >>>> > Just pick your definition and it's trivial to show that assembly is >>>> simpler >>>> > than LISP, or vice-versa, but you've still achieved nothing. If we >>>> use the >>>> > term "higher-level" instead of "simpler", then this difficulty >>>> evaporates. >>>> > >>>> > Personally I feel that Scala is simpler than Java, but that statement >>>> means >>>> > nothing without also explaining the particular definition of the term >>>> that >>>> > matters to me. In this case, it's two features of that language that >>>> really >>>> > stand out, and show Scala to be the higher-level language.. >>>> > >>>> > 1. It has constructs that closely match the way I think about >>>> problems. >>>> > When I have to mangle the design in my head so that it matches the >>>> features >>>> > of the target language, I perceive that as an unneccessary >>>> complication in >>>> > the design+implementation process. >>>> > 2. Scala has a smaller general-purpose syntax that I can use accross a >>>> wide >>>> > range of problems, instead of a larger number special-case constructs. >>>> For >>>> > example: >>>> > >>>> > - Java has the ?: operator, but Scala has the much more general idea >>>> that >>>> > all expressions return a value. >>>> > >>>> > - Java has a switch statement over numbers, enums and (soon) Strings, >>>> wheras >>>> > Scala has pattern matching that isn't limited to any type. >>>> > >>>> > - Java has primitives, and operators are limited to only working with >>>> > primitives. Everything in Scala is an object, and operators are just >>>> > methods. >>>> > >>>> > - Java has special behaviour for concatenating an object or primitive >>>> to a >>>> > string, Scala can do this with implicit conversions - a feature that's >>>> > useful in many more situations. >>>> > >>>> > - To fetch a value from an object in Java, I must first know if it's a >>>> fixed >>>> > value or if it'll be calculated, and so use field or getField() as >>>> > appropriate, Scala doesn't force this distinction and so it's enough >>>> to know >>>> > I'm fetching a value, the underlying logic could even be changed in >>>> the >>>> > future without breaking my code. >>>> > >>>> > The ability to work with general concepts and not have to chose >>>> exactly >>>> > which special feature I need in a given situation... I see that as >>>> > simplifying the task of programming. >>>> > I could say more, but it's probably just "simpler" to point here: >>>> http://stackoverflow.com/questions/727078/whats-so-great-about-scala/. >>>> .. >>>> > >>>> > On 17 September 2010 11:30, Reinier Zwitserloot <[email protected]> >>>> wrote: >>>> > >>>> > >>>> > >>>> > > That just sounds like equating "simple" to "less verbose". >>>> > >>>> > > For example, with optional () for args-less method calls, you get a >>>> > > number of things which one might deem "simpler": >>>> > >>>> > > - Less characters to type and read >>>> > > - The ability to not have to care about whether the doClick member >>>> is >>>> > > a method or a field >>>> > >>>> > > On the other hand, you also get a few things which are decidedly >>>> more >>>> > > complicated: >>>> > >>>> > > - A stylistic choice about whether or not you add the (). Having to >>>> > > make an irrelevant choice of any sort clearly seems like a lack of >>>> > > simplicity to me. >>>> > > - The INability to tell if doClick is a field or a method. In >>>> certain >>>> > > circumstances it matters, and having to look it up is more >>>> complicated >>>> > > than being able to tell at a casual glance. >>>> > >>>> > > These are clearly conflicting requirements. Forcing you to care >>>> > > whether doClick is a field or a method is needless complexity.... >>>> > > unless it isn't, in which case not being able to tell is needless >>>> > > complexity. Offering the programmer the choice doesn't help, because >>>> > > the choice in it self is needless complexity, and by existing we >>>> still >>>> > > can't tell, given "foo.doClick", if doClick is a field or a method. >>>> > > We'd have to rely on a programmer following the local style >>>> guidelines >>>> > > (if, say, these state that non-fields ought to be called with >>>> parens), >>>> > > which you can' even unit test. Now we're introducing needless >>>> > > complexity there. >>>> > >>>> > > Oh, how complicated. >>>> > >>>> > > There's also the issue of moving complexity around to the problem >>>> > > domain. My usual retort to those complaining about the complexity of >>>> > > generics is simply this: Co- and Contravariance is _inherently_ >>>> > > complicated. When you have a problem where generics is required or >>>> > > seems quite useful, then the problem has this complexity, >>>> inherently. >>>> > > You can choose not to use generics, but then the complexity is just >>>> > > hidden away in javadocs and a bunch of casts. You can tweak generics >>>> a >>>> > > bit, declaration-site generics probably being the most drastic, but >>>> a >>>> > > truly "simple" generics will never be, because co/contravariance >>>> isn't >>>> > > simple. >>>> > >>>> > > So, did java become more complex when 1.5 was introduced? Yes. Does >>>> > > this mean java 1.5 is worse than 1.4? No - in fact, it's better. >>>> > >>>> > > So, in certain ways, a more complex language is actually a good >>>> thing. >>>> > >>>> > > Hence my conclusion that all this talk about "complexity" is not >>>> going >>>> > > to convince anybody one way or another, because its very very easy >>>> for >>>> > > anyone reading the word "complexity" and imagine whatever situation >>>> is >>>> > > least likely to convince them. >>>> > >>>> > > So, to try and mitigate this, here's where I believe scala has added >>>> > > needless complexity: >>>> > >>>> > > Stylistic choice is EVERYWHERE. This is what, as I said, *I* mean by >>>> > > DSLish features (yet another vague term that can mean just about >>>> > > anything). Should I put () after an args-less method call? There's a >>>> > > stylistic choice there. dots to dereference? Another stylistic >>>> choice. >>>> > > Use operator overloading, or not, and if I do, left-associative or >>>> > > right-associative? There's also boatloads of semantic choice in >>>> scala. >>>> > > If I need to iterate over a map and, say, produce a list containing >>>> > > the concatenation of each key and associated value, in java there's >>>> > > really only two obvious ways to do it. Both involve looping, and the >>>> > > only difference is whether I iterator over entrySet() or keySet(). >>>> In >>>> > > scala, there's _way_ more choices. I can do a java-style loop, or I >>>> > > can use an each construct that fills the list, or I can turn the >>>> keys >>>> > > and the values into two sets, and then zip them up, functional >>>> style, >>>> > > or I could use a comprehension of some sort. >>>> > >>>> > > Why is this bad: >>>> > >>>> > > Well, obviously a language can't eliminate _all_ stylistic choice. >>>> At >>>> > > the very least you have to pick a name for your methods, and naming >>>> is >>>> > > clearly up to you, the API author. But, scala goes _way_ too far in >>>> my >>>> > > opinion. While it seems like a nice idea, give an API designer, and >>>> an >>>> > > API user, the ability to write in whatever feels most natural (i.e. >>>> > > readable, easy to maintain), that's great! Except when it isn't: By >>>> > > introducing all these stylistic choices, you're forcing the API user >>>> > > to pick at every stage. Sometimes, this choice is good, because the >>>> > > benefits of picking the best option available outweigh the burden of >>>> > > having the choice. In all other situations, though, this choice is >>>> not >>>> > > useful at all. It makes sharing code harder (because Joe likes >>>> 'each', >>>> > > but Jack likes 'for'). This is like spaces v. tabs: The flexibility >>>> of >>>> > > using either really isn't helping. We'd have been better off if back >>>> > > in the day someone put their foot down and declared some indent >>>> style >>>> > > to be the only one compilers will accept from here on out. Deviation >>>> > > from this one rule results in compiler warnings. I can't claim to be >>>> > > very scientific about it, but to me it feels like Scala has gone >>>> > > waaaay too far down the "give the programmers the flexibility" path. >>>> > > Where the flexibility helps me make code do different things, that's >>>> > > fantastic. Where this flexibility boils down to the exact same end >>>> > > result, and I just have many different ways of expressing the same >>>> > > concept, usually, it's just a bother. It's needless complication. >>>> > >>>> > > The python folks differentiated themselves from the Perl folks early >>>> > > by turning Larry Wall's "There Are Many Ways To Do It" around into >>>> > > "There Is Only One Way To Do It" and I subscribe to the theory. >>>> > > Introducing stylistic choice needlessly is always bad. But yet again >>>> > > there's a dichotomy here: Where stylistic choice turns from >>>> pointless >>>> > > to useful is a moving target, there isn't a single answer to the >>>> > > question. >>>> > >>>> > > Perhaps I was unclear about my comment in regards to using java >>>> > > libraries in scala code: If you're going to write scala, then... >>>> write >>>> > > scala. Which means you use THEIR collection APIs. If you stick with >>>> > > java.util.List, then interopping with other scala code is going to >>>> be >>>> > > a nightmare, and even if most scala programmers are familiar with >>>> the >>>> > > java APIs (which is clearly an argument that can't scale: If scala >>>> > > outgrows java in popularity, or gets even remotely close to it, how >>>> > > can that possibly be true?), its like not following the camelcasing >>>> > > conventions in java code. It throws people off, makes your code >>>> > > ridiculously hard to understand. Just don't do it. There's no going >>>> > > halfway, and there's not much point (as you said too) in trying to >>>> > > stay up to date with both java and scala. Pick one. That's your >>>> go-to >>>> > > language for larger projects where static typing is nice, and/or >>>> speed >>>> > > is not unimportant. If you want to learn more languages, fantastic. >>>> > > But don't pick java and scala. That's a silly combination, the >>>> problem >>>> > > domains where these 2 languages shine overlap far too much. >>>> > >>>> > > On Sep 17, 10:42 am, Ricky Clarkson <[email protected]> >>>> wrote: >>>> > > > Reinier, >>>> > >>>> > > > You want a definition of simple? Ok, some code is more simple >>>> than some >>>> > > > other code if it contains fewer tokens that are outside the >>>> domain. >>>> > > E.g., >>>> > > > Cobol's ADD 1 TO AGE GIVING AGE is not as simple as C's age++. >>>> Java's >>>> > > > SwingUtilities.invokeLater(new Runnable() { public void run() { >>>> > > > button.doClick(); } }) is not as simple as Scala's: >>>> > > doLater(button.doClick). >>>> > >>>> > > > Staying cutting edge on Scala is easier as it does not require a >>>> cutting >>>> > > > edge runtime. >>>> > >>>> > > > In my opinion, for tasks for which Java is a reasonable option, so >>>> is >>>> > > Scala, >>>> > > > as it is typed and runs in the same environment. I wouldn't look >>>> at >>>> > > Groovy, >>>> > > > JRuby or Jython for those, because they are untyped. >>>> > >>>> > > > Regarding writing in DSLs, pretty much all code unless >>>> > >>>> > ... >>>> > >>>> > read more » >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "The Java Posse" group. >>>> To post to this group, send email to [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]<javaposse%[email protected]> >>>> . >>>> For more options, visit this group at >>>> http://groups.google.com/group/javaposse?hl=en. >>>> >>>> >>> >>> >>> -- >>> Kevin Wright >>> >>> mail / gtalk / msn : [email protected] >>> pulse / skype: kev.lee.wright >>> twitter: @thecoda >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "The Java Posse" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]<javaposse%[email protected]> >>> . >>> For more options, visit this group at >>> http://groups.google.com/group/javaposse?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "The Java Posse" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<javaposse%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> > > > > -- > Kevin Wright > > mail / gtalk / msn : [email protected] > pulse / skype: kev.lee.wright > twitter: @thecoda > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
