Status of @elidable

On Tue, Mar 23, 2010 at 05:15:30PM +0100, martin odersky wrote:
> Is this in the build now? If yes I think the methods in Predef that
> use @elidable need to be documented.

This has been in the build since I checked it in, but I heard somewhere
that it's not working, so I will check it out and document it.

On Tue, Mar 23, 2010 at 5:28 PM, Paul Phillips <paulp@improving.org> wrote:

On Tue, Mar 23, 2010 at 05:15:30PM +0100, martin odersky wrote:
> Is this in the build now? If yes I think the methods in Predef that
> use @elidable need to be documented.

This has been in the build since I checked it in, but I heard somewhere
that it's not working, so I will check it out and document it.

Great, thanks! Btw I just was in a talk of Manuel Faehndrich on the work they did woth contracts on .NET. The thing that caught my attention was that
instead of a fixed number of levels they take a string: E.g.

[Conditional("DEBUG")]
void log(x: T) { ... }

The advantage is that one can be more flexible what gets included. What do you think about that?
 
-- Martin
 

On Tue, Mar 23, 2010 at 06:03:40PM +0100, martin odersky wrote:
> [Conditional("DEBUG")]
> void log(x: T) { ... }

> The advantage is that one can be more flexible what gets included.
> What do you think about that?

You gain flexibility but the simplicity cost is pretty steep if there
isn't some kind of ordering among the Strings, because no longer can you
sweep away a bunch of different kinds with one threshold argument. I
can and should expose a method like "isElidable" on Global so you can
override it and apply arbitrary logic. But I would vote for simplicity
in the command line interface (especially at this point), and generality
programmatically.

I did intend to add a second argument to elidable, so there would be
both a priority and some kind of user-definable categorization scheme;
but until we have scalac config files (another thing on my list) where
you can express lengthy things without the command line, I think even
that is premature.

I added some comments to the @elidable methods in Predef. People often
ask how exactly those methods are supposed to differ anyway, so I
included language cribbed from my collection of martin odersky quotes.
Let me know if it misrepresents anything.

I tried the compiler flag against a nightly a week ago and got a
message that the flag was not recognized. I will make another try
tonight.

Sent from iPod

Jesse

On 23 Mar 2010, at 17:15, martin odersky wrote:

> Is this in the build now? If yes I think the methods in Predef that
> use @elidable need to be documented.
>
> Cheers
>

On Tue, Mar 23, 2010 at 07:52:20PM +0100, Jesse Eichar wrote:
> I tried the compiler flag against a nightly a week ago and got a
> message that the flag was not recognized. I will make another try
> tonight.

That build change isn't going to make any difference, but using the
right compiler flag will. And to make it a little more exciting I just
changed the name of the flag today, so you have to keep on your toes.

It is now -Xelide-below. It was -Xelide-level, but I kept finding
myself having to check to see what high numbers meant vs. low. This
seems a little more self-documenting.

I am trying it right now.  I just downloaded the most recent build: 2.8.0.r21230-b20100323020203
I tried the flag in the javadocs:
jeichar: tmp$ scalac -Xelide-methods-below=1000 elidable.scala 
scalac error: Parameter '-Xelide-methods-below=1000' is not recognised by Scalac.
  scalac -help  gives more information
scalac error: bad option: '-Xelide-methods-below=1000'
  scalac -help  gives more information
jeichar: tmp$ scalac -Xelide-below=1000 elidable.scala scalac error: Parameter '-Xelide-below=1000' is not recognised by Scalac.  scalac -help  gives more information scalac error: bad option: '-Xelide-below=1000'  scalac -help  gives more information
If I do help there is no -X options that I see.  I have not used the raw scalac very often so I am probably doing something wrong.  A tip would be appreciated.
I am going to dig into the script and the docs a bit more.
Jesse

