As an extension to the ongoing Coconut (COde COnstructing User Tool) project at McMaster University, we present a Scala library for constructing type-safe domain-specific languages that uses Coconut’s hypergraph-based representation of code (code graphs) as the intermediate representation. Our library automatically produces strongly typed, deeply embedded DSLs given only a minimal specification of the DSL’s value types and primitives. We make extensive use of path-dependent types and implicit argument lookup to construct a type-safe interface on-the-fly, rather than requiring DSL designers to explicitly create a type-safe interface. In this thesis we present our library and demonstrate its utility as both a general-purpose DSL framework and as a suitable platform for continued research on the Coconut project. By giving practical examples of the library in use, we demonstrate both its general utility, and the striking swiftness with which new DSLs may be constructed, especially compared to the previously laborious Haskell DSLs of Coconut. / Thesis / Master of Science (MSc)

The interrelations of a set of software objects are usually manifold and complex. Common object-oriented programming languages provide constructs for structuring objects according to shared properties and behavior, but fail to provide abstraction mechanisms for the interactions of objects. Roles seem to be a promising approach to solve this problem as they focus on the behavior of an object in a certain context. Combining multiple roles yields collaborations, an interesting abstraction and reuse unit. However, existing approaches towards roles in programming languages require vast extensions of the underlying language or even propose new languages. We propose a programming technique that enables role-based programming with commonly available language constructs. Thus, programmers can express roles and collaborations by simply using a library, and hence, without the need to change the language, its compiler, and its tools. We explain our proposal on a language-independent level. Moreover, we provide an implementation in form of a library for the Scala programming language. Finally, we apply our ideas to design patterns and analyze to which extent these can be expressed and reused with roles. / Die Zusammenhänge zwischen Softwareobjekten sind vielfältig und komplex. In den meisten objektorientierten Programmiersprachen werden Objekte an Hand von gemeinsamen Eigenschaften und Verhalten klassifiziert. Konstrukte zum Strukturieren bezüglich ihrer Interaktionen fehlen jedoch. Ein vielversprechender Lösungsansatz sind Rollen, welche das Verhalten von Objekten in einem bestimmten Kontext beschreiben. Zusammenhängende Rollen können zu Kollaborationen abstrahiert werden. Diese sind insbesondere als wiederverwendbare Bausteine interessant. Allerdings verändern bisherige Ansätze zu rollenbasiertem Programmieren die zu Grunde liegende Sprache erheblich oder schlagen gar neue Sprachen vor. Im Gegensatz dazu zeigen wir eine Programmiermethode, die rollenbasiertes Programmieren mit üblichen Sprachkonstrukten ermöglicht. Somit können Rollen und Kollaborationen als Bibliothek bereitgestellt werden, also ohne Sprache, Compiler und Werkzeuge anpassen zu müssen. Wir erläutern unseren Ansatz zunächst sprachunabhängig. Desweiteren wird eine Implementierung als Bibliothek für die Scala Programmiersprache präsentiert. Als praktische Anwendung stellen wir Entwurfsmustern dar und überprüfen, inwiefern sich diese mit Rollen ausdrücken und wiederverwenden lassen.

L’utilisation de concepts avancés de programmation concurrente permet de dépasser les inconvénients de l’utilisation de techniques de bas niveau à base de verrous ou de moniteurs. Elle augmente le niveau d’abstraction, libérant les programmeurs d’applications concurrentes d’une focalisation excessive sur des détails. Cependant, avec les approches actuelles, la logique nécessaire à la mise en place de schémas de coordinations complexes est fragmentée en plusieurs points de l’application sous forme de« join patterns », de notifications et de la logique applicative qui crée implicitement des dépendances entre les canaux de communication et donc, indirectement, les « join patterns » (qui définissent ces canaux). Nous présentons JEScala, un langage qui capture les schémas de coordination (d’une application concurrente) d’une manière plus expressive et modulaire, en s’appuyant sur l’intégration fine d’un système d’évènements avancé et des « join patterns ». Nous implémentons des automates finis à partir de « joins » à l’aide de JEScala et introduisons un langage dédié à la définition de ces automates finis permettant d’en obtenir des implémentations plus efficaces. Nous validons notre approche avec des études de cas et évaluons l’efficacité de son exécution. Nous comparons la performance de trois implémentations d’un automate fini. Nous validons enfin l’idée d’un moniteur d’évènements en créant un programme JEScala concurrent à partir d’un découpage d’un programme séquentiel. / The advanced concurrency abstractions provided by the Join calculus overcome the drawbacks of low-level techniques such as locks and monitors. They rise the level of abstraction, freeing programmers that implement concurrent applications from the burden of concentrating on low-level details. However, with current approaches the coordination logic involved incomplex coordination schemas is fragmented into several pieces including join patterns, data emissions triggered in different places of the application, and the application logic that implicitly creates dependencies among channels, hence indirectly among join patterns. We present JEScala, a language that captures coordination schemas in a more expressive and modular way by leveraging a seamless integration of an advanced event system with join abstractions. We implement Joins-based state machines using JEScala and introduce a domain specific language for finite state machines that make faster alternative implementations possible. We validate our approach with case studies and we provide a first performance assessment. We compare the performance of three different implementations of a finite state machine. Finally, we validate the idea of constructing a concurrent JEScala program by using the parts of a sequential Event-Based program in combination with an event monitor, a component that synchronizes handling of multiple events.

Present-day software systems have to fulfill an increasing number of requirements rendering them more and more complex. Many systems need to anticipate changing contexts (self-adaptive systems) or need to adapt to changing business rules or requirements (self-optimizing systems). The challenge of 21th century software development will be to cope with these aspects. We believe that the role concept offers a simple way to adapt object-oriented programs to their changing contexts. In a role-based language, an object plays multiple roles during its lifetime. If the contexts are represented as first-class entities, they provide dynamic views to the object-oriented program, and if the context changes, the dynamic views can be switched easily, and the software system adapts automatically. However, the concepts of roles and dynamic contexts have been discussed for a long time in many areas of computer science. So far, their implementation in an existing object-oriented language requires a specific runtime environment. Also, classical object-oriented languages and their runtime systems are not able to cope with essential role-specific features, such as true delegation or dynamic binding of roles. As a solution, this work presents a simple implementation pattern for role-based objects that does not require a specific runtime system, SCROLL (SCala ROles Language). The implementation pattern is demonstrated on the basis of the Scala language. As technical support from Scala, the pattern requires dynamic mixins, compiler-translated function calls, and implicit conversions. The implementation details of the pattern are hidden in a Scala library and therefore transparent to Scala programmers. The SCROLL library supports roles embedded in structured contexts, so-called compartments. We show that they are specific, hierarchic runtime views, which enables hierarchic view-based programming for free in Scala. We also discuss how to apply the implementation pattern of SCROLL for other languages, in particular for behavioral modeling languages in MDSD. This discussion shows that the SCROLL pattern can be embedded into the generated code, so that it still is hidden to the developer, but does not require a specific runtime system. Using the pattern in model-driven code generation enables dynamic views for all kinds of modeling languages. And therefore, this paper shows a way how to realize dynamic views for all modeling languages in MDSD.

