Nabble - Scala

Re: [scala] Scala Servlets

2009-11-10T06:26:58Z

On Tuesday 10 November 2009 17:19:54 Stepan Koltsov wrote:

> On Tue, Nov 10, 2009 at 11:52, Christian Helmbold
>
> <christian.helmbold@...> wrote:
> > Dave, you and Stephan are right. My API doesn't add much value to the
> > original API but brings new trouble (as Stephan showed). This API was
> > only my first thought.
> >
> > How would the Servlet API look like if it would be rewritten from scratch
> > in Scala?
>
> Why rewrite Servlets API from scratch in Scala? Servlets API need not
> to be rewritten. Servlets do well what are they supposed to do.
>
> Probably, you want to design another web framework on top of servlets API.

...or regardless servlets at all :-)

>
> S.
>

Re: [scala] Scala Servlets

2009-11-10T06:19:54Z

On Tue, Nov 10, 2009 at 11:52, Christian Helmbold
<christian.helmbold@...> wrote:
> Dave, you and Stephan are right. My API doesn't add much value to the
> original API but brings new trouble (as Stephan showed). This API was
> only my first thought.
>
> How would the Servlet API look like if it would be rewritten from scratch in Scala?

Why rewrite Servlets API from scratch in Scala? Servlets API need not
to be rewritten. Servlets do well what are they supposed to do.

Probably, you want to design another web framework on top of servlets API.

S.

[scala] a code walkthrough of the CleanUp phase of scalac

2009-11-10T06:16:11Z

Hi,

I've been meaning for a while to get a clearer picture of the CleanUp phase
of scalac, and as a side-effect I've drafted the attached notes to (1) offer
a tutorial for future compiler-plugin authors; and (2) share information
with those interested in learning more about the internals of scalac.
Because of these different audiences, I'm cross-posting these notes to both
the scala and scala.internals mailing lists.

Comments, extensions and corrections are welcome.

Miguel
http://www.sts.tu-harburg.de/people/mi.garcia/

CleanUpCodeWalkthrough.pdf (1000K) Download Attachment

Re: [scala] A small change to compiler phases

2009-11-10T04:11:08Z

On Tue, Nov 10, 2009 at 7:48 AM, Kevin Wright
<kev.lee.wright@...> wrote:

> On Tue, Nov 10, 2009 at 6:07 AM, Stephen Haberman
> <stephen@...> wrote:
>>
>>> I'd prefer an optional phase of "please typer don't complain I WILL
>>> fix this tree for you, but may ask you to run again, oh and on that
>>> second run could you please add the following synthetics in". This
>>> would allow for the case where you need the type information from
>>> typers (as per my plugin) but would like to add synthetics.
>>
>> Speaking with absolutely zero knowledge how of scala compiler plugins
>> work, this sounds vaguely like JDK6 annotation processors.
>>
>> E.g. I can manually write some code that depends on a non-existent
>> FooClass, and so fails to compile on the first round. But then the
>> javac compiler runs the annotation processor, which creates the
>> FooClass.java source, so the compiler starts a 2nd round to compile
>> FooClass.java -> FooClass.class. Having done that, the compiler then
>> re-compiles/fixes the "FooClass not found" error from the first round,
>> and everything is now fine.
>>
>> javac would even start up a 3rd round if the FooClass.java source that
>> the first annotation processor generated happened to have annotations
>> that triggered another annotation processor to generate yet more source
>> code. It keeps going until no more source files have been generated.
>>
>> No idea whether multiple rounds makes sense for scala compiler plugins,
>> but in my experience it has worked well for annotation processors.
>>
>> - Stephen
>>
>>
>>
>
> I can imagine something like this working for a range of issues:
>
> - During typer, postpone the display of any error messages
> - Create an new phase typeSynthetics, immediately before superaccessors
> - A unit can be flagged for re-compilation by any phase before this
> (so plugins would runAfter typer, but before typeSynthetics)
> - In typeSynthetics, reprocess (namer-->typeSynthetics) any flagged unit
> - Report any outstanding typer failures
>

Thinking about this further, I'd also like to be able to REMOVE
methods via a compiler plugin.

The specific goal I have in mind is an annotation that indicates which
JVMs a particular method is valid on (i.e. a method implemented in
JDK7 could have a fallback available in a scala Rich wrapper, which is
only compiled for JDK <= 6, handy for the IO stuff). This could also
be handled very cleanly by running a second pass of the namer/typer
phases.

For now, I'm looking to see if I can write a compiler plugin to run
after parser which will perform a local run of namer/typer, do its
stuff in the AST, then throw away the localised symbol/type info and
proceed naturally onto namer and subsequent phases in global. I
suspect that minimising the amount of naming/typing performed in this
first pass (for reasons of performance) is going to be one of my
bigger challenges here, I'll have to look at what's possible in nsc by
way of building a dependency graph.

Re: AW: [scala] Scala Servlets

2009-11-10T02:17:47Z

Christian Helmbold wrote:
> How would the Servlet API look like if it would be rewritten from scratch in Scala?
>
>
case class WebApplication[IN[_], OUT[_]](f: Request[IN] => Response[OUT])

If you want lots of problems, start where most "web frameworks" do:
case class WebApplication(f: (Request, Response) => Unit)

--
Tony Morris
http://tmorris.net/

Re: [scala] Scala Servlets

2009-11-10T02:00:57Z

I like the approach that Lift has taken, where they abstracted out the
idea of a request and a response that don't have to be a
ServletRequest and Servlet response, thus opening up a whole new world
of alternate possibilities. Of course, given the title of this thread
I suspect that's not what you're looking for :)

Perhaps the crucial issue is that Scala tends to favour immutability
and functional programming far more than java, so it could be
interesting to consider an immutable RequestReponse object and then
implement doGet as:

doGet(rr:RequestResponse) : RequestResponse

This would help with testing and in implementing filters, helper
methods, etc. Although it would require a very different style of
programming to use efficiently (i.e. as any method modifying the
response would necessarily create a new RequestResponse object, you
wouldn't write direct to response, but instead to something like a
mutable ResponseBuilder, the + operator on RequestResponse could then
be implemented to take a ResponseBuilder and return a new
RequestResponse)

On Tue, Nov 10, 2009 at 8:52 AM, Christian Helmbold
<christian.helmbold@...> wrote:

> Dave, you and Stephan are right. My API doesn't add much value to the
> original API but brings new trouble (as Stephan showed). This API was
> only my first thought.
>
> How would the Servlet API look like if it would be rewritten from scratch in Scala?
>
> Christian
>
> __________________________________________________
> Do You Yahoo!?
> Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
> http://mail.yahoo.com
>

Re: [scala] Scala Servlets

2009-11-10T01:42:53Z

On Tue, Nov 10, 2009 at 9:52 AM, Christian Helmbold <christian.helmbold@...> wrote:

Dave, you and Stephan are right. My API doesn't add much value to the
original API but brings new trouble (as Stephan showed). This API was
only my first thought.

How would the Servlet API look like if it would be rewritten from scratch in Scala?

I kinda like the JAX-RS approach

Christian

__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang

AW: [scala] Scala Servlets

2009-11-10T00:52:14Z

Dave, you and Stephan are right. My API doesn't add much value to the
original API but brings new trouble (as Stephan showed). This API was
only my first thought.

How would the Servlet API look like if it would be rewritten from scratch in Scala?

Christian

__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com

Re: [scala] A small change to compiler phases

2009-11-09T23:48:19Z

On Tue, Nov 10, 2009 at 6:07 AM, Stephen Haberman
<stephen@...> wrote:

>
>> I'd prefer an optional phase of "please typer don't complain I WILL
>> fix this tree for you, but may ask you to run again, oh and on that
>> second run could you please add the following synthetics in". This
>> would allow for the case where you need the type information from
>> typers (as per my plugin) but would like to add synthetics.
>
> Speaking with absolutely zero knowledge how of scala compiler plugins
> work, this sounds vaguely like JDK6 annotation processors.
>
> E.g. I can manually write some code that depends on a non-existent
> FooClass, and so fails to compile on the first round. But then the
> javac compiler runs the annotation processor, which creates the
> FooClass.java source, so the compiler starts a 2nd round to compile
> FooClass.java -> FooClass.class. Having done that, the compiler then
> re-compiles/fixes the "FooClass not found" error from the first round,
> and everything is now fine.
>
> javac would even start up a 3rd round if the FooClass.java source that
> the first annotation processor generated happened to have annotations
> that triggered another annotation processor to generate yet more source
> code. It keeps going until no more source files have been generated.
>
> No idea whether multiple rounds makes sense for scala compiler plugins,
> but in my experience it has worked well for annotation processors.
>
> - Stephen
>
>
>

I can imagine something like this working for a range of issues:

- During typer, postpone the display of any error messages
- Create an new phase typeSynthetics, immediately before superaccessors
- A unit can be flagged for re-compilation by any phase before this
(so plugins would runAfter typer, but before typeSynthetics)
- In typeSynthetics, reprocess (namer-->typeSynthetics) any flagged unit
- Report any outstanding typer failures

Re: [scala] A small change to compiler phases

2009-11-09T22:07:03Z

> I'd prefer an optional phase of "please typer don't complain I WILL
> fix this tree for you, but may ask you to run again, oh and on that
> second run could you please add the following synthetics in". This
> would allow for the case where you need the type information from
> typers (as per my plugin) but would like to add synthetics.

Speaking with absolutely zero knowledge how of scala compiler plugins
work, this sounds vaguely like JDK6 annotation processors.

E.g. I can manually write some code that depends on a non-existent
FooClass, and so fails to compile on the first round. But then the
javac compiler runs the annotation processor, which creates the
FooClass.java source, so the compiler starts a 2nd round to compile
FooClass.java -> FooClass.class. Having done that, the compiler then
re-compiles/fixes the "FooClass not found" error from the first round,
and everything is now fine.

javac would even start up a 3rd round if the FooClass.java source that
the first annotation processor generated happened to have annotations
that triggered another annotation processor to generate yet more source
code. It keeps going until no more source files have been generated.

No idea whether multiple rounds makes sense for scala compiler plugins,
but in my experience it has worked well for annotation processors.

- Stephen

Re: [scala] A small change to compiler phases

2009-11-09T21:54:07Z