Here is the output of scala -help
jeichar: tmp$ scalac -help Usage: scalac <options> <source files>where possible standard options include:  -D<prop>                       set a Java property  -bootclasspath <path>          Override location of bootstrap class files   -classpath <path>              Specify where to find user class files  -d <directory>                 Specify where to place generated class files  -dependencyfile <file>         Specify the file in which dependencies are tracked   -deprecation                   Output source locations where deprecated APIs are used  -encoding <encoding>           Specify character encoding used by source files  -explaintypes                  Explain type errors in more detail   -extdirs <dirs>                Override location of installed extensions  -g:<g>                         Specify level of generated debugging info (none,source,line,vars,notailcalls)   -help                          Print a synopsis of standard options  -javabootclasspath <path>      Override java boot classpath.  -javaextdirs <path>            Override java extdirs classpath.   -javaignorecp                  scala will not use java's -classpath no matter what.  -make:<strategy>               Specify recompilation detection strategy (all,changed,immediate,transitive,transitivenocp)   -nowarn                        Generate no warnings  -optimise                      Generates faster bytecode by applying optimisations to the program  -print                         Print program with all Scala-specific features removed   -shutdown                      Shutdown the fsc daemon  -sourcepath <path>             Specify where to find input source files  -target:<target>               Specify for which target object files should be built (jvm-1.5,msil)   -unchecked                     Enable detailed unchecked warnings  -uniqid                        Print identifiers with unique names for debugging  -verbose                       Output messages about what the compiler is doing   -version                       Print product version and exit  @<file>                        A text file containing compiler arguments (options and source files)Options for plugin continuations:   -P:continuations:enable        Enable continuations

On Tue, Mar 23, 2010 at 08:52:51PM +0100, Jesse Eichar wrote:
> I am trying it right now. I just downloaded the most recent
> build: 2.8.0.r21230-b20100323020203
>
> I tried the flag in the javadocs:

