Re: using prefix operators as identifiers

On 31/05/2011 19:35, Yuvi Masory wrote:
> Paul pointed me to this old issue:
> https://issues.scala-lang.org/browse/SI-1696

Yes, and as you point out, it is not a problem with the REPL only (I always check in a 
small .scala file, I suspect lot of issues reported in the MLs with a REPL trace are 
inherent to the REPL way of doing things).

At least, it explains why we often see functions like ~~ or !! and never the symbols alone...

--

-- 
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --

Second CFP: Continuation Workshop 2011

Dynamic trait : method v field access

Sorry to cross-post from scala-used, but I having not had an answer
there this question is probably better targeted here.

As my first foray into Dynamic Scala land, I thought that I'd try
accessing bean properties via applyDynamic.

My first very rough cut is

trait BeanProperties extends Dynamic {
  def applyDynamic(name: String)(args: Any*) = {
    if (args.length == 0)
      PropertyUtils.getProperty(this, name)
    else
      null
  }
}

so that

val bean = new JTextField("text") with BeanProperties
bean.getText should equal("text")
bean.text should equal("text")

so far so good! But when I try

bean.background should equal(bean.getBackground)

the compiler complains, trying instead to give access to the field
named background rather than synthesizing a method -

variable background in class Component cannot be accessed in
javax.swing.JTextField with BeanPropertiesTest.this.BeanProperties

I know that Dynamic is work in progress, but for my edification - is
this by design, an oversight, or something that is planned to be
fixed?

Thanks

Duncan McGregor

Re: No doubt it's much too late now, but wouldn't it be nice to have negative indices in sequences?

В письме от Thu, 19 May 2011 02:05:18 +0400, Jim Balter <Jim <at> balter.name>  
сообщал:

>> One could think of a class inheriting the Seq trait where apply is
>> overriden. Therefore an access by .at(-1) should also be overriden if a
>> particular semantics must be conserved. If the user of an API uses  
>> .at() of
>> that SeqChild class, thinking it would produce the same result as a  
>> regular
>> apply() access, he would run into problems.

> I'm not following this. Seq#apply has a contract, "returns the element
> of this sequence at index idx, where 0 indicates the first element",
> that any subclass must obey. Given that, and discounting his buggy
> arithmetic, Gregory's naive implementation should yield the right
> result for any subclass of Seq.

True - as long as it remains naive.
But then optimizations may be implemented, working directly with data  
structure bypassing apply().
Say, in a couple of years, when everyone already forgotten this  
discussion, and would be surprised by strange bugs.

---

And - already asked - why Seq ?

When u load a database table, it might be one-directional or  
bi-directional.

Same way for sequences, fixed-size array (is it Python's Vector mentioned  
above?) would be very easy and fast to implement at on top of apply.

For usual one-way List or Stack it would be not so efficient though.
So either use of .reverse() would be better or iterating all item of List  
required.
    But .reverse() is nice when u save (cache) the result, for at (-2),  
at(-3), etc.
    Should List cache it ? if yes, then when to dispose it ? What about  
mutable List ?
Isolation vs optimisation, common trait :-D
    If u implement negative indice ouside the class, in your code, you can  
.reverse() the list and hold it as long as u need. But inside the List  
class, how can the lib know what u try to do ?

I also think that non-effective method over List would be like provoking  
to use it without thinking.

---

My guess, is that those wrapping, bouncing and clipping methods might be  
nice for SOME sequences, with easy cheap access to any random item and  
easy cheap access to current length.

Yet for Seq in general they would have to choose the implementation:
  * either naive one, provoking slow ineffective coding
  * or optimised complicated ones, including changing the internal data  
structures as well not only code, and provoking sudden bugs in the future.

Maybe that would really be better made as an syntactic sugar - implicit  
conversion lib for some carefully selected subclasses of Seq, but not the  
Seq in general.
Or some trait, that only can be applied to "some carefully selected  
subclasses of Seq", if this is possible.

--

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

ScalaLab Improvements

Hi all,

I like to inform the group that ScalaLab281 includes also an 
additional interface to the Scala Interpreter,
based on the ScalaInterpreterPane of Hanns Holger Rutz.

