gmane.comp.lang.scala.user

Re: Re: Macros - confusing results from show/showRaw

Eugene Burmako — 2012-05-24T18:41:44

Yep, it does.

Have you tried -Yreify-copypaste? It should be more suitable for that
purpose.

On 24 May 2012 20:07, Paul Butcher <paul-q9qwgYRQEc9WkMItezQGDw< at >public.gmane.org> wrote:

Re: converting type parameters (with self types) to abstract type members

Matthew Pocock — 2012-05-24T18:34:33


My rule of thumb is that I use generics where the type is 'chosen' by the
code using the API and type members where the type is 'chosen' by the
implementation code. Of course, there are exceptions to every rule, but
it's a good enough first guess most of the time.

Matthew

Re: Re: Macros - confusing results from show/showRaw

Stefan Zeiger — 2012-05-24T18:22:36

Take

     val e = reify { someComplexExpression }

What  want is a printReallyRaw(e) giving me some output that I could 
paste into a source file so that

    (e == <pasted code>) && (e match { case <pasted code> => true })

-sz

Re: Re: Macros - confusing results from show/showRaw

Paul Butcher — 2012-05-24T18:07:43

I can't speak for Stefan, clearly, but for my part I'm writing a new version of ScalaMock. As discussed in an earlier thread, I can't use reify to do this, so I'm having to write trees out explicitly.

The way that I'm working out how these trees should be structured is by using reify on an example of the kind of code I want to generate, and then passing the result of that to showRaw. This gives me an example of a specific tree, which I can generalise.

Make sense? 

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul-q9qwgYRQEc9WkMItezQGDw< at >public.gmane.org
AIM: paulrabutcher
Skype: paulrabutcher


On Thursday, 24 May 2012 at 18:58, Eugene Burmako wrote:

Re: Macros - confusing results from show/showRaw

Eugene Burmako — 2012-05-24T17:58:12

Could you be more specific about what you want to get from what?

On May 24, 6:20 pm, Stefan Zeiger <szei...-QayF08W3+w1Wk0Htik3J/w< at >public.gmane.org> wrote:

Re: Mapping a Map: type mismatch error (AST modelling)

Eugen Labun — 2012-05-24T17:33:10

Thank you very much, Jan!
Your code is very elegant.
I will try to apply your idea to my project.

Eugen

On 2012-05-24 19:16, Jan Vanek wrote:

Re: Mapping a Map: type mismatch error (AST modelling)

Jan Vanek — 2012-05-24T17:16:44

Hi Eugen, I tried to model it as a domain with an abstract value:

object Test {
     trait Domain {
         type Value <: Val

         trait Expr { def eval: Value }

         trait Val extends Expr { this: Value => def eval = this }

         trait Op extends Expr
     }

     object IntDomain extends Domain {
         trait Expr extends super.Expr {
             def add(other: Expr) = Add(this, other)

             def neg = Neg(this)
         }

         case class Value(v: Int) extends Expr with Val
         implicit def value(v: Int) = Value(v)

         case class Add(left: Expr, right: Expr) extends Expr with Op {
             def eval = left.eval.v + right.eval.v
         }

         case class Neg(expr: Expr) extends Expr with Op {
             def eval = -expr.eval.v
         }
     }

     def main(args: Array[String]) {
         import IntDomain._
         val expr = (1 add 2) neg

         println(expr)
         println(expr.eval.v)
     }
}

I happened to have a little time, perhaps it can be usable.
Regards,
Jan

Re: Re: Macros - confusing results from show/showRaw

Stefan Zeiger — 2012-05-24T16:20:55

BTW, is there any way to print a constructor/extractor for a tree 
without any simplifications? That would help with writing patterns for 
matching tree shapes if you have examples of such trees.

-sz

Re: Re: Mapping a Map: type mismatch error (AST modelling)

Eugen Labun — 2012-05-24T15:15:31

Thank you, again, Peter. This works in the simple example. I have to rewrite this yet for the real 
hierarchy of nodes. In reality there is an Op that has a parameter that evaluates to a Value that 
holds the map. Thus that Value have to be parameterized everywhere, too... What in turn would 
probably require passing of the parameter of the type parameter everywhere, too... (cyclic, as you 
say below)


Yeah, those cyclic dependencies are tricky (and ugly).

You mean 'usual': without the type parameters? I have had that before and was hoping to be able to 
create "typechecked" nodes (like IntAdd), so that the building of the whole tree is typesafe (IntAdd 
can be created only with parameters that evaluate to IntValues) and the evaluation is as simple as 
an `eval` call on the root node.

I was also thinking about from the viewpoint of the composite pattern. What I'm trying to achieve is 
a common supertype T for leaves + parameterizing of all nodes with a subtype of T. Yet couldn't find 
any implementation example for that.

The overall design (as in the posted code examples) is working for me in most situations. The only 
issue arised in this one case with "mapping a map". I suppose this could be not the last one though.



What would it look like in the code? Could you please explain a little?


Eugen

Re: converting type parameters (with self types) to abstract type members

Jan Vanek — 2012-05-24T15:08:00

On Thu, May 24, 2012 at 4:24 PM, Robbert van Dalen <
robbert.van.dalen-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


It is possible that the compiler has (or will have) some internal unifying
representation but I don't know the details.



They are sometimes less verbose for the "inside" of the code, I'd say. But
for example it would not be a good idea to have e.g. scala's List or Map to
have the element type (or key/value types) as abstract members because each
time when you use it you'd have to write code like List { type Value =
String } instead of List[String]. It's individual for each case. I don't
have the proper words to describe when is which one more suitable, though.
IMO you don't have to pick/prefer one, both are your friends.

HTH,
Jan

Re: Mapping a Map: type mismatch error (AST modelling)

Sonnenschein — 2012-05-24T14:19:12

Hi Eugen,

so even better:

def process[T <: Value[_]](m: Map[String,T]): Map[String,T] =
  m map {t => rename(t._1) -> t._2 }

Apart from this, I think you better stick with 'usual' algebraic
types. For instance, it's much simpler if  your algebraic type has a
root trait without cyclic type parameters.

Also, we could think of the '<: Value[_]' constraints as a client side
concern allowing us to eliminate it from your AST-design and packing
it into an intermediate object instead. What do you think?

Peter

Re: Macros - confusing results from show/showRaw

Eugene Burmako — 2012-05-24T13:54:37

All right, what your problem is really about is symbols.

When you deal with identifies in Scala, there are two equivalent ways
to represent them. First, you painstakingly write
`Select(Select(Select(..., newXXXName("")), newXXXName("")),
newXXXName(""))` to provide a full path to the identifier. Second, you
play smart - resolve a symbol and attach it to a bare ident, like
that: `Ident(ListClass)`.

The `Ident(newTypeName("HashMap"))` printout you're getting means that
there's a `class blah.blah.blah.HashMap` symbol underlying this
`Ident`. Current implementation of `showRaw` just prints its short
name, but, most likely, we can adjust it to print the full name. I'll
see to it, when we're done with reflection. Speaking of `show`, I'm
not sure whether it makes sense to always print full names, though.

On May 24, 12:27 am, Paul Butcher <p...-q9qwgYRQEc9WkMItezQGDw< at >public.gmane.org> wrote:

Re: Macros - confusing results from show/showRaw

Eugene Burmako — 2012-05-24T13:39:47

Doh, that's completely unrelated. Disregard my previous message,
please.

On May 24, 3:39 pm, Eugene Burmako <xeno...-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: Macros - confusing results from show/showRaw

Eugene Burmako — 2012-05-24T13:39:19

Yeah, that's a bug, and, in fact, I've stumbled upon it yesterday and
fixed it in topic/reflection.

Why does this happen? Currently I don't have a full-fledged
NodePrinter for reified stuff, so I do toString and then do a series
of String.replace. Ugly, yes, but with the rate of changes to
reification, I believe, that's the best approach.

The problem stems from the fact that one of these `replace` calls
replaces all scala.collection.immutable with an empty string to
suppress ugly `scala.collection.immutable.List` stuff. This has a
refreshing effect on eyes, but, unfortunately, it also deletes useful
info from inside strings.

On May 24, 12:27 am, Paul Butcher <p...-q9qwgYRQEc9WkMItezQGDw< at >public.gmane.org> wrote:

Re: Re: Mapping a Map: type mismatch error (AST modelling)

Eugen Labun — 2012-05-24T12:26:36

Oh, sorry. It seems that in the definition above all values in the map have to be parameterized with 
the same `T`. In my usecase there can be different types:

scala> :paste
// Entering paste mode (ctrl-D to finish)

   sealed abstract class Expr[T <: Value[_]] {def eval: T}

   sealed abstract class Value[T <: Value[_]] extends Expr[T] {def eval = this.asInstanceOf[T]}
   case class IntVal(v: Int) extends Value[IntVal]
   case class BooleanVal(v: Boolean) extends Value[BooleanVal]

   sealed abstract class Op[T <: Value[_]] extends Expr[T]
   case class IntAdd(e1: Expr[IntVal], e2: Expr[IntVal]) extends Op[IntVal] {def eval = 
IntVal(e1.eval.v + e2.eval.v)}

   def rename(s: String): String = "xxx"

   // def process(m: Map[String, Value[_]]): Map[String, Value[_]] = m map {t => (rename(t._1), t._2)}

   def process[T <: Value[_]](m: Map[String, Value[T]]): Map[String,Value[T]] = m map {t => 
rename(t._1) -> t._2 }

   process(Map("a" -> IntVal(5), "b" -> IntAdd(IntVal(2), IntVal(3)).eval))

   process(Map("a" -> IntVal(5), "b" -> IntAdd(IntVal(2), IntVal(3)).eval, "c" -> BooleanVal(true)))

// Exiting paste mode, now interpreting.

<console>:35: error: no type parameters for method process: (m: 
Map[String,Value[T]])Map[String,Value[T]] exist so that it can be applied to arguments (scala.co
llection.immutable.Map[java.lang.String,Product with Value[_ >: BooleanVal with IntVal <: Product 
with Value[_ >: BooleanVal with IntVal <: Product with Seriali
zable] with Serializable] with Serializable])
  --- because ---
argument expression's type is not compatible with formal parameter type;
  found   : scala.collection.immutable.Map[java.lang.String,Product with Value[_ >: BooleanVal with 
IntVal <: Product with Value[_ >: BooleanVal with IntVal <: P
roduct with Serializable] with Serializable] with Serializable]
  required: Map[String,Value[?T]]
                 process(Map("a" -> IntVal(5), "b" -> IntAdd(IntVal(2), IntVal(3)).eval, "c" -> 
BooleanVal(true)))
                 ^

Re: Using infix Ordering ops on String

Jason Zaugg — 2012-05-24T12:19:46

Could you please raise a bug on IntelliJ for that difference?

You could run scala -Xprint:typer ' ....; "a".min(null)' to see which
implicit kicks in. But it's a good idea to have an idea what implicits
are defined in Predef.

I would prefer Predef.augmentString and Predef.wrapString were was
moved into a (fictional) companion object for j.l.String, which would
mean they would only be used as a last resort.

-jason

Re: Re: Mapping a Map: type mismatch error (AST modelling)

Eugen Labun — 2012-05-24T11:59:45

Thank you, Peter! This works.
It seems that that `T<: Value[_]` should be passed through the whole tree...

Re: Mapping a Map: type mismatch error (AST modelling)

Sonnenschein — 2012-05-24T11:48:04

Maybe you can go with

def process[T <: Value[_]](m: Map[String, Value[T]]): Map[String,
Value[T]] =
  m map {t => rename(t._1) -> t._2 }

Peter

RE: Using infix Ordering ops on String

Chris Marshall — 2012-05-24T11:43:11

OK, I understand the problem. I still don't understand the error - how did you decipher it? IDEA jumps me (if I click on "min") to the Ordering#Ops definition; no indication of ambiguity at all
Chris

Re: Using infix Ordering ops on String

Jason Zaugg — 2012-05-24T11:27:22

Duelling implicits:

scala> augmentString("a").min
res0: Char = a

scala> import math.Ordering.Implicits._
import math.Ordering.Implicits._

scala> infixOrderingOps("a").min("b")
res1: java.lang.String = a

-jason

Mapping a Map: type mismatch error (AST modelling)

Eugen Labun — 2012-05-24T11:21:30

Dear all,

I'm trying to model the following AST:
An expression is either an operation or a value. An operation is reducible to a value via `eval` 
method. Concrete operations have expressions as parameters. It should be possible to restrict those 
parameters to expressions that evaluate to some concrete types of values.

The problem: a method that processes a map[String, Value] doesn't compile (Scala 2.9.2):

scala> :paste
// Entering paste mode (ctrl-D to finish)

   sealed abstract class Expr[T <: Value[_]] {def eval: T}
   sealed abstract class Op[T <: Value[_]] extends Expr[T]
   sealed abstract class Value[T <: Value[_]] extends Expr[T] {def eval = this.asInstanceOf[T]}

   def rename(s: String): String = "xxx"
   def process(m: Map[String, Value[_]]): Map[String, Value[_]] = m map {t => (rename(t._1), t._2)}

// Exiting paste mode, now interpreting.

<console>:12: error: type mismatch;
  found   : scala.collection.immutable.Iterable[(java.lang.String, Value[_$4]) forSome { type _$4 }]
  required: Map[String,Value[_]]
          def process(m: Map[String, Value[_]]): Map[String, Value[_]] = m map {t => (rename(t._1), 
t._2)}
                                                                           ^


Can you help me to solve this riddle? Perhaps, a better definition for Expr-Op-Value hierarchy?


Thank you,
Eugen