This is the first case of Odersky’s equivalence: signatures and traits. This is not the signature listed by Okasaki, but the signature here is closer to the Ordering trait in Scala standard library: ![]() The contract is that the result of compare is negative if the first is less than the second, zero if equal, otherwise, positive. ORDERED is our ML signature, which specifies a type T and a function named compare that takes a pair of Ts to an int. To implement a set, we’re going to need to be able to compare the elements, so we’ll demand that our elements are ordered. We will come back to ML functors in due course, but let’s start with a signature. Paulson, ML for the Working Programmer, 2nd Edition, (1996) pp.59 Signatures as Traits ML also provides functors–structures taking other structures as parameters– An ML signature specifies a class of structures by listing the name and type (or other attributes) of each component. This is a handy source as all the implementations in this book are in Standard ML (and Haskell in the appendix), so we can compare our Scala translations against the original.īefore we proceed much further we should make sure we have an understanding of the ML module system.Īn ML structure combines related types, values and other structures, with a uniform naming discipline. I’m going to use a set data structure adapted from chapter 2.2 of Purely Functional Data Structures by Chris Okasaki. Refinement ≅ Sharing Constraint Scala à la ML modulesįor the rest of this article we’re going to walk through an example to aid our exploration of the above equivalence between Scala and Standard ML. Here, Odersky points out the inspiration he drew from Modula-2, Modula-3, Haskell, and Standard ML of particular interest is the equivalence he draws between Scala and Standard ML’s module system. With this context, the slide I’d like to discuss in depth is titled “Scala’s Modular Roots”. In his talk, Odersky laments that Scala is seen as precariously balancing between OOP and FP, and argues that rather than call Scala an ‘ object/functional’ language–thus setting itself up to be caught in the crossfire of perpetual holy wars–we should instead call it a ‘modular’ language. The original academic agenda for Scala was to create a hybrid language that combines object-oriented and functional programming. Naturally, he refined his slide deck over the course of the tour, but one constant and core idea in his talk was Scala as a ‘modular language’. The purpose of this article, however, is not to critique Odersky’s talk and vision, but to explore just a single slide. And what’s more, I also have the sense that many ‘Scala people’ are “ok with that”. While Odersky seemed successful in drawing out seven core aspects of Scala, it remains a language that, as a whole, is powerful, expressive, unopinionated, and complicated. ![]() I will not attempt to describe or diagnose the nature and intricacies of the Scala community, but I have the sense that Odersky’s attempt to highlight the essence of Scala–-the simple parts, as he sees them–was ultimately received with some skepticism. This latter aspect is, while understandable, rather unfortunate. Due to the scheduling, ‘Scala – The Simple Parts’ had an air of a roadshow (he is a founder of Typesafe after all) due to the content, it also had an air of defensiveness. Similar to his 2013 talk ‘Scala with Style’, which also concluded its tour at that year’s Scala Days, Odersky’s 2014 talk appeared as a mix of advocacy, evangelism, and an attempt by a language designer to make explicit his authorial intent–as much as that is possible. The first stop was the flatMap(Oslo) conference in Norway, and then one might have observed a blur resembling Martin across Europe and the US, with a grand finale at this years’s Scala Days. Earlier this year Martin Odersky went on a whistle-stop tour of conferences and meetups with his latest talk, ‘Scala – The Simple Parts’.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |