gmane.comp.lang.scala.debate

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 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: 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:

Could the Manifest generation be implemented by a macro?

Andrés Testi — 2012-05-18T19:49:59

Currently the compiler does magic to generate Manifests on demand:

def foo[T](implicit Manifest[T]) = ...

foo[FooClass]<<Compiler generates a Manifest for FooClass in the foo 
invocation point>>

Could this compiler task, be replaced by a macro in a future version of 
Scala?

object Predef{
  
  implicit def manifest[T]: Manifest[T] = macro manifestImpl

  def manifestImpl[T](c: Context): Expr[Manifest[T]] = {
    // generate a Manifest for T
    ...
  }
}

Regards.

- Andrés

Re: right-biasing Either

missingfaktor — 2012-05-18T18:24:14

Validation's applicative instance accumulates failures. Its monad instance
doesn't (and can't), and thus does not comply with its applicative
instance. That's what he meant.

scala> val List(a, b, c) = List(Success(2), Failure("foo"), Failure("bar"))
: List[Validation[String, Int]]
a: scalaz.Validation[String,Int] = Success(2)
b: scalaz.Validation[String,Int] = Failure(foo)
c: scalaz.Validation[String,Int] = Failure(bar)

scala> (a |< at >| b |< at >| c)(_ + _ + _)
res2: scalaz.Validation[String,Int] = Failure(foobar)

scala> import Validation.Monad._
import Validation.Monad._

scala> (a |< at >| b |< at >| c)(_ + _ + _)
res3: scalaz.Validation[String,Int] = Failure(foo)


To put it differently, you can write two applicative instances for
validation:
1. one that doesn't accumulate errors
2. one that does.

With (1), you can go further ahead and define monad instance. No laws are
violated.

With (2), you obey the applicative laws, but violate monad laws, and so you
cannot define a monad instance with this accumulation behavior.

On Fri, May 18, 2012 at 8:09 PM, Chris Marshall <oxbow_lakes< at >hotmail.com>wrote: