Actual complexity in Scala that warrants simplification

2011/11/25 Rex Kerr <ichoran [at] gmail [dot] com>

2011/11/25 Piotr Kołaczkowski <pkolaczk [at] elka [dot] pw [dot] edu [dot] pl>

 

Alternatively, specialization could compile _not_ the actual classes used, but a _class bytecode generator_ which would on the first use in the code generate and load the appropriate specialized class (if done at runtime, or generate and compile the appropriate specialized class if done at compile time).  That way you could just blithely write Function3[@specialize -T1, @specialized -T2, @specialized -T3, @specialized +R] and you wouldn't have to deal with 10k different classes in general; each program would get those classes that actually were used.  This would be FAR less work than having the JVM try to do the equivalent without understanding what was going on.

This would be ideal in most situations. Unfortunately, not every deployment scenario allows you to do bytecode generation. For example, I'm not sure this would work very well on android. However, I guess there could be a post-processor stage that chews through a jar and generates a jar containing all the *actually used* cases, and then you could bundle this with your class-loader-challenged application.  Matthew

  --Rex

--
Dr Matthew PocockIntegrative Bioinformatics Group, School of Computing Science, Newcastle Universitymailto: turingatemyhamster [at] gmail [dot] com gchat: turingatemyhamster [at] gmail [dot] commsn: matthew_pocock [at] yahoo [dot] co [dot] uk irc.freenode.net: drdozerskype: matthew.pococktel: (0191) 2566550mob: +447535664143

On 26 Nov 2011, at 12:08, Matthew Pocock wrote:
> This would be ideal in most situations. Unfortunately, not every deployment scenario allows you to do bytecode generation. For example, I'm not sure this would work very well on android.

I'm certain that it would not work at all on Android :-)

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul [at] paulbutcher [dot] com
AIM: paulrabutcher
Skype: paulrabutcher

On Sat, Nov 26, 2011 at 12:59, Paul Butcher wrote:
> On 26 Nov 2011, at 12:08, Matthew Pocock wrote:
>> This would be ideal in most situations. Unfortunately, not every deployment scenario allows you to do bytecode generation. For example, I'm not sure this would work very well on android.
>
> I'm certain that it would not work at all on Android :-)

Well, ok, it wouldn't work on Android. But Scala *isn't* working on
Android right now because _static_ generation is resulting in way too
much code.

I think the idea of having a build step that generates it statically
for the closed set of usages that it can find might be the best way to
go, particularly used with SBT. Libraries could leave it open, and
then applications would "close" it and generate the required files.

Much like a link step, sadly.

In practice though, the volume of static generation and the size of the scala library itself can be largely ameliorated by using proguard.

On Sunday, 27 November 2011, Daniel Sobral wrote:

On Sat, Nov 26, 2011 at 12:59, Paul Butcher <paul [at] paulbutcher [dot] com> wrote:
> On 26 Nov 2011, at 12:08, Matthew Pocock wrote:
>> This would be ideal in most situations. Unfortunately, not every deployment scenario allows you to do bytecode generation. For example, I'm not sure this would work very well on android.
>
> I'm certain that it would not work at all on Android :-)

Well, ok, it wouldn't work on Android. But Scala *isn't* working on
Android right now because _static_ generation is resulting in way too
much code.

I think the idea of having a build step that generates it statically
for the closed set of usages that it can find might be the best way to
go, particularly used with SBT. Libraries could leave it open, and
then applications would "close" it and generate the required files.

Much like a link step, sadly.

--
Daniel C. Sobral

I travel to the future all the time.

--
Kevin Wright
mail: kevin [dot] wright [at] scalatechnology [dot] com
gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com quora: http://www.quora.com/Kevin-Wrightgoogle+: http://gplus.to/thecoda
kev [dot] lee [dot] wright [at] gmail [dot] com twitter: @thecoda
vibe / skype: kev.lee.wrightsteam: kev_lee_wright
"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

On 27 Nov 2011, at 15:27, Kevin Wright wrote:
> In practice though, the volume of static generation and the size of the scala library itself can be largely ameliorated by using proguard.

Except for the fact that, for reasons which we still haven't (as far as I'm aware?) got to the bottom of, something changed between 2.8.x and 2.9.x which means that even after being proguarded, the Scala library is often too large to fit on an Android device. See this thread for a recent discussion of this issue:

https://groups.google.com/forum/#!topic/scala-debate/El3QZEbIwHg

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: http://www.linkedin.com/in/paulbutcher
MSN: paul [at] paulbutcher [dot] com
AIM: paulrabutcher
Skype: paulrabutcher

On 2011-11-15 15:29:36 -0600, Rex Kerr said:

> If you want to solve the named argument problem, that's tricky but
> relatively doable.

