Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
Is there a Scala library that parses Scala and creates an Abstract Syntax Tree (AST)?
Ideally I am interested in a Scala library. Plan B would be a Java library.
(I know I could leverage the EBNF from the Scala Syntax Summary.)
I would think the best way to access the AST is with a compiler plugin. You should read a soft introduction before diving in deep.
A few existing parsers:
The offical Scala compiler.
The IntelliJ IDEA Scala plugin has a parser written in Scala against IntelliJ's PsiBuilder API.
The Scala Netbeans plugin used a parser implemented in Rats! (which generates Java code), but "replaced these parser and analyzer by Scala's native compiler".
The Scala-rules project, written in Scala.
Be cautious if using the EBNF from the spec, there are apparently:
"mismatches between the appendix and the inline grammar, and mismatches between the language compiled by scalac (and utilized in the scala sources) and the language claimed by the grammar" -- Scala Trac bug #1826.
You can't build an AST for Scala from the grammar alone. There's implicits to consider, and, to consider them, there is the type inferencer to consider.
You can, however, call the compiler itself -- it is just a jar file, after all. Scala 2.8, in particular, has quite a few hooks for other programs to latch on -- work of Miles Sabin, who is doing this precisely so that the Eclipse plugin for Scala can leverage the compiler in such way.
I suggest you go to the Scala Tools mailing list, and get in contact with people there.
If you want to generate AST of a piece of code. You could use scala reflection:
showRaw(reify{
//your code here like:
print(2)
})
The code above will generate an AST:
Expr(Apply(Select(Ident(scala.Predef), TermName("print")), List(Literal(Constant(2)))))
Reference:
http://docs.scala-lang.org/overviews/reflection/symbols-trees-types.html
Here is a project by one of the compiler committers http://github.com/paulp/scala-lang-combinators
Not sure about the pure scala solutions, but if you find yourself needing to implement plan B, you can start by checking out ANTLR or Rats!
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
What are the advantages of the object package syntax over simply letting you add functions and variables to a package ?
example:
package object something {
def hello = 0
}
package something {
}
Why not simply:
package something {
def hello = 0
// other classes and such
}
You could even go one step further: why have packages at all, when we have objects?
Scala is intended to be useful as a "hosted language", i.e. a language that can play nicely being hosted on top of another language's platform. The original implementations of Scala were on the Java platform and the ISO Common Language Infrastructure platform (or rather its primary implementations, .NET and Mono). Today, we also have an implementation on the ECMAScript platform (Scala.js), and the Java platform implementation can also be used on Android, for example. You can imagine other interesting platforms as well, that you would like to run Scala on, e.g. the Windows UWP platform, the Swift/Objective-C/Core Foundation/macOS/iOS/tvOS/watchOS platform, the Gnome/GObject platform, the Qt/C++ platform, etc.
Scala does not just intend to run on those platforms, it intends to fulfill two, often conflicting, goals:
high performance
tight integration with a "native" feel
So, in Scala, implementation concerns are part of language design. (Rich Hickey, the designer of Clojure, once said in a talk "the JVM is not an implementation detail", the same applies to Scala.) A good example are proper tail calls: in order to support proper tail calls, Scala would have to manage its own stack instead of using the host platform's native call stack on platforms like the JVM, which however means that you can no longer easily call Scala code from other code on the platform and vice versa. So, while proper tail calls would be nice to have, Scala settles for the less powerful proper immediate tail recursion.
Theoretically, Scala needs only objects, traits, methods, types, and paths (. and #). Everything else is basically just there to ease integration with the host platform. This includes, for example, null, classes, and packages.
Ideally, there should be an easy mapping from host platform constructs to Scala constructs and vice versa. So, for example, there is an easy mapping between Scala methods and JVM methods. There is an easy mapping between JVM interfaces and Scala traits with only abstract members. There is no easy mapping between Scala traits and JVM classes, which is why Scala has the (redundant) concept of classes as well. And similarly, there is no easy mapping between Scala objects and JVM packages (or CLI namespaces), which is why Scala has the (redundant) concept of package as well.
However, we would really like packages (which are, after all, somewhat like Scala objects) to have members as well. But JVM packages and CLI namespaces can't have members other than interfaces and classes, and since we only introduced them in Scala for compatibility with the host platform it simply doesn't make sense to make them incompatible with the host platform by adding members to them.
So, we introduce yet another separate concept, the package object, which holds the members we would like to add to packages but can't, because of host platform interoperability.
tl;dr:
we have packages because of interop (even though we already have objects, which can do all the same things as packages)
we would like packages to have members
packages can't have members, because interop
so, we have package objects as companions to packages
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
When we read the wikipedia description of the Kotlin programming language, it is stating that:
JetBrains lead Dmitry Jemerov said that most languages did not have the features they were looking for, with the exception of Scala. However, he cited the slow compile time of Scala as an obvious deficiency.[4] One of the stated goals of Kotlin is to compile as quickly as Java.
How did they achieve that goal? And why is Scala compile time so slow that it was unacceptable for the Kotlin creators? Or - in other words - which features of the Scala compiler make it slower than the Kotlin compiler?
Although I think the question is not well suited for Stack Overflow as it will tend to produce primarily opinion based answers, here is one attempt: You have two different languages, especially concerning the type system, and two completely independent implementations of compilers. So to expect them to have the "same" kind of compilation speed is already a fallacy. I have linked in my comment to another question that examines the speed of the Scala compiler. Basically, it depends on many factors, for example the amount of work that the type inferencer and implicit resolution required by a specific code base.
Nevertheless, I ran a very quick example: I compiled some Project Euler solutions in Kotlin and Scala. This gave me for a fresh re-compile of the whole project:
6 seconds in Kotlin (down to 5 seconds in successive re-builds)
10 seconds in Scala (down to 7 seconds in successive re-builds).
Origin of the source code:
I took this code for Kotlin, changed a lot of imports because apparently the Kotlin standard library changed in the meantime, in order to make it compile.
I took this code for Scala, and converted it into an sbt project with each problem wrapped in an object pXY extends App { ... } and placed it in a package euler.
Then I removed the files for which only one solution existed, ending up with 26 problems. Both projects were compiled with IntelliJ IDEA 15 CE using Rebuild Project.
To give another perspective on this business, I ran wc (word count) on the sources:
// lines words bytes
931 3603 33087 total // Kotlin
261 1166 6472 total // Scala
So now you can either argue that the Kotlin compiler needed to process "more source code" or that the Scala code was "more dense" :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
How does one organise code in a Scala project?
After years of developing with Java (most of the times using Spring), we're trying to come up with a quick prototype in Scala.
One of the first questions that popped up is: will we just basically use the same package names and code organisation and just write code in Scala?
For example, we're used to have helpers for our entities (AccountHelper, CacheHelper...) and also sometimes we use services too (AccountService...).
ot: Further away we'll also investigate on how to port our maven submodules to sbt, but that's a different story altogether.
The answer partly depends on what is most important to you. If you are really serious about the quick prototype part, then as far as the physical file/directory layout, I would just start with one flat file and only start breaking it up when there is enough code to make that awkward. This should at least make global restructuring of your code easier until you get the overall structure right. Scala does not enforce the package:directory, class:file correspondence, and given the conciseness of Scala that can be overkill in many cases anyway.
There is nothing to stop you organizing things into multiple packages within the one file before you break it up physically once you have the structure right. Actually breaking the file up when you need to should be very easy then.
You did not say much about what your Helper & Service classes do, but from the naming convention they sound like good candidates for generic (aka parametric) traits or classes. This would allow you to factor out what all the different Helpers have in common (and similarly for Services). They should have a fair bit in common to justify the naming convention. You would then end up using or possibly extending types like Helper[Cache] and Service[Account]. I am also guessing these types will have few instances with rather broad scope and may benefit from being passed around implicitly, making Helper[_] and Service[_] into type classes. It is also possible that you will no longer need Spring at this point, since implicit lookup may give you the dependency injection you need. However, I am just going by a few class names you provided and reading an awful lot into them, so the chances are that I am completely off base here.
Another possibility is that auxiliary classes like Helper & Service are just closures in disguise. This is a fairly common case with such classes in Java. In this case you should just implement them as functions in Scala, but again I am just guessing from the names...
You could also look into the Layer Cake pattern and see if that makes sense for your project.
More information about your project would probably get you better advice than these products of my overactive imagination :).
Hera are some potentially useful links:
http://jonasboner.com/real-world-scala-dependency-injection-di/
Where does Scala look for implicits?
http://www.youtube.com/watch?v=yLbdw06tKPQ
https://vimeo.com/20308847
http://www.youtube.com/watch?v=YZxL0alO1yc
I organize packages in basically the same way, but wind up
implementing things differently.
When I first started writing scala coming from java it took me a while
to get used to a few things:
Use companion objects instead of "static"
class Bla { }
object Bla { ... }
Forget about "get*", "set*" getters and setters - use val, var - prefer val.
Get to know scala.collection., Option, and scala.collection.JavaConversions. -
(which provides implicit conversion between java and scala collection types),
so you can write code like this:
class Helper {
def lookupUser( name:String ):Option[UserInfo]
...
}
val jsonUsers:Seq[String] =
Seq( "fred", "mary", "jose" ).flatMap(
name => helper.lookupUser( name )
).map( info => helper.toJson( info ) )
or
val jsonUsers:Seq[String] = for ( name <- Seq( "fred", "mary", "jose" );
info <- helper.lookupUser( name )
) yield helper.toJson( info )
or
val jsResult = helper.lookupUser( "fred" ).map( info => helper.toJson( info )
).getOrElse( jsErrorRespose )
If you feel comfortable with that kind of code, then you have a good start ...
Good luck!
We already had our whole platform written in java. And i was very enthusiastic about scala at work. So i just added my scala code to the existing code base on the same level i.e. src/main/java also i found almost 100% compatibility from scala to java with great ease. Just include the maven scala plugin and it works.
But i would suggest keeping the scala code under src/main/scala for a cleaner code base organisation and also help in resolving minor compiler dependencies. Also having a dual build both in sbt and mvn gives great flexibility for build process.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I am .NET developer and I'd like to broaden my horizons a bit and after checking out modern tendencies decided to try Scala. Can you please advise a good strategy to start on it? Should I learn Java first? What source or handbook should I read? Is there any OS projects to practice Scala and grow on them?
Thanks,
Dominique
You might gain a first impression by visiting Simply Scala where you have an online interpreter available.
An absolute classic is Scala for Java Refugees which was originally written for people coming from Java, but will be quite helpful for you, considering how similar the basics of C#/Java are.
You don't need to learn Java first , but you need to have the Java runtime/development kit installed and working.
Then go to http://www.scala-lang.org/downloads and download the appropriate package for your operating system (I always prefer the nightly builds of Scala, they have more bug-fixes than the latest stable one).
After that, run the Scala REPL which is basically "Simply Scala offline" (Simply Scala uses the Scala REPL behind the covers, too). Even many Java programmers use the Scala REPL to prototype things first.
If you prefer books to learn I can recommend Programming in Scala (2nd edition) by Martin Odersky (if you start from a language design point of view and want the "reference book"). There are others like "Programming Scala" which are more targeted at beginners so to speak, but personally I found "Programming in Scala" excellent and have learned Scala with just that book.
A nice way to start Scala is working with the collection classes. .NET has added something similar lately with LINQ and extension methods, so it will be easy to pick up for you.
A small example to get you started:
//Define a class with some properties
case class Person(name: String, var age: Int, spokenLanguages: String*)
//Create some persons
val joe = Person("Joe", 42, "English","French","Danish")
val doe = Person("Doe", 23, "English","German")
val don = Person("Don", 11, "Italian","French","Polish")
val bob = Person("Bob", 17, "German")
//Access a property
joe.name
//Don had his 12th birthday!
don.age = 12
//Put the persons into a list
val persons = List(joe, doe, don, bob)
//Divide the list into minors and adults
val (minors, adults) = persons.partition(_.age < 18)
//Get the total age of all persons
val personsTotalAge = persons.map(_.age).sum
//Return a list with only those speaking English
val englishSpeakers = persons.filter(_.spokenLanguages.contains("English"))
//Same as the example above.
val englishSpeakers2 =
for{ person <- persons
language <- person.spokenLanguages
if language == "English"
} yield person
I'm not that fluent in C#, but I believe many things might look similar to you.
Some examples of Scala's XML support:
//The shoppingCart for breakfast
val shoppingCart = <list>
<item><name>Tomatoes</name><price>0.30</price><amount>4</amount></item>
<item><name>Eggs</name><price>0.15</price><amount>10</amount></item>
<item><name>Bread</name><price>2.20</price><amount>1</amount></item>
</list>
//How much does it cost?
val total = (shoppingCart \ "item").map(i => (i \ "price").text.toDouble * (i \ "amount").text.toDouble).sum
//This is a Symbol
val sym = 'SomeSymbol
//I'm too lazy to use Strings for XML! (Example for implicits)
implicit def symbol2string(symbol: Symbol) = symbol.name
//Now I can use Symbols too!
val total = (shoppingCart \ 'item).map(i => (i \ 'price).text.toDouble * (i \ 'amount).text.toDouble).sum
You don't need to learn Java first. Are you familiar with functional programming? If you are, you should be able to jump in quite fast. Anyway, here are some thoughts on how you can learn Scala:
Get a good reference book. I recommend Programming In Scala by Odersky, Spoon, and Venners. I find it as one of the most comprehensive Scala books.
As with learning any new language, try writing several small application using Scala. If you're not a functional programmer, you might program it in a different paradigm, but that's okay for now. Try writing your program without using "var, (use val instead)" not using loops, and minimizing state change overall.
Use sbt to build your program. I'm kinda hesitant to recommend this since you have to learn a new tool to write your program. But I find it a great too to write Scala apps with. And many Scala projects use sbt it seems like.
Also check out this comment and that thread overall to help you transition to Scala. Struggle against habits formed by Java when migrating to Scala
Java as a language will not be necessary to start with scala (and anyway java itself is very similar to c#, or actually it's the other way around...).
Once you start doing productive things with scala, though, you will be interacting with a lot of java libraries and learn that java-world is a much broader galaxy of more-or-less standard libraries than .net-world where a lots of the things you need are directly in the standard .NET libraries. You can learn them as you go, but not coming from a java background, the experience might feel overwhelming. It would be the same thing had you started learning java, though....
Other java-specific things you may have to learn are about generics being much less powerful in the JVM and how scala tries to work around this.
As for scala itself as a language, coming from .NET, you may benefit more from reading a few things on functional programming than from learning java. The functional paradigm is the part where I was the most ignorant in my initial approach to scala and that caused me the most trouble in understanding example code from the resources you can find on the scala website.
Building a foundation
For functional programming I would recommend reading SICP (it's online and free).
While you learn java try to take a look at F#. It's a good language, it's well documented and "lives" in the .NET ecosystem
learning scala
Resources on the scala website
Daniel Spiewak's blog
If you want to learn Scala, you'll be much better served by learning Scala and picking up the Java you need as you go. You don't need to learn Java to be able to start using Scala.
A good place to start would be reading through this question, which lists most of the Scala books currently available.
https://stackoverflow.com/questions/3359852/scala-programming-book/3360308#3360308
I don't think you need to know Java to get started on Scala. It's helpful to know the broad strokes though, because most Scala documentation I have read refers back to Java features or bugs.
Regarding Open Source projects, you cna have a look on Github for scala projects. Most open source Scala projects tend to be frameworks, though.
Regarding books, I found both the Artima book, Programming in Scala, and the Pragmatic Programmers, Programming Scala, very good.
In addition to the others: Write simple programs for a while and completely ignore advanced features of Scala. Only move there when you have a good grasp of the basics, the functional paradigm und the type system.
I advise you to take part in Coursera Functional Programming Principles in Scala by Martin Odersky. There are video lectures, assignments and even final exam.
Twitter (one of the scala lovers) recently unveiled their own scala complete tutorial -- Scala School. It is awesome guide which I recommend to all scala beginners.
Scala school was started as a series of lectures at Twitter to prepare
experienced engineers to be productive Scala programmers. ... We
think it makes the most sense to approach teaching Scala not as if
it's an improved Java but as a new language. Experience in Java is not
expected. Focus will be around the interpreter and the
object-functional style as well as the style of programming we do
here. An emphasis will be placed on maintainability, clarity of
expression, and leveraging the type system.
Most of the lessons require no software other than a Scala REPL. The
reader is encouraged to follow along, and go further! Use these
lessons as a starting point to explore the language.
I'm currently developing one which doesn't require prior programming knowledge. It will show the strength of combining functional and imperative programming, and it is very simple to follow. Furthermore, the posts will cover best practice and solve increasingly difficult problems using Scala.
http://vigtig.it/blog/
You should give it a try, part 2 is almost finished :)
Download and install Apache Maven. Use it to create a blank Scala project and write the classic Scala hello world application. This will require you to configure the pom.xml file in the project directory that Maven creates.
Then run mvn compile over and over, correcting errors until it compiles.
Then run mvn package until you pass all the unittests.
And finally, run mvn scala:run
Once you build a real project scala:run has an option to spit out the full Java command needed to run it from a shell script or batch file.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
On the surface Groovy and Scala look pretty similar, aside from Scala being statically typed, and Groovy dynamic.
What are the other key differences, and advantages each have over the other?
How similar are they really?
Is there competition between the two?
If so, who do you think will win in the long run?
They're both object oriented languages for the JVM that have lambdas and closures and interoperate with Java. Other than that, they're extremely different.
Groovy is a "dynamic" language in not only the sense that it is dynamically typed but that it supports dynamic meta-programming.
Scala is a "static" language in that it is statically typed and has virtually no dynamic meta-programming beyond the awkward stuff you can do in Java. Note, Scala's static type system is substantially more uniform and sophisticated than Java's.
Groovy is syntactically influenced by Java but semantically influenced more by languages like Ruby.
Scala is syntactically influenced by both Ruby and Java. It is semantically influenced more by Java, SML, Haskell, and a very obscure OO language called gBeta.
Groovy has "accidental" multiple dispatch due to the way it handles Java overloading.
Scala is single dispatch only, but has SML inspired pattern matching to deal with some of the same kinds of problems that multiple dispatch is meant to handle. However, where multiple dispatch can only dispatch on runtime type, Scala's pattern matching can dispatch on runtime types, values, or both. Pattern matching also includes syntactically pleasant variable binding. It's hard to overstress how pleasant this single feature alone makes programming in Scala.
Both Scala and Groovy support a form of multiple inheritance with mixins (though Scala calls them traits).
Scala supports both partial function application and currying at the language level, Groovy has an awkward "curry" method for doing partial function application.
Scala does direct tail recursion optimization. I don't believe Groovy does. That's important in functional programming but less important in imperative programming.
Both Scala and Groovy are eagerly evaluated by default. However, Scala supports call-by-name parameters. Groovy does not - call-by-name must be emulated with closures.
Scala has "for comprehensions", a generalization of list comprehensions found in other languages (technically they're monad comprehensions plus a bit - somewhere between Haskell's do and C#'s LINQ).
Scala has no concept of "static" fields, inner classes, methods, etc - it uses singleton objects instead. Groovy uses the static concept.
Scala does not have built in selection of arithmetic operators in quite the way that Groovy does. In Scala you can name methods very flexibly.
Groovy has the elvis operator for dealing with null. Scala programmers prefer to use Option types to using null, but it's easy to write an elvis operator in Scala if you want to.
Finally, there are lies, there are damn lies, and then there are benchmarks. The computer language benchmarks game ranks Scala as being between substantially faster than Groovy (ranging from twice to 93 times as fast) while retaining roughly the same source size. benchmarks.
I'm sure there are many, many differences that I haven't covered. But hopefully this gives you a gist.
Is there a competition between them? Yes, of course, but not as much as you might think. Groovy's real competition is JRuby and Jython.
Who's going to win? My crystal ball is as cracked as anybody else's.
scala is meant to be an oo/functional hybrid language and is very well planned and designed. groovy is more like a set of enhancements that many people would love to use in java.
i took a closer look at both, so i can tell :)
neither of them is better or worse than the other. groovy is very good at meta-programming, scala is very good at everything that does not need meta-programming, so...i tend to use both.
Scala has Actors, which make concurrency much easier to implement. And Traits which give true, typesafe multiple inheritance.
You've hit the nail on the head with the static and dynamic typing. Both are part of the new generation of dynamic languages, with closures, lambda expressions, and so on. There are a handful of syntactic differences between the two as well, but functionally, I don't see a huge difference between Groovy and Scala.
Scala implements Lists a bit differently; in Groovy, pretty much everything is an instance of java.util.List, whereas Scala uses both Lists and primitive arrays. Groovy has (I think) better string interpolation.
Scala is faster, it seems, but the Groovy folks are really pushing performance for the 2.0 release. 1.6 gave a huge leap in speed over the 1.5 series.
I don't think that either language will really 'win', as they target two different classes of problems. Scala is a high-performance language that is very Java-like without having quite the same level of boilerplate as Java. Groovy is for rapid prototyping and development, where speed is less important than the time it takes for programmers to implement the code.
Scala has a much steeper learning curve than Groovy. Scala has much more support for functional programming with its pattern matching and tail based recursion, meaning more tools for pure FP.
Scala also has dynamica compilation and I have done it using twitter eval lib (https://github.com/twitter/util ). I kept scala code in a flat file(without any extension) and using eval created scala class at run time.
I would say scala is meta programming and has feature of dynamic complication