On Mon, Nov 9, 2009 at 4:38 PM, Kevin Wright
<kev.lee.wright@...> wrote:
> It seems that there's an important class of compiler plugins that
> struggle under the current setup.
> Specifically, those that generate entirely synthetic classes, or
> synthetic methods on existing classes.

I have such a plugin and I am sure there are others.

> these generated constructs, there's nothing unusual in them) but the
> tight coupling of the namer/typer phases prevents me from doing this.
>
> Would it therefore be possible to have "typer runsAfter namer" instead
> of "typer runsRightAfter namer" ?
>

Of course I realise this would be tough to do, but whilst we are
asking for compiler changes...

I'd prefer an optional phase of "please typer don't complain I WILL
fix this tree for you, but may ask you to run again, oh and on that
second run could you please add the following synthetics in". This
would allow for the case where you need the type information from
typers (as per my plugin) but would like to add synthetics.

Re: [scala] Scala Servlets

2009-11-09T14:47:39Z

Additional problems:

It keeps the return null if absent pattern of the original API, rather than wrapping with Option.

It keeps the ludicrous "two ways to ask for a session" from the original API. It wasn't a particularly good design choice back in '97, but it's really dated now.

But the big failure is that it simply doesn't add much value. Most of the really tedious operations on the Servlet API are still exactly as tedious. Which is probably why I never use the Servlet API any more, and write service servlets using the JAX-RS API. Now a full featured Scala wrapper around those would be pretty sweet.

--Dave Griffith

Re: [scala] Scala Servlets

2009-11-09T13:59:33Z

It is worse then original server API, because it wraps servlet API,
and does not provide significant value.

> The main difference to Java Servlets is the way the response is returned:
>
> // Java
> doGet(HttpServletRequest req, HttpServletResponse resp)
>
> // Scala
> get(req: HttpServletRequest): HttpServletResponse

If you think it is a shortcoming, you shoud study servlets better.

def doGet(req, resp) = {
resp.addCookie("zz", "yy")
req.getServletContext.getRequestDispatcher("/another-url").forward(req, resp)
}

is not possible in your API.

S.

On Mon, Nov 9, 2009 at 23:14, Christian Helmbold
<christian.helmbold@...> wrote:

> Hi,
>
> the Servlet API is perhaps the most popular Java EE API and
> my idea is to make this API available as a Scala-like API. I published
> my idea at http://scala-forum.org/ and was asked to bring it to a wider audience (to this list).
>
> The main difference to Java Servlets is the way the response is returned:
>
> // Java
> doGet(HttpServletRequest req, HttpServletResponse resp)
>
> // Scala
> get(req: HttpServletRequest): HttpServletResponse
>
> You can find a detailed description of the API at http://scala-forum.org/read.php?4,687 .
>
> What do you think about it?
>
> I'd prefer answers there, but of corse answers are also welcome here.
>
> Regards
> Christian
>
>
>
>

[scala] Scala Servlets

2009-11-09T12:14:42Z

Hi,

the Servlet API is perhaps the most popular Java EE API and
my idea is to make this API available as a Scala-like API. I published
my idea at http://scala-forum.org/ and was asked to bring it to a wider audience (to this list).

The main difference to Java Servlets is the way the response is returned:

// Java
doGet(HttpServletRequest req, HttpServletResponse resp)

// Scala
get(req: HttpServletRequest): HttpServletResponse

You can find a detailed description of the API at http://scala-forum.org/read.php?4,687 .

What do you think about it?

I'd prefer answers there, but of corse answers are also welcome here.

Regards
Christian

[scala] nominal versus positional access

2009-11-09T11:33:03Z

Dear Scalarazzi,

i noticed that you can use the derivative of data types to build a bridge between nominal and positional access. i've written about it here. The kernel of the idea can be illustrated in two simple equations.

T[N] = N + [N => T[N]] + T[N] x T[N]
N = ∂T[N]

The first equation is a domain equation for the data type of lambda terms. The second equation says that names (aka variables) must be contexts in lambda terms. This leads to a whole host of interesting new questions. Further, the technique is quite general and applies to a wide range of situations, not just nominal presentations of computational calculi.

Best wishes,

--greg

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com

[scala] A small change to compiler phases

2009-11-09T07:38:49Z

It seems that there's an important class of compiler plugins that
struggle under the current setup.
Specifically, those that generate entirely synthetic classes, or
synthetic methods on existing classes.

This is possible to do if no type or symbol information is needed by
the plugin (it can run between parser and namer), but it's impossible
to synthesise methods after the typer phase unless those methods are
overrides, as any classes then trying to use these methods will
already have failed to compile.

A quick look at the existing architecture shows how this issue is
handled with other code already being synthesised by the compiler:

case classes: the companion object is generated in the namer. In
addition the generated hashCode and equals methods are overrides from
the Any class
@BeanProperty: synthesis is mostly in namer, with some support for
setters in typer
@specialized: after typer, but (crucially) the code is valid and
type-checks before specialisation

It seems that the best place to handle a lot of synthesis is
immediately before typer, but this option is not available to a plugin
as typer is set runRightAfter namer.

I'm attempting to write a plugin that could very easily adopt a
similar approach to @BeanProperty, and I'm able to synthesize the
necessary entries in the AST with only symbol information (I'm
perfectly happy to allow the typer to then do its normal thing on
these generated constructs, there's nothing unusual in them) but the
tight coupling of the namer/typer phases prevents me from doing this.

Would it therefore be possible to have "typer runsAfter namer" instead
of "typer runsRightAfter namer" ?

[scala] Re: understanding generated bytecode

2009-11-09T03:00:18Z

Johannes,

Yes, javap and scalap show what's inside the generated .class files but
still I would prefer an IDE-level bytecode browser (with navigation, too?).
So I might settle on the Eclipse plugin for Soot, which can for example
display bytecode using the Grimp notation (well, the following screenshot
shows Jimple, but conveys the idea):
http://www.sable.mcgill.ca/soot/eclipse/ca.mcgill.sable.soot/doc/concepts/jimple_editor.html
unless someone suggests sthg better.

After getting an overview of some (not all :-) of the name mangling and
codegen patterns, I *would like* later to try some bytecode-level automatic
verfication techniques, e.g.
http://www-sop.inria.fr/everest/BML/Introduction.html#Introduction
or the aforementioned Findbugs.

Miguel
http://www.sts.tu-harburg.de/people/mi.garcia

Re: [scala] Re: recent changes in 2.8 nightly classpath management

2009-11-09T02:52:55Z

Hello Daniel, Eric

this behavior is expected, there was a change in the way the "classpath" setting is defined.

Before, the value of "-classpath" was defined by:
1) the user-specified value ("-classpath x"), or else
2) the value of the "CLASSPATH" environment variable, or else
3) the value of the java property "java.class.path", which is the "-classpath x" given to the java command, or else
4) the current directroy.

We decided to remove 3) as this can put unexpected things on scalac's classpath.

http://lampsvn.epfl.ch/trac/scala/changeset/19285/scala/trunk/src/compiler/scala/tools/nsc/Settings.scala

You can make the example below work by adding

settings.classpath.value = System.getProperty("java.class.path")

Cheers: Lukas

On Mon, Nov 9, 2009 at 00:15, Eric Willigers <ewilligers@...> wrote:

I've been experiencing the same problem.

Here's an example that used to work:-

// Compile.scala

import scala.tools.nsc.{Global, Settings}
import scala.tools.nsc.reporters.ConsoleReporter

object Compile
{
def main(args: Array[String]): Unit =
{
val settings = new Settings()

settings.target.value = "jvm-1.5"
settings.deprecation.value = true // enable detailed deprecation warnings
settings.unchecked.value = true // enable detailed unchecked warnings
settings.outdir.value = "."
val reporter = new ConsoleReporter(settings)

val compiler = new Global(settings, reporter)
val run = (new compiler.Run)
run.compile(List("Test.scala"))

reporter.printSummary
if (reporter.hasErrors || reporter.WARNING.count > 0)
{
error("Errors or warnings detecting during compile")
}
}
}

touch Test.scala

rm -f *.class
2.8.0.r18678-b20090910020815/bin/scalac Compile.scala
java -cp "2.8.0.r18678-b20090910020815\lib\scala-library.jar;2.8.0.r18678-b20090910020815\lib\scala-compiler.jar;." Compile
(success)

rm -f *.class
2.8.0.r19410-b20091106023416/bin/scalac Compile.scala
java -cp "2.8.0.r19410-b20091106023416\lib\scala-library.jar;2.8.0.r19410-b20091106023416\lib\scala-compiler.jar;." Compile
Exception in thread "main" scala.tools.nsc.MissingRequirementError:
object scala not found.

Re: [scala] understanding generated bytecode

2009-11-09T02:41:03Z

On Mon, Nov 9, 2009 at 11:21 AM, Miguel Garcia <miguel.garcia@...> wrote:
> I've been exploring what the nsc generated bytecode looks like, using the
> following decompiler
>
> McGill's "Dava" Java Decompiler http://www.sable.mcgill.ca/dava/
>
> One of the explicit goals of Dava is to generate compilable Java from
> non-Java bytecode (that's the idea).
> Some things work and others don't. Has anybody tried other ways to get a
> high-level view of nsc-generated bytecode?

You can use scalac -Xprint:<phase> to get an idea of what scalac is
doing. Especially using -Xprint:jvm should give something very close
to bytecodes. Low-level inspection tools are javap and scalap (though,
I don't know what the latter one does exactly. IMO it just prints the
serialized scala signatures).

What do you expect from a high-level view of bytecodes?

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

[scala] understanding generated bytecode

2009-11-09T02:21:03Z

Hi,

I've been exploring what the nsc generated bytecode looks like, using the
following decompiler

McGill's "Dava" Java Decompiler http://www.sable.mcgill.ca/dava/

One of the explicit goals of Dava is to generate compilable Java from
non-Java bytecode (that's the idea).
Some things work and others don't. Has anybody tried other ways to get a
high-level view of nsc-generated bytecode?
Soot itself provides bytecode-level languages (Grimp in particular),
comments on that are also welcome.

Somewhat related to the above, there's an enhancement ticket:
FindBugs should be run during nightly tests,
http://lampsvn.epfl.ch/trac/scala/ticket/571
Experience reports on that would also be welcome :-)

Miguel
http://www.sts.tu-harburg.de/people/mi.garcia

Re: [scala] Using generalised type constraints in 2.8 collections

2009-11-08T23:15:33Z

Sorry, hit send too soon. Here's working code:

http://gist.github.com/229756

sealed abstract class <:<[-From, +To] extends (From => To)
object <:< {
implicit def conforms[A]: A <:< A = new (A <:< A) {def apply(x: A) = x}
}

sealed abstract class ==[From, To] extends (From => To)
object == {
implicit def tpEquals[A]: A == A = new (A == A) {def apply(x: A) = x}
}

sealed abstract class <%<[-From, +To] extends (From => To)
object <%< {
implicit def conformsOrViewsAs[A <% B, B]: A <%< B = new (A <%< B) {def apply(x: A) = x}
}

trait A
trait B
implicit def AToB(a: A): B = new B {}

println(implicitly[Int == Int], implicitly[Int <:< Any], implicitly[A <%< B])

//object Predef {
implicit def identity[A](a: A): A = a
//}

println((implicitly[Int => Int], implicitly[Int => Any]))

On Mon, Nov 9, 2009 at 8:02 AM, Jason Zaugg <jzaugg@...> wrote:

It occurs to me that defining implicits to generate <:<, <%< and == in Predef would lead to ambiguity if you required A => B. So <%< and == should be defined on the companion objects:

Re: [scala] Using generalised type constraints in 2.8 collections

2009-11-08T23:02:51Z

It occurs to me that defining implicits to generate <:<, <%< and == in Predef would lead to ambiguity if you required A => B. So <%< and == should be defined on the companion objects:

sealed abstract class <:<[-From, +To] extends (From => To)
object <:< {
implicit def conforms[A]: A <:< A = new (A <:< A) {def apply(x: A) = x} }

sealed abstract class =:=[A, B]

object =:= {

implicit def tpEq[A]: A =:= A = new (A =:= A) { def apply(a: A): A = a }

}

sealed abstract class <%<[A, B]
object <%< {

implicit def tpView[A <% B, B]: A <%< B = new (A <%< B) { def apply(a: A): B = a }

}

On Sun, Nov 8, 2009 at 9:50 PM, Jason Zaugg <jzaugg@...> wrote:

In general, the flexibility to choose <:< or <%< would be useful. The former ought to be the default choice for a type-fearing API designer, but consideration of backwards compatibility and flexibility could swing the decision other way. I guess you could even sit on the fence, make the type abstract and let the user decide :)

For completeness, perhaps ==[A, B] should be included: http://article.gmane.org/gmane.comp.lang.scala.user/18879

In this particular case, I would find one of the following more intention revealing.

List(Some(1), None).filterMap { case Some(x) => x }

Which perhaps warrants its own function:

Option.somes(List(Some(5), None))

or, granting Option a(nother) ticket into TraversibleLike:

List(Some(5), None).somes

-jason

On Sun, Nov 8, 2009 at 9:47 PM, Viktor Klang <viktor.klang@...> wrote:

On Sun, Nov 8, 2009 at 9:02 PM, Adriaan Moors <adriaan.moors@...> wrote:

good point. it's a tricky design decision -- do we want subtyping or convertibility?
we could introduce <?< (or something better ascii-art welcome), but I'm definitely against going back to =>, as it conflates views and bounds (as witnessed by implicit values)

<?< would include <:<, as well as conversions such Option[A] <?< Traversable[A]

<%< ?

adriaan

On Sun, Nov 8, 2009 at 8:45 PM, Paul Phillips <paulp@...> wrote:

On Sun, Nov 08, 2009 at 07:40:05PM +0100, Adriaan Moors wrote:
> > def flatten[B](implicit asTraversable: A => /*<:<!!!*/ Traversable[B]):
> >

> it didn't work back then because there were some subtleties with the
> coup d'état that removed identity from its implicit pedestal in
> favour of <:< (bootstrapping issues, as you might imagine).

Hmmm. Such a definition excludes Option, which is as we know too well
not actually a Traversable, but converts to one.

So my oft-used List(Some(5), None).flatten no longer compiles.

--
Paul Phillips | A national political campaign is better than the
Apatheist | best circus ever heard of, with a mass baptism and
Empiricist | a couple of hangings thrown in.
pal, i pill push | -- H. L. Mencken

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang

[scala] Re: recent changes in 2.8 nightly classpath management

2009-11-08T15:15:28Z

I've been experiencing the same problem.

Here's an example that used to work:-

// Compile.scala

import scala.tools.nsc.{Global, Settings}
import scala.tools.nsc.reporters.ConsoleReporter

object Compile
{
def main(args: Array[String]): Unit =
{
val settings = new Settings()

settings.target.value = "jvm-1.5"
settings.deprecation.value = true // enable detailed
deprecation warnings
settings.unchecked.value = true // enable detailed unchecked
warnings
settings.outdir.value = "."
val reporter = new ConsoleReporter(settings)

val compiler = new Global(settings, reporter)
val run = (new compiler.Run)
run.compile(List("Test.scala"))

reporter.printSummary
if (reporter.hasErrors || reporter.WARNING.count > 0)
{
error("Errors or warnings detecting during compile")
}
}
}

touch Test.scala