That interface can be opened from the "Swing console" top-level menu
choice.

I found that interface convenient in things like the text coloring and
completion support.

Also, the design of implicit  conversions is improved to include
operations on Array[Double] and Array[Array[Double]] types.
The new design of implicit conversions is described in the 
ImplicitConversionsDesignNote.html document.

I intend to submit and other such small design documents that perhaps
can open fruitful discussion for improvements.

.. also the functional aspects of my numerical classes are very weak,
and I think to improve them significantly soon.

Best Regards

Stergios

Implicit Objects Not Found for Singleton Types

Hello,
is there any reason that an implicit object shouldn't be supplied as
an implicit parameter whose type is the Singleton type of the object
itself?

scala> implicit object foo
defined module foo

scala> implicitly[foo.type]
<console>:9: error: could not find implicit value for parameter e:
foo.type
       implicitly[foo.type]
                 ^

Reassigning the object to an implicit val yields success.

scala> implicit val bar = foo
bar: foo.type = foo$ <at> 3f375021

scala> implicitly[bar.type]
res1: bar.type = foo$ <at> 3f375021

Is this a bug or is there a distinction between objects and vals that
I'm missing?

Thanks.

2.9 Pres.Compiler -- how to tell when finished?

Is there some way to hook into the Presentation Compiler in 2.9 to 
receive notification when all compilation is finished (when outOfDate 
flips to false)?

Say I want a command 'compile all' that reloads all sources and pops up
a error/warning dialog when compilation is totally done.. Doable?

In 2.8 I was overloading recompile(..). Not pretty, but it worked.

Thanks,
Aemon

Re: 2.9 Pres.Compiler -- how to tell when finished?

collection with typed cells

Hi,

I'm looking for a general collection that works as follows:
1. it contains a set of typed cells
2. each cell has its unique type C[T], where C is another collection
and T is a unique type
3. when an element with type T is added to the collection, the element
would be appended to C[T].

I tried to implement this myself, but:
1. I'm wondering why type test on type parameters doesn't work in
test1 and test2.
2. Is it possible to define a ImpDTCollection[TYPE LIST] class instead
of a set of ImpDTCollectionX?

With thanks
Jiansen

test1:

class ImpDTCollection2[A,B]{
  var collectionA : List[A] = Nil
  var collectionB : List[B] = Nil

  def append(elem:Any) = elem match {
    case elem:A =>
     println("addA "+elem)
     collectionA = elem :: collectionA
    case elem:B =>
     println("addB "+elem)
     collectionB = elem :: collectionB
    case _ =>
      println("Not valid element")
      Unit
  }
}

object DTTest extends Application{
  val c = new ImpDTCollection2[String, Float]
  c.append(1)
  c.append("HI")
  println("hi")
}

output:
addA 1    //How?
addA HI
hi

test2:

class ImpDTCollection2[A,B]{
  var collectionA : List[Int] = Nil
  var collectionB : List[B] = Nil

  def append(elem:Any) = elem match {
    case elem:Int =>
     println("addA "+elem)
     collectionA = elem :: collectionA
    case elem:B =>
     println("addB "+elem)
     collectionB = elem :: collectionB
    case _ =>
      println("Not valid element")
      Unit
  }
}

object DTTest extends Application{
  val c = new ImpDTCollection2[Int, Float]
  c.append(1)
  c.append("HI")
  println("hi")
}

output:
addA 1
addB HI // How?
hi

Miles Sabin on Representing polymorphic function values in Scala using type classes (scala exchange 2011)

Miles Sabin has been confirmed to present on polymorphic function
values in Scala at this month's Scala eXchange, starting June 15.

Miles -- best known for his outstanding contribution to the Scala IDE
for Eclipse -- will be demonstrating to an enraptured audience some of
the practical applications of the new type class for the first annual
Scala eXchange at Skills Matter.

The eXchange starts on June 15, you can view the schedule and buy
tickets for the first annual Scala eXchange here:
http://skillsmatter.com/event-details/home/scala-exchange-2011/js-1982