Re: Pattern match on class literals

> Could xx(yy) capture something?

Yes.

scala> val o = if (Math.random < 0.5) Some(5) else None
o: Option[Int] = Some(5)

scala> o match { case Some(x) => println(x+"!"); case None => println("Damn") }
5!

Look for 'unapply' in the docs.

I may have missed the point there.  Perhaps that only works for ThisCase.

2009/1/8 Ricky Clarkson <ricky.clarkson@gmail.com>

> Could xx(yy) capture something?

Yes.

scala> val o = if (Math.random < 0.5) Some(5) else None
o: Option[Int] = Some(5)

scala> o match { case Some(x) => println(x+"!"); case None => println("Damn") }
5!

Look for 'unapply' in the docs.

Thanks for your interest.

On Wed, Jan 7, 2009 at 4:33 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

Pattern matching has to be done against a stable identifier.  classOf[String] is an expression, just as 1 +1.  Yes, the expression is unchanging, but Scala does not yet have an effects system that can determine that.  So, you need to pattern match against a pre-computed value... something that's not going to change.

You can specify the stable identifier as lower case:

val strCls = classOf[String]

and pattern match using the backticks:

def m(in: Class[_]) = m match {
  case `strCls` => ...
}

But, there's no way to pattern match against the expression classOf[String].  You must assign the expression to something.

On Wed, Jan 7, 2009 at 1:06 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

I can't do "case o: Type" because I'm passing around class literals before there is an instance: I'm parsing expression trees and need to determine the expression's type first, so double + int = double while short + int = int. I had tried the map approach and given up due to an eclipse bug for which I now seem to have a workaround: It was necessary to specify a type annotation on each element: Map( classOf[x] -> y: (Class[_], _), ... )

You must give the type inferencer some help:
Map[Class[_], (Class[_], String)]((classOf[String], (classOf[String], "foo")), (classOf[Long], (classOf[Int], "bar")))

Is your point here to pass the type parameters explicitly to the constructor, or to use standard tuple notation (,) instead of ->? Or are both helping?
Also, on scala-tools they said that with the little code snippet I gave them they problem wasn't reproducing itself, but it sounded like a resident compiler bug, so I'll see if I get around to narrowing down the problematic code and filing a bug eventually...

Gives the type inferencer enough help to get it right.

 

Also, the big problem with a map is that it's not all straightforward: Some tests are against class literals, but some need to be more general and then differentiate in other ways:   // for the & operator   case (classOf[java.lang.Boolean], classOf[java.lang.Boolean]) => classOf[Boolean]   ...   case (leftType, rightType) => // more complicated now Note that this isn't real code, just typing on the spot to illustrate the problem. And what about values that are returned from functions or methods?

Could you give us a better over-view of what you're trying to do with your application?

Also, what's your language background?  Java, Ruby, Python?

