gmane.comp.lang.scala.debate

Re: Parentheses instead of curly-braces around case-lambdas?

Erik Post — 2012-05-25T18:03:08

+1 

I used to be bothered by this in my very early days of using Scala. I don't 
really notice it anymore now, but explaining things like this to my 
colleagues was a royal pain in the you-know-what. For me personally, it 
would be a nice to have, but I think it would be a big win for all the 
Scala newbies. it might also might fit in nicely with Martin's suggestions 
for cleaning up if/else and similar constructs.

Cheers,
Erik


On Friday, 25 May 2012 14:25:56 UTC+2, Luke Vilnis wrote:

Parentheses instead of curly-braces around case-lambdas?

Luke Vilnis — 2012-05-25T12:25:56

Apologies if this has been asked before - I did a brief search and couldn't
find anything.

Would it be possible to allow case-lambdas within parentheses (instead of
braces) in a future version of Scala?

The idea is just to allow "(case pat (if cond)? => expr)" to mean the same
as "{ case pat (if cond)? => expr }", at least when inside an argument list
(but hopefully anywhere inside parentheses). So we could write things like:

Map("asd" -> 123).map(case (k, v) => (k, v + 1))

or even lose the parentheses when in a multi-argument list:

multiArgumentMethod(case (x, hd::tl) => x::tl, case (x, Nil) => x::Nil)

or whatever. For ambiguity's sake, we couldn't allow it outside of
parentheses, and maybe not outside of argument lists at all (but I don't
think we'd have to go that far):

val f = case (a, b) => a + b // No!
val f = (case (a, b) => a + b) // Maybe?

As far as I can see, this shouldn't be ambiguous in the grammar, but I
could definitely be missing something.

Thanks,
Luke

P.S. Justification for additi

Re: Object identity

Jonas Bonér — 2012-05-21T22:46:51

LOL. Taken.

--
Jonas Bonér
 On May 21, 2012 3:19 PM, "Josh Suereth" <joshua.suereth< at >gmail.com> wrote:

RE: right-biasing Either

Chris Marshall — 2012-05-21T18:44:23

Apologies - I missed the beginning of the thread. Personally I like the syntax of the twitter Try class, it maps more closely to the use case. Obviously it's less flexible than right-biasing Either because it's fixed in its "left" type; however, I dislike having two almost-identical classes in the standard library. I think for that reason, I'd have to vote for right-biasing Either.
Chris

Re: right-biasing Either

Rex Kerr — 2012-05-21T18:24:35

FWIW, the Has class that I linked to earlier in this thread handles this
case without a glitch.  (At least as it stands in my current codebase; I
may have tweaked it slightly since the PasteBin post.)

  --Rex

On Mon, May 21, 2012 at 11:59 AM, Chris Marshall <oxbow_lakes< at >hotmail.com>wrote:

Re: right-biasing Either

Joa Ebert — 2012-05-21T17:00:54

I am also in favor of a right-biased Either. It is simple, easy to 
understand and fulfills the need of encoding failure/success in a type. 

I would vote against adding Try in its current fashion to the standard 
library without a right-biased Either. Our use case is different for 
instance. We encode failure into an ADT and unexpected exceptions are 
wrapped. Try makes only sense if one does not use Either. I wonder how you 
are supposed to work with Try[Either[A, B]] in a sane way? Yeah, it is 
possible of course but not very convenient. I imagine it would be nice to 
have the best of both worlds: Tryther[A, B] ;)


Best,

Joa

On Monday, May 21, 2012 6:14:21 PM UTC+2, Jason Zaugg wrote:

Re: right-biasing Either

Jason Zaugg — 2012-05-21T16:14:21

That was the problem reported in SI-5793, which prompted me to start
this thread. I try to explain what's happening in the comments.

-jason

https://issues.scala-lang.org/browse/SI-5793?focusedCommentId=57583&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-57583

RE: right-biasing Either

Chris Marshall — 2012-05-21T15:59:59

