Aaron Novstrup | 1 Jul 01:40 2011
Picon

toString abstraction

Is there anything like this "Stringable" type class [1] in the
standard library? In cases where the library uses toString (e.g.
println), it would be nice to be able to control how the object will
be translated to a String.  A type class would make it possible to do
this even without access to the original type's source, or based on
the context (display, logging, etc).

Assuming it's not present (I'm pretty sure it's not, but I haven't
looked at trunk), any chance it might be added?

[1] http://stackoverflow.com/questions/6537179/printing-collections-variable-specific/6540191#6540191

Tony Morris | 1 Jul 01:48 2011
Picon

Coincidence on IRC

I found this an interesting coincidence!

... there was a previous discussion about lenses and a compiler plugin
about 2 weeks ago
<me> did anyone take a stab at generating lenses for case classes? I
swear that would be totally fucking awesome
<me> I would fly to your house and kiss you on either of your arse
cheeks, of which you choose
<him> If I have an object that composes a couple of other objects is
their an easy way to delegate "property" access to the wrapped objects?
<me> haha! coincidence!
<me> dude that is what a Lens *is*, it forms a category

--

-- 
Tony Morris
http://tmorris.net/

S Wade | 1 Jul 02:12 2011
Picon

Re: parameterized types, Unit and entry point problem

Done.


thanks,
wade

On Thu, Jun 30, 2011 at 1:52 PM, Paul Phillips <paulp-v5eHc9rg9U0h9ZMKESR00Q@public.gmane.org> wrote:
On 6/30/11 10:37 AM, S Wade wrote:
> That makes sense, though I gather case b would be a bug?

Something in there is a bug, can you please open a ticket.

√iktor Ҡlang | 1 Jul 02:13 2011
Picon

Re: Re: java enums more compact, flexible and obvious than scala's equivalent?

Better impl and gisted it: https://gist.github.com/1057513

2011/6/30 Josh Suereth <joshua.suereth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
+1

2011/6/30 √iktor Ҡlang <viktor.klang <at> gmail.com>
There's also this ugly duckling...

trait Enum {
  import java.util.concurrent.atomic.AtomicReference
  type EnumVal <: Value
  private val _values = new AtomicReference[Vector[EnumVal]](Vector())
  protected trait Value { self: EnumVal =>
    _values.set(_values.get() :+ this)
    def name: String
    override def toString = name   
  }
  def values: Vector[EnumVal] = _values.get
}

object Foos extends Enum {
  sealed trait EnumVal extends Value /*{ you can define your own methods etc here }*/

  val F = new EnumVal { val name = "F" }
  val X = new EnumVal { val name = "X" }
}

scala> Foos.values.find(_.name == "F")
res3: Option[Foos.EnumVal] = Some(F)

scala> def doSmth(foo: Foos.EnumVal) = foo match {
  case Foos.X => println("pigdog")
}

<console>:10: warning: match is not exhaustive!
missing combination        $anon$1
missing combination        $anon$2

scala> def doSmth(foo: Foos.EnumVal) = foo match {
         case Foos.X => println("pigdog")
         case Foos.F => println("dogpig")
       }
doSmth: (foo: Foos.EnumVal)Unit


But if you don't care about getting exhaustiveness warnings, you can do:

object Foos extends Enum {
  case class EnumVal private[Foos](name: String) extends Value { /*you can define your own methods and stuff here*/}

  val F = EnumVal("F")
  val X = EnumVal("X")
}


Which is a bit less boilerplatey.


Cheers,






--
Viktor Klang

Akka Tech Lead
Typesafe - Enterprise-Grade Scala from the Experts

Twitter: <at> viktorklang

Mitchell Hashimoto | 1 Jul 06:48 2011
Picon

Type errors with polymorphic higher order type

Hello, 


I've created the following basic trait for monads in Scala:

trait Monad[M[_]] {
  def unitM[A](a: A): M[A]
  def bindM[A, B](a: M[A], f: A => M[B]): M[B]
}

And I've created the identity monad successfully. However, when I try to make a higher order abstraction, so that I can easily switch in new monads for my computations, then I get type errors. Example:

trait Runner {
  type M[_]
  val monadOps: Monad[M]

  def run {
    val one = monadOps.unitM(1)
    val result = monadOps.bindM[Int, Int](one, x => monadOps.unitM(x + 2))
    println(monadOps.showM(result))
  }
}

object BasicRunner extends Runner {
  type M[_] = Id[_]
  val monadOps = Id
}

BasicRunner.run

Without the higher orderness, this works fine. But once I introduce the abstract members M and monadOps, I get the following error:

error: overriding value monadOps in trait Runner of type this.Monad[Main.$anon.BasicRunner.M];
 value monadOps has incompatible type
  val monadOps = Id

Any hints?

Thanks,
Mitchell


Ken Scambler | 1 Jul 08:09 2011
Picon

Re: toString abstraction

Scalaz has a Show typeclass that does this.

On 1 July 2011 09:40, Aaron Novstrup <aaron.novstrup-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Is there anything like this "Stringable" type class [1] in the
standard library? In cases where the library uses toString (e.g.
println), it would be nice to be able to control how the object will
be translated to a String.  A type class would make it possible to do
this even without access to the original type's source, or based on
the context (display, logging, etc).

Assuming it's not present (I'm pretty sure it's not, but I haven't
looked at trunk), any chance it might be added?

[1] http://stackoverflow.com/questions/6537179/printing-collections-variable-specific/6540191#6540191

Jan van der Vorst | 1 Jul 09:34 2011
Picon

Re: Type errors with polymorphic higher order type

To compile BasicRunner correct your monadOps must be of type Monad[Id]
where Id is a type constructor.
Are you sure that value Id is of type Monad[Id] ?

On Jul 1, 6:48 am, Mitchell Hashimoto <mitchell.hashim...@...>
wrote:
> Hello,
>
> I've created the following basic trait for monads in Scala:
>
> trait Monad[M[_]] {
>   def unitM[A](a: A): M[A]
>   def bindM[A, B](a: M[A], f: A => M[B]): M[B]
>
> }
>
> And I've created the identity monad successfully. However, when I try to
> make a higher order abstraction, so that I can easily switch in new monads
> for my computations, then I get type errors. Example:
>
> trait Runner {
>   type M[_]
>   val monadOps: Monad[M]
>
>   def run {
>     val one = monadOps.unitM(1)
>     val result = monadOps.bindM[Int, Int](one, x => monadOps.unitM(x + 2))
>     println(monadOps.showM(result))
>   }
>
> }
>
> object BasicRunner extends Runner {
>   type M[_] = Id[_]
>   val monadOps = Id
>
> }
>
> BasicRunner.run
>
> Without the higher orderness, this works fine. But once I introduce the
> abstract members M and monadOps, I get the following error:
>
> error: overriding value monadOps in trait Runner of type
> this.Monad[Main.$anon.BasicRunner.M];
>  value monadOps has incompatible type
>   val monadOps = Id
>
> Any hints?
>
> Thanks,
> Mitchell

Adriaan Moors | 1 Jul 10:26 2011
Picon
Picon

Re: Type errors with polymorphic higher order type

please have a look at


and

one thing that jumps out right away:

type M[_] = Id[_]

this means

type M[x] = (Id[y] forSome {type y})

In types, an underscore never refers to another underscore: an `_` introduces a distinct type every time it occurs. When a `_` occurs in a type parameter *definition* list, it introduces an unnamed type parameter. When a `_` occurs in a type (reference), it introduces an anonymous existential.

It is quite unfortunate that the type-level underscore behaves differently from the value-level underscore, where `_ + _` indeed means `(x, y) => x + y`

adriaan

On Fri, Jul 1, 2011 at 6:48 AM, Mitchell Hashimoto <mitchell.hashimoto-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hello, 

I've created the following basic trait for monads in Scala:

trait Monad[M[_]] {
  def unitM[A](a: A): M[A]
  def bindM[A, B](a: M[A], f: A => M[B]): M[B]
}

And I've created the identity monad successfully. However, when I try to make a higher order abstraction, so that I can easily switch in new monads for my computations, then I get type errors. Example:

trait Runner {
  type M[_]
  val monadOps: Monad[M]

  def run {
    val one = monadOps.unitM(1)
    val result = monadOps.bindM[Int, Int](one, x => monadOps.unitM(x + 2))
    println(monadOps.showM(result))
  }
}

object BasicRunner extends Runner {
  type M[_] = Id[_]
  val monadOps = Id
}

BasicRunner.run

Without the higher orderness, this works fine. But once I introduce the abstract members M and monadOps, I get the following error:

error: overriding value monadOps in trait Runner of type this.Monad[Main.$anon.BasicRunner.M];
 value monadOps has incompatible type
  val monadOps = Id

Any hints?

Thanks,
Mitchell



Chris Marshall | 1 Jul 10:58 2011
Picon

RE: toString abstraction

Unfortunately as of scalaz 6, show gives you a List[Char], which is, um, not *quite* so useable in a practical application.

Date: Fri, 1 Jul 2011 16:09:50 +1000
Subject: Re: [scala-user] toString abstraction
From: ken.scambler-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
To: aaron.novstrup-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
CC: scala-user-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org

Scalaz has a Show typeclass that does this.

On 1 July 2011 09:40, Aaron Novstrup <aaron.novstrup-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Is there anything like this "Stringable" type class [1] in the
standard library? In cases where the library uses toString (e.g.
println), it would be nice to be able to control how the object will
be translated to a String.  A type class would make it possible to do
this even without access to the original type's source, or based on
the context (display, logging, etc).

Assuming it's not present (I'm pretty sure it's not, but I haven't
looked at trunk), any chance it might be added?

[1] http://stackoverflow.com/questions/6537179/printing-collections-variable-specific/6540191#6540191

sross | 1 Jul 12:03 2011
Picon

Re: java enums more compact, flexible and obvious than scala's equivalent?

Thanks for the feedback everyone, I've added the solution to the SO
post.

On Jun 29, 6:57 pm, Jan van der Vorst <ndervo...@...> wrote:
> Well, it was an interesting exercise. I agree with all points.
>
> On Jun 29, 7:34 pm, Dave <dave.mahabiers...@...> wrote:
>
>
>
>
>
>
>
> > I think Sean's solution should be the second usage example in
> > Enumeration.scala/Scaladoc.
>
> > The problem(s) I have with Jan's (last) solution is that:
> > - it is a duplicate functionality, a fork on Enumeration and then
> > modified the Enumeration class (duplicate code is hard too maintain,
> > avoid duplicate code what's already in the API as much as possible).
> > - MyEnumeration is not extending standard Scala Enumeration  (where is
> > withName?) so it is not compatible with existing Enumeration
> > If someone made a framework/library that uses Enumeration, you'll have
> > to change that framework as well in order to use it (poor reusibility)
> > - it's an object and a class solution, not one object solution and the
> > total solution is bigger
> > - Pluto is not a planet


Gmane