The name of the option in the comment was incorrect (since I never look
at the docs I'm not the best at knowing when a comment is wrong.) You
also have the wrong syntax for passing arguments and the wrong argument
name, and you're trying to use the new argument name I just checked in
on last night's nightly.

There are supposed to be two lines in the standard help output which
tell you to pass -X by itself for the X arguments and same for -Y. They
seem to have gone missing. I'll see if I can find them.

OK, in the future the -help output should look like it's supposed to:

% scalac -help
Usage: scalac
where possible standard options include:
-D set a Java property
-P:: Pass an option to a plugin
-X Print a synopsis of advanced options
-Y Print a synopsis of private options

% scalac -X
Usage: scalac
Possible advanced options include:
-Xassem-extdirs List of directories containing assemblies, defaults to `lib'
-Xassem-name Name of the output assembly (only relevant with -target:msil)
-Xassem-path List of assemblies referenced by the program (only relevant with -target:msil)
-Xcheck-null Emit warning on selection of nullable reference
-Xcheckinit Add runtime checks on field accessors. Uninitialized accesses result in an exception being thrown.
-Xdisable-assertions Generate no assertions and assumptions
-Xelide-below Generate calls to @elidable-marked methods only if method priority is greater than argument.
[...]

Ok I have it working to some degree.  It is working with the assert I annotated one of my methods and that is not working at the moment.  I am sure it is a stupid user error and I will do some homework.
Since I don't have your update the following worked:
scalac -Xelide-level 1000000 elidable.scala
The assert(false) no longer causes an exception
Thanks
Jesse

On Tue, Mar 23, 2010 at 9:01 PM, Paul Phillips <paulp@improving.org> wrote:

On Tue, Mar 23, 2010 at 08:52:51PM +0100, Jesse Eichar wrote:
> I am trying it right now.  I just downloaded the most recent
> build: 2.8.0.r21230-b20100323020203
>
> I tried the flag in the javadocs:

The name of the option in the comment was incorrect (since I never look
at the docs I'm not the best at knowing when a comment is wrong.) You
also have the wrong syntax for passing arguments and the wrong argument
name, and you're trying to use the new argument name I just checked in
on last night's nightly.

There are supposed to be two lines in the standard help output which
tell you to pass -X by itself for the X arguments and same for -Y.  They
seem to have gone missing.  I'll see if I can find them.

--
Paul Phillips      | These are the climbs that apply men's soles.
Vivid              |
Empiricist         |
up hill, pi pals!  |----------* http://www.improving.org/paulp/ *----------

Hi Paul,

I think before we ship a @elidable we should try to come up with the best possible solution. Manuel's talk has convinced me that it will be a hugely important addition in the future.

A linear range will never scale. People will try to embed more and more distinctions in it, and will inevitably run into conflicts.

The C# solution of just using strings also has a nasty problem in that one has to mention each and every option on the command line; no aggregation is possible.

But we could use the power of Scala's type system. First, I think instead of @elidable the .NET version of @conditional works better. It's always better to state things in the positive. Second, we could specify the level of conditional inclusion as a type parameter.

So I'm thinking of something like

@conditional[Debug]
def log(x: T) { ... }

The idea would be that calls to `log' are included if there is a current conditonal inclusion type specified which is a supertype of Debug. In any compilation run, a number of conditional inclusion types may be specified. The default might be just the inclusion type scala.annotations.Assertion. You can include or exclude a conditional inclusion type with a command line option

-Xinclude fullname
-Xexclude fullname

The beauty of this scheme is that it gives you an extremely flexible way to define new levels. Something like

object mylevel {
  type DebugAndVerify >: Debug <: Assertion
}

If (what I expect) some future version of Scala will allow union types this means you can define every possible ordering of inclusion levels with types, in any order you desire.

The last question is how to name included and excluded types on the command line. The simplest answer would be: by their full name. We can think about whether we want to also allow abbreviations.

What do you think about this?

Cheers

 -- Martin

On Tue, Mar 23, 2010 at 09:57:36PM +0100, martin odersky wrote:
> I think before we ship a @elidable we should try to come up with the
> best possible solution. Manuel's talk has convinced me that it will be
> a hugely important addition in the future.

Your idea sounds plausible as described -- I'm all for improving the
granularity given a reasonable mechanism to control it. The only
obstacle I anticipate up front is that I've really struggled with acting
on annotation arguments, because except in the most extreme
circumstances, they have a tendency to look like raw ASTs instead of
like literals. I don't know the annotation spec so I don't know how
much is expected and how much might be bug.

As an example, I tried desperately in the course of annotating all the
migrated ++/-- methods to find a way to avoid cutting and pasting a
super similar string in dozens of different places. But I never found a
way to do it which would give me a String literal when I needed it,
other than a literal argument to the annotation.

Anyway, this may not turn out to be relevant, but since all my attempts
to do anything too clever with annotations ran into that same roadblock,
I feel like it'll turn up here too. But I will give it a whirl.

On Tue, Mar 23, 2010 at 10:35 PM, Paul Phillips <paulp@improving.org> wrote:

On Tue, Mar 23, 2010 at 09:57:36PM +0100, martin odersky wrote:
> I think before we ship a @elidable we should try to come up with the
> best possible solution. Manuel's talk has convinced me that it will be
> a hugely important addition in the future.

Your idea sounds plausible as described -- I'm all for improving the
granularity given a reasonable mechanism to control it.  The only
obstacle I anticipate up front is that I've really struggled with acting
on annotation arguments, because except in the most extreme
circumstances, they have a tendency to look like raw ASTs instead of
like literals.  I don't know the annotation spec so I don't know how
much is expected and how much might be bug.

As an example, I tried desperately in the course of annotating all the
migrated ++/-- methods to find a way to avoid cutting and pasting a
super similar string in dozens of different places.  But I never found a
way to do it which would give me a String literal when I needed it,
other than a literal argument to the annotation.

Yes, that's as expected, because term arguments really are ASTs. But type arguments are evaluated by the compiler, so that might give us the lever we need!

Cheers

 -- Martin

Paul Phillips wrote:
> OK, in the future the -help output should look like it's supposed to:
>
> % scalac -help
> Usage: scalac
> where possible standard options include:
> -D set a Java property
> -P:: Pass an option to a plugin
> -X Print a synopsis of advanced options
> -Y Print a synopsis of private options

Isn't -Y supposed to be private in the sense that users shouldn't even
know it exists? In that case, we probably shouldn't even list it in the
synopsis.

Philipp

On Wed, Mar 24, 2010 at 10:25:56AM +0100, Philipp Haller wrote:
> Isn't -Y supposed to be private in the sense that users shouldn't even
> know it exists? In that case, we probably shouldn't even list it in
> the synopsis.

You are right. I'll list it under -X.