rm -f *.class
2.8.0.r18678-b20090910020815/bin/scalac Compile.scala
java -cp
"2.8.0.r18678-b20090910020815\lib\scala-library.jar;2.8.0.r18678-b20090910020815\lib\scala-compiler.jar;."
Compile
(success)

rm -f *.class
2.8.0.r19410-b20091106023416/bin/scalac Compile.scala
java -cp
"2.8.0.r19410-b20091106023416\lib\scala-library.jar;2.8.0.r19410-b20091106023416\lib\scala-compiler.jar;."
Compile
Exception in thread "main" scala.tools.nsc.MissingRequirementError:
object scala not found.

Re: [scala] Using generalised type constraints in 2.8 collections

2009-11-08T12:50:16Z

In general, the flexibility to choose <:< or <%< would be useful. The former ought to be the default choice for a type-fearing API designer, but consideration of backwards compatibility and flexibility could swing the decision other way. I guess you could even sit on the fence, make the type abstract and let the user decide :)

For completeness, perhaps ==[A, B] should be included: http://article.gmane.org/gmane.comp.lang.scala.user/18879

In this particular case, I would find one of the following more intention revealing.

List(Some(1), None).filterMap { case Some(x) => x }

Which perhaps warrants its own function:

Option.somes(List(Some(5), None))

or, granting Option a(nother) ticket into TraversibleLike:

List(Some(5), None).somes

-jason

On Sun, Nov 8, 2009 at 9:47 PM, Viktor Klang <viktor.klang@...> wrote:

On Sun, Nov 8, 2009 at 9:02 PM, Adriaan Moors <adriaan.moors@...> wrote:

good point. it's a tricky design decision -- do we want subtyping or convertibility?
we could introduce <?< (or something better ascii-art welcome), but I'm definitely against going back to =>, as it conflates views and bounds (as witnessed by implicit values)

<?< would include <:<, as well as conversions such Option[A] <?< Traversable[A]

<%< ?

adriaan

On Sun, Nov 8, 2009 at 8:45 PM, Paul Phillips <paulp@...> wrote:

On Sun, Nov 08, 2009 at 07:40:05PM +0100, Adriaan Moors wrote:
> > def flatten[B](implicit asTraversable: A => /*<:<!!!*/ Traversable[B]):
> >

> it didn't work back then because there were some subtleties with the
> coup d'état that removed identity from its implicit pedestal in
> favour of <:< (bootstrapping issues, as you might imagine).

Hmmm. Such a definition excludes Option, which is as we know too well
not actually a Traversable, but converts to one.

So my oft-used List(Some(5), None).flatten no longer compiles.

--
Paul Phillips | A national political campaign is better than the
Apatheist | best circus ever heard of, with a mass baptism and
Empiricist | a couple of hangings thrown in.
pal, i pill push | -- H. L. Mencken

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang

Re: [scala] Using generalised type constraints in 2.8 collections

2009-11-08T12:47:04Z

On Sun, Nov 8, 2009 at 9:02 PM, Adriaan Moors <adriaan.moors@...> wrote:

good point. it's a tricky design decision -- do we want subtyping or convertibility?
we could introduce <?< (or something better ascii-art welcome), but I'm definitely against going back to =>, as it conflates views and bounds (as witnessed by implicit values)

<?< would include <:<, as well as conversions such Option[A] <?< Traversable[A]

<%< ?

adriaan

On Sun, Nov 8, 2009 at 8:45 PM, Paul Phillips <paulp@...> wrote:

On Sun, Nov 08, 2009 at 07:40:05PM +0100, Adriaan Moors wrote:
> > def flatten[B](implicit asTraversable: A => /*<:<!!!*/ Traversable[B]):
> >

> it didn't work back then because there were some subtleties with the
> coup d'état that removed identity from its implicit pedestal in
> favour of <:< (bootstrapping issues, as you might imagine).

Hmmm. Such a definition excludes Option, which is as we know too well
not actually a Traversable, but converts to one.

So my oft-used List(Some(5), None).flatten no longer compiles.

--
Paul Phillips | A national political campaign is better than the
Apatheist | best circus ever heard of, with a mass baptism and
Empiricist | a couple of hangings thrown in.
pal, i pill push | -- H. L. Mencken

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: [scala] Using generalised type constraints in 2.8 collections

2009-11-08T12:02:32Z

good point. it's a tricky design decision -- do we want subtyping or convertibility?

we could introduce <?< (or something better ascii-art welcome), but I'm definitely against going back to =>, as it conflates views and bounds (as witnessed by implicit values)

<?< would include <:<, as well as conversions such Option[A] <?< Traversable[A]

adriaan

On Sun, Nov 8, 2009 at 8:45 PM, Paul Phillips <paulp@...> wrote:

On Sun, Nov 08, 2009 at 07:40:05PM +0100, Adriaan Moors wrote:
> > def flatten[B](implicit asTraversable: A => /*<:<!!!*/ Traversable[B]):
> >

> it didn't work back then because there were some subtleties with the
> coup d'état that removed identity from its implicit pedestal in
> favour of <:< (bootstrapping issues, as you might imagine).

Hmmm. Such a definition excludes Option, which is as we know too well
not actually a Traversable, but converts to one.

So my oft-used List(Some(5), None).flatten no longer compiles.

