gmane.comp.lang.scala.debate

Re: [scala-debate] Uncluttering Scala’s syntax

Alec Zorab — 2013-05-21T19:38:02

I wasn't trying to ressurect all of SIP 12, I was hoping to bring in what I
imagined was a relatively uncontroversial feature. Unfortunately, I didn't
consider any of Rex's examples. Still, we could deprecate

for (...) do ...

in favor of

for (...) {do ...}

as another incremental step towards slowly disambiguating things.


On 21 May 2013 20:15, martin odersky <martin.odersky< at >epfl.ch> wrote:

Re: [scala-debate] Uncluttering Scala’s syntax

martin odersky — 2013-05-21T19:15:15

Scala 2.11 is definitely too early for SIP 12. For afterwards, ... it
depends. It's currently neither buried nor on the roadmap for any
particular release.

Cheers

 - Martin


On Tue, May 21, 2013 at 6:59 PM, Rex Kerr <ichoran< at >gmail.com> wrote:

Fwd: [scala-debate] Uncluttering Scala’s syntax

Rex Kerr — 2013-05-21T16:59:09

I don't know.  Maybe someone else on the list knows the status of SIP-12?

  --Rex

---------- Forwarded message ----------
From: Eric Kolotyluk <eric.kolotyluk< at >gmail.com>
Date: Tue, May 21, 2013 at 11:57 AM
Subject: Re: [scala-debate] Uncluttering Scala’s syntax
To: Rex Kerr <ichoran< at >gmail.com>

Is SIP-12 dead, or merely postponed?

Is there any chance of SIP-12 making it into Scala 11.0?

Cheers, Eric

On Tue, May 21, 2013 at 8:00 AM, Rex Kerr <ichoran< at >gmail.com> wrote:

Re: [scala-debate] Uncluttering Scala’s syntax

Rex Kerr — 2013-05-21T15:00:01

I'm assuming that the proposal was for it to be optional, not required.  In
combination with SIP-12 and with all long names required, the ambiguity
would go away (at least in the cases I've thought about).

  --Rex


On Tue, May 21, 2013 at 8:52 AM, Andrés Testi <andres.a.testi< at >gmail.com>wrote:

Mailing list reminder: Scala-debate

Scala Mailing Lists — 2013-05-21T13:32:03

Welcome to the "Scala-debate" mailing list.

This automatic reminder is sent once a month to the list,
to keep subscribers up-to-date with the mailing list services,
and to help keeping the list on topic.

-------------------------------------------------------------------

The "Scala-debate" mailing list:

This list is a more relaxed forum for Scala discussions
that would probably be off-topic or too convoluted for
the other lists, but that may still be quite interesting
to follow for a selected readership.

In particular, the following are appropriate:

  * threads that evolved beyond their initial topic,
      and have become too long or convoluted to be
      of interest to most readers
  * threads discussing extremely specialized topics
  * threads that are mostly speculative in nature,
      out-of-the-box thinking, philosophical views
      (as long as they are still somehow related
      to Scala)
  * debates (of course)

The "Scala-debate" list is the natural destination of all
the threads that start on other mailing lists, but are no
longer on topic on their original list, or have turned
into an in-depth debate about something.

-------------------------------------------------------------------

Other information:

There are several Scala lists devoted to individual topics (and
more may be created in the future). For the full list, please
see: http://www.scala-lang.org/node/199

Try to avoid cross-posting whenever possible. If you can, select
the list that is closer to your topic and post in that list only.
In any case, never cross-post replies.

If you ever want to unsubscribe from this list, just visit this
page: http://groups.google.com/group/scala-debate/subscribe
or send an email to scala-debate+unsubscribe< at >googlegroups.com

Thank you!
The Scala Team

Re: [scala-debate] Uncluttering Scala’s syntax

Andrés Testi — 2013-05-21T12:52:15

Are these snippets valid with the full support of the new syntax? Aren't 
you missing an extra "do" for each "while"?

  for (i <- 1 to 10) do println(i) while (j < 10) j += 1

for i <- 1 to 10 do println(i) while j < 10 do j+= 1
 


for i <- 10 to 10 do println(i)
while j < 10 do j += 1

 


for i <- 1 to 10 do
  do println(i) while j < 10
j + = 1

Re: [scala-debate] Uncluttering Scala’s syntax

ARKBAN — 2013-05-21T12:32:40

Yeah that is one of the things I encourage when writing Scala -- write 
full signatures for methods. It might be redundant information to the 
compiler but in my experience generally easier to read. (At least in my 
code base rare is the one liner methods whose return types are obvious.)

ARKBAN

On 5/21/13 8:22 AM, Alec Zorab wrote:

Re: [scala-debate] Uncluttering Scala’s syntax

Alec Zorab — 2013-05-21T12:22:17

true.

def doubleList(xs: List[Double]) = for(x <- xs) double(x)

Merrily compiles without issue though and doesn't return what one might
immediately expect.


On 21 May 2013 13:17, ARKBAN <arkban< at >arkban.net> wrote:

Re: [scala-debate] Uncluttering Scala’s syntax

ARKBAN — 2013-05-21T12:17:01

 > def doubleList(xs: List[Double]) : List[Double] = for(x <- xs) double(x)

This fails to compile and produces a pretty clear error message. Would 
an additional keyword really solve this? If you forgot the "do" keyword 
you'd likely get the same compiler error message.

 > However, for the point of view of someone who has to occasionally 
teach bits of scala to others...

I am in a similar situation, I help developers with Scala frequently. I 
think value of "do" depends on who you are teaching. I am usually 
dealing with developers familiar with other languages: Java, C#, 
JavaScript, etc. For people with familiarity with those kinds of 
languages adding "do" wouldn't be helpful, it would make Scala less 
familiar. (This is /especially/ true in mixed language shops like mine

Re: [scala-debate] Uncluttering Scala’s syntax

Rex Kerr — 2013-05-21T11:05:30

I like the idea in principle, but

  for (i <- 1 to 10) do println(i) while (j < 10) j += 1

  for (i <- 1 to 10) do println(i)
  while (j < 10) j += 1

  for (i<- 1 to 10)
    do println(i) while (j < 10)
  j += 1

...which is it?

  --Rex



On Tue, May 21, 2013 at 6:14 AM, Alec Zorab <aleczorab< at >gmail.com> wrote:

[scala-debate] Uncluttering Scala’s syntax

Alec Zorab — 2013-05-21T10:14:34

I was greatly saddened when the community collectively killed off SIP-12,
because I personally thought it would be an excellent improvement over the
current mess of inconsistent parens rules.

However, for the point of view of someone who has to occasionally teach
bits of scala to others (and tech them how to debug things), the single
biggest increase in quality of life for me would have come from the ability
to write this:

for (i <- 0 to 10) do println(i)

Yes, the lowly "do" keyword would be an absolute boon if we could use it as
a big screaming marker to say "look, I'm side effecting here", especially
since it's not unreasonable for a new user to (incorrectly) see a parallel
between

def double(x:Double) : Double = 2*x //don't have to use a keyword to return
something

and

def doubleList(xs: List[Double]) : List[Double] = for(x <- xs) double(x)
//so I shouldn't need one in this loop, right?

So. Are we still early enough in the 2.11 cycle to try and get this in?
If so, thoughts/comments from the crowd?

Re: Re: Code Coverage for Scala

Anjaiah Yamagani — 2013-05-17T19:00:53

Hi All,

I would like to ask couple of questions about the Scala Code Coverage and
Quality Metrics.

I have gone though the SCCT tool, It just tells about the JUnit Code
Coverage.

But I would like to see suitable tool for scala which will cover.

1. Unit Test case report.
2. Integration test cases
3. Functional test cases.
4. Load Test cases.
4. Code Quality metrics (like code complexity, design issues,package
triangle index)
5. Statics Analysis of the code.


As per my knowledge we have

1. Jacoco
2. Cobetura
3. SCCT
4. Sonar

Please advise me a best suitable tool for the above mentioned points.


Regards,
Anjaiah Y



On Sat, Apr 20, 2013 at 11:05 AM, Alexis Agahi <alexis.agahi< at >gmail.com>wrote:

Proposal for dollar semantics

Som Snytt — 2013-05-16T22:42:19

When you are new to a city, it helps the budget-conscious traveler to pick
up a Zagat guide and figure out where to find a meal.

It might help the performance-minded newcomer to Scala if the compiler
adopted the following conventions:

$    - cheap accommodation of nested entities
$$   - still reasonable artifact that won't bust your budget
$$$  - rather pricey computation, time- or space-wise
$$$$ - you must be wearing a tie to invoke this function

For example, I might invoke Partner$available$$$$diningOption$anon$1 if I
thought you might be the one, or maybe if I was just looking for something
anon.

How much time does paulp have left?

Som Snytt — 2013-05-12T03:23:47

imperative

For the record, I would wear this t-shirt every day (except for laundry
days), just to keep myself honest.

Also, scala-lang.org could display a counter in the corner with the "paulp
clock".

It would have to tie in with the jenkins PR validator, of course.

Love and care of artifacts

Som Snytt — 2013-05-12T03:08:16

Twitter sends me emails, like this one:

Carl Byström<https://twitter.com/i/redirect?url=https%3A%2F%2Ftwitter.com%2Fcgbystrom%2Fstatus%2F331783368725372928%3Frefsrc%3Demail&sig=22e23cbecb11cc7ed7caacb13dd15c6c469b75a0&uid=388517968&iid=fe75c683-cf94-4c16-9764-1c19b84cd374&nid=12+139+20130507&t=1>
< at >cgbystrom<https://twitter.com/i/redirect?url=https%3A%2F%2Ftwitter.com%2Fcgbystrom%2Fstatus%2F331783368725372928%3Frefsrc%3Demail&sig=22e23cbecb11cc7ed7caacb13dd15c6c469b75a0&uid=388517968&iid=fe75c683-cf94-4c16-9764-1c19b84cd374&nid=12+149+20130507&t=1>

If only developers wrote commit messages with same love and care as code.
This may be obvious to everyone, but s/code/paulp/.

paulp commits make archaeology fun again.

I thought maybe Carl was part of the Scala ecosystem on the Akka side
(because of the two dots), so I consulted his blog.

He riffs on David Pollak's view that Scala is a measure of something, like
taking calculus.  He adds that this is so important to the Scala ethos that
the spec should say, "Scala differentiates good programmers from the
rest."  And in an appendix, "Since you have read this far, you are either a
good programmer or a good reader."

I made up that last bit.

I honestly believe that everyone, no matter what sins they have committed
in the past, deserve to benefit from Scala.

Full disclosure:  When DPP said "Zed Shaw," I went, "Like Scala Zed?"

Re: How can we teach the utility of Try?

Julien Richard-Foy — 2013-05-06T10:33:37

I think Try gives you more control than try because it turns “computation 
attempts” into first class values.

Le mardi 30 avril 2013 00:58:45 UTC+2, Rex Kerr a écrit :

Re: propositions for scala that could increase reliability and controllability

Paul Phillips — 2013-05-03T23:55:01


I recently proposed that access should be done with annotations. Using type
bounds to articulate access restrictions would allow for that level of
granularity, and much more. Plus we could throw two keywords back into the
hopper.

propositions for scala that could increase reliability and controllability

arkantos — 2013-05-03T23:27:47

There are a few things I always missed in java:
1) design by contract (pre- and post condition, invariant ...)
2) class scoping like in eiffel:
   wouldn't it be handy to hide functions from other objects except from 
those we gave the permission to access
  
   ex: {A,B} class C extends D ...
      -> only A, B and C itselve may access the methods of C

  thus we could use a strict variation of the fascade pattern or do any other 
helpful things. It shouldn't be overused of course but we gain much more 
control of who  uses our classes.

This expansions wouldn't affect old code i guess, because there's no need 
to change anything about the scopes used so far (private, ...)

Moreover we could find many bugs at compile time. Debugging and Testing 
might get much easier.

Re: How can we teach the utility of Try?

marius a. eriksen — 2013-04-29T23:34:22

The initial idea behind com.twitter.util.Try -- from which
scala.util.Try is derived -- was to divorce exception handling from
the call stack. Where you can get away with normal exception handling,
consider using stack-based exception handling, otherwise use Try.

-marius

How can we teach the utility of Try?

Rex Kerr — 2013-04-29T22:58:45

I've noticed repeatedly on StackOverflow (and also scala-users) that even
some of the most sophisticated members of the Scala community write
suboptimal-clarity Try code.

When I use Try, I make heavy use of two patterns:

(1) Assume the best, prepare for the worst.

  val x = Try { ... }
  val y = Try { ... }
  val z = Try { ...; f(x.get, y.get); ... }

(This is/should be the answer to pretty much every question of the form "I
have Try inside and I want it outside".)

(2) Exceptions are classes, too.

  case class Net(fish: String) extends Exception
  Try { ...; throw Net("salmon"); ... } match {
     case Failure(Net(fish)) => println("Oh, it's just a "+fish)
     case Failure(t) => ...
     case Success(s) => ...
  }

(This is/should be the answer to pretty much every question of the form
"Sometimes I need to return some data along with a failure.")

I'm sure there are more.  But it seems--am I wrong?--that these sorts of
patterns are not really occurring naturally to people.

Why not, and what can we do about it (or is there something wrong with
these patterns?--yes, I know it's a pretty heavyweight fishing operation
there)?

  --Rex

Re: Is the writing on the wall for client side JVM?

Rex Kerr — 2013-04-26T14:45:02



That's because we don't need Java 8 for anything.  Some features might give
a performance advantage, but until basically everyone is using 8, Scala
can't assume they're present.




Er, it's days are already over on the bulk of client side OSes, because
Windows is the bulk, and it doesn't install the JVM by default.



Security problems are a issue for servers too.  Maybe even a bigger issue,
since if you get server access you generally have a lot more exploitable
data available.  (Not so useful if you just want a botnet, though.)  I'm
not sure why you think the security issues are client/desktop-specific.




Can't argue with that.



I don't think this is realistic.  Dalvik and Avian already seem to be
beyond the reach of substantial efforts, and this is despite them opening
up the entire mobile/smartphone market.  Instead, people rely upon the
standard bytecode transformation toolchain to use Dalvik, and on Avian to
not require anything different.




People aren't buying a desktop/laptop becaues they don't need one, they're
not buying one because they've already got one.  It's the same problem that
car manufacturers have: a five year old car works just fine.  How, then, do
you get people to upgrade?  Selling unreliable hardware doesn't really cut
it, because people learn to avoid junk after a while.




Why bother?  JavaFX is open source and works fine on Linux.  (Could work
better, I suppose.)




Ouch, why?!  That requires an enormous bundle of work just to stay
compatible with mainstream Java.

Code reuse goes for not duplicating effort in libraries/compilers/operating
systems/etc. also.  I think not seriously working on mobile platforms is a
long-term strategic mistake, but bailing on the giant ecosystem built
around the JVM seems precisely the wrong direction to go in.

Now, if you could _not care_ (except for performance) whether you were
using the JVM and calling libraries there or calling C libraries, that
would be awesome.  But it would also be impossible, I think: the models for
what you are responsible for are just too different.

  --Rex