I have just got myself *incredibly confused* trying to understand what is going on is a for-comprehension using Either.RightProjection as the monad. Basically I can write a simple for-comprehension using Option
scala> for {       |     str <- Option("1")       |     i <- intOpt(str)  //intOpt is String => Option[String]       |     val j = i + 10    //Note use of = in generator       |   }       |   yield j    res18: Option[Int] = Some(11)
..and I want to convert it to using the Either monad. (i.e. replace Option("1") with Right[Throwable, String]("1") and intOpt with an intEither function
But it doesn't work (I think because RP.flatMap expects an R => Either[L, R]).
I've put it as a question on SO [1]. Any modifications to Either/Try etc should probably leave users less confused.
Chris
[1] 
http://stackoverflow.com/questions/10688447/scala-either-rightprojection-confusion-for-comprehension-de-sugaring

Mailing list reminder: Scala-debate

Scala Mailing Lists — 2012-05-21T13:32:02

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 star

Re: Object identity

Josh Suereth — 2012-05-21T13:18:39

a hasSameMemoryLocationAs b

Or with a pointless DSL:

a has same memory location as b

Verbosity FTW.


And an implementation for the confused:

object location
object same
implciit def betterEquals[A](a: A) = new {
  def has(x: same.type) = new {
    def memory(x: location.type) = new {
      def as[B](b: B) = a eq b
    }
  }
}


On Mon, May 21, 2012 at 9:07 AM, Eric Kolotyluk <eric.kolotyluk< at >gmail.com>wrote:

Re: Object identity

Eric Kolotyluk — 2012-05-21T13:07:04

In some languages the keyword 'isa' is used - presumably in Scala you 
could use 'is' and 'isa' as two different keywords - but I am not 
advocating that.

I also find 'eq' a little annoying as for me 'it does not read well' in 
code. On the other hand, I would not be offended if there was some 
symbolic operator (chicken track) for 'these two objects are the same 
object, that is they are identical' such as '≡' so long as there were an 
easy way to insert it from a standard keyboard in the appropriate IDE. I 
think

    if a ≡ b then . . . else . . .

is perfectly clear (to me) and most readable, where 'eq' is a synonym 
for '≡'

We have a wonderful world of UTF-8 that we should use better, as there 
are just some mathematical symbols that are very clear and well 
understood, just so long as no-one gets carried away, for example using 
'⊨' instead of 'true' and '⊭' instead of false.

Cheers, Eric

On 2012-05-21 2:41 AM, Paul wrote:

Re: right-biasing Either

Jason Zaugg — 2012-05-21T09:37:54

Try catches exception on map/flatMap, which we can't (and shouldn't)
replicate with a wrapper around Either. It's really a different beast.
Maybe we need some input from people who use it.

-jason

Re: right-biasing Either

√iktor Ҡlang — 2012-05-21T09:14:11

So what's the status here.

I strongly think that we should right-bias Either and then remove Try and
then simply have:

object Try {
  def apply[T](body: => T): Either[Throwable, T] = try Right(body) catch {
case NonFatal(t) => Left(t) }
}

You could even add extracts for Success and Failure:

object Success {
  def unapply[T](e: Either[Throwable, T]): Option[T] = e.right.toOption
//or simply e.toOption if right-biased
}

object Failure {
  def unapply[T](e: Either[Throwable, T]): Option[Throwable] =
e.left.toOption //or simply e.toOption if right-biased
}

Cheers,
√

On Mon, May 14, 2012 at 9:08 AM, Jason Zaugg <jzaugg< at >gmail.com> wrote:

Re: Object identity

Paul — 2012-05-21T06:41:58

Am Sonntag, 20. Mai 2012 22:52:02 UTC+2 schrieb Rex Kerr:
This sounds reasonable.

Re: Object identity

etorreborre — 2012-05-20T23:57:55

Yes, claiming a new "is" reserved word would be problematic for some people<http://etorreborre.github.com/specs2/guide-SNAPSHOT/org.specs2.guide.QuickStart.html#Acceptance>
 :-).

E.

On Monday, May 21, 2012 6:52:02 AM UTC+10, Rex Kerr wrote:
>

Re: Object identity

Rex Kerr — 2012-05-20T20:52:02

This eq a really bad idea.

"A cow is a mammal."

Seems like "is" has as much to do with types than with individual identity,
and certainly isn't a synonym for referential equality.

Besides which, introducing a new reserved word, which happens to be an
extremely common word, for aesthetic reasons is a good way to cause a huge
headache for people who used the word to mean something else.  There will
be many such headaches.

  --Rex


On Sun, May 20, 2012 at 4:45 PM, Paul <paul< at >vorb.de> wrote:

Object identity

Paul — 2012-05-20T20:45:20

You can use the `eq` operator for checking for object identity with any 
AnyRef object in Scala.

Wouldn’t it be more elegant to rename this to `is`. This way, you could 
write more readable code

    if (a is b) ...

What do you think?

Regards, Paul

Re: right-biasing Either

Tony Morris — 2012-05-18T23:43:56

validation.toEither.flatMap(f).toValidation

Actually it's the same as:
validation.toEither.flatMap(f andThen (_.toEither)).toValidation.

I agree this is a fine thing and only object to the method being called
flatMap or the operation being called a monad. It is not.

it were. This is perfectly alright.
functor.
wrote:
Validation, fixed in its Failure type is an Applicative functor (which want
to keep). It is also a Monad (which you don't). I recall someone saying
something about types not lying
wrote:

Re: Could the Manifest generation be implemented by a macro?

Andrés Testi — 2012-05-18T20:05:37

Cool! Even as experimental, macros are useful to prototype language 
improvements!
Thanks for your reply.

- Andrés

El viernes, 18 de mayo de 2012 16:54:17 UTC-3, Eugene Burmako escribió:

Re: Could the Manifest generation be implemented by a macro?

Eugene Burmako — 2012-05-18T19:54:17

Currently implicit macros are broken, so manifest materialization
macros are hardcoded into the compiler. Later on, before RC, I'm going
to fix macros, and the hardcode will be gone.

On May 18, 10:52 pm, Eugene Burmako <eugene.burm...< at >epfl.ch> wrote:

Re: Could the Manifest generation be implemented by a macro?

Eugene Burmako — 2012-05-18T19:52:48

Sure

https://github.com/scalamacros/kepler/blob/1d70943d85ea61e19b1bd718ca527bc1d6833222/src/compiler/scala/tools/nsc/typechecker/Implicits.scala#L1125

On May 18, 10:49 pm, Andrés Testi <andres.a.te...< at >gmail.com> wrote: