Donna Malayeri | 2 Jan 18:18 2010
Picon

Re: Structured types - restrictions?

I'm not sure how you could define the structural type so that it didn't refer to the type parameter. I think you're better off passing in the comparison function:

> def listMax[U, T <: List[U]] (l: T, max: (U, U) => U) = l.reduceLeft(max)

> listMax(List(1, 2, 3, 4), (_:Int) max (_:Int))
res16: Int = 4

Btw, the reason that Int doesn't conform to the type { def max[T](T) : T } is that the max function in Int is not parameterized.

Donna

On Mon, Dec 21, 2009 at 7:24 PM, Yoel Jacobsen <yoel.jacobsen <at> gmail.com> wrote:
Hello list,

I'm trying to understand what can and cannot be done with structured
types but can't find a complete documentation (sadly Programmingin
Scala does not contains a discussion of the subject).

To understand it I'm toying with a function that should find a
sequence's maximum.

Conceptually, to make the function really generic it should accept a
data structure of the form S[E] (Such as List[Int]) such that S
implements reduceLeft() and E implements max().

As I can't think of a way to describe S[E] in Scala I'll reduce the
problem to List[T] where T implements max().

My first failure at defining listMax using structural types is:

scala> def listMax[T](l:List[{def max(that:T):T}]) = l.reduceLeft(_ max _)
<console>:4: error: Parameter type in structural refinement may not refer to
abstract type defined outside that same refinement
      def listMax[T](l:List[{def max(that:T):T}]) = l.reduceLeft(_ max _)
                                          ^
<console>:4: error: type mismatch;
 found   : AnyRef{def max(T): T}
 required: T
      def listMax[T](l:List[{def max(that:T):T}]) = l.reduceLeft(_ max _)
                                                                       ^
If due to the first error I'm trying to specializing the max function
the compiler does not contains, but does not match l with List[Int]:

scala> def listMax(l:List[{def max[T](that:T):T}]) = l.reduceLeft(_ max _)
listMax: (List[AnyRef{def max[T](T): T}])AnyRef{def max[T](T): T}

scala> listMax(List(1,2,3,2,1))
<console>:6: error: type mismatch;
 found   : Int(1)
 required: AnyRef{def max[T](T): T}
      listMax(List(1,2,3,2,1))
                   ^

Therefore, I have two questions:

1. Is there a way to define in Scala the listMax function as
l.reduceLeft(_ max _) ?

2. Is there a way to define a seqMax function on all sequences (with
reduceLeft) on elements (with max) ?

Thanks,
 Yoel

Jason Zaugg | 3 Jan 23:06 2010
Picon

Implicit Search Oddities (including 2.7.6 -> 2.8 regressions)

The finer points of implicit search confuse me. I know that implicits
can be masked by name, either by defining a local identifier with the
same name as an imported implicit, or by using import such as A.{x =>
_}.

I've assembled a smorgasbord of examples which puzzle me. There are
two cases where 2.7.6 reports ambiguity, and 2.8.0 does not.

http://gist.github.com/

I'm missing a clear understanding of how names are bound within a
given lexical scope. Does the identifier 'a' have a single binidng in
the block below, or does it change after declaring `val a`?

locally {
   import A.x
   ...
   val x = ...
}

There are quite a few tickets matching 'implicit ambiguous', both open
and closed. I haven't found one explaining the regression. Let me know
if one exists, or if there are spec changes that explain this
behaviour. Otherwise I'll raise a ticket.

-jason

Viktor Klang | 3 Jan 23:10 2010
Picon

Re: Implicit Search Oddities (including 2.7.6 -> 2.8 regressions)

Jason, I think you might want to refine that link.

On Sun, Jan 3, 2010 at 11:06 PM, Jason Zaugg <jzaugg <at> gmail.com> wrote:
The finer points of implicit search confuse me. I know that implicits
can be masked by name, either by defining a local identifier with the
same name as an imported implicit, or by using import such as A.{x =>
_}.

I've assembled a smorgasbord of examples which puzzle me. There are
two cases where 2.7.6 reports ambiguity, and 2.8.0 does not.

http://gist.github.com/

I'm missing a clear understanding of how names are bound within a
given lexical scope. Does the identifier 'a' have a single binidng in
the block below, or does it change after declaring `val a`?

locally {
  import A.x
  ...
  val x = ...
}

There are quite a few tickets matching 'implicit ambiguous', both open
and closed. I haven't found one explaining the regression. Let me know
if one exists, or if there are spec changes that explain this
behaviour. Otherwise I'll raise a ticket.

-jason



--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang
Jason Zaugg | 3 Jan 23:16 2010
Picon

Re: Implicit Search Oddities (including 2.7.6 -> 2.8 regressions)

Oops, here is the correct link: http://gist.github.com/268141

-jason

On Sun, Jan 3, 2010 at 11:06 PM, Jason Zaugg <jzaugg <at> gmail.com> wrote:
> I've assembled a smorgasbord of examples which puzzle me. There are
> two cases where 2.7.6 reports ambiguity, and 2.8.0 does not.
>
> http://gist.github.com/

Ross Judson | 4 Jan 05:30 2010
Picon

Re: Re: scala.ref

