Re: Re: Re: Re: Re:

classpath setByUser in Scala 2.10

Hi all,

finally I ported ScalaLab to Scala 2.10.

The reason behind the "object Scala not found"
message that I took before,
is the new
  "setByUser" flag
that defaults to false and requires to set it to set to true,
in order to enable configuration of the classpath of the compiler in
2.10.

It seems to me somewhat tricky to find it !!

Best Regards

Stergios

[scala-language] Units of Measurement — Scala Macros to the rescue?

Re: [scala-language] Units of Measurement — Scala Macros to the rescue?

On Fri, Feb 3, 2012 at 15:50, Simon Ochsenreither
<simon.ochsenreither <at> googlemail.com> wrote:
> Hi everyone,
>
> as some people know, I have been working on the Units of Measurement
> functionality of metascala, where a unit is represented by a numerical value
> for quantity and 7 generic types representing the SI units.
>
> The last two major things missing in my book are implementations of
> toString, equals and probably hashCode. They are currently not really
> implementable, because they depend on the generic types which are not
> available at runtime.
>
> Would macros enable me to implement these operations by looking at them at
> compile time? E.g. implementing equals by checking that the two compared
> instances have the same generic types with a macro and refusing to compile
> if they don't?

That's not the semantics of ==. The == method never fails to compile
-- for better or worse. Please, don't change its semantics for *one*
thing, while it keeps the old semantics for everything else.

As for hashcode, it's my understanding that Scala uses ## precisely to
handle numbers better, so you'd probably be handling that, though I
don't see what you might want with it.

--

-- 
Daniel C. Sobral

I travel to the future all the time.

Re: [scala-language] Units of Measurement — Scala Macros to the rescue?

On Fri, Feb 03, 2012 at 09:50:52AM -0800, Simon Ochsenreither said
> Hi everyone,
> 
> as some people know, I have been working on the Units of Measurement 
> functionality of metascala, where a unit is represented by a numerical 
> value for quantity and 7 generic types representing the SI units.
> 
> The last two major things missing in my book are implementations of 
> toString, equals and probably hashCode. They are currently not really 
> implementable, because they depend on the generic types which are not 
> available at runtime.

I think it should be possible to get enough information at runtime by
reification through an implicit parameter for Quantity. I think that
it'd better to and add a typesafe equality operator for Quantity instead
of trying to make use of equals a compiler error.

A sketch:

type UV[T] = TypeToValue[T, Int]

class UnitRep
  [M <: MInt : UV, KG <: MInt : UV, S <: MInt : UV, A <: MInt : UV, K <:
   MInt : UV, Mol <: MInt : UV, CD <: MInt : UV] {
  def v[T : UV] = to[T, Int]
  def rep = {
    val u = List(("m",v[M]),("kg",v[KG]),("s",v[S]),("A",v[A]),
                 ("K",v[K]),("mol",v[Mol]),("cd",v[CD]))
    u.map {
      case (u,0) => ""
      case (u,1) => "*"+u
      case (u,-1) => "/"+u
      case (u,x) if x > 1 => "*%s^%d".format(u,x)
      case (u,x) if x < 1 => "/%s^%d".format(u,-x)
    } mkString "" drop 1
  }
}

Re: [scala-language] Units of Measurement — Scala Macros to the rescue?

The problem with this approach would be that, unless some caching scheme 
is implemented, a new instance of UnitRep would be created for each 
Quantity instance. This would be a huge memory overhead.

/Jesper Nordenberg

Geoff Reedy skrev 2012-02-03 23:08:
> On Fri, Feb 03, 2012 at 09:50:52AM -0800, Simon Ochsenreither said
>> Hi everyone,
>>
>> as some people know, I have been working on the Units of Measurement
>> functionality of metascala, where a unit is represented by a numerical
>> value for quantity and 7 generic types representing the SI units.
>>
>> The last two major things missing in my book are implementations of
>> toString, equals and probably hashCode. They are currently not really
>> implementable, because they depend on the generic types which are not
>> available at runtime.
>
> I think it should be possible to get enough information at runtime by
> reification through an implicit parameter for Quantity. I think that
> it'd better to and add a typesafe equality operator for Quantity instead
> of trying to make use of equals a compiler error.
>
> A sketch:
>
> type UV[T] = TypeToValue[T, Int]
>
> class UnitRep
>    [M<: MInt : UV, KG<: MInt : UV, S<: MInt : UV, A<: MInt : UV, K<:
>     MInt : UV, Mol<: MInt : UV, CD<: MInt : UV] {
>    def v[T : UV] = to[T, Int]
>    def rep = {
>      val u = List(("m",v[M]),("kg",v[KG]),("s",v[S]),("A",v[A]),
>                   ("K",v[K]),("mol",v[Mol]),("cd",v[CD]))
>      u.map {
>        case (u,0) =>  ""
>        case (u,1) =>  "*"+u
>        case (u,-1) =>  "/"+u
>        case (u,x) if x>  1 =>  "*%s^%d".format(u,x)
>        case (u,x) if x<  1 =>  "/%s^%d".format(u,-x)
>      } mkString "" drop 1
>    }
> }
>

