With the advent of multi-core processors concurrent programming is becoming indispensable. Scala's primary concurrency construct is actors. Actors are basically concurrent processes that communicate by exchanging messages. Actors can also be seen as a form of active objects where invoking a method corresponds to sending a message. The Scala Actors library provides both asynchronous and synchronous message sends (the latter are implemented by exchanging several asynchronous messages). Moreover, actors may communicate using futures where requests are handled asynchronously, but return a representation (the future) that allows to await the reply. This tutorial is mainly designed as a walk-through of several complete example programs Our first example consists of two actors that exchange a bunch of messages and then terminate. The first actor sends "ping" messages to the second actor, which in turn sends "pong" messages back (for each received "ping" message one "pong" message).
Abstract. Join patterns are an attractive declarative way to synchronize both threads and asynchronous distributed computations. We explore joins in the context of extensible pattern matching that recently appeared in languages such as F# and Scala. Our implementation supports join patterns with multiple synchronous events, and guards. Furthermore, we integrated joins into an existing actor-based concurrency framework. It enables join patterns to be used in the context of more advanced synchronization modes, such as future-type message sending and token-passing continuations.
emir burak scala.xml (draft book, updated for Scala 2.6.1) I. Semistructured Syntax and Data 1. Introduction XML, Types and Objects 2. The scala.xml API Nodes and Attributes Elements and Text Embedded expressions Other nodes Matching XML Updates and Queries Names and Namespaces Sharing namespace nodes 3. XPath projection 4. XSLT style transformations 5. XQuery style querying 6. Loading and Saving XML The native Scala parser Pull parsing (experimental) II. Library 7. Overview 8. scala.xml runtime classes 9. Scala's XML syntax, formally 10. Interpretation of XML expressions and patterns
The Scala Community Library (Scalax) is a nascent project to develop a general utility library for the Scala language, as a companion to the standard library. All members of the Scala community are invited to participate, by contributing code and by reviewing existing contributions. Scalax is released under a 3-clause BSD-style license, the same as Scala itself. Our Mercurial repositories and 0.1 release are available to preview. dormant?
Twitter has become quite the hotbed of chatter about functional programming over the past few months, as a substantial number of pretty well known FP people have either been present all along or have signed up recently and started following each other. Here is a list of people I know about who tweet about FP on a semi-regular basis, along with what I think are their main interest
Scala is clearly an interesting language, well suited for showing off nifty new ideas in language theory and innovation, but at the end of the day, for it to be of any "real" use, it has to be able to meet practicing developers halfway and have some applicability in the "real world." Now that we've looked at some of the core features of the language, can recognize some of Scala's linguistic flexibility, and have witnessed Scala in action creating DSLs, it's time to start reaching out to the environments that real applications use and show how Scala fits. We'll begin this new phase of the series by starting with the heart of most Java™ applications: the Servlet API.
Once you start thinking about structuring your code to use Option in languages which have built-in support for it, you’ll find yourself dreaming about such patterns in other, less fortunate languages. It’s really sort of bizarre how much this little device can open your mind to new possibilities. Take my code, and give it a try in your project. Better yet, implement something on your own which solves the problem more elegantly! The stodgy old Java “best practices” could use a little fresh air. P.S. Yes, I know that the original implementation of this was actually the Maybe monad in Haskell. I picked Option instead mainly because a) I like the name better, and b) it’s Scala, so it’s far more approachable than Haskell.