Present-day software systems have to fulfill an increasing number of requirements, which makes them more and more complex. Many systems need to anticipate changing contexts or need to adapt to changing business rules or requirements. The challenge of 21th-century software development will be to cope with these aspects. We believe that the role concept offers a simple way to adapt an object-oriented program to its changing context. In a role-based application, an object plays multiple roles during its lifetime. If the contexts are represented as first-class entities, they provide dynamic views to the object-oriented program, and if a context changes, the dynamic views can be switched easily, and the software system adapts automatically. However, the concepts of roles and dynamic contexts have been discussed for a long time in many areas of computer science. So far, their employment in an existing object-oriented language requires a specific runtime environment. Also, classical object-oriented languages and their runtime systems are not able to cope with essential role-specific features, such as true delegation or dynamic binding of roles. In addition to that, contexts and views seem to be important in software development. The traditional code-oriented approach to software engineering becomes less and less satisfactory. The support for multiple views of a software system scales much better to the needs of todays systems. However, it relies on programming languages to provide roles for the construction of views. As a solution, this thesis presents an implementation pattern for role-playing objects that does not require a specific runtime system, the SCala ROles Language (SCROLL). Via this library approach, roles are embedded in a statically typed base language as dynamically evolving objects. The approach is pure in the sense that there is no need for an additional compiler or tooling. The implementation pattern is demonstrated on the basis of the Scala language. As technical support from Scala, the pattern requires dynamic mixins, compiler-translated function calls, and implicit conversions. The details how roles are implemented are hidden in a Scala library and therefore transparent to SCROLL programmers. The SCROLL library supports roles embedded in structured contexts. Additionally, a four-dimensional, context-aware dispatch at runtime is presented. It overcomes the subtle ambiguities introduced with the rich semantics of role-playing objects. SCROLL is written in Scala, which blends a modern object-oriented with a functional programming language. The size of the library is below 1400 lines of code so that it can be considered to have minimalistic design and to be easy to maintain. Our approach solves several practical problems arising in the area of dynamical extensibility and adaptation.

In today’s internet era, more text than ever is being uploaded online. The text comes in many forms, such as social media posts, business reviews, and many more. For various reasons, there is an interest in analyzing the uploaded text. For instance, an airline business could ask their customers to review the service they have received. The feedback would be collected by asking the customer to leave a review and a score. A common scenario is a review with a good score that contains negative aspects. It is preferable to avoid a situation where the entirety of the review is regarded as positive because of the score if there are negative aspects mentioned. A solution to this would be to analyze each sentence of a review and classify it by negative, neutral or, positive depending on how the sentence is perceived.  With the amount of text uploaded today, it is not feasible to manually analyze text. To automatically classify text by a set of criteria is called text classification. The process of specifically classifying text by how it is perceived is a subcategory of text classification known as sentiment analysis. Positive, neutral and, negative would be the sentiments to classify.  The most popular frameworks associated with the implementation of sentiment analyzers are developed in the programming language Python. However, over the years, text classification has had an increase in popularity. The increase in popularity has caused new frameworks to be developed in new programming languages. Scala is one of the programming languages that has had new frameworks developed to work with sentiment analysis. However, in comparison to Python, it has fewer available resources. Python has more available libraries to work with, available documentation, and community support online. There are even fewer resources regarding sentiment analysis in a less common language such as Swedish. The problem is no one has compared a sentiment analyzer for Swedish text implemented using Scala and compared it to Python. The purpose of this thesis is to compare recall and precision of a sentiment analyzer implemented in Scala to Python. The goal of this thesis is to increase the knowledge regarding the state of text classification for less common natural languages in Scala.  To conduct the study, a qualitative approach with the support of quantitative data was used. Two kinds of sentiment analyzers were implemented in Scala and Python. The first classified text as either positive or negative (binary sentiment analysis), the second sentiment analyzer would also classify text as neutral (multiclass sentiment analysis). To perform the comparative study, the implemented analyzers would perform classification on text with known sentiments. The quality of the classifications was measured using their F1-score.  The results showed that Python had better recall and quality for both tasks. In the binary task, there was not as large of a difference between the two implementations. The resources from Python were more specialized for Swedish and did not seem to be as affected by the small dataset used as the resources in Scala. Scala had an F1-score of 0.78 for binary sentiment analysis and 0.65 for multiclass sentiment analysis. Python had an F1-score of 0.83 for binary sentiment analysis and 0.78 for multiclass sentiment analysis. / I dagens internetera laddas mer text upp än någonsin online. Texten finns i många former, till exempel inlägg på sociala medier, företagsrecensioner och många fler. Av olika skäl finns det ett intresse av att analysera den uppladdade texten. Till exempel kan ett flygbolag be sina kunder att lämna omdömen om tjänsten de nyttjat. Feedbacken samlas in genom att be kunden lämna ett omdöme och ett betyg. Ett vanligt scenario är en recension med ett bra betyg som innehåller negativa aspekter. Det är att föredra att undvika en situation där hela recensionen anses vara positiv på grund av poängen, om det nämnts negativa aspekter. En lösning på detta skulle vara att analysera varje mening i en recension och klassificera den som negativ, neutral eller positiv beroende på hur meningen uppfattas.  Med den mängd text som laddas upp idag är det inte möjligt att manuellt analysera text. Att automatiskt klassificera text efter en uppsättning kriterier kallas textklassificering. Processen att specifikt klassificera text efter hur den uppfattas är en underkategori av textklassificering som kallas sentimentanalys. Positivt, neutralt och negativt skulle vara sentiment att klassificera.  De mest populära ramverken för implementering av sentimentanalysatorer utvecklas i programmeringsspråket Python. Men genom åren har textklassificering ökat i popularitet. Ökningen i popularitet har gjort att nya ramverk utvecklats för nya programmeringsspråk. Scala är ett av programmeringsspråken som har utvecklat nya ramverk för att arbeta med sentimentanalys. I jämförelse med Python har den dock mindre tillgängliga resurser. Python har mer bibliotek, dokumentation och mer stöd online. Det finns ännu färre resurser när det gäller sentimentanalyser på ett mindre vanligt språk som svenska. Problemet är att ingen har jämfört en sentimentanalysator för svensk text implementerad med Scala och jämfört den med Python. Syftet med denna avhandling är att jämföra precision och recall på en sentimentanalysator implementerad i Scala med Python. Målet med denna avhandling är att öka kunskapen om tillståndet för textklassificering för mindre vanliga naturliga språk i Scala.  För att genomföra studien användes ett kvalitativt tillvägagångssätt med stöd av kvantitativa data. Två typer av sentimentanalysatorer implementerades i Scala och Python. Den första klassificerade texten som antingen positiv eller negativ (binär sentimentanalys), den andra sentimentanalysatorn skulle också klassificera text som neutral (sentimentanalys i flera klasser). För att utföra den jämförande studien skulle de implementerade analysatorerna utföra klassificering på text med kända sentiment. Klassificeringarnas kvalitet mättes med deras F1-poäng.  Resultaten visade att Python hade bättre precision och recall för båda uppgifterna. I den binära uppgiften var det inte lika stor skillnad mellan de två implementeringarna. Resurserna från Python var mer specialiserade för svenska och verkade inte påverkas lika mycket av den lilla dataset som används som resurserna i Scala. Scala hade ett F1-poäng på 0,78 för binär sentimentanalys och 0,65 för sentimentanalys i flera klasser. Python hade ett F1-poäng på 0,83 för binär sentimentanalys och 0,78 för sentimentanalys i flera klasser.

