Re: Detect if AnyVal or AnyRef

On Mon, Jan 12, 2009 at 2:04 PM, Seth Tisue <seth@tisue.net> wrote:

>>>>> "Naftoli" == Naftoli Gugenheim <naftoligug@gmail.com> writes:

 Naftoli> Not bad. Is there no better way, tough?

Can you tell us about the context in which you are wanting to do this?
Perhaps we can help you avoid it altogether.

I think that I already have (this came up a while ago and I just didn't get around to asking it before), but that isn't the answer to my question. :) Maybe the answer is that there is no (known) need to do so and therefore you can't, except by using a hack with implicits. :)
Although it probably had to do with my project that I mentioned in the thread about pattern matching on class literals, or more specifically, after parsing expressions, determining in advance the type of the expression, for use e.g. in selecting an overloaded method.

--
Seth Tisue / http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

Is it feasible for your parse tree to encode type parameters.  So your tree doesn't look like

sealed trait Exp
case class IntExp extends Exp
//etc

It looks like

sealed trait Exp[T]
case class IntExp extends Exp[Int]
case class JIntExp extends Exp[java.lang.Integer]
// etc

On Mon, Jan 12, 2009 at 11:29 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

On Mon, Jan 12, 2009 at 2:04 PM, Seth Tisue <seth@tisue.net> wrote:

>>>>> "Naftoli" == Naftoli Gugenheim <naftoligug@gmail.com> writes:

 Naftoli> Not bad. Is there no better way, tough?

Can you tell us about the context in which you are wanting to do this?
Perhaps we can help you avoid it altogether.

I think that I already have (this came up a while ago and I just didn't get around to asking it before), but that isn't the answer to my question. :) Maybe the answer is that there is no (known) need to do so and therefore you can't, except by using a hack with implicits. :)
Although it probably had to do with my project that I mentioned in the thread about pattern matching on class literals, or more specifically, after parsing expressions, determining in advance the type of the expression, for use e.g. in selecting an overloaded method.

--
Seth Tisue / http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

Not really. Well, Literal has a type parameter, but at parse time it doesn't get into the type of functions, properties, or variables. It just parses the expression into a tree, and then at run time it has to figure out how to evaluate it, and in the case of bindings, listen on property dependencies.
Anyway, I'm not so sure that this was where it came up.
In any case, anyone that's interested in the project can join the mailing list at http://appbuilder.dev.java.net.

On Mon, Jan 12, 2009 at 4:12 PM, James Iry <jamesiry@gmail.com> wrote:

Is it feasible for your parse tree to encode type parameters.  So your tree doesn't look like

sealed trait Exp
case class IntExp extends Exp
//etc

It looks like

sealed trait Exp[T]
case class IntExp extends Exp[Int]
case class JIntExp extends Exp[java.lang.Integer]
// etc

On Mon, Jan 12, 2009 at 11:29 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

On Mon, Jan 12, 2009 at 2:04 PM, Seth Tisue <seth@tisue.net> wrote:

>>>>> "Naftoli" == Naftoli Gugenheim <naftoligug@gmail.com> writes:

 Naftoli> Not bad. Is there no better way, tough?

Can you tell us about the context in which you are wanting to do this?
Perhaps we can help you avoid it altogether.

I think that I already have (this came up a while ago and I just didn't get around to asking it before), but that isn't the answer to my question. :) Maybe the answer is that there is no (known) need to do so and therefore you can't, except by using a hack with implicits. :)
Although it probably had to do with my project that I mentioned in the thread about pattern matching on class literals, or more specifically, after parsing expressions, determining in advance the type of the expression, for use e.g. in selecting an overloaded method.

--
Seth Tisue / http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/

I had figured that the reason 1.isInstanceOf[AnyRef] is because isInstanceOf is supposed to return whether or not asInstanceOf will work, and 1.asInstanceOf[AnyRef] is a java.lang.Integer. However, isInstanceOf is not always the same as try { ...asInstanceOf...; true } catch case {_:ClassCastException=>false}. My code had tested whether either one of the nonprimitive version of the types of the operands of an infix operation is classOf[java.lang.Float] or classOf[java.lang.Double], in order to disallow whole-number only operations (bitwise operations). If so, it evaluates the operands by calling evalExpr which returns an Any. Then it casted them to Long. The problem was that that although the above isInstanceOf behaviors are meant to blur the distinction between AnyVals and their boxed equivalents, they don't act the same. For example, 1.asInstanceOf[Long] is fine, but new Integer(1).asInstanceOf[Long] throws an exception (although asInstanceOf[Int] is fine, but chaining casts doesn't work because it's still really boxed internally). On the other hand, I can't automatically call toLong (in the case of whole numbers, or toDouble for reals) because there's no common base class or trait for the "primitive" number types in scala or the rich number types in scala.runtime. As a result, my code looks approximately like this:   def anyToDouble(n: Any) = n match {   case l: Byte => l.toDouble   case l: Short => l.toDouble       ...   case _ => error(...) } def anyToLong...   ... // in evalInfixOperation else if((numberTypes contains leftType) && (numberTypes contains rightType) {   if((realTypes contains leftType) || (realTypes contains rightType) {     val left = anyToDouble(evalLeft)     val right = anyToDouble(evalRight)     operator match {        case "+" => left + right        case "-" => left - right        ...     }   } else { // both whole numbers by elimination     val left = anyToLong(evalLeft)     val right = anyToLong(evalRight)     operator match {        case "+" => left + right        case "-" => left - right        ...        case "&" => left & right        ...     }  } }   Except that in actuality I have to write a lot more than "..." in anyToDouble and anyToLong. Is there no better way? I just thought -- can I cast to java.lang.Number and call n.doubleValue or n.longValue? I don't have Scala on this computer to check right now, but I clicked on the link to the source in the online API docs and I got an HTTP 403 message -- The website declined to show this webpage
 HTTP 403 
   Most likely causes:
This website requires you to log in. 

On Tue, Jan 13, 2009 at 11:57 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Not really. Well, Literal has a type parameter, but at parse time it doesn't get into the type of functions, properties, or variables. It just parses the expression into a tree, and then at run time it has to figure out how to evaluate it, and in the case of bindings, listen on property dependencies.
Anyway, I'm not so sure that this was where it came up.
In any case, anyone that's interested in the project can join the mailing list at http://appbuilder.dev.java.net.

On Mon, Jan 12, 2009 at 4:12 PM, James Iry <jamesiry@gmail.com> wrote:

Is it feasible for your parse tree to encode type parameters.  So your tree doesn't look like

sealed trait Exp
case class IntExp extends Exp
//etc

It looks like

sealed trait Exp[T]
case class IntExp extends Exp[Int]
case class JIntExp extends Exp[java.lang.Integer]
// etc

On Mon, Jan 12, 2009 at 11:29 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

On Mon, Jan 12, 2009 at 2:04 PM, Seth Tisue <seth@tisue.net> wrote:

>>>>> "Naftoli" == Naftoli Gugenheim <naftoligug@gmail.com> writes:

 Naftoli> Not bad. Is there no better way, tough?

Can you tell us about the context in which you are wanting to do this?
Perhaps we can help you avoid it altogether.

I think that I already have (this came up a while ago and I just didn't get around to asking it before), but that isn't the answer to my question. :) Maybe the answer is that there is no (known) need to do so and therefore you can't, except by using a hack with implicits. :)
Although it probably had to do with my project that I mentioned in the thread about pattern matching on class literals, or more specifically, after parsing expressions, determining in advance the type of the expression, for use e.g. in selecting an overloaded method.

--
Seth Tisue / http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/