More Java than anything else, although I've been doing scala for a while.
As for the previous question, to satisfy your curiosity :) here's what my project is about, tell me what you think.
It's basically following in the footsteps of projects like Jaxx, SwixML -- XML GUIs, but the point is to simplify and generalize the syntax so that it's not tied to Swing, nor SWT, or anything in particular. You can use it for Scenegraph, or just to put together the pieces of your program outside of the program, so that the components are completely self contained. I guess it's very similar to Adobe Flex, except for Java (not that it's the same exact syntax, and I don't have to create a class library, only make it easy to leverage existing libraries). Also, it would be an easy way to create forms that are bound directly to a database, like in MS Access.
It supports binding properties to expressions, whose dependencies are monitored for changes (property change listeners for JavaBeans properties, although it's completely pluggable). It supports event listeners, specified as a script. (Expresions can also contain embedded scripts, although it can't determine the script's dependencies.) Scripts can be in any language provided by the javax.script mechanism.
I'm writing it in scala, and I'm amazed at how much easier it is to program in scala. The first reason is the expressive conciseness. After trying functional programming, anything else seems full of boilerplate (doing all transformations--filters, maps, etc. manually?!). Second of all, most of the "debugging" is during the compile stage. Once the program compiles successfully, there are usually (so far anyway!) much less bugs. (Although I suppose that's more meaningful in an IDE like eclipse, where you see compile errors in place immediately, or at least after saving.) Not to mention the powerful XML support.
The project is hosted at appbuilder.dev.java.net, although I don't commit code changes anywhere near as often as I make them (once a week is a lot) since my computer is usually not connected to the internet.
I am extremely interested in hearing what people have to say about the project in general, as well as what features they would like to see. It is currently in a relatively early stage - basic examples work, some basics are still being written, e.g. executing if expressions, new expressions that refer to a class inside a variable. Also, any semantics or syntax is open to suggestions for change.
(Personally I like the idea of having one XML solution to writing declarative GUIs than having to write a separate language for JavaFX, and a wrapper library for scala-swing, and maybe another one for SWT... although I'm not saying that this would make those completely superfluous, of course, but I think that if it is successful it would be another solution with perhaps a lot less work put into it... Also, not having to compile the GUI--although it could be supported if it interests people--means faster tweaking GUIs. Also, XML means easier to create visual designers.)

Thanks,

David
 

Is there a good reason why back ticks don't work on non-simple names, or better yet, why lowercase names with parameters are taken as meaning to capture the value? Could xx(yy) capture something? Thanks!
On Wed, Jan 7, 2009 at 3:52 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

No better way using Pattern Matching, but if you've got a lot, why not use a Map:

val toDo: Map[Class[_], () => Unit] = Map(
  (classOf[String], () => println("Got a String")),
  (classOf[Object], () => println("Got an object")))

toDo(classOf[String])()



On Wed, Jan 7, 2009 at 12:44 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Thanks, but as I specifically said: "I need to match on a bunch of possibilities, so defining uppercase constants for each one isn't such a good idea"... Is there really no better way?

On Wed, Jan 7, 2009 at 3:42 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

scala> val StrCls = classOf[String]
StrCls: java.lang.Class[String] = class java.lang.String

scala> val ObjCls = classOf[Object]
ObjCls: java.lang.Class[java.lang.Object] = class java.lang.Object

scala> def m(c: Class[_]) = c match {
     | case ObjCls => "Object"      
     | case StrCls => "String"      
     | case _ => "Huh?"             
     | }
m: (Class[_])java.lang.String

scala> m(classOf[String])
res1: java.lang.String = String

scala> m(classOf[AnyRef])
res2: java.lang.String = Object

scala> m(classOf[Int])  
res3: java.lang.String = Huh?


On Wed, Jan 7, 2009 at 12:35 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

How do you pattern match on something like class literals, or for that matter anything that is only available from a function that starts with lowercase? clazz match {  case classOf[java.lang.Integer] => ... } doesn't work, and adding back ticks `...` causes the [ to be invalid syntax. I need to match on a bunch of possibilities, so defining uppercase constants for each one isn't such a good idea, and putting the comparison as an if guard:   case c if c==classOf[...] => ... seems to make pattern matching extra -- I might as well just right a bunch of if/else ifs, which is what I did in meanwhile. Another option that I don't like is matching on clazz.getName Similar situations (not tested recently):  case v.getA =>  case getCalculation(param) => Is there no straightforward solution for such a typical scenario? Thanks!  

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

On Mon, Jan 12, 2009 at 10:51 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Thanks for your interest.

You must give the type inferencer some help:
Map[Class[_], (Class[_], String)]((classOf[String], (classOf[String], "foo")), (classOf[Long], (classOf[Int], "bar")))

Is your point here to pass the type parameters explicitly to the constructor

Yes.  The type inferencer is only so good and it sometimes needs hints... plus for an important data structure like this, documenting the type is pretty important.
 

, or to use standard tuple notation (,) instead of ->?

Using the standard tuple notation is mildly easier for the compiler.
 

Also, what's your language background?  Java, Ruby, Python?

Okay... Your code has a "dynamic" feel about it, but your words have a "static" feel about them.  I like to know the background of folks so I can use the words that are most likely to resonate with them.  Thus the question.
 

More Java than anything else, although I've been doing scala for a while.
As for the previous question, to satisfy your curiosity :) here's what my project is about, tell me what you think.

I've been tilting at this windmill for years.  Back in 1999-2001, I worked on a framework called SmartMode which used XML files to describe workflow and validation.  We had a great Web UI and were working on a Swing UI.  It's a huge task to, in effect, design a new lanuage that has XML as its syntax, allows for embedded logic from other languages, and compiles down to JVM byte-code.  Best of luck on the project... I hope you wind up slaying dragons where I was only able to knock over a windmill or two.

Thanks,

David

 

It's basically following in the footsteps of projects like Jaxx, SwixML -- XML GUIs, but the point is to simplify and generalize the syntax so that it's not tied to Swing, nor SWT, or anything in particular. You can use it for Scenegraph, or just to put together the pieces of your program outside of the program, so that the components are completely self contained. I guess it's very similar to Adobe Flex, except for Java (not that it's the same exact syntax, and I don't have to create a class library, only make it easy to leverage existing libraries). Also, it would be an easy way to create forms that are bound directly to a database, like in MS Access.
It supports binding properties to expressions, whose dependencies are monitored for changes (property change listeners for JavaBeans properties, although it's completely pluggable). It supports event listeners, specified as a script. (Expresions can also contain embedded scripts, although it can't determine the script's dependencies.) Scripts can be in any language provided by the javax.script mechanism.
I'm writing it in scala, and I'm amazed at how much easier it is to program in scala. The first reason is the expressive conciseness. After trying functional programming, anything else seems full of boilerplate (doing all transformations--filters, maps, etc. manually?!). Second of all, most of the "debugging" is during the compile stage. Once the program compiles successfully, there are usually (so far anyway!) much less bugs. (Although I suppose that's more meaningful in an IDE like eclipse, where you see compile errors in place immediately, or at least after saving.) Not to mention the powerful XML support.
The project is hosted at appbuilder.dev.java.net, although I don't commit code changes anywhere near as often as I make them (once a week is a lot) since my computer is usually not connected to the internet.
I am extremely interested in hearing what people have to say about the project in general, as well as what features they would like to see. It is currently in a relatively early stage - basic examples work, some basics are still being written, e.g. executing if expressions, new expressions that refer to a class inside a variable. Also, any semantics or syntax is open to suggestions for change.
(Personally I like the idea of having one XML solution to writing declarative GUIs than having to write a separate language for JavaFX, and a wrapper library for scala-swing, and maybe another one for SWT... although I'm not saying that this would make those completely superfluous, of course, but I think that if it is successful it would be another solution with perhaps a lot less work put into it... Also, not having to compile the GUI--although it could be supported if it interests people--means faster tweaking GUIs. Also, XML means easier to create visual designers.)

Thanks,

David
 

Is there a good reason why back ticks don't work on non-simple names, or better yet, why lowercase names with parameters are taken as meaning to capture the value? Could xx(yy) capture something? Thanks!
On Wed, Jan 7, 2009 at 3:52 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

No better way using Pattern Matching, but if you've got a lot, why not use a Map:

val toDo: Map[Class[_], () => Unit] = Map(
  (classOf[String], () => println("Got a String")),
  (classOf[Object], () => println("Got an object")))

toDo(classOf[String])()



On Wed, Jan 7, 2009 at 12:44 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Thanks, but as I specifically said: "I need to match on a bunch of possibilities, so defining uppercase constants for each one isn't such a good idea"... Is there really no better way?

On Wed, Jan 7, 2009 at 3:42 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

scala> val StrCls = classOf[String]
StrCls: java.lang.Class[String] = class java.lang.String

scala> val ObjCls = classOf[Object]
ObjCls: java.lang.Class[java.lang.Object] = class java.lang.Object

scala> def m(c: Class[_]) = c match {
     | case ObjCls => "Object"      
     | case StrCls => "String"      
     | case _ => "Huh?"             
     | }
m: (Class[_])java.lang.String

scala> m(classOf[String])
res1: java.lang.String = String

scala> m(classOf[AnyRef])
res2: java.lang.String = Object

scala> m(classOf[Int])  
res3: java.lang.String = Huh?


On Wed, Jan 7, 2009 at 12:35 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

How do you pattern match on something like class literals, or for that matter anything that is only available from a function that starts with lowercase? clazz match {  case classOf[java.lang.Integer] => ... } doesn't work, and adding back ticks `...` causes the [ to be invalid syntax. I need to match on a bunch of possibilities, so defining uppercase constants for each one isn't such a good idea, and putting the comparison as an if guard:   case c if c==classOf[...] => ... seems to make pattern matching extra -- I might as well just right a bunch of if/else ifs, which is what I did in meanwhile. Another option that I don't like is matching on clazz.getName Similar situations (not tested recently):  case v.getA =>  case getCalculation(param) => Is there no straightforward solution for such a typical scenario? Thanks!  

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

P.S. what is the reason pattern matching requires a stable identifier? Why can't it be translated into complicated if/else ifs (as well as a custom PartialFunction.isDefined)?

On Mon, Jan 12, 2009 at 1:51 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Thanks for your interest.

On Wed, Jan 7, 2009 at 4:33 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

Pattern matching has to be done against a stable identifier.  classOf[String] is an expression, just as 1 +1.  Yes, the expression is unchanging, but Scala does not yet have an effects system that can determine that.  So, you need to pattern match against a pre-computed value... something that's not going to change.

You can specify the stable identifier as lower case:

val strCls = classOf[String]

and pattern match using the backticks:

def m(in: Class[_]) = m match {
  case `strCls` => ...
}

But, there's no way to pattern match against the expression classOf[String].  You must assign the expression to something.

On Wed, Jan 7, 2009 at 1:06 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

I can't do "case o: Type" because I'm passing around class literals before there is an instance: I'm parsing expression trees and need to determine the expression's type first, so double + int = double while short + int = int. I had tried the map approach and given up due to an eclipse bug for which I now seem to have a workaround: It was necessary to specify a type annotation on each element: Map( classOf[x] -> y: (Class[_], _), ... )

You must give the type inferencer some help:
Map[Class[_], (Class[_], String)]((classOf[String], (classOf[String], "foo")), (classOf[Long], (classOf[Int], "bar")))

Is your point here to pass the type parameters explicitly to the constructor, or to use standard tuple notation (,) instead of ->? Or are both helping?
Also, on scala-tools they said that with the little code snippet I gave them they problem wasn't reproducing itself, but it sounded like a resident compiler bug, so I'll see if I get around to narrowing down the problematic code and filing a bug eventually...

Gives the type inferencer enough help to get it right.

 

Also, the big problem with a map is that it's not all straightforward: Some tests are against class literals, but some need to be more general and then differentiate in other ways:   // for the & operator   case (classOf[java.lang.Boolean], classOf[java.lang.Boolean]) => classOf[Boolean]   ...   case (leftType, rightType) => // more complicated now Note that this isn't real code, just typing on the spot to illustrate the problem. And what about values that are returned from functions or methods?

Could you give us a better over-view of what you're trying to do with your application?

Also, what's your language background?  Java, Ruby, Python?

More Java than anything else, although I've been doing scala for a while.
As for the previous question, to satisfy your curiosity :) here's what my project is about, tell me what you think.
It's basically following in the footsteps of projects like Jaxx, SwixML -- XML GUIs, but the point is to simplify and generalize the syntax so that it's not tied to Swing, nor SWT, or anything in particular. You can use it for Scenegraph, or just to put together the pieces of your program outside of the program, so that the components are completely self contained. I guess it's very similar to Adobe Flex, except for Java (not that it's the same exact syntax, and I don't have to create a class library, only make it easy to leverage existing libraries). Also, it would be an easy way to create forms that are bound directly to a database, like in MS Access.
It supports binding properties to expressions, whose dependencies are monitored for changes (property change listeners for JavaBeans properties, although it's completely pluggable). It supports event listeners, specified as a script. (Expresions can also contain embedded scripts, although it can't determine the script's dependencies.) Scripts can be in any language provided by the javax.script mechanism.
I'm writing it in scala, and I'm amazed at how much easier it is to program in scala. The first reason is the expressive conciseness. After trying functional programming, anything else seems full of boilerplate (doing all transformations--filters, maps, etc. manually?!). Second of all, most of the "debugging" is during the compile stage. Once the program compiles successfully, there are usually (so far anyway!) much less bugs. (Although I suppose that's more meaningful in an IDE like eclipse, where you see compile errors in place immediately, or at least after saving.) Not to mention the powerful XML support.
The project is hosted at appbuilder.dev.java.net, although I don't commit code changes anywhere near as often as I make them (once a week is a lot) since my computer is usually not connected to the internet.
I am extremely interested in hearing what people have to say about the project in general, as well as what features they would like to see. It is currently in a relatively early stage - basic examples work, some basics are still being written, e.g. executing if expressions, new expressions that refer to a class inside a variable. Also, any semantics or syntax is open to suggestions for change.
(Personally I like the idea of having one XML solution to writing declarative GUIs than having to write a separate language for JavaFX, and a wrapper library for scala-swing, and maybe another one for SWT... although I'm not saying that this would make those completely superfluous, of course, but I think that if it is successful it would be another solution with perhaps a lot less work put into it... Also, not having to compile the GUI--although it could be supported if it interests people--means faster tweaking GUIs. Also, XML means easier to create visual designers.)

Thanks,

David
 

Is there a good reason why back ticks don't work on non-simple names, or better yet, why lowercase names with parameters are taken as meaning to capture the value? Could xx(yy) capture something? Thanks!
On Wed, Jan 7, 2009 at 3:52 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

No better way using Pattern Matching, but if you've got a lot, why not use a Map:

val toDo: Map[Class[_], () => Unit] = Map(
  (classOf[String], () => println("Got a String")),
  (classOf[Object], () => println("Got an object")))

toDo(classOf[String])()



On Wed, Jan 7, 2009 at 12:44 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Thanks, but as I specifically said: "I need to match on a bunch of possibilities, so defining uppercase constants for each one isn't such a good idea"... Is there really no better way?

On Wed, Jan 7, 2009 at 3:42 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

scala> val StrCls = classOf[String]
StrCls: java.lang.Class[String] = class java.lang.String

scala> val ObjCls = classOf[Object]
ObjCls: java.lang.Class[java.lang.Object] = class java.lang.Object

scala> def m(c: Class[_]) = c match {
     | case ObjCls => "Object"      
     | case StrCls => "String"      
     | case _ => "Huh?"             
     | }
m: (Class[_])java.lang.String

scala> m(classOf[String])
res1: java.lang.String = String

scala> m(classOf[AnyRef])
res2: java.lang.String = Object

scala> m(classOf[Int])  
res3: java.lang.String = Huh?


On Wed, Jan 7, 2009 at 12:35 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

How do you pattern match on something like class literals, or for that matter anything that is only available from a function that starts with lowercase? clazz match {  case classOf[java.lang.Integer] => ... } doesn't work, and adding back ticks `...` causes the [ to be invalid syntax. I need to match on a bunch of possibilities, so defining uppercase constants for each one isn't such a good idea, and putting the comparison as an if guard:   case c if c==classOf[...] => ... seems to make pattern matching extra -- I might as well just right a bunch of if/else ifs, which is what I did in meanwhile. Another option that I don't like is matching on clazz.getName Similar situations (not tested recently):  case v.getA =>  case getCalculation(param) => Is there no straightforward solution for such a typical scenario? Thanks!  

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

On Mon, Jan 12, 2009 at 11:31 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

P.S. what is the reason pattern matching requires a stable identifier? Why can't it be translated into complicated if/else ifs (as well as a custom PartialFunction.isDefined)?

One reason is to be able to optimize the pattern matching (which is done.)  Imagine:

def foo: Int = randomInt(0, 100)

x match {
  case (`foo`, "Bar") =>something
  case (`foo`, "Baz") => somethingElse
}
 
In this case, without a stable identifier, you cannot reduce this to:

if (x._1 == foo) {
  if (x._2 == "Bar") {something}
  else if (x._2 == "Baz") {somethingElse}
}

On Mon, Jan 12, 2009 at 1:51 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Thanks for your interest.

On Wed, Jan 7, 2009 at 4:33 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

Pattern matching has to be done against a stable identifier.  classOf[String] is an expression, just as 1 +1.  Yes, the expression is unchanging, but Scala does not yet have an effects system that can determine that.  So, you need to pattern match against a pre-computed value... something that's not going to change.

You can specify the stable identifier as lower case:

val strCls = classOf[String]

and pattern match using the backticks:

def m(in: Class[_]) = m match {
  case `strCls` => ...
}

But, there's no way to pattern match against the expression classOf[String].  You must assign the expression to something.

On Wed, Jan 7, 2009 at 1:06 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

I can't do "case o: Type" because I'm passing around class literals before there is an instance: I'm parsing expression trees and need to determine the expression's type first, so double + int = double while short + int = int. I had tried the map approach and given up due to an eclipse bug for which I now seem to have a workaround: It was necessary to specify a type annotation on each element: Map( classOf[x] -> y: (Class[_], _), ... )

You must give the type inferencer some help:
Map[Class[_], (Class[_], String)]((classOf[String], (classOf[String], "foo")), (classOf[Long], (classOf[Int], "bar")))

Is your point here to pass the type parameters explicitly to the constructor, or to use standard tuple notation (,) instead of ->? Or are both helping?
Also, on scala-tools they said that with the little code snippet I gave them they problem wasn't reproducing itself, but it sounded like a resident compiler bug, so I'll see if I get around to narrowing down the problematic code and filing a bug eventually...

Gives the type inferencer enough help to get it right.

 

Also, the big problem with a map is that it's not all straightforward: Some tests are against class literals, but some need to be more general and then differentiate in other ways:   // for the & operator   case (classOf[java.lang.Boolean], classOf[java.lang.Boolean]) => classOf[Boolean]   ...   case (leftType, rightType) => // more complicated now Note that this isn't real code, just typing on the spot to illustrate the problem. And what about values that are returned from functions or methods?

Could you give us a better over-view of what you're trying to do with your application?

Also, what's your language background?  Java, Ruby, Python?

More Java than anything else, although I've been doing scala for a while.
As for the previous question, to satisfy your curiosity :) here's what my project is about, tell me what you think.
It's basically following in the footsteps of projects like Jaxx, SwixML -- XML GUIs, but the point is to simplify and generalize the syntax so that it's not tied to Swing, nor SWT, or anything in particular. You can use it for Scenegraph, or just to put together the pieces of your program outside of the program, so that the components are completely self contained. I guess it's very similar to Adobe Flex, except for Java (not that it's the same exact syntax, and I don't have to create a class library, only make it easy to leverage existing libraries). Also, it would be an easy way to create forms that are bound directly to a database, like in MS Access.
It supports binding properties to expressions, whose dependencies are monitored for changes (property change listeners for JavaBeans properties, although it's completely pluggable). It supports event listeners, specified as a script. (Expresions can also contain embedded scripts, although it can't determine the script's dependencies.) Scripts can be in any language provided by the javax.script mechanism.
I'm writing it in scala, and I'm amazed at how much easier it is to program in scala. The first reason is the expressive conciseness. After trying functional programming, anything else seems full of boilerplate (doing all transformations--filters, maps, etc. manually?!). Second of all, most of the "debugging" is during the compile stage. Once the program compiles successfully, there are usually (so far anyway!) much less bugs. (Although I suppose that's more meaningful in an IDE like eclipse, where you see compile errors in place immediately, or at least after saving.) Not to mention the powerful XML support.
The project is hosted at appbuilder.dev.java.net, although I don't commit code changes anywhere near as often as I make them (once a week is a lot) since my computer is usually not connected to the internet.
I am extremely interested in hearing what people have to say about the project in general, as well as what features they would like to see. It is currently in a relatively early stage - basic examples work, some basics are still being written, e.g. executing if expressions, new expressions that refer to a class inside a variable. Also, any semantics or syntax is open to suggestions for change.
(Personally I like the idea of having one XML solution to writing declarative GUIs than having to write a separate language for JavaFX, and a wrapper library for scala-swing, and maybe another one for SWT... although I'm not saying that this would make those completely superfluous, of course, but I think that if it is successful it would be another solution with perhaps a lot less work put into it... Also, not having to compile the GUI--although it could be supported if it interests people--means faster tweaking GUIs. Also, XML means easier to create visual designers.)

Thanks,

David
 

Is there a good reason why back ticks don't work on non-simple names, or better yet, why lowercase names with parameters are taken as meaning to capture the value? Could xx(yy) capture something? Thanks!
On Wed, Jan 7, 2009 at 3:52 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

No better way using Pattern Matching, but if you've got a lot, why not use a Map:

val toDo: Map[Class[_], () => Unit] = Map(
  (classOf[String], () => println("Got a String")),
  (classOf[Object], () => println("Got an object")))

toDo(classOf[String])()



On Wed, Jan 7, 2009 at 12:44 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Thanks, but as I specifically said: "I need to match on a bunch of possibilities, so defining uppercase constants for each one isn't such a good idea"... Is there really no better way?

On Wed, Jan 7, 2009 at 3:42 PM, David Pollak <feeder.of.the.bears@gmail.com> wrote:

scala> val StrCls = classOf[String]
StrCls: java.lang.Class[String] = class java.lang.String

scala> val ObjCls = classOf[Object]
ObjCls: java.lang.Class[java.lang.Object] = class java.lang.Object

scala> def m(c: Class[_]) = c match {
     | case ObjCls => "Object"      
     | case StrCls => "String"      
     | case _ => "Huh?"             
     | }
m: (Class[_])java.lang.String

scala> m(classOf[String])
res1: java.lang.String = String

scala> m(classOf[AnyRef])
res2: java.lang.String = Object

scala> m(classOf[Int])  
res3: java.lang.String = Huh?


On Wed, Jan 7, 2009 at 12:35 PM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

How do you pattern match on something like class literals, or for that matter anything that is only available from a function that starts with lowercase? clazz match {  case classOf[java.lang.Integer] => ... } doesn't work, and adding back ticks `...` causes the [ to be invalid syntax. I need to match on a bunch of possibilities, so defining uppercase constants for each one isn't such a good idea, and putting the comparison as an if guard:   case c if c==classOf[...] => ... seems to make pattern matching extra -- I might as well just right a bunch of if/else ifs, which is what I did in meanwhile. Another option that I don't like is matching on clazz.getName Similar situations (not tested recently):  case v.getA =>  case getCalculation(param) => Is there no straightforward solution for such a typical scenario? Thanks!  

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

I've been tilting at this windmill for years.  Back in 1999-2001, I worked on a framework called SmartMode which used XML files to describe workflow and validation.  We had a great Web UI and were working on a Swing UI.  It's a huge task to, in effect, design a new lanuage that has XML as its syntax, allows for embedded logic from other languages, and compiles down to JVM byte-code.  Best of luck on the project... I hope you wind up slaying dragons where I was only able to knock over a windmill or two.

Thanks,

David

Did you see the sample XML file on the site? (http://appbuilder.dev.java.net) It's pretty minimal, but it works. Also I wish people would subscribe to the mailing list to discuss it. Probably nobody knows about it.

On Tue, Jan 13, 2009 at 8:52 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

I've been tilting at this windmill for years.  Back in 1999-2001, I worked on a framework called SmartMode which used XML files to describe workflow and validation.  We had a great Web UI and were working on a Swing UI.  It's a huge task to, in effect, design a new lanuage that has XML as its syntax, allows for embedded logic from other languages, and compiles down to JVM byte-code.  Best of luck on the project... I hope you wind up slaying dragons where I was only able to knock over a windmill or two.

Thanks,

David

Did you see the sample XML file on the site? (http://appbuilder.dev.java.net) It's pretty minimal, but it works. Also I wish people would subscribe to the mailing list to discuss it. Probably nobody knows about it.

I did.  The simple cases are, well, simple.  The problem is that complex user interaction (e.g., changing what fields are displayed dynamically when a given item is chosen from a pull-down.)  There's just a ton of stuff that gets very hard or very verbose when you're trying to build a declarative system that replaces code written in an imperative form.  


--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp