ideas/questions on works in progress

While you're at it, would it be possible to automate some inclusions/exclusions for @conditional?In particular, I'm thinking of the target JVM version...

On 5 November 2010 14:35, Paul Phillips <paulp@improving.org> wrote:

1) @conditional:

1a) I find it tricky to land on good defaults with only one annotation.
The problem is that sometimes one would like a method included by
default, and sometimes removed by default.  This needs to be specifiable
at the annotation level if we want something reasonable to happen when
no -Xinclude or -Xexclude direectives are given.

Options include some marker, where presumably the one meaning
"KeepByDefault" is the default so only one need be marked:

 @conditional[RemoveByDefault with Development]

Or some annotation argument:

 @conditional[Development](defaultIsKeep: Boolean)

Or two annotations, which I can't even propose because the unambiguous
names I can think of are way too long.

1b) I have locally changed the zillion instances in the compiler of

 if (settings.debug.value)
   log(...)

To call dlog (different name very available.) I find the above a
terrible eyesore.  I plan on that rewrite accompanying @conditional in
whenever it's ready to go unless you say otherwise.

 @conditional[Development] def dlog(...)

Nice bonus of eliding all the calls to dlog or any other by-name taking
method is dropping one object per call site.  Just now I built the
distribution with and without @conditionals being removed.

 Before: 13524 classfiles
  After: 13134 classfiles

That's dropping calls we wouldn't want to drop in real life like all the
asserts and requires, but we could certainly drop the dlogs.

2) exception handling:

I have it all working with arbitrary expressions and it's pretty nifty.
But there's one thing we still can't do and it'd be really great if we
could do it.  There is still no way to treat catch blocks as values and
write abstractions to manipulate them, because as it stands the current
syntax is "special" and you have no way to get at what is really just a
partial function with a particular signature.

What I want is a way to compile a body of source code and implement some
policy which impacts all the catch blocks.  Obvious examples of this are
"don't catch everything" and "don't catch InterruptedException or
NonLocalReturnException or other breaky ones unless you intend to", and
there are also all kinds of opportunities for statistics gathering and
logging by wrapping the given handler in a richer one.

Idea: the specification for try blocks, instead of accepting
PF[Throwable, T] for catch, accepts some scala specific class like
scala.Catch:

 trait Catch[+T] extends PartialFunction[Throwable, T]

And there is a low priority implicit from PF[Throwable, T] to Catch[T].
Result: all current code is treated exactly as before, but one can
introduce a different implicit with a higher priority:

 implicit def wrapCatch(pf: PartialFunction[Throwable, T]): MyCatch[T]

and we're in business.

Or maybe there's a better way to get where I'm trying to go: anything
which broke the ice around those catches would be great.

3) Array matching showing covariance:

https://lampsvn.epfl.ch/trac/scala/ticket/3968

This is pretty much done as far as I know, but I could use some input as
to how the end result should behave and how one might reasonably expect
to match all Array[T] where T is any AnyRef subtype.

--
Paul Phillips      | It's better to have gloved and tossed than never to
Stickler           | have played baseball.
Empiricist         |
pull his pi pal!   |----------* http://www.improving.org/paulp/ *----------

--
Kevin Wright

mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda

On Fri, Nov 05, 2010 at 02:44:26PM +0000, Kevin Wright wrote:
> While you're at it, would it be possible to automate some
> inclusions/exclusions for @conditional? In particular, I'm thinking of
> the target JVM version...

Command line arguments can expand to arbitrary settings, so it'd be easy
enough for -target:java-1.5 to throw in some conditionals. (We still
need to improve the composability of such things though.) Whether that
way or another way, there's no need I can see for @conditional to know
anything about it.