Com o avanço tecnológico dos últimos anos passou a ser normal vermos microprocessadores com múltiplos núcleos (cores). A expectativa é de que o crescimento da quantidade de núcleos passe a ser maior do que o crescimento da velocidade desses núcleos. Assim, além de se preocuparem em otimizar algoritmos sequenciais, os programadores começaram a dar mais atenção às possibilidades de aproveitamento de toda a capacidade oferecida pelos diversos cores. Existem alguns modelos de programação que permitem uma abordagem concorrente. O modelo de programação concorrente mais adotado atualmente é o baseado em threads, que utiliza memória compartilhada e é adotado em Java. Um outro modelo é o baseado em troca de mensagens, no qual as entidades computacionais ativas são denominadas atores. Nesse trabalho, estudamos a linguagem Scala e seu modelo de atores. Além disso, implementamos em Scala uma versão paralela de um algoritmo de classicação que simula o sistema imunológico dos animais, o AIRS paralelo, e comparamos seu desempenho com a versão em Java. / With the technological advance of the last years it has been normal to see microprocessors with multiple cores. The expectation is that the growth of number of cores becomes greater than the growth of the speed of these cores. This way, besides worrying about optimizing sequential algorithms, developers started to give more attention to the possibilities of proting from all capacity offered by the cores. There exists a few programming models that allow a concurrent approach. In these days, the most adopted concurrent programming model is the one based on threads, which uses shared memory and is adopted in Java. Other model is based on message passing, on which the active computational entities are called actors. In this project, we studied Scala language and its model based on actors. Besides that, we implemented in Scala a parallel version of a classification algorithm that simules the immune system of the animals, parallel AIRS, and compared its performance with the Java version.

Domänenspezifische Sprachen (DSLs) sind Software-Sprachen, die speziell für bestimmte Anwendungsdomänen entwickelt wurden. Mithilfe von DSLs können Domänenexperten ihr Domänenwissen auf einem hohen Abstraktionsniveau beschreiben. Wie andere Software-Sprachen auch, benötigen DSLs Sprachwerkzeuge, die Assistenz bei der Erstellung und Verarbeitung von domänenspezifischen Modellen bieten. Eine domänenspezifische Werkbank (DSW) ist ein Software-Werkzeug, welches mehrere solcher Sprachwerkzeuge für eine DSL miteinander integriert. Existierende Werkzeuge, die es erlauben eine DSW aufgrund der Beschreibung einer DSL automatisch generieren zu lassen, unterstützen jedoch nicht die Beschreibung und Generierung von editierbaren Sichten. Eine Sicht ist ein Teil einer DSW, der nur einen bestimmten Aspekt eines Modells darstellt. Diese Dissertation stellt spezielle Modelltransformationssprachen (MTLs) vor, mit denen die Synchronisation von Sichten in einer generierten DSW beschrieben werden kann. Dadurch können DSWs mit editierbaren Sichten mittels existierender Werkzeuge zur Generierung von Sprachwerkzeugen erstellt werden. Dafür wird eine DSW für die Nanophysik-Domäne sowie eine Taxonomie von Synchronisationstypen vorgestellt, welche es erlaubt genau zu bestimmen, welche Art von Modelltransformationen für die Synchronisation von Sichten in dieser Werkbank benötigt werden. Entsprechend dieser Anforderungen werden zwei MTLs entwickelt. Insbesondere wird eine bidirektionale MTL entwickelt. Mit solch einer Sprache kann man eine Relation, welche definiert ob zwei Modelle synchron sind, so beschreiben, dass die entsprechende Synchronisationslogik automatisch abgeleitet werden kann. Die gezeigten MTLs werden als interne DSLs - das heißt eingebettet als ausdrucksstarke Bibliotheken - in der Programmiersprache Scala implementiert. Auf diese Weise kann Scalas Typprüfung genutzt werden, um Transformationen und deren Komposition statisch zu verifizieren. / Domain-specific languages (DSLs) are software languages which are tailored to a specific application domain. DSLs enable domain experts to create domain-specific models, that is, high-level descriptions of domain knowledge. As any other software languages, DSLs rely on language tools which provide assistance for processing and managing domain-specific models. A domain-specific workbench is an integrated set of such tools for a DSL. A recently proposed approach is to automatically generate a domain-specific workbench for a DSL from a description of that DSL. However, existing tools which apply this approach do not support to describe and generate editable domain-specific views. A view is a part of domain-specific workbench that presents only one aspect of a model, for example, its hierarchical structure. This dissertation presents special model transformation languages which support the description of view synchronization in a generated domain-specific workbench. This allows a multi-view domain-specific workbench to be created with existing tools for language tool generation. We present a generated domain-specific workbench for the nanophysics domain and present a taxonomy of synchronization types. This allows us to precisely define what model transformations are required for view synchronization in that workbench. According to these requirements, we develop two transformation languages by adapting existing ones. In particular, we develop a bidirectional transformation language. With such a language one can describe a relation which defines whether two models are in sync and let the synchronization logic be inferred automatically. We implement model transformation languages as internal DSLs - that is, embedded as expressive libraries - in the Scala programming language and use Scala''s type checking for static verification of transformations and their composition.

O modelo de atores tem sido visto como uma abordagem alternativa à programação concorrente convencional, baseada em travas e variáveis de condição. Atores são agentes computacionais que se comunicam por troca de mensagens e que possuem uma caixa de correio e um comportamento. As mensagens destinadas a um ator são armazenadas na caixa de correio do ator e processadas de maneira assíncrona. Sistemas de middleware orientados a mensagens trabalham com troca assíncrona de mensagens e formam uma base que simplifica o desenvolvimento de aplicações distribuídas. Tais sistemas permitem interoperabilidade com baixo acoplamento e provêm suporte para tratamento robusto de erros em caso de falhas. Message brokers são frequentemente apresentados como uma tecnologia que pode mudar a maneira com que sistemas distribuídos são construídos. A especificação AMQP é uma proposta recente de padronização de um protocolo para message brokers. Neste trabalho exploramos a potencial sinergia entre um message broker e uma implementação do modelo de atores. Criamos uma versão modificada da implementação do modelo de atores do projeto Akka que utiliza um message broker AMQP como mecanismo de transporte de mensagens para atores remotos. / The actor model has been seen as an alternative for conventional concurrent programming based on locks and condition variables. Actors are computational agents that communicate by sending messages and have a mailbox and a behavior. The messages sent to an actor are stored in its mailbox and are asynchronously processed. Message oriented middleware systems work with asynchronous message exchange and create a base that simplifies the development of distributed applications. These systems have interoperability with low coupling and provide support for robust error handling in case of failures. Message brokers are often presented as a technology that can change the way distributed systems are built. The AMQP specification is a recent proposal of a standard protocol for message brokers. In this document we explore the potential synergy between a message broker and an implementation of the actor model. We created a modified version of the actor model implementation provided by the Akka project. Our modified implementation uses an AMQP message broker as the transport engine for messages to remote actors.

