scalalint

specializing Numeric

Hi,

is there a particular reason why the Numeric, Integral, Fractional etc. traits are not specialized (yet)?
Is it risky to do so?

I've done a very simple (and very ugly) benchmark that seems to show that the performance benefits could be
quite incredible. I've pasted the benchmark to https://gist.github.com/762943

It was compiled without any compiler options and, when run on the standard Mac OS X 64bit server VM, produced
the following output:

direct implementation took 60 ms and resulted in 4999999950000000
generic implementation took 1492 ms and resulted in 4999999950000000
generic + specialized implementation took 58 ms and resulted in 4999999950000000

To me, it looks like a quick-win but I guess I am not seeing something in the whole picture here. 

Thanks in advance for clarifying comments
Andreas

P.S.
Scala version used for this is 2.8.1

Is it reasonable that the compiler ignores import statements based on the method's purpose?

As suggested by Kevin Wright, I'll ask what the list thinks about this.

Consider this code:

> object O {
>   object Z {
>     def foo(a: Int) = a+1
>   }
>   class Z(a: Int, b: Int) {
>     import Z._
>     def this(a: Int) = this(a, foo(a))
>     def bar = foo(42)
>   }
> }

The code doesn't compile:
> error: not found: value foo
>   def this(a: Int) = this(a, foo(a))
>                              ^

I wonder if it is useful that the import statement depends on certain  
method purposes (like secondary constructors) to decide if it actually  
imports Z.

While I can understand that there are restrictions on fields and  
methods a constructor is allowed to use, the import statement is not  
such a case, it doesn't even exist at runtime at all.

What do you think?
Also, did you perceive the recommended fix as obvious or trivial?

Thanks and bye!

Simon

Re: Is it reasonable that the compiler ignores import statements based on the method's purpose?

On Mon, Jan 03, 2011 at 05:33:35PM +0100, Simon Ochsenreither wrote:
> I wonder if it is useful that the import statement depends on certain 
> method purposes (like secondary constructors) to decide if it actually 
> imports Z.

That is not really what's happening.  The axuiliary constructor is 
lifted out of the class and never sees the import.

http://lampsvn.epfl.ch/trac/scala/ticket/1207
"Import and constructor inconsistency"

--

-- 
Paul Phillips      | Christ died for our sins.  Dare we make his martyrdom
Imperfectionist    | meaningless by not committing them?
Empiricist         |     -- Jules Feiffer
ha! spill, pupil   |----------* http://www.improving.org/paulp/ *----------

Re: Is it reasonable that the compiler ignores import statements based on the method's purpose?

Hi Paul!

> That is not really what's happening.  The axuiliary constructor is
> lifted out of the class and never sees the import.

While this is a perfectly fine explanantion for every compiler
implementer out there, is this something a language user should really
care about?

I don't know how much work it would be to take the import into account
when lifting the constructor, but in my humble opinion maybe we should
look at what is easier to understand for developers and not what's
easier to implement in the compiler.

Thanks and bye,

Simon

Re: Is it reasonable that the compiler ignores import statements based on the method's purpose?

On Mon, Jan 03, 2011 at 11:46:26PM +0100, Simon Ochsenreither wrote:
> While this is a perfectly fine explanantion for every compiler 
> implementer out there, is this something a language user should really 
> care about?

No, that's why there is a ticket open, at which I pointed.

> I don't know how much work it would be to take the import into account 
> when lifting the constructor, but in my humble opinion maybe we should 
> look at what is easier to understand for developers and not what's 
> easier to implement in the compiler.

I'm glad we're in agreement about what we should do.  Now all we have to 
do is figure out why "we" is such an elusive character.  I already write 
code as fast as I can; I'm sure you'll forgive me if I prioritize the 
600 or so open tickets according to my own metrics.

--

-- 
Paul Phillips      | A national political campaign is better than the
Caged Spirit       | best circus ever heard of, with a mass baptism and
Empiricist         | a couple of hangings thrown in. 
i'll ship a pulp   |     -- H. L. Mencken

RabbitMQ, monadically

Re: RabbitMQ, monadically

Re: RabbitMQ, monadically

Dear Viktor,

Trust me -- you wouldn't want my brain... i'm way stupider and slower than the average programmer... which is why i have to work with simple abstractions.

Best wishes,

--greg

On Tue, Jan 4, 2011 at 6:53 AM, √iktor Klang <viktor.klang <at> gmail.com> wrote:

Dear Greg,

Do you want to swap brains?

On Tue, Jan 4, 2011 at 3:41 PM, Meredith Gregory <lgreg.meredith <at> gmail.com> wrote:

Dear Scalarazzi,

i've been playing around with a little demonstration of monadic interfaces to streams using delimited continuations and now have a little demonstration of how to do this over RabbitMQ. 

• Blog post (still rough around the edges)
• Github source

Because i've been comparing it to the actor-based interface to RabbitMQ in lift, i've put the code in that package in a simple lift app. This is completely independent of that interface, however. Basically, the monadic interface looks like this

for( msg <- rabbitMonadically.beginService() ) {

// msg handling code goes here

...

}

All the state management and threading is safely tucked behind an interface that matches a very reasonable intuition about message-processing applications: iterate message handling code over a stream of messages. Now, among the cool ideas that this can scale up to is something like this

for( val1 <- key1; ...; valK <- keyK if filter1( key1, ..., keyK ) op ... op filterM( key1, ..., keyK ) ) {

// content processing code goes here
...

}

Where keys in some cloud-based key-value DB are Prolog terms, and it's natural to consider filter processing roughly mimicking Prolog predicate processing with backtracking. Thus, we only do content processing when we have received values from several locations that meet some sophisticated set of constraints. That's where the NoSQL/Datalog experiment i've been working on is heading. This is like join patterns on whatever comes after steroids.

Also, if you'd like to see more of this sort of thing -- but published nicely in a book format -- there's only 11 days left in the Kickstarter project for monadic design patterns for the web.

Best wishes,

--greg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SW

Seattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SW

Seattle, WA 98136

+1 206.650.3740

http://biosimilarity.blogspot.com

Stuff to think about: the new .Net approach regarding async processes

Hi

I just would like to inform you of the new approach which is about to
be used in .Net for async processes, mostly for ui work.

Indeed, it aims for ease of use, which looks like they've achieved in
a level I haven't seen yet. Notably they've :
- a new keyword, async, which is required to be cascaded up in the
code up to a void function, in order be aware of the nature of the
call,
- proper exception propagation,
- facilities for progress reporting (push or pull) and cancellation

For sure, this requires compiler support, but this doesn't sound like
a showstopper ;)

Being a scala newbe (rather wannabe actually, since I just read about
it up to now), I welcome your view on this new way to tackle async
calls. More specifically, I don't remind such a support in Scala,
which would be a plus IMHO (but I would be pleased to be informed why
not).

More info on the proposal there http://bit.ly/gTBsZE  (I esp recommand
the pdf http://bit.ly/eFAfoN)

best
nono