Custom Search
|
Date: March 31, 2006
From: Jason Carreira <jcarreira@xxxxxxxxx>
References:
<3EB92C4A-9941-4DFE-BA68-298991D52DA6@xxxxxxxxx> <Pine.LNX.4.63.0603302210050.12898@xxxxxxxxxxxxx> <3CF8C89F-937C-4B80-92A9-942F0663FFD2@xxxxxxxxxxxxxx>
Adriaan Moors <adriaan.moors <at> cs.kuleuven.be> writes: > > > On 30 Mar 2006, at 22:27, Vincent Cremet wrote: > > It works also for encoding monads. > As an example of another use-case, see my post (of 27 March) on > encoding datatype generic programming > > adriaan > > I don't see your Scala source for the examples from that paper in the gmane archive... Can you send them to me (jcarreira at gmail.com)? I've been reading through it, and the Haskell syntax is getting in the way. Thanks very much! Jason
Date: March 31, 2006
From: martin odersky <martin.odersky@xxxxxxx>
In-reply-to:
<Pine.LNX.4.63.0603302210050.12898@xxxxxxxxxxxxx>
References:
<3EB92C4A-9941-4DFE-BA68-298991D52DA6@xxxxxxxxx> <Pine.LNX.4.63.0603302210050.12898@xxxxxxxxxxxxx>
Vincent Cremet wrote:
Hi,
currently there is no special syntax for higher-order type parameters
in Scala. But we discovered some time ago we can sometimes translate
them using type members. Actually the usual translation scheme that
converts type parameters into type members works in the case of your
program. It works also for encoding monads. The translation relies on
the possibility of having abstract type members with refinements, like
the type t.Fn{type Elem = Foo} below. We are now convinced that this
feature is safe (modulo some minor complications due to the null
value) but to my knowledge it is not part of the Scala reference. For
now it is a hidden bonus of the compiler. :-)
Actually, this is now officially allowed by the final Scala-2 reference. -- Martin
Date: March 30, 2006
From: Adriaan Moors <adriaan.moors@xxxxxxxxxxxxxx>
In-reply-to:
<Pine.LNX.4.63.0603302210050.12898@xxxxxxxxxxxxx>
References:
<3EB92C4A-9941-4DFE-BA68-298991D52DA6@xxxxxxxxx> <Pine.LNX.4.63.0603302210050.12898@xxxxxxxxxxxxx>
On 30 Mar 2006, at 22:27, Vincent Cremet wrote:
As an example of another use-case, see my post (of 27 March) on encoding datatype generic programmingIt works also for encoding monads.
adriaan
Date: March 30, 2006
From: Vincent Cremet <vincent.cremet@xxxxxxx>
In-reply-to:
<3EB92C4A-9941-4DFE-BA68-298991D52DA6@xxxxxxxxx>
References:
<3EB92C4A-9941-4DFE-BA68-298991D52DA6@xxxxxxxxx>
Hi,
currently there is no special syntax for higher-order type parameters
in Scala. But we discovered some time ago we can sometimes translate
them using type members. Actually the usual translation scheme that
converts type parameters into type members works in the case of your
program. It works also for encoding monads. The translation relies on
the possibility of having abstract type members with refinements, like
the type t.Fn{type Elem = Foo} below. We are now convinced that this
feature is safe (modulo some minor complications due to the null
value) but to my knowledge it is not part of the Scala reference. For
now it is a hidden bonus of the compiler. :-)
--------------------------------------------------
abstract class Seq {
type Elem;
}
abstract class TypeOp {
type Fn <: Seq;
}
abstract class Foo {
val t: TypeOp;
val children: t.Fn{type Elem = Foo};
}
abstract class Bar {
val t: TypeOp;
val elements : t.Fn{type Elem = Bar};
}
--------------------------------------------------
Vincent.
On Thu, 30 Mar 2006, Alan Lawrence wrote:
Hi,is there any way to have a 'type'-like member (of an object or class), which stores a type operator (like scala.Seq), rather than a type (like e.g. scala.Seq[int] or scala.Seq[String])? Are there any plans to add this feature to the language? I have an application in which I want to pass around such type operators as fields of objects, so e.g. I can writeclass TypeOp { type Fn <: Seq; } class Foo(t : TypeOp) { val children: t.Fn[Foo]; } class Bar(t : TypeOp) { val elements : t.Fn[Bar]; }Alternatively if anyone can see a way of doing this with abstract type members / path-dependent types / etc., then that would be great!Thanks, Alan. ---------- "It is a mistake to confound strangeness with mystery" --Sherlock Holmesttt
Date: March 30, 2006
From: Alan Lawrence <acl33@xxxxxxxxx>
Hi,is there any way to have a 'type'-like member (of an object or class), which stores a type operator (like scala.Seq), rather than a type (like e.g. scala.Seq[int] or scala.Seq[String])? Are there any plans to add this feature to the language? I have an application in which I want to pass around such type operators as fields of objects, so e.g. I can write
class TypeOp {
type Fn <: Seq;
}
class Foo(t : TypeOp) {
val children: t.Fn[Foo];
}
class Bar(t : TypeOp) {
val elements : t.Fn[Bar];
}
Alternatively if anyone can see a way of doing this with abstract
type members / path-dependent types / etc., then that would be great!
Thanks, Alan.
----------
"It is a mistake to confound strangeness with mystery"
--Sherlock Holmesttt
Date: March 30, 2006
From: "Judson, Ross" <rjudson@xxxxxxxxxxxxxxxxxx>
I've created an initial port of The Reasoned Schemer's Mini Kanren core
into Scala. The core is less than 100 lines of code, and I think you'll
find it quite readable compared to the macro-intensive Scheme version :)
val c:Var = fresh
val k = run('q,
eq(c, 'b),
eq('q, c),
conde(eq('b, 10)))
for (val r <- k.lst) Console.println("Q -> " + r)
Produces:
Q -> Value(10)
Note that symbols are transformed with views to Vars. "fresh" creates
new anonymous variables.
A tiny logic library (3k) like this is certainly nice to have for some
problems (like GUI creation and arrangement). I can't quite figure out
what kind of syntax would be the most natural and simultaneously be
"Scala-like", so I'm quite open to suggestions.
You can see the code on the Scala Wiki at:
http://scala.sygneca.com/code/mini-kanren
RJ
Date: March 29, 2006
From: Stefan Matthias Aust <nobody@xxxxxxxxx>
In-reply-to:
<87wtehndke.fsf@xxxxxxxxxxxxxxxxxx>
References:
<87odzvvec3.fsf@xxxxxxxxxxxxxxxxxx> <442451FB.2040802@xxxxxxx> <87k6aivkdc.fsf_-_@xxxxxxxxxxxxxxxxxx> <4425318C.2040406@xxxxxxx> <87wtehndke.fsf@xxxxxxxxxxxxxxxxxx>
Lex Spoon schrieb: > BTW, here's my best idea so far for a good syntax for multi-line > strings, in both XML texts and in regular strings: > > "def fact(x: int): int = > | if(x == 0) > | 1 > | else > | x*fact(x-1) > | I really like that syntax. Although, I'd expect to see a closing " somewhere. So the last | should probably be a ". -- Stefan Matthias Aust
Date: March 29, 2006
From: Martin Odersky <martin.odersky@xxxxxxx>
There are also the following new tools: - a new `scalac' compiler, which is completely written in Scala - a new `scalaint' interpreter shell, which is integrated with the compiler and which drops most restrictions of the previous version. - a new Eclipse plugin. See http://scala.epfl.ch/docu/eclipse/index.html - a new tool `sbaz' to manage and distribute Scala packages. See http://scala.epfl.ch/downloads/sbaz.html This implementation runs on the Java VM, JDK 1.4 or 1.5. An automatic installer is available for Windows, MacOS X, Linux, Solaris, and most other operating systems. For further information and downloads, please visit: http://scala.epfl.ch
Date: March 29, 2006
From: Jason Carreira <jcarreira@xxxxxxxxx>
References:
<loom.20060329T003501-870@xxxxxxxxxxxxxx> <1143616173.5213.63.camel@xxxxxxxxxxxxxxx> <442A39C8.8060601@xxxxxxx>
Burak Emir <Burak.Emir <at> epfl.ch> writes:
> >> def doRange()(start: int, aggregate: (int, int) => int)(f: int =>
> >> int)(a:
> >>int, b: int): int = {
> >>
>
>
> Note: in this case you should use "val" instead of "def", because you
> only need to build the "sum" function once. The "sum" value can then be
> applied to arguments, like a normal function.
>
> cheers,
> Burak
>
Hey, thanks guys!
That worked great.
Does anyone know the status of the Intellij IDEA plugin for Scala? Syntax error
highlighting and autocomplete would be a lifesaver. I don't think I could code
in Java without them, and I use that everyday, so it's making the learning curve
for Scala longer for me, for sure.
Also, is there a good description of val vs. def and when to use each somewhere?
Thanks again,
Jason
Date: March 29, 2006
From: Burak Emir <Burak.Emir@xxxxxxx>
In-reply-to:
<1143616173.5213.63.camel@xxxxxxxxxxxxxxx>
References:
<loom.20060329T003501-870@xxxxxxxxxxxxxx> <1143616173.5213.63.camel@xxxxxxxxxxxxxxx>
Hi Jason, Nikolay Mihaylov wrote:
Hi Jason On Wed, 2006-03-29 at 00:30 +0000, Jason Carreira wrote:def doRange()(start: int, aggregate: (int, int) => int)(f: int => int)(a: int, b: int): int = {
Nik's comment is pertinent, but additionally, your error message is caused by the fact that you define "doRange()...."
The inital empty parameter block is useless and you can omit it. If you choose to leave it the definition, then... (see below)
def iter(a : int, result : int) : int = { if (a > b) result else iter(a + 1, aggregate(f(a), result)) } iter(a, start) } but this doesn't seem to work for me. When I run it in scalaint and try to define sum() in terms of doRange(), I get this: scala> def sum = doRange(0, (x: int, y: int) => x + y)
...you would have to write val sum: <its type> = doRange()(0, ....)Note: in this case you should use "val" instead of "def", because you only need to build the "sum" function once. The "sum" value can then be applied to arguments, like a normal function.
cheers, Burak
<console>:4 error: wrong number of arguments for method doRange: ()(scala.Int,(scala.Int, scala.Int) => scala.Int)((scal a.Int) => scala.Int)(scala.Int,scala.Int)scala.Int def sum = doRange(0, (x: int, y: int) => x + y)If someone could point me in the right direction it would be really helpful...
-- Burak Emir http://lamp.epfl.ch/~emir
Date: March 29, 2006
From: Nikolay Mihaylov <nikolay.mihaylov@xxxxxxx>
In-reply-to:
<loom.20060329T003501-870@xxxxxxxxxxxxxx>
References:
<loom.20060329T003501-870@xxxxxxxxxxxxxx>
Hi Jason
On Wed, 2006-03-29 at 00:30 +0000, Jason Carreira wrote:
> def doRange()(start: int, aggregate: (int, int) => int)(f: int => int)(a:
> int, b: int): int = {
> def iter(a : int, result : int) : int = {
> if (a > b) result
> else iter(a + 1, aggregate(f(a), result))
> }
> iter(a, start)
> }
>
> but this doesn't seem to work for me. When I run it in scalaint and try to
> define sum() in terms of doRange(), I get this:
>
> scala> def sum = doRange(0, (x: int, y: int) => x + y)
> <console>:4 error: wrong number of arguments for method doRange:
> ()(scala.Int,(scala.Int, scala.Int) => scala.Int)((scal
> a.Int) => scala.Int)(scala.Int,scala.Int)scala.Int
> def sum = doRange(0, (x: int, y: int) => x + y)
>
> If someone could point me in the right direction it would be really
> helpful...
In Scala2 you can partially apply a function only if it's type (after
the partial application) matches the expected type. You cannot rely on
type inference for the type of a definition, you have to write it
yourself:
def sum: (int=>int)=>(int,int)=>int = doRange(0, (x, y) => x + y)
In general, the type of curried definition (using single parameters
without loss of generality)
def foo(x1: T1)(x2: T2)...(xn: Tn): T
is
T1=>T2=>...=>Tn=>T
where '=>' assoiciates to the right (that's why the type of sum's f
parameter has to be in parentheses; if it's not, it will be the type of
sth like def sum(x: int)(y: int)(a: int, b: int): int). The type of a
partially applied function can be obtained by stripping T1,...,Tm, m <
n.
Cheers
Nikolay
Date: March 29, 2006
From: Jason Carreira <jcarreira@xxxxxxxxx>
So I'm working my way through Scala By Example (as it appears in Programming in
Scala) and I'm having problems with the last exercise in the Currying section. I
think it's probably just a syntax thing, but here goes. I've got the sum()
function as a tail recursive function:
def sum(f: int => int)(a: int, b: int): int = {
def iter(a : int, result : int) : int = {
if (a > b) result
else iter(a + 1, f(a) + result)
}
iter(a, 0)
}
similarly, the product() function is defined like this:
def product(f: int => int)(a: int, b: int): int = {
def iter(a: int, result: int) : int = {
if (a > b) result
else iter(a + 1, f(a) * result)
}
iter(a, 1)
}
so now I'm trying to define those functions in terms of a higher-level function.
I couldn't think of a way to pass in and use the "+" or "*" functions, so I was
trying to pass in a function of 2 ints which returns an int as the aggregate
function. I also turned out to need a start value, so that's in there too. So
here's what I've got so far:
def doRange()(start: int, aggregate: (int, int) => int)(f: int => int)(a:
int, b: int): int = {
def iter(a : int, result : int) : int = {
if (a > b) result
else iter(a + 1, aggregate(f(a), result))
}
iter(a, start)
}
but this doesn't seem to work for me. When I run it in scalaint and try to
define sum() in terms of doRange(), I get this:
scala> def sum = doRange(0, (x: int, y: int) => x + y)
<console>:4 error: wrong number of arguments for method doRange:
()(scala.Int,(scala.Int, scala.Int) => scala.Int)((scal
a.Int) => scala.Int)(scala.Int,scala.Int)scala.Int
def sum = doRange(0, (x: int, y: int) => x + y)
If someone could point me in the right direction it would be really helpful...
Oh, and I'm loving Scala so far! It's very refreshing coming from Javaland...
Thanks,
Jason Carreira
Date: March 28, 2006
From: Martin Odersky <martin.odersky@xxxxxxx>
In-reply-to:
<20060323013426.GX27058@xxxxxxxxxxxxxxxx>
References:
<dvridp$8g0$2@xxxxxxxxxxxxx> <F131BA27-5948-4CB8-9DFA-36AFCD54C056@xxxxxxx> <dvs1hb$bmc$1@xxxxxxxxxxxxx> <C2F14690-AE18-48F0-B977-669CF4AC51D0@xxxxxxx> <20060323013426.GX27058@xxxxxxxxxxxxxxxx>
Jamie Webb wrote:
Back on topic: Someone added a link to the Wiki referring to a GUI toolkit for Scala. Are there any more details anywhere? What will it be based on?
It's just a proof of concept at present. It is based on Swing, but makes typical usage much easier. As an example, I attach two CelsiusToFahrenheit converters, the first one being derived from an example in the Java Tutorial. As you can see, these are much more compact than the corresponding Java versions (typically, a factor of 4 reduction in lines of code). Part of the savings are obtained by a new treatment of events. Events are treated as first-class instances of case classes, and components have first class reactions to events. A reaction is just a pattern matching closure that maps event patterns to actions. Reactions can be installed and de-installed dynamically.
The whole package is available through sbaz. Just do a:
sbaz update
sbaz install ScalaSwing
and you should have sources and class files. You can test the package
out of the box by typing
scala gui.test.CelsiusConverter
The sources are also available independently on our svn server under
`scalaswing'.
As I said, right now it's a proof of concept. I think this could be made into a really nice toolkit that showcases some of the strengths of Scala over Java. Right now I don't have the time to work on this. So if anyone would like to take this up and develop it further, I'd be happy.
Cheers -- Martin Odersky
import gui._
import layout._
import event._
import Orientation.{left, right}
/** A GUI app to convert celsius to centigrade
*/
object CelsiusConverter extends SimpleGUIApplication {
def top: Frame = new MainFrame {
title = "Convert Celsius to Fahrenheit"
defaultButton = convertButton
object tempCelsius extends TextField();
object celsiusLabel extends Label {
text = "Celsius"
border = new EmptyBorder(5, 5, 5, 5)
}
object convertButton extends Button {
icon = new
javax.swing.ImageIcon("c:\\workspace\\gui\\images\\convert.gif")
border = new EmptyBorder(5, 5, 5, 5)
}
object fahrenheitLabel extends Label {
text = "Fahrenheit "
border = new EmptyBorder(5, 5, 5, 5)
listenTo(convertButton, tempCelsius)
reactions += {
case ButtonPressed(_) | TextModified(_) =>
val c = Integer.parseInt(tempCelsius.text)
val f = c * 9 / 5 + 32
text = "<html><font color = red>"+f+"</font> Fahrenheit</html>"
}
}
contents += new Panel(tempCelsius, celsiusLabel, convertButton,
fahrenheitLabel) {
layout = grid(2, 2)
border = new EmptyBorder(10, 10, 10, 10)
}
}
}
import gui._
import layout._
import event._
import Orientation.{left, right, center}
object CelsiusConverter2 extends SimpleGUIApplication {
def top = new MainFrame {
title = "Convert Celsius / Fahrenheit"
object Celsius extends TextField { columns = 5 };
object Fahrenheit extends TextField { columns = 5 }
contents += new Panel(Celsius, new Label(" Celsius = "),
Fahrenheit, new Label(" Fahrenheit")) {
border = new EmptyBorder(15, 10, 10, 10)
}
listenTo(Fahrenheit, Celsius)
reactions += {
case TextModified(Fahrenheit) =>
val f = Integer.parseInt(Fahrenheit.text)
val c = (f - 32) * 5 / 9
Celsius.text = c.toString
case TextModified(Celsius) =>
val c = Integer.parseInt(Celsius.text)
val f = c * 9 / 5 + 32
Fahrenheit.text = f.toString
}
}
}
Date: March 27, 2006
From: Adriaan Moors <adriaan.moors@xxxxxxxxxxxxxx>
Hi, I've been studying the paper "Design Patterns as Higher-Order Datatype-Generic Programs" by Jeremy Gibbons and to better understand the concepts it discusses, I've tried to convert the example Haskell code to Scala. I've attached the original Haskell code as well as my rendition in Scala. (I hope this does no go against this list's policy.) There's also a thread on LtU on this paper and I put additional initial thoughts on my homepage. Briefly put, my questions to the list are: - how could my encoding of hodgp.hs in hodgp.scala be improved? - I used type refinement to simulate type application (e.g. 's{type a=aa;type b=bb}' corresponds to 's a b' in Haskell), are there other/better ways? - how could I more faithfully encode build's rank-2 type (the "forall bb")? def build[s <: Bifunctor[s],ba](f : (forall bb.(s{type a=ba; type b=bb} => bb) => bb) ) :Fix[s,ba]= f(Fix) - why doesn't [s{type a=ha; type b=hb},ha,hb,hc] conform to [s <: Bifunctor[s],ha,hb,hc], whereas [s,ha,hb,hc] does ? - why aren't type members in scope in the definition of a (primary) constructor? - in the context of my attempt at the encoding (hodgprectypesyn.scala) of the pseudo-Haskell code in hodgp recursive type synonym.hs (suggested by leemarks on LtU): - is it possible to directly encode recursive type synonyms? (I tried using type refinement on this.type, but couldn't get it to work) i.e, can you encode type Fix s a = mu f. s a (f s a) ? - can s{type a = mb; type b = Fix[s,mb]} be made equivalent to Fix[s,mb] (does this require structural subtyping?) - why isn't id accessible? (I thought it was defined in Predef) thank you for taking the time to read this, suggestions for improvement are greatly appreciated! regards, Adriaan Moors |
hodgp.hs
Description: Binary data
hodgp recursive type synonym.hs
Description: Binary data
hodgprectypesyn.scala
Description: Binary data
hodgp.scala
Description: Binary data
Date: March 27, 2006
From: Burak Emir <Burak.Emir@xxxxxxx>
In-reply-to:
<91a2ba3e0603261302p11e7ce80s5294e5a6f9df0a73@xxxxxxxxxxxxxx>
References:
<87odzvvec3.fsf@xxxxxxxxxxxxxxxxxx> <442451FB.2040802@xxxxxxx> <87k6aivkdc.fsf_-_@xxxxxxxxxxxxxxxxxx> <4425318C.2040406@xxxxxxx> <87wtehndke.fsf@xxxxxxxxxxxxxxxxxx> <4426FD79.3010307@xxxxxxx> <91a2ba3e0603261302p11e7ce80s5294e5a6f9df0a73@xxxxxxxxxxxxxx>
Raoul Duke wrote:
I agree, especially since the whitespace juggling does not solve the problem of pretty printing. The XML spec is quite clear on what is an XML element and what is not. There's advantage to sticking to that kind of clarity.codify a convention for tabs -- how many blanks is a tab character?isn't this a classic minefield for programming languges?! whitespace in python, or makefiles, or... :-) just thinking one ought to be very careful, and if there already exist standard w/in the relevant domain (XML in this case) they might be the best things to follow, whenever possible.
(Unfortunately sticking to the spec does not always increase clarity...)What's so bad about the left end of the editor window anyway? I find something like <code>
if(cond) thenPart else elsePart</code> acceptable, it will make code examples stick out quite nicely in the XML.
I am working on supporting the xml:space attribute in the pretty printer, that should make "code and poetry" (as the spec says) easier to pretty-print
cheers, Burak -- Burak Emir http://lamp.epfl.ch/~emir
Date: March 27, 2006
From: Iulian Dragos <iulian.dragos@xxxxxxx>
Ok, that's great to know. By the way, which framework version do you plan to support? In my highest hopes Scala would support .NET 2.0 with generics, but I do realize that would be mean a *lot* of work for you.
We'll start by porting what was available in Scala 1.4. We don't know yet what will follow :-). Anyway, an optimistic estimate of a beta for .NET is Aug - Sept. this year... Iulian
Date: March 26, 2006
From: "Raoul Duke" <raould@xxxxxxxxx>
In-reply-to:
<4426FD79.3010307@xxxxxxx>
References:
<87odzvvec3.fsf@xxxxxxxxxxxxxxxxxx> <442451FB.2040802@xxxxxxx> <87k6aivkdc.fsf_-_@xxxxxxxxxxxxxxxxxx> <4425318C.2040406@xxxxxxx> <87wtehndke.fsf@xxxxxxxxxxxxxxxxxx> <4426FD79.3010307@xxxxxxx>
> codify a convention for tabs -- how many blanks is a tab character? isn't this a classic minefield for programming languges?! whitespace in python, or makefiles, or... :-) just thinking one ought to be very careful, and if there already exist standard w/in the relevant domain (XML in this case) they might be the best things to follow, whenever possible. sincerely.
Date: March 26, 2006
From: martin odersky <martin.odersky@xxxxxxx>
In-reply-to:
<87wtehndke.fsf@xxxxxxxxxxxxxxxxxx>
References:
<87odzvvec3.fsf@xxxxxxxxxxxxxxxxxx> <442451FB.2040802@xxxxxxx> <87k6aivkdc.fsf_-_@xxxxxxxxxxxxxxxxxx> <4425318C.2040406@xxxxxxx> <87wtehndke.fsf@xxxxxxxxxxxxxxxxxx>
Lex Spoon wrote:
I agree, we could say that an XML document is the text deliminated by a pair of tags, except for any whitespace text to the left of the starting position of the opening tag. The only tricky thing is that we have to codify a convention for tabs -- how many blanks is a tab character?Burak Emir <Burak.Emir@xxxxxxx> wrote:The whitespace handling of the Scala parser is my attempt to conform to http://www.w3.org/TR/REC-xml/#sec-white-space Note the "MUST".Cool, but what about the chunk of text that gets considered as XML at all? Already we discard text in the .scala file that is "above" and "below" the XML. If we wanted, it would be perfectly legal to also discard stuff to the "left" in some sense. If we wanted. I haven't thought thoroughly about XML integration, for sure
Date: March 26, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<87odzvvec3.fsf@xxxxxxxxxxxxxxxxxx> <442451FB.2040802@xxxxxxx> <87k6aivkdc.fsf_-_@xxxxxxxxxxxxxxxxxx> <4425318C.2040406@xxxxxxx>
Burak Emir <Burak.Emir@xxxxxxx> wrote: > The whitespace handling of the Scala parser is my attempt to conform to > > http://www.w3.org/TR/REC-xml/#sec-white-space > > Note the "MUST". Cool, but what about the chunk of text that gets considered as XML at all? Already we discard text in the .scala file that is "above" and "below" the XML. If we wanted, it would be perfectly legal to also discard stuff to the "left" in some sense. If we wanted. I haven't thought thoroughly about XML integration, for sure! > However, the whitespace handling of the pretty printer is a different > story. Pretty printing works well to turn record-like XML into something reasonably human readable. However, it does not help in the small problem of embedded code samples, where the user is trying to control each space explicitly. Most uses of XML, I'm sure, prefer that spaces be treated in a more relaxed manner, and might even *not* like spaces to be treated explicitly. BTW, here's my best idea so far for a good syntax for multi-line strings, in both XML texts and in regular strings: "def fact(x: int): int = | if(x == 0) | 1 | else | x*fact(x-1) | <code>def fact(x: int): int = | if(x == 0) | 1 | else | x*fact(x-1) |</code> The XML version, it is worth noting, can be accomplished via a user's library code, so it does not strictly need compiler support. -Lex
Date: March 25, 2006
From: Sean McDirmid <sean.mcdirmid@xxxxxxx>
In-reply-to:
<442305E0.2060906@xxxxxxxxxxx>
References:
<dvridp$8g0$2@xxxxxxxxxxxxx> <F131BA27-5948-4CB8-9DFA-36AFCD54C056@xxxxxxx> <dvs1hb$bmc$1@xxxxxxxxxxxxx> <C2F14690-AE18-48F0-B977-669CF4AC51D0@xxxxxxx> <20060323013426.GX27058@xxxxxxxxxxxxxxxx> <4422CEDF.6070607@xxxxxxxxxxx> <C2194345-F22C-47F8-AF14-DF73673E1031@xxxxxxx> <442305E0.2060906@xxxxxxxxxxx>
On Mar 23, 2006, at 9:32 PM, Jon Pretty wrote:
Hi Sean,I think it seems that in general, SWT provides a better user experience, with an inferior programmer 'experience'. I wonder, therefore, whether a new Scala API can be written to wrap SWT into something more pleasant to use (possibly along the lines of JFace, though that isn't something Iknow anything about).
I think we are better off wrapping Swing than SWT, as Swing is more extensible and therefore we would get more mileage out of the wrapping. However, wrapping SWT would let us write Eclipse plugins in Scala :) I don't know, it really depends on who wants to do the work :)
I haven't yet had time to give your SuperGlue paper the attention it deserves, though I have had the briefest of glances through it, and it looks similar to Trolltech's Qt signals and slots mechanism(http://doc.trolltech.com/4.1/signalsandslots.html). As I never program in C++, I only have hearsay to go on, but I've only ever heard positivethings about this particular feature of Qt.
Signals and slots in QT are very simple forms of connections. They don't really scale; e.g., you can't connect an unbounded tree of signals. Actually, thats the problem with connections in general: they don't scale over space, which is one of the problems I'm solving with SuperGlue. Anyways, there is a lot of room for exploring new kinds of languages when trying to solve the component assembly problem.
I'd be interested to see some of Martin's sample UI code. I have aparticularly busy agenda for the next few weeks, though I would like tothink that Jamie and myself at Sygneca could have some collaborative involvement in developing such an API in the future. Whilst I'm still largely off-topic, might I pass on a big 'well done' for the Scala Eclipse plugin. We are still currently developing inScala 1.3, though we plan to migrate some 20000 lines of code to Scala 2over the next few weeks and will almost certainly make use of Eclipse. I hope to be able to post some feedback on the plugin once we startusing it extensively, but I've liked what I've seen so far - keep up thegood work!
Well, I hope it works out for you, I haven't seen Eclipse being used in a production system. If its of any use, I do my scalac hacking (10,000 lines of code?) with Eclipse, and the only big annoyance is the start-up time when I open the first big file of the project. After this happens, the performance is OK, but we think there might be a memory leak that causes the build compiler to eventually crash (again, this only really shows up on large projects such as scalac). OK, crashes are bad, and memory leaks are bad, but it seems workable right now. I'm planning a rewrite to deal with the performance and stability issues, and hopefully things will keep getting better.
Sean
Date: March 25, 2006
From: martin odersky <martin.odersky@xxxxxxx>
In-reply-to:
<442451FB.2040802@xxxxxxx>
References:
<87odzvvec3.fsf@xxxxxxxxxxxxxxxxxx> <442451FB.2040802@xxxxxxx>
Burak Emir wrote:
That seems to be the major advatange of XML over case classes with raw strings. I much preferIt's funny you should prefer case classes over XML, I have encountered situations where I prefer XML because I don't have to put quotes around multiline strings.
<para>This is
a multiline
text</para>
Over
Para("This is "+
"a multiline "+
"text")
Note however that you can have hybrids -- A system with case classes
that contains embedded text surrounded by XML tags. That way you could
have a document that is program and needs no interpreter for expansion.
I am not sure it's worth it, just wanted to point out it's possible.
Cheers -- Martin
Date: March 25, 2006
From: Burak Emir <Burak.Emir@xxxxxxx>
In-reply-to:
<87k6aivkdc.fsf_-_@xxxxxxxxxxxxxxxxxx>
References:
<87odzvvec3.fsf@xxxxxxxxxxxxxxxxxx> <442451FB.2040802@xxxxxxx> <87k6aivkdc.fsf_-_@xxxxxxxxxxxxxxxxxx>
The whitespace handling of the Scala parser is my attempt to conform to http://www.w3.org/TR/REC-xml/#sec-white-space Note the "MUST".However, the whitespace handling of the pretty printer is a different story.
We could make the pretty printer honor the xml:space="preserve" attribute, that would solve your code example.
cheers, B. Lex Spoon wrote:
A couple of people pointed out that XML works great in Scala. This is
true. I normally think of XML as interchange format, so did not even
think of using it for the un-typed tree hackery. No doubt you can
write your XML inside a Scala program and get an immediate win because
of subroutines, etc.
Interestingly, though, case classes seem about equal to XML, when both
are used inside Scala. This means that unless existing standards are
an issue, you can equally well use either one. The main difference is
that one is statically typed and the other is not. And as an aside,
this obvservation suggests that it would be nice if case classes could
get turned into XML and back without trouble. But maybe they already
can?
Syntactically, case classes have the edge over XML *most* of the time,
because (a) you can write a single close parenthesis instead of a
close tag, and (b) you can often use multi-argument case classes
instead of having to tag the sub-elements of a tag. That is, compare
these two:
<section><title>Here is a Title</title><para>here is a para</para></section>
Section("Here is a Title", "Here is a Para")
The last example also shows a second difference between case classes
and XML: it is statically typed (IMO a small net loss for this
application--you have to declare lots of types but they don't help
much), and it can use implicit coercions to turn the strings into
whatever exact class they need to be (IMO a small win).
Granted, multi-line strings are a possible place XML can win. But it
depends! First, if you care about leading spaces on your lines, then
you need to write some extra code to clean up your XML (becuase, IMHO,
if you have to write everything in the left column, your approach is
not very good at all!). Second, if you insert a lot of tags inside
your multi-line text, things like <emphasis>...</emphasis>, then the
XML will gradually start to look worse due to its more verbose tags.
"" is extremely concise, after all, even if you have to add an extra
pair per line!
For multi-line strings, this experiment shows ways that both XML and
regular strings have room to improve. In XML, it would be nice to
have *something* so that I can indent a multi-line text without the
indentation being counted as part of the text. That is, I'd like to
write things like this:
<codeexample>
def fact(x: int): int =
if(x == 0)
1
else
x*fact(x-1)
</codeexample>
I would like it if there were not 4 spaces inserted in front of the
code example; "def fact" should be the first 8 characters of the
string. Don't ask me how to encode this, but it would be nice if it
were there....
For regular strings, it would be nice if there were support for
multi-line strings. Something like what Andrew Appel uses in the
Tiger language would seem nice:
"def fact(x: int): int =\
\ if(x == 0)\
\ 1\
\ else\
\ x*fact(x-1)"
The above wtould be a little nicer for multi-line strings than Tiger,
IMHO, because in Tiger you have to write the \n's explicitly:
"def fact(x: int): int =\n\
\ if(x == 0)\n\
\ 1\n\
\ else\n\
\ x*fact(x-1)"
Ick. Since the only real application of this feature is to support
multi-line strings, surely it makes sense to insert the \n's
automatically.
And actually, why require the ending \ ? Something like the following
might also work well:
"def fact(x: int): int =
" if(x == 0)
" 1
" else
" x*fact(x-1)"
Any thoughts? Anyone know a good syntax for multi-line strings that
allows the string to be indented in the source code?
Anyway, this is all fun stuff. Thanks for the pointers, everyone. I
don't think I'll be using too much DocBook in the future.
-Lex
Date: March 25, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<87odzvvec3.fsf@xxxxxxxxxxxxxxxxxx> <442451FB.2040802@xxxxxxx>
A couple of people pointed out that XML works great in Scala. This is
true. I normally think of XML as interchange format, so did not even
think of using it for the un-typed tree hackery. No doubt you can
write your XML inside a Scala program and get an immediate win because
of subroutines, etc.
Interestingly, though, case classes seem about equal to XML, when both
are used inside Scala. This means that unless existing standards are
an issue, you can equally well use either one. The main difference is
that one is statically typed and the other is not. And as an aside,
this obvservation suggests that it would be nice if case classes could
get turned into XML and back without trouble. But maybe they already
can?
Syntactically, case classes have the edge over XML *most* of the time,
because (a) you can write a single close parenthesis instead of a
close tag, and (b) you can often use multi-argument case classes
instead of having to tag the sub-elements of a tag. That is, compare
these two:
<section><title>Here is a Title</title><para>here is a para</para></section>
Section("Here is a Title", "Here is a Para")
The last example also shows a second difference between case classes
and XML: it is statically typed (IMO a small net loss for this
application--you have to declare lots of types but they don't help
much), and it can use implicit coercions to turn the strings into
whatever exact class they need to be (IMO a small win).
Granted, multi-line strings are a possible place XML can win. But it
depends! First, if you care about leading spaces on your lines, then
you need to write some extra code to clean up your XML (becuase, IMHO,
if you have to write everything in the left column, your approach is
not very good at all!). Second, if you insert a lot of tags inside
your multi-line text, things like <emphasis>...</emphasis>, then the
XML will gradually start to look worse due to its more verbose tags.
"" is extremely concise, after all, even if you have to add an extra
pair per line!
For multi-line strings, this experiment shows ways that both XML and
regular strings have room to improve. In XML, it would be nice to
have *something* so that I can indent a multi-line text without the
indentation being counted as part of the text. That is, I'd like to
write things like this:
<codeexample>
def fact(x: int): int =
if(x == 0)
1
else
x*fact(x-1)
</codeexample>
I would like it if there were not 4 spaces inserted in front of the
code example; "def fact" should be the first 8 characters of the
string. Don't ask me how to encode this, but it would be nice if it
were there....
For regular strings, it would be nice if there were support for
multi-line strings. Something like what Andrew Appel uses in the
Tiger language would seem nice:
"def fact(x: int): int =\
\ if(x == 0)\
\ 1\
\ else\
\ x*fact(x-1)"
The above wtould be a little nicer for multi-line strings than Tiger,
IMHO, because in Tiger you have to write the \n's explicitly:
"def fact(x: int): int =\n\
\ if(x == 0)\n\
\ 1\n\
\ else\n\
\ x*fact(x-1)"
Ick. Since the only real application of this feature is to support
multi-line strings, surely it makes sense to insert the \n's
automatically.
And actually, why require the ending \ ? Something like the following
might also work well:
"def fact(x: int): int =
" if(x == 0)
" 1
" else
" x*fact(x-1)"
Any thoughts? Anyone know a good syntax for multi-line strings that
allows the string to be indented in the source code?
Anyway, this is all fun stuff. Thanks for the pointers, everyone. I
don't think I'll be using too much DocBook in the future.
-Lex
Date: March 24, 2006
From: Burak Emir <Burak.Emir@xxxxxxx>
In-reply-to:
<87odzvvec3.fsf@xxxxxxxxxxxxxxxxxx>
References:
<87odzvvec3.fsf@xxxxxxxxxxxxxxxxxx>
Hi Lex,I used DocBook, too, and still do (the <scala/xml> draft). Actually the subroutines are not a problem, you can invent your own tag and make a pass over the thing with a handcrafted Scala program that replaces it with the repetitive bit you need. Then you produce XML and run the usual tools. Here's some more tourist photos from the path you are about to take:
* For the scala/xml book, I handle XInclude that way. I copied ERH's SaxxIncluder to Scala, it's very nice for including Scala sources, since the XInclude spec has ways to automatically escape text (things might contain '<') etc. After doing the xincluding, I run the docbook stylesheets.
* For my ideosyncratic bqbase blog, I have some xhtml-body tag with my own tags around it for classification. I cut out embedded SVG subtrees, transform them to png using the batik lib and replace the inlined svg with a <imsg src=...> tag, copying all the files in the right directory. Fun stuff! The absence of an svg2x transformation in any scheme language is I think reason enough to stop that endless s-expression argument, but people are free to choose to stay ignorant.
Check out this one: (well here even the SVG is generated, and not handwritten, but that's another story)
http://lamp.epfl.ch/~emir/bqbase/2005/03/08/drawingTrees.html* Finally the Scala poster and the Scala XML poster on the LAMP corridor were also written in Scala, using the XSLFO dialect and the Apache FOP library. XSLFO was a bit lowlevel, so subroutines were quite handy.
* encouraged by that I actually made a 20 slide presentation for a conference entirely in XSLFO, with automata diagrams in SVG. it was like 2000 lines or so and took a while to compile, but I didn't want to mess with latex slides if I have one diagram after another and they have to be in exactly the same x,y position on the next slide etc. (btw SVG has ways to define macros, it depends on your "XML Application" as we should call it... it's the docbook designers' fault, not the W3Cs)
It's funny you should prefer case classes over XML, I have encountered situations where I prefer XML because I don't have to put quotes around multiline strings.
Finally, there are two really simple explanations why the standard print XSLTs for DocBook look so basic, it's because companies that are producing high-quality, identical html and pdf output are actually making money (check out http://www.renderx.com for instance, they talk about the docbook stylesheets that come with their product somewhere)> It's kind of dampening motivation of the open source folks I guess?
Another reason is because XSLT is a nightmare, and most hackers don't like yet it's still less tedious than Java (and Scala hackers have not tried to implement a complete transformation tool yet :-)
If you explain me what you are trying to do I can try to give you a hint on some cool undocumented library feature that you might want to use.
cheers, Burak p.s.: look ma no quotes. val intro = <my:section title="Overview" xmlns:my="myCuteLittleNamespace">Scala Bazaars supports Scala enthusiasts in sharing the software they create with each other. The community is strengthened when people can help each other out by sharing code. A programming language needs an archive of library code to be its most useful.
<my:bulletlist> ... </my:bulletlist>
</my:section>
def transform(x:Node):SeqNode = x match {
case Elem("my","section", attrs, scp, ch@_*) =>
<section>
<title>{attrs.getValue("title")}</title>
<para>{ transform(ch) }</para>
</section>
...
}
def transform(x:Seq[Node]): Seq[Node] => ...
// ok, in fact you should do Elem(pre,....scp,...) if
pre.getURI="myCuteLittleNamespace" if afraid that others use the same
prefix...
p.p.s.: why not cut out LaTeX formula, run LaTeX on them, reinsert the result.
Lex Spoon wrote:
I have used DocBook in the past for documents where I would like to distribute both HTML and for-print versions. It works reasonably well, but there are three major shortcomings: 1. There are no subroutines or macros. If you do something twenty times, you have to repeat yourself. 2. It does not look as nice as a carefully written Latex file.3. It does not handle math formulas, where Latex remains king.I have long yearned for a Turing-complete language to use instead of XML. It turns out that Scala's case classes are about equally as expressive, while addressing most of these issues. The first issue goes away entirely. The second is actually reduced, but only because I wrote my own style sheets instead of relying on Docbook. (As an aside, why in the world do the standard Docbook styles generate such bad for-print versions? Latex's simple article style looks much better.) Only the third is left untouched. Enough said. The implementations are about equally long, if you discount the style sheets. Here's the original file size:* manual.xml: 795 lines, 33kbAnd here are the new file sizes, including all the infrastructure that was needed to write: * Manual.scala: 720 lines, 32kb * Documents.scala: 41 lines, 1.5kb * EmitHtml.scala: 115 lines, 2kb * EmitLatex.scala: 138 lines, 3kb* Total: 1014 lines, 38kbThe following web page has all the files, included the old and new output: http://www.lexspoon.org/blog/scala-as-xml.html I've appended a chunk of the XML and the Scala. When I was writing it, the Scala *felt* shorter and nicer, but it actually has just about the same amount of raw text. Odd. Anyway, equally dense means that writing in Scala is no worse for Docbook-like files even if you do nothing special. However, using Scala also means that you can use subroutines if you want. Since I don't use much of Docbook anyway, maintaining my own style sheets is not a big deal. So, I'll probably pick Scala in the future for the things where I used Docbook in the past. I wonder what other XML-based applications would work well in Scala... -Lex PS -- Jonathan Rees deserves credit as having programmed a (much larger) document in a real programming language much earlier. If Scheme can do it, so can Scala! http://www.paulgraham.com/thist.html ======== docbook version ========== <?xml version = '1.0' encoding = 'UTF-8'?> <!DOCTYPE article PUBLIC "-//Norman Walsh//DTD DocBook XML V3.1.7//EN" "http://nwalsh.com/docbook/xml/3.1.7/db3xml.dtd";> <article> <artheader> <title>Scala Bazaars Reference Manual</title> <author> <firstname>Alexander</firstname> <surname>Spoon</surname> </author> <pubdate>March 2006</pubdate> </artheader> <sect1><title>Overview</title> <para>Scala Bazaars supports Scala enthusiasts in sharing the software they create with each other. The community is strengthened when people can help each other out by sharing code. A programming language needs an archive of library code to be its most useful.</para> <para>Scala Bazaars has several features specialized for this kind of community:</para> <itemizedlist> <listitem><para>Since programming efforts in the community are distributed around the world, the system must allow loose, decoupled collaboration. Participants are not required to wait for each other nor for any centralized authority.</para></listitem> ======= scala version ============= package sbaz.manual object Manual { import Documents._ val intro = Section("Overview", "Scala Bazaars supports Scala enthusiasts in sharing the software "& "they create with each other. The community is strengthened when "& "people can help each other out by sharing code. A programming "& "language needs an archive of library code to be its most useful.", "Scala Bazaars has several features specialized for this kind of "& "community:", BulletList( "Since programming efforts in the community are distributed "& "around the world, the system must allow loose, decoupled "& "collaboration. Participants are not required to wait for each "& "other nor for any centralized authority. ", "Since subgroups of the community have their own "& "needs"&MDash&"just consider groups doing commercial "& "development!"&"the system should support subgroup-specific "& "access control policies.", "Since many open source projects are updated frequently, the "& "system must allow conveniently updating components as new "& "versions become available.",
Date: March 24, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
I have used DocBook in the past for documents where I would like to
distribute both HTML and for-print versions. It works reasonably well,
but there are three major shortcomings:
1. There are no subroutines or macros. If you do something twenty
times, you have to repeat yourself.
2. It does not look as nice as a carefully written Latex file.
3. It does not handle math formulas, where Latex remains king.
I have long yearned for a Turing-complete language to use instead of
XML. It turns out that Scala's case classes are about equally as
expressive, while addressing most of these issues. The first issue
goes away entirely. The second is actually reduced, but only because I
wrote my own style sheets instead of relying on Docbook. (As an aside,
why in the world do the standard Docbook styles generate such bad
for-print versions? Latex's simple article style looks much better.)
Only the third is left untouched.
Enough said. The implementations are about equally long, if you
discount the style sheets. Here's the original file size:
* manual.xml: 795 lines, 33kb
And here are the new file sizes, including all the infrastructure that
was needed to write:
* Manual.scala: 720 lines, 32kb
* Documents.scala: 41 lines, 1.5kb
* EmitHtml.scala: 115 lines, 2kb
* EmitLatex.scala: 138 lines, 3kb
* Total: 1014 lines, 38kb
The following web page has all the files, included the old and new
output:
http://www.lexspoon.org/blog/scala-as-xml.html
I've appended a chunk of the XML and the Scala. When I was writing
it, the Scala *felt* shorter and nicer, but it actually has just about
the same amount of raw text. Odd.
Anyway, equally dense means that writing in Scala is no worse for
Docbook-like files even if you do nothing special. However, using
Scala also means that you can use subroutines if you want. Since I
don't use much of Docbook anyway, maintaining my own style sheets is
not a big deal. So, I'll probably pick Scala in the future for the
things where I used Docbook in the past.
I wonder what other XML-based applications would work well in Scala...
-Lex
PS -- Jonathan Rees deserves credit as having programmed a (much
larger) document in a real programming language much earlier. If
Scheme can do it, so can Scala!
http://www.paulgraham.com/thist.html
======== docbook version ==========
<?xml version = '1.0' encoding = 'UTF-8'?>
<!DOCTYPE article PUBLIC "-//Norman Walsh//DTD DocBook XML V3.1.7//EN"
"http://nwalsh.com/docbook/xml/3.1.7/db3xml.dtd";>
<article>
<artheader>
<title>Scala Bazaars Reference Manual</title>
<author>
<firstname>Alexander</firstname>
<surname>Spoon</surname>
</author>
<pubdate>March 2006</pubdate>
</artheader>
<sect1><title>Overview</title>
<para>Scala Bazaars supports Scala enthusiasts in sharing the
software they create with each other. The community is
strengthened when people can help each other out by sharing code.
A programming language needs an archive of library code to be its
most useful.</para>
<para>Scala Bazaars has several features specialized for this kind
of community:</para>
<itemizedlist>
<listitem><para>Since programming efforts in the community are
distributed around the world, the system must allow loose,
decoupled collaboration. Participants are not required to wait
for each other nor for any centralized
authority.</para></listitem>
======= scala version =============
package sbaz.manual
object Manual {
import Documents._
val intro = Section("Overview",
"Scala Bazaars supports Scala enthusiasts in sharing the software "&
"they create with each other. The community is strengthened when "&
"people can help each other out by sharing code. A programming "&
"language needs an archive of library code to be its most useful.",
"Scala Bazaars has several features specialized for this kind of "&
"community:",
BulletList(
"Since programming efforts in the community are distributed "&
"around the world, the system must allow loose, decoupled "&
"collaboration. Participants are not required to wait for each "&
"other nor for any centralized authority. ",
"Since subgroups of the community have their own "&
"needs"&MDash&"just consider groups doing commercial "&
"development!"&"the system should support subgroup-specific "&
"access control policies.",
"Since many open source projects are updated frequently, the "&
"system must allow conveniently updating components as new "&
"versions become available.",
Date: March 24, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<87zmjkuf7g.fsf@xxxxxxxxxxxxxxxxxx> <dvrmvm$qhi$1@xxxxxxxxxxxxx>
> Instead of > > fluid.set(newValue) > > I'd probably prefer > > fluid.value = newValue Ah yes, this is nicer. I've changed it. -Lex
Date: March 23, 2006
From: Jon Pretty <jon.pretty@xxxxxxxxxxx>
In-reply-to:
<C2194345-F22C-47F8-AF14-DF73673E1031@xxxxxxx>
References:
<dvridp$8g0$2@xxxxxxxxxxxxx> <F131BA27-5948-4CB8-9DFA-36AFCD54C056@xxxxxxx> <dvs1hb$bmc$1@xxxxxxxxxxxxx> <C2F14690-AE18-48F0-B977-669CF4AC51D0@xxxxxxx> <20060323013426.GX27058@xxxxxxxxxxxxxxxx> <4422CEDF.6070607@xxxxxxxxxxx> <C2194345-F22C-47F8-AF14-DF73673E1031@xxxxxxx>
Hi Sean, Thanks for your detailed reply. Having a brief look at http://developer.apple.com/documentation/Java/Conceptual/Java131Development/overview/chapter_2_section_4.html explains why Mac OS X seems to be so much more responsive. Windows users aren't so lucky, and this is a similar sort of performance increase to that of SWT over Swing under other OSs, for the same reasons. I think it seems that in general, SWT provides a better user experience, with an inferior programmer 'experience'. I wonder, therefore, whether a new Scala API can be written to wrap SWT into something more pleasant to use (possibly along the lines of JFace, though that isn't something I know anything about). I haven't yet had time to give your SuperGlue paper the attention it deserves, though I have had the briefest of glances through it, and it looks similar to Trolltech's Qt signals and slots mechanism (http://doc.trolltech.com/4.1/signalsandslots.html). As I never program in C++, I only have hearsay to go on, but I've only ever heard positive things about this particular feature of Qt. I'd be interested to see some of Martin's sample UI code. I have a particularly busy agenda for the next few weeks, though I would like to think that Jamie and myself at Sygneca could have some collaborative involvement in developing such an API in the future. Whilst I'm still largely off-topic, might I pass on a big 'well done' for the Scala Eclipse plugin. We are still currently developing in Scala 1.3, though we plan to migrate some 20000 lines of code to Scala 2 over the next few weeks and will almost certainly make use of Eclipse. I hope to be able to post some feedback on the plugin once we start using it extensively, but I've liked what I've seen so far - keep up the good work! All the best, Jon -- Jon Pretty | Sygneca Ltd. http://www.sygneca.com/
Date: March 23, 2006
From: Sean McDirmid <sean.mcdirmid@xxxxxxx>
In-reply-to:
<4422CEDF.6070607@xxxxxxxxxxx>
References:
<dvridp$8g0$2@xxxxxxxxxxxxx> <F131BA27-5948-4CB8-9DFA-36AFCD54C056@xxxxxxx> <dvs1hb$bmc$1@xxxxxxxxxxxxx> <C2F14690-AE18-48F0-B977-669CF4AC51D0@xxxxxxx> <20060323013426.GX27058@xxxxxxxxxxxxxxxx> <4422CEDF.6070607@xxxxxxxxxxx>
Hi,This is so OT but I can't really resist. First, Swing applications look native to me, at least under Mac OSX. I must admit, I don't do much development under Windows, where things might be really different. SWT under Mac OSX is also a bit flaky (e.g., crashes and resource leaks), so my biases are magnified. From my own user's perspective, I don't see the benefit of SWT at all, but then again I don't use Windows (and only SWT under Linux where everything looks bad anyways ... because its GTK!). I guess SWT does provide some more consistency because native widgets are used directly, whereas Swing depends on a renderer. (Also note that the renderer used for Swing widgets in Mac OSX is Quartz, the Sun software renderer hasn't been used in a while).
SWT is a huge step back in terms of API design. The focus of SWT is on performance, and therefore strings and ints are used everywhere where I'd rather see higher-level objects (documentation is constantly needed to figure out what int mask to pass into my widget constructors?). Resources are managed manually, even trivial ones like colors, there is no high-level way to do this (e.g., through color maps, or just use the garbage collector!). MVC in SWT is non- existent, say you want list order in a table, there is no easy way to do that, and your best bet is to use integers as row handles. In Swing, a model is well defined and mostly easy to use, although the fact that you always need a model makes doing trivial stuff a bit harder. And lets not even get started on how layouts work. I don't think a UI in SWT will look as professional as in Swing, at least not with a lot more programming effort.
Programming in SWT actually feels a lot like programming in AWT with the addition of a table and a tree widget. Actually, Swing was designed with a really good interface, but its reputation was ruined with slow early implementations. SWT is the exact opposite: lousy interface, but fast early implementations. The best thing going for SWT is JFace (technically built on top of SWT), which is higher-level and more like Swing in its interface. JFace suffers, however, when it leaks SWT details, and not to mention all the XML code that makes it more difficult to understand whats going on. Then we get to Eclipse, which overall is much better than Netbeans (implemented in Swing). I don't regret building the plugin for Eclipse rather than Netbeans. But the XML is definitely annoying (I see why its needed, but it makes plugin programming much more difficult).
I've actually done a substantial amount of programming in both Swing and SWT, so I'm mostly reporting my direct experiences. I also have a research agenda, which is to make programs easier to write. Martin has done some work done with a Scala UI library, which uses case classes to better deal with event handling details. Its a nice start, but unfortunately there is nobody working on this project right now (volunteers?). UI libraries are nice examples of component frameworks that suffer a lot from bad interfaces. I've done some work in this field that doesn't use Scala but instead uses a new declarative language. If anyone is interested, here is a link to a draft of my paper that is being published at this year's ECOOP:
http://lamp.epfl.ch/~mcdirmid/mcdirmid06superglue.pdfThe idea is to make things like UI programming dead-simple through high-level programming constructs.
Thanks for your time, Sean On Mar 23, 2006, at 5:37 PM, Jon Pretty wrote:
Jamie Webb wrote:On Wed, Mar 22, 2006 at 06:54:17PM +0100, Sean McDirmid wrote:Actually, SWT is horrible when compared to Swing.I've only played with SWT fairly briefly, but I'm surprised you find it so. My feeling was that it was rather light on features, but those that were present were reasonably useable.From a user's perspective, SWT is undeniably an improvement over Swing: it much better fits in with the look and feel of the host platform, andresponds as quickly as a GUI running on a modern computer should.Swing does neither of these. It renders widgets in a whole new look and feel which shows no bias towards any particular operating system (or inother words, looks out of place everywhere) and requires far more computing power than it should just to be responsive.The opinions I have read about SWT seem to suggest that it is great forsimple GUIs, though the coding becomes overly difficult for anything more complex. This could be, as much as anything, a reflection of the ability of the 'average' Java programmer to handle complicated things, though it seems like something which could be addressed with a carefully-abstracted Scala API, and I would support this approach.My impression is that Swing is almost single-handedly responsible forthe popular belief that Java is slow (okay, maybe the JVM startup timeis significant too).Both are definitely factors. Another is that many people's experienceof Java is in the form of applets which tend to need downloading beforeuse, not to mention the fact that Java, by almost any benchmark (JITCs aside), is indeed slower than most compiled languages.However, I imagine that Swing, even if written in C, would still manageto be slow.Back on topic: Someone added a link to the Wiki referring to a GUI toolkit for Scala. Are there any more details anywhere? What will it be based on?This sounds exciting. Having seen how many programmer-hours it hastaken for SWT to have (most of) its bugs ironed out, I would be wary ofembarking on something new which is not based around an existing technology. Given the slightly polarised views highlighted in the last couple of messages in this thread, it would be interesting to see some ideas shared and discussed on what there is planned. Cheers, Jon -- Jon Pretty | Sygneca Ltd. http://www.sygneca.com/
Date: March 23, 2006
From: Jon Pretty <jon.pretty@xxxxxxxxxxx>
In-reply-to:
<20060323013426.GX27058@xxxxxxxxxxxxxxxx>
References:
<dvridp$8g0$2@xxxxxxxxxxxxx> <F131BA27-5948-4CB8-9DFA-36AFCD54C056@xxxxxxx> <dvs1hb$bmc$1@xxxxxxxxxxxxx> <C2F14690-AE18-48F0-B977-669CF4AC51D0@xxxxxxx> <20060323013426.GX27058@xxxxxxxxxxxxxxxx>
Jamie Webb wrote: > On Wed, Mar 22, 2006 at 06:54:17PM +0100, Sean McDirmid wrote: >> Actually, SWT is horrible when compared to Swing. > > I've only played with SWT fairly briefly, but I'm surprised you find > it so. My feeling was that it was rather light on features, but those > that were present were reasonably useable. >From a user's perspective, SWT is undeniably an improvement over Swing: it much better fits in with the look and feel of the host platform, and responds as quickly as a GUI running on a modern computer should. Swing does neither of these. It renders widgets in a whole new look and feel which shows no bias towards any particular operating system (or in other words, looks out of place everywhere) and requires far more computing power than it should just to be responsive. The opinions I have read about SWT seem to suggest that it is great for simple GUIs, though the coding becomes overly difficult for anything more complex. This could be, as much as anything, a reflection of the ability of the 'average' Java programmer to handle complicated things, though it seems like something which could be addressed with a carefully-abstracted Scala API, and I would support this approach. > My impression is that Swing is almost single-handedly responsible for > the popular belief that Java is slow (okay, maybe the JVM startup time > is significant too). Both are definitely factors. Another is that many people's experience of Java is in the form of applets which tend to need downloading before use, not to mention the fact that Java, by almost any benchmark (JITCs aside), is indeed slower than most compiled languages. However, I imagine that Swing, even if written in C, would still manage to be slow. > Back on topic: Someone added a link to the Wiki referring to a GUI > toolkit for Scala. Are there any more details anywhere? What will it > be based on? This sounds exciting. Having seen how many programmer-hours it has taken for SWT to have (most of) its bugs ironed out, I would be wary of embarking on something new which is not based around an existing technology. Given the slightly polarised views highlighted in the last couple of messages in this thread, it would be interesting to see some ideas shared and discussed on what there is planned. Cheers, Jon -- Jon Pretty | Sygneca Ltd. http://www.sygneca.com/
Date: March 23, 2006
From: Jamie Webb <j@xxxxxxxxxxxxxxx>
In-reply-to:
<C2F14690-AE18-48F0-B977-669CF4AC51D0@xxxxxxx>
References:
<dvridp$8g0$2@xxxxxxxxxxxxx> <F131BA27-5948-4CB8-9DFA-36AFCD54C056@xxxxxxx> <dvs1hb$bmc$1@xxxxxxxxxxxxx> <C2F14690-AE18-48F0-B977-669CF4AC51D0@xxxxxxx>
On Wed, Mar 22, 2006 at 06:54:17PM +0100, Sean McDirmid wrote: > Actually, SWT is horrible when compared to Swing. I've only played with SWT fairly briefly, but I'm surprised you find it so. My feeling was that it was rather light on features, but those that were present were reasonably useable. > I'm not really a UI > person, so I just want to crank out a simple form with some fields > and such, and this is overly difficult in SWT. Why did IBM have to > write SWT when Swing already existed? Because Swing is a) horribly designed, b) horribly slow, and c) horribly ugly (and none of the 'look 'n feel plugins' I've seen are much better, aside from Apple's which I believe is more than just a plugin). While I haven't used SWT enough to vouch for it, I find the motive for improvement unquestionable. > They made an argument about > performance, but I really can't tell the difference between the two. Eclipse is pretty slow. Try comparing a plain SWT app to a Swing app. The difference is quite noticeable (though SWT still trails the raw Java GTK binding, which is hard to distinguish from native code). Given that, I hate to think how slow Eclipse would be if it used Swing. My impression is that Swing is almost single-handedly responsible for the popular belief that Java is slow (okay, maybe the JVM startup time is significant too). I remember writing a perfectly responsive vector graphics drawing applet in AWT, while on the same machine (this was a while ago) Swing would take so long just to, e.g. redraw a button when I clicked on it as to make Swing applications almost unusable. Back on topic: Someone added a link to the Wiki referring to a GUI toolkit for Scala. Are there any more details anywhere? What will it be based on? Cheers -- Jamie Webb
Date: March 22, 2006
From: Sean McDirmid <sean.mcdirmid@xxxxxxx>
In-reply-to:
<dvs1hb$bmc$1@xxxxxxxxxxxxx>
References:
<dvridp$8g0$2@xxxxxxxxxxxxx> <F131BA27-5948-4CB8-9DFA-36AFCD54C056@xxxxxxx> <dvs1hb$bmc$1@xxxxxxxxxxxxx>
On Mar 22, 2006, at 6:29 PM, Stefan Matthias Aust wrote:
Sean, thanks your for reply. I've to confess that I didn't read your known issues document before I wrote done my findings. Next time, I'll look into that document before.
The docs aren't very good. Just one page of issues that should probably be expanded. Anyways, the best way to solve these problems is to avoid issues altogether, if only :)
SWT isn't that bad. Just just different :) Regarding the Groupcontrol. Just don't use it for naming input fields. That is what I wasrefering to with "titled border". Instead add SWT.BORDER to the constructor of your input fields to add a widget border and prefix the input field with a Label.
Actually, SWT is horrible when compared to Swing. I'm not really a UI person, so I just want to crank out a simple form with some fields and such, and this is overly difficult in SWT. Why did IBM have to write SWT when Swing already existed? They made an argument about performance, but I really can't tell the difference between the two.
Do you scan the source code or the class files for the outliner? If youscan the source code, it shouldn't be a problem. If you get some AST