The municipalities in Sweden can use the PBL-legislation to request a land developer to fund new public infrastructure in the dwelling area where the developer are active. The municipality have had two options to choose between. To purchase a contract with an entrepreneur that build the infrastructure paid by the developer, or let the developer both build and pay the infrastructure. The La Scala-judgment came 2001 from the EG-tribunal. This judgment have by many people been interpreted as that as public infrastructure in Sweden should be purchased by the municipalities through LOU. Therefore, the purpose of this report is to discuss how the land development process has changed and which problems that have arisen since 2010, when it became customary that the municipality should procure public streets and sewage facilities under the Swedish Public Procurement Act (“LOU”). The purpose is also to discuss if this way to proceed satisfies the purpose of LOU and also discuss if their can be any alternative interpretations of the La Scalajudgment than have been done so far for Swedish conditions. The questions that became a consequence of the purpose where answered as follow in the report: Changes Today, the general rule is that the municipality is to purchase all public streets itself in the land development process. This rule has replaced the freedom of choosing whether to do so, that previously existed. Necessary land transfers take place today at an early stage of the process, often when the zoning plan becomes valid, as compared to before when it took place late in the land development process. Problems Some problems have arisen in cases when the municipality procures. This leads to the conclusion that the land development process today has become more risky, significantly more expensive, and that it takes longer time before the houses are ready for occupants to move in to, than previously was the case. To what extent does this new procedure implement LOU’s purpose? LOU's purpose, to get an effectively use of tax money, is not fulfilled by this procedure because the municipalities do not have any expenditures, which means that there are no funds which can be considered “effectively used”. As the municipality has no cost, it is questionable whether it really is to the municipality that an entrepreneur sells his services, rather than to the land developer paying for the services. Overall, this means that the purpose is probably not fulfilled by this new procedure. In what situations can the LOU procedure be questioned? The consequences of LOU can be questioned where it leads to major problems that would not occur if the legislation was more flexible. An example of this is when there is a lone land developer, who builds on his own property. If the municipality procures this, as happens today, problems arise in terms of money, time and coordination problems. This because it is more efficient if the developer that are already active in the area build all necessary infrastructure. Can any other interpretations of the La Scala-judgment and it´s relationship to the Swedish development process be found? One alternative interpret is that the municipal should use LOU on this kind of contracts when there is a risk that the municipal lose financial resources if they don´t do it. In the Italian development process there is always a risk that the municipal lose financial resources if they don´t purchase the contracts. The Swedish land development legislation are structured so the municipality never take a risk to lose financial recourses if they let the developer build everything in the area and therefore the municipality never can lose financial recourses in these cases. The Swedish municipalities don’t get any advantages if they use LOU here because the developer pays the real cost for all parts of the contract. Therefore, LOU is irrelevant in this part of the development process. / I Sverige kan en kommun med stöd av PBL begära att en exploatör ska bekosta utbyggnad av allmänna platser där exploatören bygger nya bostadsområden. Kommunen har historiskt haft två utförandealternativ att välja mellan. Man har haft möjlighet att själv upphandla en entreprenör med LOU som bygger och som bekostas av exploatören eller låta exploatören både bygga och bekosta anläggningarna. År 2001 kom en dom från EG-domstolen som av många tolkats som att allmänna platser ska upphandlas via LOU av kommunen. Som en konsekvens har det de senaste åren skett en övergång där kommunen idag som huvudregel tillämpar LOU på utbyggnad av allmänna platser. Syftet är därför att diskutera hur exploateringsprocessen har förändrats och vilka problem som uppstått sedan 2010 då kommuner som en konsekvens av La Scala-domen upphandlar allmänna platser enligt LOU. Syftet är även att diskutera om detta förfarande uppfyller LOU:s syfte och om det finns några alternativa tolkningar av La Scala-domen än dem som hittills gjorts i Sverige. De frågor som följde på syftet besvaras i rapporten enligt följande Förändringar Huvudregeln är idag att kommunen ska upphandla alla allmänna gator själv i exploateringsprocessen istället för som tidigare när det som huvudregel var exploatören som upphandlade dessa. Erforderliga marköverföringar sker idag i ett tidigt skede, ofta i samband med att detaljplanen vinner laga kraft, istället för som tidigare när det skedde i slutet av exploateringsprocessen. Problem Det finns risk för problem som tidigare inte funnits i lika stor utsträckning när kommunen upphandlar. Exempel är samordningsproblem och tidsproblem. Dessa leder sammanfattningsvis till att exploateringsprocessen idag riskerar att bli dyrare samt att det tar längre tid innan husen står inflyttningsklara än vad fallet var tidigare. Hur väl uppfyller detta nya förfarande LOU:s syfte? LOU:s syfte, att få ett effektivt utnyttjande av skattemedel, uppfylls inte eftersom det i dessa fall saknas skattemedel att få ett effektivt utnyttjande av. Syftet att alla företag ska ha möjlighet att sälja sin tjänst till kommunen kan starkt ifrågasättas eftersom det är exploatören som betalar för upphandlingen. I vilka situationer kan LOU-förfarandet ifrågasättas? De situationer där LOU-förfarandet kan ifrågasättas är där det uppstår stora problem som inte skulle uppstå om lagstiftningen medgav flexibilitet. Ett exempel på detta är de fall där det är en ensam exploatör som bygger på sin egen fastighet. Om kommunen upphandlar allmän gata, så som sker idag, uppstår problem i termer av pengar, tid och samordningsproblem eftersom det är mer effektivt att den exploatör som redan är verksam i området bygger all nödvändig infrastruktur. Finns alternativa tolkningar av La Scala-domen och dess förhållande till den svenska exploateringsprocessen? En alternativ tolkning är att kommuner ska upphandla den här typen an entreprenader i de fall kommunen kan förlora ekonomiska medel på att inte göra det. Så som den italienska exploateringsprocessen är uppbyggd finns alltid en risk att italienska kommuner gör en förlust i ekonomiska termer i de fall man väljer att inte upphandla infrastruktur offentligt. I Sverige är exploateringslagstiftningen däremot utformad så att kommunen aldrig tar någon ekonomisk risk och därför inte kan förlora ekonomiska medel i de fall man låter en exploatör upphandla en entreprenör. Kommunen har i det svenska fallet inte något att vinna på en offentlig upphandling eftersom det är exploatören som betalar den faktiska kostnaden. Offentlig upphandling saknar därför relevans och betydelse i den här delen av exploateringsprocessen.