Re: Newbie: Java to Scala translation problems

If you want to iterate over the lines you could use scala.io.Source:

    import scala.io.Source
    val source = Source.fromInputStream(process.getInputStream)
    for (line <- source.getLines) print(line)

An alternative to using "for" is to use "foreach":

  source.getLines foreach print

Some might think of it as a train wreck, but then you could have:

  Source.fromInputStream(process.getInputStream).getLines foreach print

Re: Welcome to scala-xml!

Re: Welcome to scala-xml!

Meredith Gregory wrote:
> Ricky's correct, i was speaking of a backing store. So, in the case of 
> SQL, we are looking at a RDBMS, such as MySQL while in the case of 
> XQuery we are looking at something like BDBXML.
Got it... So if you have a widely used root element you don't want to 
lock out everybody who might be making changes way down in the guts of 
the document.
> You can probably get a reasonable factorization pushing commits to 
> some surrounding context, but i need to think about this a bit more. i 
> would certainly like a do-notation like widget in which what appears 
> to be an atomic "assignment" makes a commit to store that the 
> remainder of the straight line code can rely on to have happened.
This is actually something I've been thinking about--without any 
concrete result--for a long time.  The challenge is how to safely 
accomplish actual mutations in a complex object graph, in which calls to 
"setters" are really deferred transformations, while presenting users 
with an idiomatic OO view.  After thinking about it for a depressingly 
long time, I realized that STM was likely a big part of the answer; the 
challenge then became how to expose STM functionality while retaining a 
"look and feel" that's as OO-idiomatic as possible.  Scala's implicits 
would of course be able to play a big role here.

The JVSTM (http://web.ist.utl.pt/~joao.cachopo/jvstm/) guy has come up 
with what I feel is a good compromise solution--he invented a Java-like 
but intentionally limited language for describing classes 
declaratively--without reference to STM--including their properties, 
relationships and invariants, which is then fed into a code generator.  
While code generation is often thought to result in two-way issues, he 
makes a pretty good case for it.

At this point I'm waiting to see what Martin comes up with 
(http://lampsvn.epfl.ch/trac/scala/changeset/16836/scalax) before I dive 
back in to my futile wandering. :)

-0xe1a

Re: Welcome to scala-xml!

Compilation of complex match expressions - Quadratic explosion possible?

I'm in the process of developing a variety of intentions and inspections for
IntelliJ IDEA's Scala support, and ran across an interesting issue.  For
several desirable code transformations, it is necessary to be able to
calculate whether two Scala expressions have equivalent parse trees, up to
some simple transformations.   I've been using Scala's pattern matching
extensively in this project, and have created a large set of extractors to
allow convenient matching against the JetBrains Scala AST, so I naturally
turned to it for this problem.  My first cut looked something like

  def isEquivalent(exp1: ScExpression, exp2: ScExpression): Boolean =
    (exp1, exp2) match {
      case (literal1: ScLiteral, literal2: ScLiteral) => literal1.getText ==
literal2.getText
      case (InfixExpr(lhs1, op1, rhs1), InfixExpr(lhs2, op2, rhs2)) => op1
== op2 && isEquivalent(lhs1, lhs2) && isEquivalent(rhs1, rhs2)
      case (PrefixExpr(op1, operand1), PrefixExpr(op2, operand2)) => op1 ==
op2 && isEquivalent(operand1, operand2)
      case (PostfixExpr(op1, operand1), PostfixExpr(op2, operand2)) => op1
== op2 && isEquivalent(operand1, operand2)
      case (Return(None), Return(None)) => true
      case (Return(Some(val1)), Return(Some(val2))) => isEquivalent(val1,
val2)
      case (Throw(val1), Throw(val2)) => isEquivalent(val1, val2)
      case (While(cond1, body1), While(cond2, body2)) => isEquivalent(cond1,
cond2) && isEquivalent(body1, body2)
      case (Do(cond1, body1), Do(cond2, body2)) => isEquivalent(cond1,
cond2) && isEquivalent(body1, body2)
      case (Tuple(ops1), Tuple(ops2)) => ops1.length== ops2.length &&
ops1.equalsWith(ops2, isEquivalent(_, _))
      case (Block(ops1), Block(ops2)) => ops1.length== ops2.length &&
ops1.equalsWith(ops2, isEquivalent(_, _))
      case _ => false
    }

This worked fine, but as I added more cases, the compilation got slower and
slower, and eventually when it got to the size shown would simply fail to
compile, with some cryptic error message that indicated that some method had
gotten too long.   It seems as though this sort of pattern matching against
pairs of extractors engenders some odd quadratic behaviour. (It doesn't seem
to have anything to do with tail recursion, as it still occurs if I recode
it with a debugging println after the match.)  I've rewritten the
equivalence checker to use nested match expressions instead, and the problem
goes away, but I was looking for some insight as to why this might have
occured.  Any pointers to the mechanics of compilation of match expressions
would be geatly appreciated.  Ideally, I would then take those insights,
automate them, and have IDEA tell me when matches were getting problematic.

And as an aside, I'll take this opportunity to say that Scala extractors
aren't better than sex, but sliced bread is pretty worried.   I realize they
probably aren't all that interesting from a type-theoretic standpoint, but
from a business point of view, it means I get to pitch Scala by saying "And
using this feature, you can code up pretty much any of your common business
rules in a way that is clear, concise, nestable, cascadable, reusable, and
independent of the underlying data structure.  Oh, and it also works with
XML.  Now let me show you for-comprehensions, which lets you do the same for
your looping logic..."  That code sample above is about 10% of the size of
the equivalent Java, and vastly more likely to be correct the moment it is
written (or would be, um, if it compiled).  Good work.
--

-- 
View this message in context: http://www.nabble.com/Compilation-of-complex-match-expressions---Quadratic-explosion-possible--tp21790310p21790310.html
Sent from the Scala mailing list archive at Nabble.com.

Jane Street Summer Program

Scala plugin for IntelliJ IDEA: how-to and feature list

Re: Scala plugin for IntelliJ IDEA: how-to and feature list

Hi,

On Tue, Feb 3, 2009 at 12:01 AM, Ilya Sergey <ilya.sergey <at> jetbrains.com> wrote:
> Hello, all!
>
> To eliminate multiple questions and misunderstandings related to Scala
> plugin for IntellilJ IDEA we've created complete list of current available
> features with appropriate descriptions. All this stuff and short "getting
> started" guide can be found at
> http://www.jetbrains.net/confluence/display/SCA/Scala+Plugin+for+IntelliJ+IDEA
> All comments and remarks are appreciated!

Thanks for putting this up. I have been planning to switch to IntelliJ
for a while and was wondering if it supports
importing of existing scala projects ?

I have rather non-trivial scala project, which i have been managing
using buildr so far (and hence my project follows maven layout) and
trying to import it into Eclipse/Netbeans has met with failure (on
various levels in spite of using buildr task for generating eclipse
project file). I wouldn't want to lose my version control history.

Re: Scala plugin for IntelliJ IDEA: how-to and feature list

[ANN] Italian Scala User Group

Some days ago the Italian Scala User Group started on google groups:

http://groups.google.com/group/sug-it

I hope it will be usefull for italian Scala programmers.

Bye

Franco

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
http://www.francolombardo.net
Scala, Java, As400.....
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~