Custom Search
|
Date: January 31, 2006
From: Adriaan Moors <Adriaan.Moors@xxxxxxxxxxxxxx>
In-reply-to:
<43D11E18.6090301@xxxxxxx>
References:
<loom.20060120T132035-992@xxxxxxxxxxxxxx> <43D11E18.6090301@xxxxxxx>
| Hi, Thank you for the clarifications! However, it's not yet clear to me how nested conversions solve the problem of the makeLazy coercion, which has to be preceded by the T to => T coercion. (If I understand correctly, with nested conversions, you apply the conversion after the argument has already been passed, but then it is too late in this case.) So, to avoid having to write makeLazy explicitly, I see two possible solutions: 1) define restrictions on implicit conversion (and overloaded functions?) so that, no matter which chain of conversions is chosen, the results are the same (similar to the seminal paper by Reynolds [1] -- by the way: does anyone have references for recent results in this area?) 2) have a special case that allows chaining the T to => T coercion (and possibly other built-in coercions) with a user-defined coercion (since this seems to be the only kind of chaining you can't simulate by nesting coercions) Although I think it should be possible to restrict implicit conversions so that they may be chained in certain cases, this is probably overkill. given that you can achieve the same by combining option 2) and -- as you demonstrated -- nested implicit conversions. (Note that languages like C# also adopt option 2, in that a chain of implicit conversions may consist of at most 1 user-defined conversion and several standard conversions [2]. ) I'll do my best to package it up nicely :-) (Or to integrate it with existing frameworks, such as Ross Judson's, if that's more appropriate.) regards, adriaan ps: Since it's been a while since you replied to my original question (sorry about that), here is a link to my original post (on gmane) (http://article.gmane.org/gmane.comp.lang.scala/1743) and your reply (http://article.gmane.org/gmane.comp.lang.scala/1744). [1] John C. Reynolds. Using Category Theory to Design Implicit Conversions and Generic Operators. In Semantics Directed Compiler Generation. LNCS 94, 1980. (http://www.daimi.au.dk/~nygaard/CTfCS/papers/reynolds1.pdf) [2] Evaluation of user-defined conversions. (C# Language Specification, http://msdn.microsoft.com/library/default.asp?url="">) Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm for more information. |
Date: January 30, 2006
From: Marko van Dooren <Marko.vanDooren@xxxxxxxxxxxxxx>
Dear all,I am studying Scala as part of a related work study for a paper on inheritance. I read the OOPSLA'05 paper "Scalable Component Abstractions", and was trying to reuse RichIterator under the assumption that it had been developed as an abstract class instead of a mixin class (or trait in the paper). I managed to do this, as shown by the code below, by creating an empty mixin class MixinRichIterator that extends the now abstract class RichIterator. As far as I see, writing "with MixinRichIterator" achieves the same as writing "with RichIterator" (if abstract classes could be used as mixins). So, assuming that the above is correct, my question is: what is the rationale for not allowing abstract classes to be used as mixins, but allowing the construction above?
Minor remark on the code in the paper: LoggedIterator and SyncIterator should be traits (or mixin classes), and not abstract classes. Otherwise the Iter2 class in the paper does not compile.
mixin class AbsIterator {
type T;
def hasNext: boolean;
def next: T;
}
abstract class RichIterator extends AbsIterator {
def foreach(f: T=> unit): unit = while (hasNext) f(next);
}
class StringIterator(s: String) extends AbsIterator {
type T=char;
private var i=0;
def hasNext = i<s.length();
def next = {val x=s.charAt(i);i=i+1;x}
}
mixin class MixinRichIterator extends RichIterator {}
class RichStringIterator(s: String) extends StringIterator(s)
with MixinRichIterator {
def m(f:T => unit) = foreach(f);
}
Regards,
Marko
Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
Date: January 30, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<F418C1909C57A14E9456C8BEA885634507DD1D@xxxxxxxxxxxxxxxxxx>
"Judson, Ross" <rjudson@xxxxxxxxxxxxxxxxxx> writes: > I thought I'd share a neat UI trick for Swing with the list. Have a > look at this screenshot: > > http://www.soletta.com/sbaz/clip.PNG Hey, that looks great! It is funny how strong instinct is. I found myself stupidly reaching to click some of the links even though I knew it was just a PNG. > [Lex -- this just wraps and calls the sbaz classes you have now] Great! I was hoping they would be reusable, so that other UI's could be developed. -Lex
Date: January 30, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<43DA74FC.9010003@xxxxxxx> <loom.20060128T194150-251@xxxxxxxxxxxxxx> <20060128112840.2prd65n85m888g44@xxxxxxxxxxxx>
Hey, Joel, Actually, when I write web stuff using Scala, I use raw Java servlets. When I write GUI code, I use Java Swing. You put the rationale nicely: > I'd like to see Scala do well, and I think you would get an > objectively better, > more robust solution by hooking into an existing framework. Indeed. It's hard enough to develop a general purpose programming language. Additionally developing an entire suite of libraries is not practical. And even if we somehow did, it would not address people's existing legacy codebases. IMHO, at least, it is essential to talk to Java if you want to provide a practical language for enterprise software. That doesn't mean we don't do libraries, too. But they are for optional use. If you want, it is possible to treat Scala as nothing more than a more productive language to do your next component in. Thanks for the pointers about WebObjects and Tapestry. If anyone gives them a try with Scala, it would be great to hear back on how it goes! -Lex
Date: January 30, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<20060128234643.GG4582@xxxxxxxxxxxxxxxx>
Jamie Webb <j@xxxxxxxxxxxxxxx> writes: > The Scala Wiki is now up at http://scala.sygneca.com/. So, have fun! > And let me know how you get on. Looks great! Thanks, Jamie! I started a "Who's Who" page that anyone should feel free to add themselves to. Jamie, I see, has posted some interesting coding patterns.... -Lex
Date: January 28, 2006
From: Jamie Webb <j@xxxxxxxxxxxxxxx>
The Scala Wiki is now up at http://scala.sygneca.com/. So, have fun! And let me know how you get on. Note that file uploads and edits to the front page are allowed for authorised users only to prevent abuse. I'll authorise everyone who registers and whose name I recognise, or you can mail me if I don't notice or don't know you. Cheers -- Jamie Webb
Date: January 28, 2006
From: joel@xxxxxxxxxxxx
In-reply-to:
<loom.20060128T194150-251@xxxxxxxxxxxxxx>
References:
<43DA74FC.9010003@xxxxxxx> <loom.20060128T194150-251@xxxxxxxxxxxxxx>
I noticed that the Scala Servlet support is heading toward a JSP-like solution.
I wanted to point out a technology started by NeXT which has become Apple WebObjects. It also has open-source versions on the Java platform. The problem with JSP is that you embed code in your HTML, JSP encourages scripting, and discourages component re-use. Putting your html in your scalasource code is not a good solution, because (like JSP) you cannot edit the html
with a normal editor or view it with a normal browser.The WebObject solutions solves this problem. The HTML is left in a separate file
that looks like (and conforms to) html except for an extra attribute in theelements (all editors/viewers will still render properly since extra attributes
are allowed in the html spec). So, an id is added to the elements like: <html><body> <span jwcid="myID"> </span> ... </body></html> At runtime, WebObjects finds what component myID corresponds with and replaces the html with the custom widget html (ie. PageLink, Table, Conditional, etc.), that has been intialized thru a separate XML file (or code).This is a vastly more powerful component methodology that will supplant JSP-like scripting solutions. This is used by Tapestry, RIFE, Wicket, and will be used in
Struts II (thru Tapestry). JSF allows componentization as well but is crippled by its JSP heritage, but the approach is rapidly catching on for good reason. The good thing is that you could possibly plug-in Scala into Tapestry (Scalastry?). Tapestry does dynamically extend classes, and relies on OGNL to do reflective look-ups on classes, but I think it should be do-able, as at onepoint there was a "Groovestry" running (Groovy/Tapestry). Or, you could rewrite
Tapestry (Java) in Scala I imagine. I might do it, but doubt Ill find the time. Scala looks really neat as a language, but I think is taking a step back with the technology, like Ruby did with its JSP-like implementation. (There is a project for Ruby called Iowa to bring Tapestry to Ruby, I've heard of versions like-technology for Python as well)I'd like to see Scala do well, and I think you would get an objectively better,
more robust solution by hooking into an existing framework. Joel Quoting Nathan Sobo <nathansobo@xxxxxxxxx>:
Hey Burak, thanks for taking the time to reply. Things have evolved a little and we're going to be using w3c schema instead of DTD, which I think is a very good thing! I checked out dtd2schema and it looks cool, but it seemed like for now that it only handles DTDs? Anyway, since schemas are XML, they are pretty easy to analyze with Scala, and I was able to get an empty boilerplate facade generated pretty quickly. Subclassing Node worked out very well, thanks for that. I'm going to interpret annotations to the schema as instructions about what classes need to be loaded to provide access to different parts of the facade. Scala is awesome so far. Thanks!
Date: January 28, 2006
From: Nathan Sobo <nathansobo@xxxxxxxxx>
References:
<43DA74FC.9010003@xxxxxxx>
Hey Burak, thanks for taking the time to reply. Things have evolved a little and we're going to be using w3c schema instead of DTD, which I think is a very good thing! I checked out dtd2schema and it looks cool, but it seemed like for now that it only handles DTDs? Anyway, since schemas are XML, they are pretty easy to analyze with Scala, and I was able to get an empty boilerplate facade generated pretty quickly. Subclassing Node worked out very well, thanks for that. I'm going to interpret annotations to the schema as instructions about what classes need to be loaded to provide access to different parts of the facade. Scala is awesome so far. Thanks!
Date: January 27, 2006
From: Burak Emir <Burak.Emir@xxxxxxx>
Hello Nathan,Have you looked at schema2src, Scala's data binding tools (formerly dtd2scala)?
It is not even alpha but available in source form at http://lamp.epfl.ch/~emir/projects/index.html
(in the scalax package)The thing is, it is now modular enough that a user can create own modules that read a DTD and then turn it into something else.
You just need to build the stuff in the schema2src directory and then use the "dtd" module as a basis for your own.
This should help with the "administrative" side of the problem. To get an XML facade that acts as a proxy to a database, you just have to subclass scala.xml.Node. Putting altoghether, your "myproxydtd" module would generate code which subclasses scala.xml.Node and implements methods children, attributes, ... in a special way.
hope this helps, Burak Nathan Sobo wrote:
Hi. I just picked up Scala a few days ago and it's looking awesome. I was hoping to get some feedback on the best way to employ the existing XML tools in solving a problem. My plan is to link the structure of a document as defined in a DTD to the code necessary to construct each fragment of the document. Rather than querying against an actual document, the user would specify an Xpath against the virtual document, which would locate and execute functions to build what they requested. This way, I can make a hairy legacy database look like a collection of XML documents to the outside world, but only construct those fragments of the document that are needed. Any tips on the best approach in Scala? Thanks!
-- Burak Emir http://lamp.epfl.ch/~emir
Date: January 27, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<F418C1909C57A14E9456C8BEA8856345A4FC1B@xxxxxxxxxxxxxxxxxx> <87d5if6io3.fsf@xxxxxxxxxxxxxxxxxx>
Okay, version 1.10 of sbaz has a hook to help people who need proxy settings. If you have a file config/sbaz.properties in your Scala home directory, then sbaz will read that file into the Java system settings. So, if you are using a Sun JDK, and you want to set up sbaz to use an HTTP proxy, you should create the file config/sbaz.properties and put the following three lines in it: http.proxySet=true http.proxyHost=localhost http.proxyPort=3128 Ross, or anyone, if you give this a try, I'd love to hear how it goes. -Lex
Date: January 27, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
If you have the Scala Bazaar tool, sbaz, installed on your machine,
then your next upgrade needs to be done carefully. The ritual is:
sbaz update
sbaz install sbaz/1.9
sbaz install sbaz
In more detail, the issue is that a forthcoming change in the Scala
library is binary incompatible. Future versions of sbaz's own sbaz
package are going to use their own copy of the library binary, to
avoid this problem. The first upgrade, however, needs to be done
carefully.
Alternatively, you can (re)start from a fresh bootstrap file for sbaz,
in which case you'll already have version 1.10 or newer properly
installed.
-Lex
Date: January 27, 2006
From: "Judson, Ross" <rjudson@xxxxxxxxxxxxxxxxxx>
I thought I'd share a neat UI trick for Swing with the list. Have a look at this screenshot: http://www.soletta.com/sbaz/clip.PNG [Lex -- this just wraps and calls the sbaz classes you have now] Nice looking HTML-type UIs can be generated -- Scala's XML handling makes it easy. Swing's HTML handling is a little primitive so the Scala stylesheets aren't followed as carefully as they should be. The Clicker expressions could use a little polish, too -- I struggled a bit with the syntax. Because an XML expression is part of a formal scope, generating complex details about domain info and so forth is quite simple...here's a little clip from the code: class MDFrame(private var md: ManagedDirectory) extends SFrame { val html = new SEditorPane; html.contentType = "text/html"; html.editable = false; html.text = <html> <head> <link rel="stylesheet" type="text/css" media="print" href="http://scala.epfl.ch/css/screen.css"/> <link rel="stylesheet" type="text/css" media="screen" href="http://scala.epfl.ch/css/print.css"/> </head> <body bgcolor="#ebb85c"><div id="body-area"><div id="body-content"> <div id="menu-area"><div id="menu-content"> </div></div> <div id="main-area"><div id="main-content"> <h1><img alt="Scala" src="http://scala.epfl.ch//images/scala_logo.png"/></h1> <p/><b>SBaz</b> is a <i>package manager</i> for <a href="http://scala.epfl.ch";>Scala</a>. Below you can see listings of the packages that are <i>available</i> and the packages that you have already <i>installed</i>. <b>Click</b> on an available package to install it, or <b>click</b> on a package that is already installed to remove it (you will be asked to confirm removal). If a newer version of a package is available the newer version is highlighted. <p/>Your base sbaz directory is currently: <b>{ md.directory.toString }</b>. { Clicker("Change the base", cmd => changeBase).html }. <p/>You can also { Clicker("Update the list", cmd => updateList).html } of what's available (downloads the latest package list); { Clicker("Upgrade", cmd => upgrade).html } your installed packages to the latest versions; { Clicker("Compact", cmd => compact).html } the download cache (saves space by removing downloaded archives); <h1>Available</h1> {availableHTML(md.available.packages)} <h1>Installed</h1> {installedHTML(md.installed.packages)} </div></div> </div></div></body> </html> ; build; case class Clicker(command: String, body: String => unit) { def html = { // TODO: Add listener <a href={"#" + command.replace(' ', '_')}>{command}</a>; } } def changeBase: unit = { } def updateList: unit = { } def upgrade: unit = { } def compact: unit = { } private def availableHTML(lst: List[AvailablePackage]): List[xml.Elem] = lst match { case Nil => Nil case h :: t => apHTML(h) :: availableHTML(t) } // Generate HTML for an available package. private def apHTML(ap: AvailablePackage) = <span> { Clicker("Install " + ap.toString(), cmd => { Console.println("Install of " + ap) }).html} <br/> </span> ; private def installedHTML(lst: List[InstalledEntry]): List[xml.Elem] = lst match { case Nil => Nil case h :: t => <span> {Clicker("Remove " + h.name + '/' + h.version, cmd => { Console.println("Remove of " + h); }).html} <br/> </span> :: installedHTML(t) }
Date: January 27, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<E1F2PfG-0006ew-00.i-denis-list-ru@xxxxxxxxxxx>
![http://scala.epfl.ch//images/scala_logo.png"/](http://scala.epfl.ch//images/scala_logo.png"/){kind=link}
This using idiom is a nice one!
Since Scala has closures, you don't need special syntax for this. The
idea is, instead of the programmer writing down "val wr", they write
down the "wri" as a closure parameter, i.e. "wri =>" . Here's the
whole thing:
import java.io._
object UsingExample {
def using[T <: Closeable](obj: T)(user: T=>Unit): Unit = {
user(obj)
obj.close
}
def main(args: Array[String]) = {
using(new FileWriter("test")) {wri =>
wri.write("?")
}
}
}
Notice that using is declared using a parameterized type, so that the
"wri" variable ends up being typed as a FileWriter. If you declared
using using "Closeable", instead of "T <: Closeable", then "wri"
would end up being a "Closeable".
-Lex
Date: January 27, 2006
From: Denis Ivaikin <i.denis@xxxxxxx>
Is it possible to emulate C# "using" in Scala? I'm trying to do the following:
import java.io._;
object Test with Application {
def using(closeable : Closeable)(body: => Unit): Unit = try {
body;
} finally {
closeable.close();
}
var wri = new FileWriter("test"); using(wri) {
wri.write("?");
}
}
It works fine but I'd like to use it like this:
using(val wri = new FileWriter("test")) {
wri.write("?");
}
Is it possible?
Date: January 26, 2006
From: "Judson, Ross" <rjudson@xxxxxxxxxxxxxxxxxx>
Forgot: The code is at http://www.soletta.com/sbaz/Future.html if you feel like looking at it. RJ
Date: January 26, 2006
From: Clive Jevons <clive.jevons@xxxxxxxxxxx>
In-reply-to:
<87d5if6io3.fsf@xxxxxxxxxxxxxxxxxx>
References:
<F418C1909C57A14E9456C8BEA8856345A4FC1B@xxxxxxxxxxxxxxxxxx> <87d5if6io3.fsf@xxxxxxxxxxxxxxxxxx>
Cheers, C On 26 Jan 2006, at 17:46, Lex Spoon wrote:
"Judson, Ross" <rjudson@xxxxxxxxxxxxxxxxxx> writes:On sbaz -- I was wondering if the default port could be moved from 8006to the http default port...at home I can use sbaz fully but at the office I cannot due to firewalls.Well let's figure this out for sure. Sbaz uses HTTP precisely so that it can be used from behind typical office firewalls. I had hoped that typical Java VM's would use the OS's HTTP proxy settings by default. Could you try hacking your "sbaz" script (or sbaz.bat for Windows) and adding to the java command line: -DproxySet=true -Dhttp.proxyHost=YOURHOST -Dhttp.proxyPort=YOURPORT where YOURHOST and YOURPORT are for your office's proxy? If that works, then perhaps there is a global file of system properties that typical JVM's load by default? Does anyone know? If not, then I guess sbaz needs a little configuration file holding the proxy information to use. That, and/or it can sniff around with getenv(). -Lex
Date: January 26, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<F418C1909C57A14E9456C8BEA8856345A4FC1B@xxxxxxxxxxxxxxxxxx>
"Judson, Ross" <rjudson@xxxxxxxxxxxxxxxxxx> writes: > On sbaz -- I was wondering if the default port could be moved from 8006 > to the http default port...at home I can use sbaz fully but at the > office I cannot due to firewalls. Well let's figure this out for sure. Sbaz uses HTTP precisely so that it can be used from behind typical office firewalls. I had hoped that typical Java VM's would use the OS's HTTP proxy settings by default. Could you try hacking your "sbaz" script (or sbaz.bat for Windows) and adding to the java command line: -DproxySet=true -Dhttp.proxyHost=YOURHOST -Dhttp.proxyPort=YOURPORT where YOURHOST and YOURPORT are for your office's proxy? If that works, then perhaps there is a global file of system properties that typical JVM's load by default? Does anyone know? If not, then I guess sbaz needs a little configuration file holding the proxy information to use. That, and/or it can sniff around with getenv(). -Lex
Date: January 26, 2006
From: "Judson, Ross" <rjudson@xxxxxxxxxxxxxxxxxx>
I extended my Futures code to encapsulate Cells (also known as Modifiables,
Calculated values, or Dependent values). The syntax is pretty cool; the
implementation is something of a hack, but it works as long as you play by the
rules. You can more or less write "normal" code for your expressions. When
the value of a Cell is retrieved, it is assumed that the current thread may
"touch" other Cells/Dependents in the process of calculating its value. I keep
a stack of Cells that are calculating themselves on the current thread
(accessible through a ThreadLocal). When a Cell is figuring out its value it
pushes itself on the stack. When other Cells are "read" for their values, they
peek at the top of the stack and add a dependency edge if one does not already
exist. By using the stack only immediate dependencies are stored. This is a
naïve implementation, serving mostly to demonstrate that the resulting syntax
is quite pleasant.
Cells come in two flavors -- Dependent (can't update the expression), and Cell
(can modify the expression). Cells descend from Futures, which descend from
Function0[T].
The big question is...when a cell is marked as "unset", what is the best
strategy for recalculation? Currently it is recalculated the next time it is
accessed, but that strategy should be pluggable so that recalculation can be
"pushed" to an appropriate processor.
Calling the code looks like this:
object FutureTest extends Application {
import Future._;
// Cells can contain arbitrary expressions,
// and those expressions can be altered.
val a = cell(10);
val b = cell(20);
// Formulas calculate their value based on an
// expression, but the expression cannot be changed.
val c = formula(a + b); c.description = "a + b";
val d = cell(a * b - sqr(c)); d.description = "a * b - sqr(c)";
val e = formula(b * c * d); e.description = "b * c * d";
p("initial");
a.update(30); p("a = 30");
b.update(100); p("b = 100");
d.update(sqr(c) - b * 2 + a); d.description = "sqr(c) - b * 2 + a";
p("d formula");
def sqr(i: int) = i * i;
def p(comment: String): unit = {
Console.println(comment + ": ");
p(a,b,c,d,e); Console.println;
}
def p(n: AnyRef*):unit = n.foreach(i => Console.println(i));
}
The output looks like this:
[C:\src]scala2 -classpath classes;\scala1\scala\build\quick\library FutureTest
initial:
Cell([10])
Cell([20])
Formula("a + b" [30])
Cell("a * b - sqr(c)" [-700])
Formula("b * c * d" [-420000])
a = 30:
Cell([30]->2)
Cell([20]->3)
Formula("a + b" 2->[50]->2)
Cell("a * b - sqr(c)" 3->[-1900]->1)
Formula("b * c * d" 3->[-1900000])
b = 100:
Cell([30]->2)
Cell([100]->3)
Formula("a + b" 2->[130]->2)
Cell("a * b - sqr(c)" 3->[-13900]->1)
Formula("b * c * d" 3->[-180700000])
d formula:
Cell([30]->2)
Cell([100]->3)
Formula("a + b" 2->[130]->2)
Cell("sqr(c) - b * 2 + a" 3->[16730]->1)
Formula("b * c * d" 3->[217490000])
Date: January 25, 2006
From: "Judson, Ross" <rjudson@xxxxxxxxxxxxxxxxxx>
Thanks :) I like the unified notion of future values. Now I just need to find something to use it in. On sbaz -- I was wondering if the default port could be moved from 8006 to the http default port...at home I can use sbaz fully but at the office I cannot due to firewalls. -----Original Message----- From: news [mailto:news@xxxxxxxxxxxxx] On Behalf Of Lex Spoon Sent: Tuesday, January 24, 2006 4:00 AM To: scala@xxxxxxxxxxxxxx Subject: Re: Laziness and chained implicit coercions "Judson, Ross" <rjudson@xxxxxxxxxxxxxxxxxx> writes: > This is the future/lazy value code I've been playing with (Scala 2 > syntax). Elegant, work! -Lex
Date: January 24, 2006
From: Nikolay Mihaylov <nikolay.mihaylov@xxxxxxx>
In-reply-to:
<dr4mso$11u$1@xxxxxxxxxxxxx>
References:
<dr4mso$11u$1@xxxxxxxxxxxxx>
Hello
Scala 1.4 compiles mixed in classes from sources. Althought there is a
scala.Application class compiled in scala.dll it is of no use as a mixin
(in fact, it is totally useless because even extending it doesn't make
the object executable - Scala 1.4 only creates the appropriate static
method forwarders for methods declared in the object or mixed in). The
problem is that Scala only ships with the sources of the JVM version of
the library. As you can see, scala.Application contains references to
java.lang which does not exist on .NET. You can (1) modify
scala/Application.scala and remove all Java references, (2) write the
main function yourself
object Test {
def main(args: Array[String]): Unit = {
Console.WriteLine("Hello world!");
}
}
or (3) install the J# redistributable package and include references to
vjscor.dll and vjslib.dll with the -r option.
I would do #2. In any case, I consider mixing in scala.Application as
bad style because it forces you to write your code as object-level
statements which are executed in the object constructor. Consequently,
the body of the mixed in main method gets executed only later thus
preventing you from passing any command-line arguments to your object-
level code. Also, all values and variables are effectively fields of the
object instead of local val/vars as one would expect if the same code
resides in the main method.
Hope that helps
Nikolay
On Tue, 2006-01-24 at 10:01 +0200, Niko Korhonen wrote:
> I seem to be unable to compile the simplest Scala programs targeting the
> .NET CLR. I'm running Windows XP with Scala 1.4.0.4 package.
>
> I have copied mscorlib.dll from .NET CLR v1.1 to Scala's lib directory.
> Here is the program I try to compile (it's the example from the Scala
> homepage):
>
> <code>
> import System.Console;
>
> object test with Application {
> Console.WriteLine("Hello world!");
> }
> </code>
>
> I use the command line:
>
> scalac -target:msil -r c:\tools\scala\lib CLRTest.scala
>
> The result is:
>
> <code>
> c:\tools\Scala\bin\..\src\scala\Application.scala:41: value System is
> not a memb er of java.lang
> val executionStart: Long = java.lang.System.currentTimeMillis();
> ^
> c:\tools\Scala\bin\..\src\scala\Application.scala:46: value System is
> not a memb er of java.lang
> if (java.lang.System.getProperty("scala.time") != null)
> ^
> c:\tools\Scala\bin\..\src\scala\Application.scala:47: value System is
> not a memb er of java.lang
> java.lang.System.out.println("[total " +
> ^
> c:\tools\Scala\bin\..\src\scala\Application.scala:48: value System is
> not a memb er of java.lang
> (java.lang.System.currentTimeMillis()
> ^
> four errors found
> </code>
>
> I don't think that I should be missing something crucial at my compile
> procedure, but in case I am, please enlighten me :)
>
> --
> Niko Korhonen
> Software engineer
>
>
Date: January 24, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<43D27B67.40700@xxxxxxxxx>
John Williams <jrw@xxxxxxxxx> writes: > The link to <http://scala.epfl.ch/nsc/files/Changes.pdf> from > <http://scala.epfl.ch/nsc/> is broken. Also I couldn't find any way > to send bug reports without subscribing to this mailing list. The link works for me. Could you try again? It's a very useful document, so you'll want to grab it if you are playing with Scala. To post bug reports into the central bug-tracking system, go to scala.epfl.ch and click in the left-hand column on "Reporting a Bug". -Lex
Date: January 24, 2006
From: Niko Korhonen <niko.korhonen@xxxxxxxxx>
I seem to be unable to compile the simplest Scala programs targeting the
.NET CLR. I'm running Windows XP with Scala 1.4.0.4 package.
I have copied mscorlib.dll from .NET CLR v1.1 to Scala's lib directory.
Here is the program I try to compile (it's the example from the Scala
homepage):
<code>
import System.Console;
object test with Application {
Console.WriteLine("Hello world!");
}
</code>
I use the command line:
scalac -target:msil -r c:\tools\scala\lib CLRTest.scala
The result is:
<code>
c:\tools\Scala\bin\..\src\scala\Application.scala:41: value System is
not a memb er of java.lang
val executionStart: Long = java.lang.System.currentTimeMillis();
^
c:\tools\Scala\bin\..\src\scala\Application.scala:46: value System is
not a memb er of java.lang
if (java.lang.System.getProperty("scala.time") != null)
^
c:\tools\Scala\bin\..\src\scala\Application.scala:47: value System is
not a memb er of java.lang
java.lang.System.out.println("[total " +
^
c:\tools\Scala\bin\..\src\scala\Application.scala:48: value System is
not a memb er of java.lang
(java.lang.System.currentTimeMillis()
^
four errors found
</code>
I don't think that I should be missing something crucial at my compile
procedure, but in case I am, please enlighten me :)
--
Niko Korhonen
Software engineer
Date: January 24, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<F418C1909C57A14E9456C8BEA885634507DD19@xxxxxxxxxxxxxxxxxx>
"Judson, Ross" <rjudson@xxxxxxxxxxxxxxxxxx> writes: > This is the future/lazy value code I've been playing with (Scala 2 > syntax). Elegant, work! -Lex
Date: January 23, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<20060120122041.ym2q4vd4ery80ck4@xxxxxxxxxxxx> <87zmlnz4zx.fsf@xxxxxxxxxxxxxxxxxx>
> joel@xxxxxxxxxxxx writes: > > The Fowler article is here: > > http://www.martinfowler.com/bliki/AnemicDomainModel.html Ah yes, that does sound lame. Why make a whole extra layer of objects on top of your low-level data representation, if you aren't going to add some methods, too? You may as well just leave out such a layer. In general, Scala does not seem to have commited to any particular components or layering approach. If you are happy using "POJO's", as Martin Fowler calls them, then surely you would also be happy using "POSO's" :) . (And, for completeness, you can probably use J2EE stuff with Scala if you really want to; I don't know if anyone has tried, though....) Thanks for all the comments, Joel! -Lex
Date: January 23, 2006
From: Martin Odersky <martin.odersky@xxxxxxx>
In-reply-to:
<dr1ac5$g1l$1@xxxxxxxxxxxxx>
References:
<dq881r$p4r$1@xxxxxxxxxxxxx> <43CFD527.9000309@xxxxxxx> <dr1ac5$g1l$1@xxxxxxxxxxxxx>
Gabriel Riba wrote:
I have realized that the syntax '${' <expr> '}' is used to embed short
expressions in *ML frameworks that, like JSP, have other means to include
multiline code
while '{' <expr> '}' seems mainly used in frameworks that want to fit in a
"multiline" code block(s), eg XQuery, Javascript XML extension,
Cheers -- Martin
Date: January 23, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<20060120122041.ym2q4vd4ery80ck4@xxxxxxxxxxxx>
joel@xxxxxxxxxxxx writes: > The Fowler article is here: > http://www.martinfowler.com/bliki/AnemicDomainModel.html Thanks! I look forward to reading it. > Enterprise Java: > > I should of empasized "enterprise" (and possibly "Java"), when I said OOP > doesn't happen. The EJB model and reference implementations [...] I see what you are saying now. I actually don't know these tools in detail, so it's very helpful to get word from a thoughtful person enmeshed in the industry. > I think part of the solution could be to > use a language with multi-methods (does Scala support multimethods?), so you > can separate XML concern from domain classes. See here: > http://nice.sourceforge.net/visitor.html. Scala has a pattern matcher that looks like it would help here, though it does not have multi-methods per se. Here is the prettyPrint example done in stylistic Scala: def prettyPrint(e: Expression): String = e match { case AddExp(e1, e2) => prettyPrint(e1) + " + " + prettyPrint(e2) case IntExp(n) => n.toString() } The complete example code is appended. One note here is that the above example is particularly short because AddExp and IntExp are "case" classes, a facility of Scala for dealing with small data-like object such as nodes in a binary tree. The pattern matcher still works, though, for non-case classes: def prettyPrint(e: Expression): String = e match { case ae: AddExp => prettyPrint(ae.e1) + " + " + prettyPrint(ae.e2) case ie: IntExp => ie.n.toString() } The other note I'll toss in is that this pattern matcher can match against XML documents.... -Lex ==== ExpressionsExample.scala ==== object ExpressionsExample { abstract class Expression case class AddExp(e1: Expression, e2: Expression) extends Expression case class IntExp(n: int) extends Expression def prettyPrint(e: Expression): String = e match { case AddExp(e1, e2) => prettyPrint(e1) + " + " + prettyPrint(e2) case IntExp(n) => n.toString() } def main(args: Array[String]) = { Console.println(prettyPrint(AddExp(AddExp(IntExp(1),IntExp(2)),IntExp(3)))) } }
Date: January 23, 2006
From: "Gabriel Riba" <griba2010@xxxxxx>
References:
<dq881r$p4r$1@xxxxxxxxxxxxx> <43CFD527.9000309@xxxxxxx>
"Martin Odersky" <martin.odersky@xxxxxxx> ha escrit en el missatge dels grups de
discussió:43CFD527.9000309@xxxxxxxxxx
> Gabriel Riba wrote:
> > Now that there is a new big version change ahead (scala2)
> > I would vote for a change in the syntax for xml embedded code
> > from actual pair of curly braces
> > {<expr>}
> > to the more traditional and widely used in other frameworks, dollar
prefixed
> > ${<expr>}
> > so regular text curly braces, actually "{{<text>}" doubling the open one
> > could be written as "{<text>}"
> >
> Which frameworks are using ${...}? We modeled our scheme after XQuery,
> which also uses simple {...}.
>
I have realized that the syntax '${' <expr> '}' is used to embed short
expressions in *ML frameworks that, like JSP, have other means to include
multiline code
while '{' <expr> '}' seems mainly used in frameworks that want to fit in a
"multiline" code block(s), eg XQuery, Javascript XML extension,
for short expressions '${<expr>}' is more easyly recognized visually within
xml text than '{<expr>}' because of the two character sequence '${'
but probably I am not aware enough of the Scala language and I should leave
it to
the authors.
Here is a list of some frameworks and their handling of the question.
JSP. Java Server Pages uses the ${<expr>} syntax to embed expressions in
html
http://java.sun.com/products/jsp/syntax/2.0/syntaxref207.html#1010522
LaszloSystems XML component language uses ${<expr>} in attributes
http://www.laszlosystems.com/lps-3.1.1/docs/guide/constraints.html
Struts uses the ${<expr>} syntax too.
http://struts.apache.org/struts-el/struts-el.html
Java Server Faces uses the number-sign prefixed #{<expr>}
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JSFPage10.html#wp119849
but may change to a "Unified Expression Language"
with ${<expr>} for immediate evaluation and #{<expr>} for late eval.
http://java.sun.com/products/jsp/reference/techart/unifiedEL.html
Zope Template language uses ${<path>}
http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/AppendixC.stx#3-173
Coldfusion uses #<expr># like in
<CFOUTPUT>#Request.field_name1#</CFOUTPUT>
http://www.macromedia.com/v1/documents/cf4/AcrobatDocs/40quickref.pdf
--------
XQuery FLWOR expressions use {<expr>}
http://www.w3.org/TR/2005/WD-xquery-20050915/#id-flwor-expressions
Javascript's XML extension (ECMA-357) uses the braces {<expr>} as in Scala
http://www.ecma-international.org/publications/standards/Ecma-357.htm
Microsoft XAML uses {<expr>} in attributes
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnintlong/html/longhornch03.asp
Microsoft Comega will use {<expr>} in XML
http://research.microsoft.com/Comega/doc/comega_whatis.htm
--------
Cheers!
Gabriel Riba.
Date: January 21, 2006
From: John Williams <jrw@xxxxxxxxx>
--jw
Date: January 21, 2006
From: Nathan Sobo <nathansobo@xxxxxxxxx>
Hi. I just picked up Scala a few days ago and it's looking awesome. I was hoping to get some feedback on the best way to employ the existing XML tools in solving a problem. My plan is to link the structure of a document as defined in a DTD to the code necessary to construct each fragment of the document. Rather than querying against an actual document, the user would specify an Xpath against the virtual document, which would locate and execute functions to build what they requested. This way, I can make a hairy legacy database look like a collection of XML documents to the outside world, but only construct those fragments of the document that are needed. Any tips on the best approach in Scala? Thanks!
Date: January 21, 2006
From: "Judson, Ross" <rjudson@xxxxxxxxxxxxxxxxxx>
This is the future/lazy value code I've been playing with (Scala 2
syntax).
RJ
package scalax.future;
/** A Future is a function of arity 0 that returns a value of type T.
It can be queried to find out if the value is available, if a failure
has occurred, and what the failure is, if failure happened. If the
value of the future is retrieved and a failure results, the failure
exception is thrown. */
mixin class Future[T] extends Function0[T] {
def isSet: boolean;
def isFailure: boolean;
def failure: Throwable;
}
/** A Promise is a placeholding Future, where the result
of the computation can be set externally. */
mixin class Promise[T] extends Future[T] {
def set(t: T): unit;
def fail(ex: Throwable): unit;
def future: Future[T];
}
object Future {
/** Implicitly convert arbitrary values of T into a Future[T]. */
implicit def lazyConst[T](t: T): Future[T] = LazyConst(t);
/** Retrieve the value, which may result in forcing the value if it is
not already available. */
implicit def fromFuture[T](lz: Future[T]): T = lz();
/** We want to be able to treat our lazy values like regular values
when we're iterating over them, and so forth. We define a kind of
"reverse lifter" here that wraps a function on T into a function on
Future[T]. */
implicit def lazyLift[T,B](tfunc: (T) => B): (Future[T]) => B = (lt)
=> tfunc(lt());
/** Directly construct a lazy value of type T. Note that using the
anonymous class this way seems to be the simplest way to prevent
execution of "f" until we really mean to, and still keep it around
cleanly. */
def lazy[T](f: => T): Future[T] = new Lazy[T] {
def func: T = f;
}
/** Create a future that is failed from the start. */
def fail[T](ex: Throwable): Future[T] = Failed(ex);
/** Build a concurrent future, starting a thread to perform the
computation. */
def spawn[T](f: => T): Future[T] = new ExceptionSyncVar[T] {
val thread = new Thread() {
override def run() = {
try {
set(f)
} catch {
case ex: Throwable => fail(ex)
}
Console.println("Spawn done");
}
}
thread.start
}
/** Build a promise for a future value; the promise can be fulfilled
on this or any other thread. A thread getting the value will
block
if the promise has not been fulfilled. */
def promise[T]: Promise[T] = new ExceptionSyncVar[T] with Promise[T] {
def future = this;
override def toString = createString("Promise");
}
}
mixin class Executor {
def run(f: => unit): unit;
def run[A](f: A => unit)(a: A): unit = run( f(a) );
def run[A,B](f: (A, B) => unit)(a: A, b: B): unit = run( f(a,b) );
def run[A,B,C](f: (A, B, C) => unit)(a: A, b: B, c: C): unit = run(
f(a,b,c) );
def submit[T](f: => T): Future[T];
def submit[A,T](f: A => T)(a: A): Future[T] = submit( f(a) );
def invokeAll[T](tasks: Function0[T]*): Seq[Future[T]];
def invokeAny[T](tasks: Function0[T]*): T;
def isShutdown: boolean;
def isTerminated: boolean;
def shutdown: unit;
def shutdownNow: unit;
}
object Executors {
}
private class ExceptionSyncVar[T] extends Future[T] {
private var ex: Throwable = _;
private var isDefined: Boolean = false;
private var value: T = _;
def failure = ex;
override def apply() = get;
def isFailure = isDefined && (ex != null);
def set(x: T) = synchronized {
value = x
isDefined = true
notifyAll()
}
def fail(e: Throwable): unit = synchronized {
ex = e
isDefined = true
notifyAll()
}
def isSet: Boolean = synchronized {
isDefined
}
def get = synchronized {
if (!isDefined) wait();
if (ex != null) throw ex;
value
}
override def toString = createString("ESync");
def createString(head: String) =
if (!isDefined) head + "(?)"
else if (ex != null) head + '(' + ex + ')'
else head + '(' + value + ')';
}
private abstract class Lazy[T] extends ExceptionSyncVar[T] {
def func: T;
override def get: T = synchronized {
if (!isSet)
try {
val ret = func;
set(ret);
ret
} catch {
case e: Throwable => fail(e)
throw e;
}
else
super.get
}
override def toString() = createString("Lazy");
}
private case class Failed[T](ex: Throwable) extends Future[T] {
def apply(): T = throw ex;
def failure = ex;
def isFailure = true;
def isSet = true;
}
private case class LazyConst[T](v: T) extends Future[T] {
def apply() = v;
override def failure = null;
def isFailure = false;
def isSet = true;
}
Date: January 20, 2006
From: joel@xxxxxxxxxxxx
The Fowler article is here: http://www.martinfowler.com/bliki/AnemicDomainModel.html Enterprise Java: I should of empasized "enterprise" (and possibly "Java"), when I said OOP doesn't happen. The EJB model and reference implementations (Pet shop) give examples of Transaction scripts, and discourage rich domains (try putting behavior on a CMP bean for instance). This is changing of late with EJB 3. The reason I can say it doesn't happen is current J2EE doesn't support it, starting from JSP down to EJB 2. Ability to do true OOP has largely been open-source (I'd point to Tapestry, Cayenne, and WebObjects which came from Objective-C over to Java). So, if you were doing OO with persistence you weren't mainstream. I do think that is changing currently. XML: I think your approach on XML is the correct one, however the current tools to map directly to your domain classes in Java are very poor (Toplink and Jibx are the only ones I know that come close). I think part of the solution could be to use a language with multi-methods (does Scala support multimethods?), so you can separate XML concern from domain classes. See here: http://nice.sourceforge.net/visitor.html. Interesting discussion. Joel From: Lex Spoon <lex <at> cc.gatech.edu> Subject: Re: Hello / First Impressions Newsgroups: gmane.comp.lang.scala Date: 2006-01-20 10:35:31 GMT (9 hours and 21 minutes ago) joel <at> harpsoft.com writes: > I see that the main premise behind Scala is to solve enterprise software type > problems with better XML parsing and Servlet support. I don't disagree > that may > be useful, but strongly feel that neither is the number one issue with > enterprise software / Java. The number one issue is that OOAD/OOP is not > followed by and large for enterprise software even in Java. The vast majority > consists of an Anemic Domain Model written with biz logic in Transaction > Scripts (re: Martin Fowler article). I see EJB mentioned on site as OO, when > it's really again transaction scripts. I hesitate to say that successful software engineers are en masse doing completely the wrong thing. I grant that I'm not involved in it personally. But let's take a moment and speculate on why the practitioners may be doing something different than scholars and philosophers recommend. One simple is that they embrace the philosophy that the design is in the code somewhere, that the meeaning is in the software. This approach has advantages. For example, the software gets routinely tested and thus gets really felt out. Also, it allows for an extremely iterative approach to deciding what exactly the domain model should be. At the language level, Gerald Sussman and Alan Kay seem interested in this view. For software engineering, Kent Beck and the XP crowd seem to lean towards it. But it's just a speculation. Stepping back again, I'll say that being a complete hack monster cowboy certainly sounds wrong. On the other hand, it also sounds wrong to dismiss code as a place to put domain models. Code is a terrific formal specification for semantic notions. Maybe you can give some more specific examples? Or, maybe you can insist that everyone go read this Martin Fowler article! > If a language can make it easy to avoid anemic domain models, I think a real > problem is solved, and I think Scala may fit that solution well. The problem > crops up a lot because you have to fetch data from systems, but typically have > little control over assigning behavior to the "data classes", because they are > either generated (like XMLBeans), or map into generic classes (ie. DOM). So > Scala XML parsing does help in this regard, but what happens if you parse the > same data in two differing XML (or other) formats? Which classes do > you put the > behavior? Man there is a lot of talk about XML on this list the last week or two. I'll just toss in that my working strategy, which seems to go well for a few years now, is to have little functions mapping my domain model into and out of XML and/or s-expressions, depending on the specific wire format. Into XML is done with a toXML method, while out of it is done with a fromXML method in an appropriate library -- often with a big case statement switching on the top-level tag in the XML node. I have found this strategy to work fine. It lets me have a real domain model in my application, while communicating using a very flexible low-level encoding. The programs my code communicates with can perfectly well have a slightly different domain model, but that is a strength, too: it allows the domain model to shift over time, and it allows the domain model to be tweaked based on the subjective needs of each program. XML's semantic poverty loosens coupling and thus allows more communication. Philosophy aside, I wouldn't insist that XML per se is the exact level to work at. It looks like something *like* schemas and dtd's can help to increase the level of abstraction just slightly and improve things overall, but I don't know the XML acronym soup well enough to say which exact tools are the best way to go. > Another problem is meta-information in enterprise apps. The bean > property names > are interesting as anything else if for no other reason doing queries (not to > mention validation and security). So I'm curious how you go about your > proposed > O/R solutions as I saw on the site. Is this developed/documented more > anywhere? > Please let me know. No idea on this. -Lex
Date: January 20, 2006
From: "Judson, Ross" <rjudson@xxxxxxxxxxxxxxxxxx>
I implemented the four basic future types outlined in AliceML's documentation -- concurrent, lazy, promised, and failed...sort of a neat exercise in Scala. For laziness I used the trick Matthias Zenger outlined -- the nested-class-calls-def bit. Seems to work fine. The implicit keyword worked fine for creating conversion functions that would move in and out of future values. If we could combine pattern matching and laziness it'd be a lot easier to adapt Haskell code. ;) Plus there's the "where" clause in pattern matching that always requires code rearrangement. It's quite short so I'll try and post it to the list tonight for comment. RJ
Date: January 20, 2006
From: Martin Odersky <martin.odersky@xxxxxxx>
In-reply-to:
<loom.20060120T132035-992@xxxxxxxxxxxxxx>
References:
<loom.20060120T132035-992@xxxxxxxxxxxxxx>
Hi Adriaan: There are several arguments against chaining of conversions:1. Algorithmic: Since the space of types reachable by conversions is infinite, how do you find a conversion path between two types without the possibility of looping?
2. Ambiguities: How do you detect multiple possible paths and if you do, which path do you choose?
3. Avoiding surprising coercions by some path a user had not thought about.However, conversions can be nested. For instance, an implicit conversion function might take another conversion function as implicit parameter. This can achieve the same effect, but requires a bit more planning by the library designer. In your example, I can force chaining of the forceLazy and int2string conversions by defining the latter as follows:
implicit def int2string[T](x: T)(implicit toInt: T => int): String =
toInt(i).toString
or, equivalently, by using a view bound:
implicit def int2string[T <% int](x: T): String = (i: int).toString
Btw: Please consider to make the library available as an sbaz package
when it is done.
Cheers -- Martin
Date: January 20, 2006
From: Adriaan Moors <adriaan@xxxxxxxxxxxxxx>
Hi,
I've been experimenting with implementing Packrat parsers [3] in Scala and, in
trying to get the Scala version to mimick the original Haskell implementation as
closely as possible, I tried to implement a class Lazy[T] that encapsulates
memoisation and call-by-name evaluation. (By the way I was thrilled to
see Scala supports everything -- except true laziness ;-) -- to make porting
this kind of code from Haskell to Scala almost trivial.)
My goal was to write a class and some implicit coercions, so that, for an
argument to be passed lazily, a method simply has to define that argument as
having type Lazy[T] instead of type T. The implicit coercion makeLazy was
supposed to take care of this. On the other hand, when we want the actual
value,
the forceLazy coercion returns the actual value when something of type T was
expected. In the case of method invocation on a lazy value, this amounts to
delegating methods not found in Lazy[T] to the value of type T (Lazy[T]
overrides some standard methods from Any so that they are also delegated
to the forced value).
This is the code for the class and a small main method that demonstrates its
use
and the problems I encountered. (I also found an older post on this mailing
list
with a similar implementation [1]) Ideally, this code should work as-is, but
currently, you have to uncomment the xxxxLazy calls.
object laziness {
implicit def forceLazy[T](stub :Lazy[T]) :T = stub.__force
// the makeLazy-coercion requires the special coercion of T to => T,
// but coercions are never combined --> maybe make an exception for the
// call-by-name coercion?
implicit def makeLazy[T](stub : => T) :Lazy[T] = new Lazy[T](stub)
class Lazy[T]( stub: => T) {
private var memo :T = _
private var memoed :Boolean = false
def __force :T = {if(!memoed) { memo = stub; memoed = true}; memo}
// override methods in Any and (manually) delegate to forced stub
override def equals(other :Any) :Boolean = __force.equals(other)
override def hashCode() :Int = __force.hashCode
override def toString() :String = __force.toString
// it's a pitty you can't override this anymore:
//override def match[a, b](cases: a => b): b = __force.match(cases)
// can't override reference equality
}
implicit def int2string(i :Int) :String = i.toString
def main(args :Array[String]) :Unit = {
def loop(a :Int) :Int = loop(a)
def nonstrict(a :Lazy[Int]) :Int = 42
def strict(a :Lazy[Int]) :String = /*forceLazy(*/a/*)*/
def strict2(a :Lazy[Int]) :String = /*forceLazy(*/a/*)*/ match {
case 0 => "zero!"
case _ => /*int2string(*/a/*)*/ }
System.out.println(nonstrict(/*makeLazy(*/loop(13)/*)*/))
System.out.println(strict(/*makeLazy(*/loop(13)/*)*/))
System.out.println("Ceci is not printed...")
}
}
In fact, Scala's only limitation (I think) here is that coercions are not
chained. I'm sure there is a good reason for this, but I was wondering if this
rule could be relaxed so that (at least) the built-in T to => T coercion can be
chained to another coercion (such as the makeLazy coercion). Another (slightly
less important) example of chained coercions can be seen in the strict method,
where the forceLazy and the int2string coercion should be chained. Finally (in
the strict2 method), it would be nice if pattern matching could be used to
force
a lazy value, just like in Haskell.
More generally, I'm interested in what the rationale is behind disallowing
chaining of coercions (is it just that the resulting search space is too big?).
I haven't studied this problem much (although [2] is ranked high on my TODO-
list), but I'm very interested to hear what your opinion is on this.
greetings,
adriaan
[1] Matthias Zenger. Re: lazy evaluation. The Scala Mailing list, 2004.
(http://article.gmane.org/gmane.comp.lang.scala/241)
[2] John C. Reynolds. Using Category Theory to Design Implicit Conversions and
Generic Operators. In Semantics Directed Compiler Generation. LNCS 94, 1980.
(http://www.daimi.au.dk/~nygaard/CTfCS/papers/reynolds1.pdf)
[3] Bryan Ford. Packrat Parsing: a Practical Linear-Time Algorithm with
Backtracking. Master's Thesis, MIT, 2002.
(http://pdos.csail.mit.edu/~baford/packrat/thesis/)
Date: January 20, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<20060118212145.jws3d9it7dkcc0os@xxxxxxxxxxxx> <20060119145051.pjkc9ksrsqeooc40@xxxxxxxxxxxx>
joel@xxxxxxxxxxxx writes: > I see that the main premise behind Scala is to solve enterprise software type > problems with better XML parsing and Servlet support. I don't disagree > that may > be useful, but strongly feel that neither is the number one issue with > enterprise software / Java. The number one issue is that OOAD/OOP is not > followed by and large for enterprise software even in Java. The vast majority > consists of an Anemic Domain Model written with biz logic in Transaction > Scripts (re: Martin Fowler article). I see EJB mentioned on site as OO, when > it's really again transaction scripts. I hesitate to say that successful software engineers are en masse doing completely the wrong thing. I grant that I'm not involved in it personally. But let's take a moment and speculate on why the practitioners may be doing something different than scholars and philosophers recommend. One simple is that they embrace the philosophy that the design is in the code somewhere, that the meeaning is in the software. This approach has advantages. For example, the software gets routinely tested and thus gets really felt out. Also, it allows for an extremely iterative approach to deciding what exactly the domain model should be. At the language level, Gerald Sussman and Alan Kay seem interested in this view. For software engineering, Kent Beck and the XP crowd seem to lean towards it. But it's just a speculation. Stepping back again, I'll say that being a complete hack monster cowboy certainly sounds wrong. On the other hand, it also sounds wrong to dismiss code as a place to put domain models. Code is a terrific formal specification for semantic notions. Maybe you can give some more specific examples? Or, maybe you can insist that everyone go read this Martin Fowler article! > If a language can make it easy to avoid anemic domain models, I think a real > problem is solved, and I think Scala may fit that solution well. The problem > crops up a lot because you have to fetch data from systems, but typically have > little control over assigning behavior to the "data classes", because they are > either generated (like XMLBeans), or map into generic classes (ie. DOM). So > Scala XML parsing does help in this regard, but what happens if you parse the > same data in two differing XML (or other) formats? Which classes do > you put the > behavior? Man there is a lot of talk about XML on this list the last week or two. I'll just toss in that my working strategy, which seems to go well for a few years now, is to have little functions mapping my domain model into and out of XML and/or s-expressions, depending on the specific wire format. Into XML is done with a toXML method, while out of it is done with a fromXML method in an appropriate library -- often with a big case statement switching on the top-level tag in the XML node. I have found this strategy to work fine. It lets me have a real domain model in my application, while communicating using a very flexible low-level encoding. The programs my code communicates with can perfectly well have a slightly different domain model, but that is a strength, too: it allows the domain model to shift over time, and it allows the domain model to be tweaked based on the subjective needs of each program. XML's semantic poverty loosens coupling and thus allows more communication. Philosophy aside, I wouldn't insist that XML per se is the exact level to work at. It looks like something *like* schemas and dtd's can help to increase the level of abstraction just slightly and improve things overall, but I don't know the XML acronym soup well enough to say which exact tools are the best way to go. > Another problem is meta-information in enterprise apps. The bean > property names > are interesting as anything else if for no other reason doing queries (not to > mention validation and security). So I'm curious how you go about your > proposed > O/R solutions as I saw on the site. Is this developed/documented more > anywhere? > Please let me know. No idea on this. -Lex
Date: January 20, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<671EC7F9-56C8-45FD-904C-14EC8ACCE17C@xxxxxxxxxxx>
Clive Jevons <clive.jevons@xxxxxxxxxxx> writes:
> My question is whether I can do this with a proper comprehension -
> I've tried the following, but can't get the types to match up:
>
> val proTestMultiplier = new RuleTransformer(
> new RewriteRule () {
> override def transform (n: Node): Seq[Node] = n match {
> case e @ <IDorKonfig /> if (e.attribute("name") ==
> "ProTest") =>
> for (val count <- Iterator.range(0, 100)) yield
> changeAttribute("name", "ProTest" +
> count.toString()).transform(e);
> case _ => n
> }
> }
> );
The idea is great, but there are two problems.
The first issue is that an Iterator is weaker than a full-blown
sequence and is not really enough. So, use List.range instead of
Iterator.range .
(As an aside, an Interval class would seem nice for cases like
these....)
After that, you have an issue because transform(e) yields a *Seq* of
nodes, not a single node. Thus, the for yields a list of lists of
nodes, not simply the list of nodes that you want from the function.
To deal with this, you could use List.flatten, but a more elegant
approach is to use a second clause of the for comprehension that
iterates of the answer from transform(e).
The final result looks like this:
val proTestMultiplier2 = new RuleTransformer(
new RewriteRule () {
override def transform (n: Node): Seq[Node] = n match {
case e @ <IDorKonfig /> if (e.attribute("name") ==
"ProTest") =>
for (val count <- List.range(0, 100);
val node <-
changeAttribute("name", "ProTest" +
count.toString()).transform(e).toList)
yield node
case _ => n
}
}
);
This is a good example of a place to use for comprehensions -- good intuition!
-Lex
Date: January 19, 2006
From: joel@xxxxxxxxxxxx
In-reply-to:
<20060118212145.jws3d9it7dkcc0os@xxxxxxxxxxxx>
References:
<20060118212145.jws3d9it7dkcc0os@xxxxxxxxxxxx>
Scala looks pretty cool. I'm going to give it a try. I really think that the major strong-point is (or could be) the Views. Javacould really use such a facility, in fact it's the reason I found Scala. I read
Objective-C, Dylan, ML, and Nice have a similar features, but I really wantedsomething that could potentially work with Java (Nice does look really nice but
dead too). I see that the main premise behind Scala is to solve enterprise software typeproblems with better XML parsing and Servlet support. I don't disagree that may
be useful, but strongly feel that neither is the number one issue with enterprise software / Java. The number one issue is that OOAD/OOP is not followed by and large for enterprise software even in Java. The vast majority consists of an Anemic Domain Model written with biz logic in Transaction Scripts (re: Martin Fowler article). I see EJB mentioned on site as OO, when it's really again transaction scripts. If a language can make it easy to avoid anemic domain models, I think a real problem is solved, and I think Scala may fit that solution well. The problem crops up a lot because you have to fetch data from systems, but typically have little control over assigning behavior to the "data classes", because they are either generated (like XMLBeans), or map into generic classes (ie. DOM). So Scala XML parsing does help in this regard, but what happens if you parse thesame data in two differing XML (or other) formats? Which classes do you put the
behavior?I like the idea that I can put methods on existing classes (Views), I think that
goes a ways toward solving the data/object impedance problem. I see Microsoft working in this direction with Partial Objects, and I think it's a partial solution as well.Another problem is meta-information in enterprise apps. The bean property names
are interesting as anything else if for no other reason doing queries (not tomention validation and security). So I'm curious how you go about your proposed O/R solutions as I saw on the site. Is this developed/documented more anywhere?
Please let me know. Anyway, thanks for the good work. I hope Scala goes places. Cheers, Joel
Date: January 19, 2006
From: Martin Odersky <martin.odersky@xxxxxxx>
In-reply-to:
<dq881r$p4r$1@xxxxxxxxxxxxx>
References:
<dq881r$p4r$1@xxxxxxxxxxxxx>
Gabriel Riba wrote:
Now that there is a new big version change ahead (scala2)
I would vote for a change in the syntax for xml embedded code
from actual pair of curly braces
{<expr>}
to the more traditional and widely used in other frameworks, dollar prefixed
${<expr>}
so regular text curly braces, actually "{{<text>}" doubling the open one
could be written as "{<text>}"
Cheers -- Martin
Date: January 19, 2006
From: Stéphane Micheloud <stephane.micheloud@xxxxxxx>
Dear Scala users, Version 1.4.0.4 of Scala is now available from the Scala website. http://scala.epfl.ch/downloads/changes.htmlDevelopment efforts now focus on the upcoming release of Scala 2 (planned for end of February 2006).
Regards --The Scala team
Date: January 19, 2006
From: Clive Jevons <clive.jevons@xxxxxxxxxxx>