--
Paul Phillips | A national political campaign is better than the
Apatheist | best circus ever heard of, with a mass baptism and
Empiricist | a couple of hangings thrown in.
pal, i pill push | -- H. L. Mencken

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: [scala] Using generalised type constraints in 2.8 collections

2009-11-08T11:45:23Z

On Sun, Nov 08, 2009 at 07:40:05PM +0100, Adriaan Moors wrote:
> > def flatten[B](implicit asTraversable: A => /*<:<!!!*/ Traversable[B]):
> >
> it didn't work back then because there were some subtleties with the
> coup d'état that removed identity from its implicit pedestal in
> favour of <:< (bootstrapping issues, as you might imagine).

Hmmm. Such a definition excludes Option, which is as we know too well
not actually a Traversable, but converts to one.

So my oft-used List(Some(5), None).flatten no longer compiles.

--
Paul Phillips | A national political campaign is better than the
Apatheist | best circus ever heard of, with a mass baptism and
Empiricist | a couple of hangings thrown in.
pal, i pill push | -- H. L. Mencken

Re: [scala] Using generalised type constraints in 2.8 collections

2009-11-08T10:40:05Z

I'm sure you'll both notice if you haven't already that the current type
signature of flatten is:

def flatten[B](implicit asTraversable: A => /*<:<!!!*/ Traversable[B]): CC[B] = {

which has that definite ring of "didn't work for some reason."

it didn't work back then because there were some subtleties with the coup d'état that removed identity from its implicit pedestal in favour of <:< (bootstrapping issues, as you might imagine).

That's history now, so nothing (should be) stopping you (or me, of course) from doing the obvious search/replace.

adriaan

Re: [scala] Using generalised type constraints in 2.8 collections

2009-11-08T10:31:53Z

On Sun, Nov 08, 2009 at 05:44:19PM +0100, Adriaan Moors wrote:
> > - Should List.flatten be tightened to accept 'implicit ev: A <:<
> > Iterable[B]' rather than 'implicit f : A => Iterable[B]'?
>
> nope! nail: meet hammer; hammer: meet flatten

I'm sure you'll both notice if you haven't already that the current type
signature of flatten is:

def flatten[B](implicit asTraversable: A => /*<:<!!!*/ Traversable[B]): CC[B] = {

which has that definite ring of "didn't work for some reason."

To the question about what <:< enables, all kinds of goodness. One that
I checked in not too long ago is on Either, which has long suffered from
having methods which conceptually belong on the instance having to be
defined on the object because the types could not be inferred.

For example:

scala> val x: Either[Either[Int, String], String] = Left(Right("a"))
x: Either[Either[Int,String],String] = Left(Right(a))

Without some means to limit the type of A "from the inside", flattening
had to be done like this:

scala> Either.joinLeft(x)
res1: Either[Int,String] = Right(a)

Now the method is on the instance:

scala> x.joinLeft
res0: Either[Int,String] = Right(a)

With this signature:

def joinLeft[A1 >: A, B1 >: B, C](implicit ev: A1 <:< Either[C, B1]): Either[C, B1]

--
Paul Phillips | A Sunday school is a prison in which children do
Protagonist | penance for the evil conscience of their parents.
Empiricist | -- H. L. Mencken
pal, i pill push |----------* http://www.improving.org/paulp/ *----------

Re: [scala] Using generalised type constraints in 2.8 collections

2009-11-08T08:44:19Z

On Sun, Nov 8, 2009 at 12:08 AM, Jason Zaugg <jzaugg@...> wrote:

In light of generalised type constraints:

- Should List.flatten be tightened to accept 'implicit ev: A <:< Iterable[B]' rather than 'implicit f : A => Iterable[B]'?
- Could we have Option.flatten, along the lines of: http://gist.github.com/228927 ?

Or am I just wielding a shiny new hammer in search of things resembilng nails?

nope! nail: meet hammer; hammer: meet flatten

i'll look into it in the next couple of days

thanks!

adriaan

Re: [scala] Using generalised type constraints in 2.8 collections

2009-11-08T08:21:39Z

Here's a demo of what they enable, showing the equivalent Scala 2.7 code. http://gist.github.com/229163

In 2.7 and 2.8, <: allows you to constraint type parameters of the current method. But to constrain other in-scope abstract types, you needed to add an implicit parameter to the method (see List.flatten.)

In 2.7, you could require an implicit of type (A => B) and expect this implicit to be provided by Predef.identity. But it could also come from other in scope implicit conversion functions. Requiring a parameter of (A <:< B) is stricter because the instances can only be generated if A conforms to B.

As far as I can tell, it is just a library change to Predef, no compiler magic at all.

2.7:
Predef.scala
implicit def identity[A](x: A): A = x

2.8
Predef.scala
sealed abstract class <:<[-From, +To] extends (From => To)
implicit def conforms[A]: A <:< A = new (A <:< A) {def apply(x: A) = x}

-jason

On Sun, Nov 8, 2009 at 4:35 PM, Johannes Rudolph <johannes.rudolph@...> wrote:

On Sun, Nov 8, 2009 at 12:08 AM, Jason Zaugg <jzaugg@...> wrote:
> In light of generalised type constraints:

Are these somewhere documented? What do they do?

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

Re: [scala] structural type example from paper not compiling

2009-11-08T07:55:32Z

Also, if you want to return some kind of result:

object d {
type Close = { def close() : Unit }
def safe[R,T <: Close](t : T)(run : T => R) : R = try { run(t) } finally { t.close }
}

On Sun, Nov 8, 2009 at 4:37 PM, Luc Duponcheel <luc.duponcheel@...> wrote:

what about

import java.io._

object d {

type Close = { def close(): Unit }

def autoclose[X <: Close](x: X)(run: X => Unit): Unit = {
   try { run(x) }
   finally { x.close }
}

autoclose[FileInputStream](new FileInputStream("test.txt"))(

   { file =>
     var byte: Int = file.read();
     while(byte > -1) {
       print(byte.toChar)
       byte = file.read()
     }
   }
)
}

On Sun, Nov 8, 2009 at 4:20 PM, Miguel Garcia <miguel.garcia@...> wrote:

Hi,

I'm having trouble getting to compile with 2.8 the example appearing in the paper

Compiling structural types on the JVM: a comparison of reflective and generative techniques from Scala's perspective
http://infoscience.epfl.ch/record/138931/files/

i.e. this snippet:

import java.io.FileInputStream

object d {

type Close = { def close(): Unit }

def autoclose(t: Close)(run: Close => Unit): Unit = {
try { run(t) }
finally { t.close }
}

autoclose(new FileInputStream("test.txt"))(
{ file =>
var byte: Int = file.read();
while(byte > -1) {
print(byte.toChar)
byte = file.read()
}
}
)
}

because of a type mismatch: the 2nd argument to the autoclose invocation, with actual type FileInputStream => Unit, is taken to have type Close => Unit, and thus file.read() is rejected because "value read is not a member of d.Close"

The type of "file" in "file => ..." is not inferred based on the preceding actual argument. Any way out of this?

Miguel
http://www.sts.tu-harburg.de/people/mi.garcia/

--
__~O
-\ <,
(*)/ (*)

reality goes far beyond imagination

Re: [scala] structural type example from paper not compiling

2009-11-08T07:37:08Z

what about

import java.io._

object d {

type Close = { def close(): Unit }

def autoclose[X <: Close](x: X)(run: X => Unit): Unit = {
   try { run(x) }
   finally { x.close }
}

autoclose[FileInputStream](new FileInputStream("test.txt"))(
   { file =>
     var byte: Int = file.read();
     while(byte > -1) {
       print(byte.toChar)
       byte = file.read()
     }
   }
)
}

On Sun, Nov 8, 2009 at 4:20 PM, Miguel Garcia <miguel.garcia@...> wrote:

Hi,

I'm having trouble getting to compile with 2.8 the example appearing in the paper

Compiling structural types on the JVM: a comparison of reflective and generative techniques from Scala's perspective
http://infoscience.epfl.ch/record/138931/files/

i.e. this snippet:

import java.io.FileInputStream

object d {

type Close = { def close(): Unit }

def autoclose(t: Close)(run: Close => Unit): Unit = {
try { run(t) }
finally { t.close }
}

autoclose(new FileInputStream("test.txt"))(
{ file =>
var byte: Int = file.read();
while(byte > -1) {
print(byte.toChar)
byte = file.read()
}
}
)
}

because of a type mismatch: the 2nd argument to the autoclose invocation, with actual type FileInputStream => Unit, is taken to have type Close => Unit, and thus file.read() is rejected because "value read is not a member of d.Close"

The type of "file" in "file => ..." is not inferred based on the preceding actual argument. Any way out of this?

Miguel
http://www.sts.tu-harburg.de/people/mi.garcia/

--
__~O
-\ <,
(*)/ (*)

reality goes far beyond imagination

Re: [scala] Using generalised type constraints in 2.8 collections

2009-11-08T07:35:39Z

On Sun, Nov 8, 2009 at 12:08 AM, Jason Zaugg <jzaugg@...> wrote:
> In light of generalised type constraints:
Are these somewhere documented? What do they do?

--
Johannes

-----------------------------------------------
Johannes Rudolph
http://virtual-void.net

[scala] structural type example from paper not compiling

2009-11-08T07:20:06Z

Hi,

I'm having trouble getting to compile with 2.8 the example appearing in
the paper

Compiling structural types on the JVM: a comparison of reflective and
generative techniques from Scala's perspective
http://infoscience.epfl.ch/record/138931/files/

i.e. this snippet:

import java.io.FileInputStream

object d {

type Close = { def close(): Unit }

def autoclose(t: Close)(run: Close => Unit): Unit = {
try { run(t) }
finally { t.close }
}

autoclose(new FileInputStream("test.txt"))(
{ file =>
var byte: Int = file.read();
while(byte > -1) {
print(byte.toChar)
byte = file.read()
}
}
)
}

because of a type mismatch: the 2nd argument to the autoclose
invocation, with actual type FileInputStream => Unit, is taken to have
type Close => Unit, and thus file.read() is rejected because "value read
is not a member of d.Close"

The type of "file" in "file => ..." is not inferred based on the
preceding actual argument. Any way out of this?

Miguel
http://www.sts.tu-harburg.de/people/mi.garcia/