Re: [scala-language] Units of Measurement — Scala Macros to the rescue?

Good point. I bet you could do something clever with Miles' unboxed tagged types so that Quantity takes
implicit Int  <at>  M, Int  <at>  KG, etc. and then there's only the overhead of 7 int fields and maybe no object
creation during the implicit resolution.

On Feb 4, 2012, at 1:12 AM, Jesper Nordenberg <megagurka <at> yahoo.com> wrote:

> The problem with this approach would be that, unless some caching scheme is implemented, a new instance of
UnitRep would be created for each Quantity instance. This would be a huge memory overhead.
> 
> /Jesper Nordenberg
> 
> Geoff Reedy skrev 2012-02-03 23:08:
>> On Fri, Feb 03, 2012 at 09:50:52AM -0800, Simon Ochsenreither said
>>> Hi everyone,
>>> 
>>> as some people know, I have been working on the Units of Measurement
>>> functionality of metascala, where a unit is represented by a numerical
>>> value for quantity and 7 generic types representing the SI units.
>>> 
>>> The last two major things missing in my book are implementations of
>>> toString, equals and probably hashCode. They are currently not really
>>> implementable, because they depend on the generic types which are not
>>> available at runtime.
>> 
>> I think it should be possible to get enough information at runtime by
>> reification through an implicit parameter for Quantity. I think that
>> it'd better to and add a typesafe equality operator for Quantity instead
>> of trying to make use of equals a compiler error.
>> 
>> A sketch:
>> 
>> type UV[T] = TypeToValue[T, Int]
>> 
>> class UnitRep
>>   [M<: MInt : UV, KG<: MInt : UV, S<: MInt : UV, A<: MInt : UV, K<:
>>    MInt : UV, Mol<: MInt : UV, CD<: MInt : UV] {
>>   def v[T : UV] = to[T, Int]
>>   def rep = {
>>     val u = List(("m",v[M]),("kg",v[KG]),("s",v[S]),("A",v[A]),
>>                  ("K",v[K]),("mol",v[Mol]),("cd",v[CD]))
>>     u.map {
>>       case (u,0) =>  ""
>>       case (u,1) =>  "*"+u
>>       case (u,-1) =>  "/"+u
>>       case (u,x) if x>  1 =>  "*%s^%d".format(u,x)
>>       case (u,x) if x<  1 =>  "/%s^%d".format(u,-x)
>>     } mkString "" drop 1
>>   }
>> }
>> 
> 
> 

Re: [scala-language] Units of Measurement — Scala Macros to the rescue?

Re: [scala-language] Units of Measurement — Scala Macros to the rescue?

On Sat, Feb 4, 2012 at 09:16, Simon Ochsenreither
<simon.ochsenreither <at> googlemail.com> wrote:
> Sorry, I completely disagree. Imho it is dozen times worse to have two
> methods where of them is just not working, because it can only compare the
> value, but not the types. An alternative would be to implement equals by
> always throwing an exception. But then I would just prefer making a known
> wrong equals comparison a compile time error instead.

That's why libraries such as Scalaz have a different equality
comparison. If you do this, then you are basically breaking both your
equals methods and Scala's equals method, so that we end with NO
equals method. Except, of course, for Scala.

I'm all for fixing equality, but either it is done for everything, or
it is done for nothing. I can compromise on it remaining broken, but
not on having two different versions with the same name.

--

-- 
Daniel C. Sobral

I travel to the future all the time.

Re: [scala-language] Units of Measurement — Scala Macros to the rescue?

On Sat, Feb 4, 2012 at 10:59 AM, Geoff Reedy <geoff <at> programmer-monk.net> wrote:
> Good point. I bet you could do something clever with Miles' unboxed tagged types so that Quantity takes
implicit Int  <at>  M, Int  <at>  KG, etc. and then there's only the overhead of 7 int fields and maybe no object
creation during the implicit resolution.

I'm afraid that's not going to work very well here, because Int  <at>  <at>  M
<: Int, so the compiler wouldn't prevent you from adding dimensioned
and dimensionless quantities, which is pretty much defeating the
object of the exercise.

There's another trick I discovered recently, which is a little closer
to newtype than tagging,

  https://gist.github.com/5a76bb0c7a51bea3fabe

but unfortunately the types involved here (eg., Any  <at>  <at> 
QuantityTag[Double, M, ...]) will always be boxed.

But I'm not sure this is all that big a deal anyway ... Simon's
quantities are already boxed, so we've paid that price already.

Cheers,

Miles

--

-- 
Miles Sabin
tel: +44 7813 944 528
gtalk: miles <at> milessabin.com
skype: milessabin
g+: http://www.milessabin.com
http://twitter.com/milessabin
http://www.chuusai.com/