Another possibility is making the scala.ref.SoftReference be a
subclass of java's, at least on the Java runtime:

class SoftReference extends java.lang.ref.SoftReference with Reference

...or something to that effect. Gain the Function0 in the Reference
trait; don't bother with the wrapping. Subclassing is then once again
an appropriate way of providing resource clues. Subclasses would also
avoid the need for the Option object as well, which is useful because
references are often pretty numerous, and it's a good idea for them to
be as light as possible.

It seems that the wrapper approach was deliberately chosen over
subclassing. Beyond cross-platform reasons, I wonder why?

RJ

Graham Lea | 4 Jan 11:39 2010

What is the motivation for Scala assignment evaluating to Unit rather than the value assigned?

Whole question is at the link below, for the rest of the world's benefit.  ; )

http://stackoverflow.com/questions/1998724/what-is-the-motivation-for-scala-assignment-evaluating-to-unit-rather-than-the-va

Cheers,

Graham.
Grand, Mark D. | 4 Jan 13:18 2010

RE: Re: scala.ref

I think that keeping as much of the Scala library independent of the underlying platform as possible is an
important goal.  I think it is a sufficient reason for choosing a wrapper over a subclassed approach.

-----Original Message-----
From: Ross Judson [mailto:rossjudson <at> gmail.com]
Sent: Sunday, January 03, 2010 11:30 PM
To: Grand, Mark D.
Cc: Jesper Nordenberg; scala <at> listes.epfl.ch
Subject: Re: [scala] Re: scala.ref

Another possibility is making the scala.ref.SoftReference be a
subclass of java's, at least on the Java runtime:

class SoftReference extends java.lang.ref.SoftReference with Reference

...or something to that effect. Gain the Function0 in the Reference
trait; don't bother with the wrapping. Subclassing is then once again
an appropriate way of providing resource clues. Subclasses would also
avoid the need for the Option object as well, which is useful because
references are often pretty numerous, and it's a good idea for them to
be as light as possible.

It seems that the wrapper approach was deliberately chosen over
subclassing. Beyond cross-platform reasons, I wonder why?

RJ

This e-mail message (including any attachments) is for the sole use of
the intended recipient(s) and may contain confidential and privileged
information.  If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution
or copying of this message (including any attachments) is strictly
prohibited.

If you have received this message in error, please contact
the sender by reply e-mail message and destroy all copies of the
original message (including attachments).

Philipp Haller | 4 Jan 14:37 2010
Picon
Picon

Re: Re: scala.ref

Ross Judson wrote:
> Another possibility is making the scala.ref.SoftReference be a
> subclass of java's, at least on the Java runtime:
> 
> class SoftReference extends java.lang.ref.SoftReference with Reference

I tried to do that when attempting to fix #2852 and #2854. However, 
that's impossible, since `scala.ref.Reference[T]` defines a method `get: 
Option[T]` which conflicts with method `get(): T` of 
`java.lang.ref.Reference[T]`. This conflict is kind of unfortunate, but 
it's in the public API.

Btw, besides making `Reference[+T]` a `Function0[T]`, we also gain the 
covariance of `T`. Otherwise, it would be hard to justify a Scala 
wrapper apart from platform independence, I think.

The solution I came up with (r20341) is based on an idea by ikasiuk 
mentioned in a comment on Trac (see #2854). Basically, we introduce a 
private subclass of `java.lang.ref.SoftReference` that holds a pointer 
to the `scala.ref.SoftReference`. This allows retrieving the 
`scala.ref.SoftReference` whenever an instance of that subclass is 
enqueued in a reference queue. Thus, the methods in 
`scala.ref.ReferenceQueue` can return those instances of 
`scala.ref.Reference`.

As a result, resource clues can again be provided by subclassing the 
public `scala.ref.Reference`s. At the same time we keep the original 
wrapping scheme, which avoids the `get` conflict and enables platform 
independence.

Cheers,
Philipp

Ross Judson | 4 Jan 15:47 2010
Picon

Re: Re: scala.ref

So this boils down to maintaining the current public API of
get:Option, at the expense of doubling the heap storage for
references. Ouch ;) The primary use case for Soft and Weak references
is large scale storage in memory; I've seen "large" mean both many and
sizable. The wrapper solution has little impact if the objects being
referred to are sizable, but if there are many small objects, it
starts to occupy a lot of excess memory (particularly on 64 bit VMs).
That defeats the purpose (to some degree) of the memory management
offered by refs.

I think there's some case for altering the public API here, but
probably not in the current release timeframe.

David Pollak | 4 Jan 17:19 2010
Picon

Re: What is the motivation for Scala assignment evaluating to Unit rather than the value assigned?

I advocated for having assignments return the value assigned rather than unit.  Martin and I went back and forth on it, but his argument was that putting a value on the stack just to pop it off 95% of the time was a waste of byte-codes and have a negative impact on performance.

On Mon, Jan 4, 2010 at 2:39 AM, Graham Lea <graham <at> grahamlea.com> wrote:
Whole question is at the link below, for the rest of the world's benefit.  ; )

http://stackoverflow.com/questions/1998724/what-is-the-motivation-for-scala-assignment-evaluating-to-unit-rather-than-the-va

Cheers,

Graham.



--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

Gmane