I have never understood why named arguments are not treated as part of
the method name (like smalltalk, perhaps prying out the 1st parameter
better than smalltalk does) e.g.

object . move from: aPlace to: anotherPlace by: aTime via: aRoute

(smalltalk would do object.moveFrom: ... to: ... by: .... via: ...)

method name = move:from:to:by:via:
param ordering can be treated as fixed, can even allow positional
invocation for those who won't have it otherwise:

object . move (aPlace, aPlace, aTime, aRoute)

Just an observation, I know there is zero chance of anything like this
happening.

On Wed, Nov 30, 2011 at 9:10 AM, Sophie <itsme213 [at] hotmail [dot] com> wrote:

I have never understood why named arguments are not treated as part of the method name (like smalltalk, perhaps prying out the 1st parameter better than smalltalk does) e.g.

Probably because it means that parameter names now become part of the API, so a simple renaming will break existing users.
-- Cédric 

2011/11/30 Cédric Beust ♔ :
>
> On Wed, Nov 30, 2011 at 9:10 AM, Sophie wrote:
>>
>> I have never understood why named arguments are not treated as part of the
>> method name (like smalltalk, perhaps prying out the 1st parameter better
>> than smalltalk does) e.g.
>
> Probably because it means that parameter names now become part of the API,
> so a simple renaming will break existing users.

That is already true with named arguments.

There's a decent answer:  Java interoperability.
If we made the names part of the method, calling it from java and, more importantly *overriding* a java method would be difficult.
- Josh

On Wed, Nov 30, 2011 at 12:10 PM, Sophie <itsme213 [at] hotmail [dot] com> wrote:

On 2011-11-15 15:29:36 -0600, Rex Kerr <ichoran [at] gmail [dot] com> said:

If you want to solve the named argument problem, that's tricky but
relatively doable.

I have never understood why named arguments are not treated as part of the method name (like smalltalk, perhaps prying out the 1st parameter better than smalltalk does) e.g.

       object . move from: aPlace to: anotherPlace by: aTime via: aRoute

(smalltalk woucld do object.moveFrom: ... to: ... by: .... via: ...)

method name =  move:from:to:by:via:
param ordering can be treated as fixed, can even allow positional invocation for those who won't have it otherwise:

       object . move (aPlace, aPlace, aTime, aRoute)

Just an observation, I know there is zero chance of anything like this happening.

Exactly.  Argument names are part of the API.  Here's a fun one:
val x : Int => Int = _ + 1
x(v1 = 2)  // Right, v1 become part of our official API in 2.8.x
2011/11/30 Daniel Sobral <dcsobral [at] gmail [dot] com>

2011/11/30 Cédric Beust ♔ <cedric [at] beust [dot] com>:
>
> On Wed, Nov 30, 2011 at 9:10 AM, Sophie <itsme213 [at] hotmail [dot] com> wrote:
>>
>> I have never understood why named arguments are not treated as part of the
>> method name (like smalltalk, perhaps prying out the 1st parameter better
>> than smalltalk does) e.g.
>
> Probably becauset means that parameter names now become part of the API,
> so a simple renaming will break existing users.

That is already true with named arguments.

--
Daniel C. Sobral

I travel to the future all the time.

On Thu, Dec 1, 2011 at 3:47 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Exactly.  Argument names are part of the API.  Here's a fun one:
val x : Int => Int = _ + 1
x(v1 = 2)  // Right, v1 become part of our official API in 2.8.x

Actually, the official policy is that you should not rely on parameter names like `x` or `v1` being kept stable. If the parameter name is an intelligible word, users should be able to rely on them and APIs should honor that by keeping the names stable or using a deprecation path. But for identifiers that are simple letter/digit combinations that does not hold. Or so we decided when 2.8 came out. Admittedly all of this is convention, not hardcoded. But then, most naming aspects are conventions.
Cheers
 -- Martin

On Thu, Dec 1, 2011 at 9:16 AM, martin odersky <martin [dot] odersky [at] epfl [dot] ch> wrote:

On Thu, Dec 1, 2011 at 3:47 AM, Josh Suereth <joshua [dot] suereth [at] gmail [dot] com> wrote:

Exactly.  Argument names are part of the API.  Here's a fun one:
val x : Int => Int = _ + 1
x(v1 = 2)  // Right, v1 become part of our official API in 2.8.x

Actually, the official policy is that you should not rely on parameter names like `x` or `v1` being kept stable. If the parameter name is an intelligible word, users should be able to rely on them and APIs should honor that by keeping the names stable or using a deprecation path. But for identifiers that are simple letter/digit combinations that does not hold. Or so we decided when 2.8 came out. Admittedly all of this is convention, not hardcoded. But then, most naming aspects are conventions.

It's probably worth mentioning @deprecatedName, that allows parameter names to be evolved without breaking backwards compatibility.
-jason