L. Parreaux, Aleksander Boruch-Gruszecki, Paolo G. Giarrusso
Generalized algebraic data types (GADT) have been notoriously difficult to implement correctly in Scala. Both major Scala compilers, Scalac and Dotty, are currently known to have type soundness holes related to them. In particular, covariant GADTs have exposed paradoxes due to Scala's inheritance model. We informally explore foundations for GADTs within Scala's core type system, to guide a principled understanding and implementation of GADTs in Scala.
{"title":"Towards improved GADT reasoning in Scala","authors":"L. Parreaux, Aleksander Boruch-Gruszecki, Paolo G. Giarrusso","doi":"10.1145/3337932.3338813","DOIUrl":"https://doi.org/10.1145/3337932.3338813","url":null,"abstract":"Generalized algebraic data types (GADT) have been notoriously difficult to implement correctly in Scala. Both major Scala compilers, Scalac and Dotty, are currently known to have type soundness holes related to them. In particular, covariant GADTs have exposed paradoxes due to Scala's inheritance model. We informally explore foundations for GADTs within Scala's core type system, to guide a principled understanding and implementation of GADTs in Scala.","PeriodicalId":436969,"journal":{"name":"Proceedings of the Tenth ACM SIGPLAN Symposium on Scala","volume":"2 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-07-17","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128538908","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Konstantin Läufer, John O'Sullivan, G. Thiruvathukal
In testing stateful abstractions, it is often necessary to record interactions, such as method invocations, and express assertions over these interactions. Following the Test Spy design pattern, we can reify such interactions programmatically through additional mutable state. Alternatively, a mocking framework, such as Mockito, can automatically generate test spies that allow us to record the interactions and express our expectations in a declarative domain-specific language. According to our study of the test code for Scala's Iterator trait, the latter approach can lead to a significant reduction of test code complexity in terms of metrics such as code size (in some cases over 70% smaller), cyclomatic complexity, and amount of additional mutable state required. In this tools paper, we argue that the resulting test code is not only more maintainable, readable, and intentional, but also a better stylistic match for the Scala community than manually implemented, explicitly stateful test spies.
{"title":"Tests as maintainable assets via auto-generated spies: a case study involving the scala collections library's iterator trait","authors":"Konstantin Läufer, John O'Sullivan, G. Thiruvathukal","doi":"10.1145/3337932.3338814","DOIUrl":"https://doi.org/10.1145/3337932.3338814","url":null,"abstract":"In testing stateful abstractions, it is often necessary to record interactions, such as method invocations, and express assertions over these interactions. Following the Test Spy design pattern, we can reify such interactions programmatically through additional mutable state. Alternatively, a mocking framework, such as Mockito, can automatically generate test spies that allow us to record the interactions and express our expectations in a declarative domain-specific language. According to our study of the test code for Scala's Iterator trait, the latter approach can lead to a significant reduction of test code complexity in terms of metrics such as code size (in some cases over 70% smaller), cyclomatic complexity, and amount of additional mutable state required. In this tools paper, we argue that the resulting test code is not only more maintainable, readable, and intentional, but also a better stylistic match for the Scala community than manually implemented, explicitly stateful test spies.","PeriodicalId":436969,"journal":{"name":"Proceedings of the Tenth ACM SIGPLAN Symposium on Scala","volume":"289 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-07-17","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114201122","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Test smells are indications of poorly designed unit tests. Previous studies have demonstrated their negative impact on test understanding and maintenance. Moreover, surveys show that developers are not able to identify test smells, hindering optimal software quality. Automated tools can aid developers to handle these issues and detect test smells in the early stage of software development. However, few tools are publicly available and all of them target JUnit -- the most popular testing framework in Java. To overcome these limitations, we propose SoCRATES. This fully automated tool is able to identify six test smells in Scala Test which is the most prevalent testing framework in Scala. An empirical investigation on 164 Scala projects shows that our tool is able to reach a high precision without sacrificing recall. Moreover, the results show that Scala projects have a lower diffusion than Java projects. We make SoCRATES publicly available as an IntelliJ IDEA plugin, as well as an open-source project in order to facilitate the detection of test smells.
{"title":"SoCRATES: Scala radar for test smells","authors":"Jonas De Bleser, D. D. Nucci, Coen De Roover","doi":"10.1145/3337932.3338815","DOIUrl":"https://doi.org/10.1145/3337932.3338815","url":null,"abstract":"Test smells are indications of poorly designed unit tests. Previous studies have demonstrated their negative impact on test understanding and maintenance. Moreover, surveys show that developers are not able to identify test smells, hindering optimal software quality. Automated tools can aid developers to handle these issues and detect test smells in the early stage of software development. However, few tools are publicly available and all of them target JUnit -- the most popular testing framework in Java. To overcome these limitations, we propose SoCRATES. This fully automated tool is able to identify six test smells in Scala Test which is the most prevalent testing framework in Scala. An empirical investigation on 164 Scala projects shows that our tool is able to reach a high precision without sacrificing recall. Moreover, the results show that Scala projects have a lower diffusion than Java projects. We make SoCRATES publicly available as an IntelliJ IDEA plugin, as well as an open-source project in order to facilitate the detection of test smells.","PeriodicalId":436969,"journal":{"name":"Proceedings of the Tenth ACM SIGPLAN Symposium on Scala","volume":"5 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-07-17","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123110341","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
DOT (Dependent Object Types) is an object calculus with path-dependent types and abstract type members, developed to serve as a theoretical foundation for the Scala programming language. As yet, DOT does not model all of Scala's features, but a small subset. We present the calculus DIF (DOT with Implicit Functions), which extends the set of features modelled by DOT to include implicit functions, a feature of Scala to aid modularity of programs. We show type safety of DIF, and demonstrate that the generic programming focused use cases for implicit functions in Scala are also expressible in DIF.
{"title":"Dependent object types with implicit functions","authors":"A. Jeffery","doi":"10.1145/3337932.3338811","DOIUrl":"https://doi.org/10.1145/3337932.3338811","url":null,"abstract":"DOT (Dependent Object Types) is an object calculus with path-dependent types and abstract type members, developed to serve as a theoretical foundation for the Scala programming language. As yet, DOT does not model all of Scala's features, but a small subset. We present the calculus DIF (DOT with Implicit Functions), which extends the set of features modelled by DOT to include implicit functions, a feature of Scala to aid modularity of programs. We show type safety of DIF, and demonstrate that the generic programming focused use cases for implicit functions in Scala are also expressible in DIF.","PeriodicalId":436969,"journal":{"name":"Proceedings of the Tenth ACM SIGPLAN Symposium on Scala","volume":"21 4","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-07-17","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"120902291","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
We present Effpi: an experimental toolkit for strongly-typed concurrent and distributed programming in Dotty, with verification capabilities based on type-level model checking. Effpi addresses a main challenge in creating and maintaining concurrent programs: errors like protocol violations, deadlocks, and livelocks are often spotted late, at run-time, when applications are tested or (worse) deployed. Effpi aims at finding them early, when code is written and compiled. Effpi provides: (1) a set of Dotty classes for describing communication protocols as types; (2) an embedded DSL for concurrent programming, with process-based and actor-based abstractions; (3) a Dotty compiler plugin to verify whether protocols and programs enjoy desirable properties, such as deadlock-freedom; and (4) an efficient run-time system for executing Effpi's DSL-based programs. The combination of (1) and (2) allows the Dotty compiler to check whether an Effpi program implements a desired protocol/-type; and this, together with (3), means that many typical concurrent programming errors are found and ruled out at compile-time. Further, (4) allows to run highly concurrent Effpi programs with millions of interacting processes/actors, by scheduling them on a limited number of CPU cores. In this paper, we give an overview of Effpi, illustrate its design and main features, and discuss its future.
{"title":"Effpi","authors":"A. Scalas, Nobuko Yoshida, Elias Benussi","doi":"10.1145/3337932.3338812","DOIUrl":"https://doi.org/10.1145/3337932.3338812","url":null,"abstract":"We present Effpi: an experimental toolkit for strongly-typed concurrent and distributed programming in Dotty, with verification capabilities based on type-level model checking. Effpi addresses a main challenge in creating and maintaining concurrent programs: errors like protocol violations, deadlocks, and livelocks are often spotted late, at run-time, when applications are tested or (worse) deployed. Effpi aims at finding them early, when code is written and compiled. Effpi provides: (1) a set of Dotty classes for describing communication protocols as types; (2) an embedded DSL for concurrent programming, with process-based and actor-based abstractions; (3) a Dotty compiler plugin to verify whether protocols and programs enjoy desirable properties, such as deadlock-freedom; and (4) an efficient run-time system for executing Effpi's DSL-based programs. The combination of (1) and (2) allows the Dotty compiler to check whether an Effpi program implements a desired protocol/-type; and this, together with (3), means that many typical concurrent programming errors are found and ruled out at compile-time. Further, (4) allows to run highly concurrent Effpi programs with millions of interacting processes/actors, by scheduling them on a limited number of CPU cores. In this paper, we give an overview of Effpi, illustrate its design and main features, and discuss its future.","PeriodicalId":436969,"journal":{"name":"Proceedings of the Tenth ACM SIGPLAN Symposium on Scala","volume":"130 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2019-04-18","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116878377","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Proceedings of the Tenth ACM SIGPLAN Symposium on Scala","authors":"","doi":"10.1145/3337932","DOIUrl":"https://doi.org/10.1145/3337932","url":null,"abstract":"","PeriodicalId":436969,"journal":{"name":"Proceedings of the Tenth ACM SIGPLAN Symposium on Scala","volume":"91 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132951427","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：