The great attractiveness of purely functional languages is their ability to depart from sequential order of computation. Theoretically, it enables two important features of the compiler:
1) The ability to reorder computation flow, making the program implicitly parallelisable. Modern imperative language compilers, even using careful synchronization of concurrent code, still generate huge chunks of sequential instructions that need to be executed on a single processor core; a purely functional language compilers can dispatch very small chunks to many (hundreds and thousands) of cores, carefully eliminating as many execution path dependencies as possible.
2) As the compiler formalizes different types of side effects, it can detect a whole new class of program errors at compile time, including resource acquisition and releasing problems, concurrent access to shared resources, many types of deadlocks etc. It is not yet a full-fledged program verification, but it is a big step in that direction.
Scala is a semi-imperative language with strong support for functional programming and rich type system. One can isolate the purely functional core of the language which can be put on the firm mathematical foundation of dependent type theories. We argue that it is possible to treat Scala code as it's written by now as an implicit do-notation which can be then reduced to a purely functional core by means of recently introduced Scala macros. The formalism of arrows and applicative contexts can bring Scala to a full glory of an implicitly parallelisable programming language, while still keeping its syntax mostly unchanged.
Advanced Scala reflection & runtime meta-programming. The Scala compiler toolbox. Reading Scala Annotations and overcoming type erasure with some real world use cases.
Some notes about programming in Scala: it covers Scala syntax and semantics, programming techniques, idioms, patterns. Many Scala features are introduced, from basic to intermediate and advanced. These are not introductory notes, but they assume a working knowledge with some other programming language (Java, C#, C++), object-oriented programming (OOP) concepts, and functional programming (FP) concepts.
Advanced Scala reflection & runtime meta-programming. The Scala compiler toolbox. Reading Scala Annotations and overcoming type erasure with some real world use cases.
Some notes about programming in Scala: it covers Scala syntax and semantics, programming techniques, idioms, patterns. Many Scala features are introduced, from basic to intermediate and advanced. These are not introductory notes, but they assume a working knowledge with some other programming language (Java, C#, C++), object-oriented programming (OOP) concepts, and functional programming (FP) concepts.
Scala Intro training @ Lohika, Odessa, UA.
This is a basic Scala Programming Language overview intended to evangelize the language among any-language programmers.
The Scala programming language has been gaining momentum recently as an alternative (and some might say successor) to Java on the JVM. This talk will start with an introduction to basic Scala syntax and concepts, then delve into some of Scala's more interesting and unique features. At the end we'll show a brief example of how Scala is used by the Lift web framework to simplify dynamic web apps.
I used these slides for a Scala workshop that I gave. They are based on these: http://www.scala-lang.org/node/4454. Thanks to Alf Kristian Støyle and Fredrik Vraalsen for sharing!
Short (45 min) version of my 'Pragmatic Real-World Scala' talk. Discussing patterns and idioms discovered during 1.5 years of building a production system for finance; portfolio management and simulation.
Presentation on the new features introduced in JDK 8, presented on the 26.02.2013 in Sofia University in front of students and members of the Bulgarian java user group.
While the Java platform has gained notoriety in the last 15 years as a robust application platform with a thriving ecosystem and well-established practices, the Java language has had its share of criticism. Highly verbose, overly didactic, limited feature set; whichever flavor of criticism you prefer, it's patently obvious that Java is playing catch up to more modern languages with a less rigid evolution path.
The language landscape today is vastly different than it had been five or ten years ago; a wide array of languages are available, designed to suit a variety of flavors: Groovy, Clojure, Scala, Gosu, Kotlin... which should you choose? This lecture focuses on one company's decision to focus on Scala, and presents a case study based on our experiences using Scala in practice, in the hope of providing much-needed real world context to assist your decision.
This presentation was used for the Scala In Practice lecture at the Botzia Israeli Java User Group meeting, May 3rd 2012.
Scalding: Twitter's Scala DSL for Hadoop/Cascadingjohnynek
Talk given at the 2012 Hadoop Summit in San Jose, CA.
Scalding is a Scala DSL for Cascading which brings natural functional programming to Hadoop. It is open-source, developed by Twitter and others.
Follow: twitter.com/scalding
github.com/twitter/scalding
Scala Intro training @ Lohika, Odessa, UA.
This is a basic Scala Programming Language overview intended to evangelize the language among any-language programmers.
The Scala programming language has been gaining momentum recently as an alternative (and some might say successor) to Java on the JVM. This talk will start with an introduction to basic Scala syntax and concepts, then delve into some of Scala's more interesting and unique features. At the end we'll show a brief example of how Scala is used by the Lift web framework to simplify dynamic web apps.
I used these slides for a Scala workshop that I gave. They are based on these: http://www.scala-lang.org/node/4454. Thanks to Alf Kristian Støyle and Fredrik Vraalsen for sharing!
Short (45 min) version of my 'Pragmatic Real-World Scala' talk. Discussing patterns and idioms discovered during 1.5 years of building a production system for finance; portfolio management and simulation.
Presentation on the new features introduced in JDK 8, presented on the 26.02.2013 in Sofia University in front of students and members of the Bulgarian java user group.
While the Java platform has gained notoriety in the last 15 years as a robust application platform with a thriving ecosystem and well-established practices, the Java language has had its share of criticism. Highly verbose, overly didactic, limited feature set; whichever flavor of criticism you prefer, it's patently obvious that Java is playing catch up to more modern languages with a less rigid evolution path.
The language landscape today is vastly different than it had been five or ten years ago; a wide array of languages are available, designed to suit a variety of flavors: Groovy, Clojure, Scala, Gosu, Kotlin... which should you choose? This lecture focuses on one company's decision to focus on Scala, and presents a case study based on our experiences using Scala in practice, in the hope of providing much-needed real world context to assist your decision.
This presentation was used for the Scala In Practice lecture at the Botzia Israeli Java User Group meeting, May 3rd 2012.
Scalding: Twitter's Scala DSL for Hadoop/Cascadingjohnynek
Talk given at the 2012 Hadoop Summit in San Jose, CA.
Scalding is a Scala DSL for Cascading which brings natural functional programming to Hadoop. It is open-source, developed by Twitter and others.
Follow: twitter.com/scalding
github.com/twitter/scalding
Introduction to ad-3.4, an automatic differentiation library in Haskellnebuta
Haskellの自動微分ライブラリ Ad-3.4 の紹介(の試み) If you don't see 21 slides in this presentation, try this one (re-uploaded): http://www.slideshare.net/nebuta/130329-ad-by-ekmett
Shape Safety in Tensor Programming is Easy for a Theorem Prover -SBTB 2021Peng Cheng
We present shapesafe (https://github.com/tribbloid/shapesafe) - the most comprehensive compile-time verifier for scala linear algebra - by only exploiting scala's type system as a theorem prover. This new paradigm allows type-level tensor computations, even those as complex as composite neural network blocks, to be rewritten, simplified and verified while being written. We will talk about its design and limitations, and most important, what we have observed and learned from it
A tour of Python: slides from presentation given in 2012.
[Some slides are not properly rendered in SlideShare: the original is still available at http://www.aleksa.org/2015/04/python-presentation_7.html.]
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
State of ICS and IoT Cyber Threat Landscape Report 2024 preview
Procedure Typing for Scala
1. Procedure Typing for Scala
Procedure Typing for Scala
Alexander Kuklev∗ , Alexander Temerev‡
* Institute of Theoretical Physics, University of Göttingen
‡ Founder and CEO at Miriamlaurel Sàrl, Geneva
April 10, 2012
2. Procedure Typing for Scala
Functions and procedures
In programming we have:
– pure functions;
– functions with side effects (AKA procedures).
3. Procedure Typing for Scala
Functions and procedures
In programming we have:
– pure functions;
– functions with side effects (AKA procedures).
Scala does not differentiate between them:
– both have types A => B .
5. Procedure Typing for Scala
But it should!
Static side effect tracking enables
– implicit parallelisability;
6. Procedure Typing for Scala
But it should!
Static side effect tracking enables
– implicit parallelisability;
– compile-time detection of a whole new class of problems:
(resource acquisition and releasing problems, race conditions,
deadlocks, etc.).
7. Procedure Typing for Scala
Short list of applicable methodologies:
Kleisli Arrows of Outrageous Fortune (2011, C. McBride)
Capabilities for Uniqueness and Borrowing (2010, P. Haller, M. Odersky)
Static Detection of Race Conditions [..] (2010, M. Christakis, K. Sagonas)
Static Deadlock Detection [..] (2009, F. de Boer, I. Grabe,M. Steffen)
Complete Behavioural Testing of Object-Oriented Systems using
CCS-Augmented X-Machines (2002, M. Stannett, A. J. H. Simons)
An integration testing method that is proved to find all faults
(1997, F. Ipate, M. Holcombe)
8. Procedure Typing for Scala
Specifying procedure categories
We propose a new syntax
where a function definition may include a category it belongs to:
A =>[Pure] B – pure functions;
A =>[Proc] B – procedures.
9. Procedure Typing for Scala
Specifying procedure categories
There’s a lot more than Pure and Proc
There is a whole lattice of categories between Pure and Proc :
Logged: procedures with no side effects besides logging;
Throws[E]: no side effects besides throwing exceptions of type E ;
Reads(file): no side effects besides reading the file ;
etc.
10. Procedure Typing for Scala
Specifying procedure categories
Extensible approach
An effect system should be extensible.
⇒ We must provide a way to define procedure categories.
Procedure categories are binary types like Function[_,_] or
Logged[_,_] 1
1
Definition of parameterized categories, e.g. Throws[E] or Reads(resource),
is also possible with the help of type lambdas and/or type providers.
11. Procedure Typing for Scala
Specifying procedure categories
Extensible approach
An effect system should be extensible.
⇒ We must provide a way to define procedure categories.
Procedure categories are binary types like Function[_,_] or
Logged[_,_] 1 equipped with some additional structure using an
associated type class.
1
Definition of parameterized categories, e.g. Throws[E] or Reads(resource),
is also possible with the help of type lambdas and/or type providers.
12. Procedure Typing for Scala
Specifying procedure categories
Extensible approach
Syntax details
– A =>[R] B R[A,B]
– A => B Function[A,B] , i.e. type named “Function” from the
local context, not necessarily the Function from Predef2 .
2
(A, B) should also mean Pair[A,B] from the local context, as they
must be consistent with functions: (A, B) => C ∼ A => B => C .
=
13. Procedure Typing for Scala
Specifying procedure categories
Extensible approach
Proposed syntax for definitions
def process(d: Data):
=>[Throws[InterruptedException]] Int = { ...
// Procedure types can be dependent
def copy(src: File, dest: File):
=>[Reads(src), Writes(dest)] { ...
// Pre- and postconditions can be treated as effects too:
def open(file: File):
=>[Pre{file@Closed}, Post{file@Open}] { ...
Last two examples rely on recently added dependent method types.
(N.B. Such stunts are hard to implement using type-and-effect systems.)
14. Procedure Typing for Scala
Defining procedure categories
How to define a procedure category?
15. Procedure Typing for Scala
Defining procedure categories
First of all, it should be a category in the usual mathematical sense,
i.e. we have to provide procedure composition and its neutral.
trait Category[Function[_,_]] {
def id[T]: T => T
def compose[A, B, C](f: B => C, g: A => B): A => C
}
16. Procedure Typing for Scala
Defining procedure categories
To give an example, let’s model logged functions on pure functions:
type Logged[A, B] = (A =>[Pure] (B, String))
object Logged extends Category[Logged] {
def id[T] = {x: T => (x, "")}
def compose[A, B, C](f: B => C, g: A => B) = {x: A =>
val (result1, logOutput1) = g(x)
val (result2, logOutput2) = f(result1)
(result2, logOutput1 + logOutput2)
}
}
Besides their results, logged functions produce log output of type
String. Composition of logged functions concatenates their logs.
17. Procedure Typing for Scala
Defining procedure categories
Linear functional composition is not enough.
We want to construct arbitrary circuits.
(This is the key step in enabling implicit parallelisability.)
18. Procedure Typing for Scala
Defining procedure categories
To make arbitrary circuits, we need just one additional operation
besides composition:
def affix[A, B, C, D](f: A => B, g: C => D): (A, C) => (B, D)
19. Procedure Typing for Scala
Defining procedure categories
In case of pure functions, affix is trivial:
– the execution of f and g is independent.
In case of procedures affix is not-so-trivial:
– have to pass the effects of f to the execution context of g ;
– execution order can be significant.
20. Procedure Typing for Scala
Defining procedure categories
Thus, procedures belong to a stronger structure than just a
category, namely a structure embracing the affix operation.
Such a structure is called circuitry.
21. Procedure Typing for Scala
Defining procedure categories
A circuitry is a closed monoidal category with respect to the affix
operation, where affix splits as follows:
trait Circuitry[F[_,_]] extends PairCategory[F] {
def passr[A, B, C](f: A => B): (A, C) => (B, C)
def passl[B, C, D](g: C => D): (B, C) => (B, D)
override def affix[A, B, C, D](f: A => B, g: C => D) = {
compose(passl(g), passr(f))
}
}
+ =
22. Procedure Typing for Scala
Defining procedure categories
For the mathematicians among us:
trait PairCategory[F[_,_]] extends Category[F] {
type Pair[A, B]
def assoc[X, Y, Z]: ((X, Y), Z) => (X, (Y, Z))
def unassoc[X, Y, Z]: (X, (Y, Z)) => ((X, Y), Z)
type Unit
def cancelr[X]: (X, Unit) => X
def cancell[X]: (Unit, X) => X
def uncancelr[X]: X => (X, Unit)
def uncancell[X]: X => (Unit, X)
def curry[A, B, C](f: (A, B) => C): A => B => C
def uncurry[A, B, C](f: A => B => C): (A, B) => C
def affix[A, B, C, D](f: A => B, g: C => D): (A, B) => (C, D)
}
23. Procedure Typing for Scala
Defining procedure categories
For the mathematicians among us:
trait PairCategory[F[_,_]] extends Category[F] {
type Pair[A, B]
def assoc[X, Y, Z]: ((X, Y), Z) => (X, (Y, Z))
def unassoc[X, Y, Z]: (X, (Y, Z)) => ((X, Y), Z)
type Unit
def cancelr[X]: (X, Unit) => X
def cancell[X]: (Unit, X) => X
def uncancelr[X]: X => (X, Unit)
def uncancell[X]: X => (Unit, X)
def curry[A, B, C](f: (A, B) => C): A => B => C
def uncurry[A, B, C](f: A => B => C): (A, B) => C
def affix[A, B, C, D](f: A => B, g: C => D): (A, B) => (C, D)
}
Don’t panic!
24. Procedure Typing for Scala
Defining procedure categories
For the mathematicians among us:
trait PairCategory[F[_,_]] extends Category[F] {
type Pair[A, B]
def assoc[X, Y, Z]: ((X, Y), Z) => (X, (Y, Z))
def unassoc[X, Y, Z]: (X, (Y, Z)) => ((X, Y), Z)
type Unit
def cancelr[X]: (X, Unit) => X
def cancell[X]: (Unit, X) => X
def uncancelr[X]: X => (X, Unit)
def uncancell[X]: X => (Unit, X)
def curry[A, B, C](f: (A, B) => C): A => B => C
def uncurry[A, B, C](f: A => B => C): (A, B) => C
def affix[A, B, C, D](f: A => B, g: C => D): (A, B) => (C, D)
}
Don’t panic!
In most cases the default Pair and Unit work perfectly well.
⇒ No need to understand any of this, just use with Cartesian .
25. Procedure Typing for Scala
Defining procedure categories
Elements of circuitries are called generalised arrows.
Besides procedures, circuitries provide a common formalism for:
– reversible quantum computations;
– electrical and logical circuits;
– linear and affine logic;
– actor model and other process calculi.
Circuitries provide the most general formalism for computations, see
“Multi-Level Languages are Generalized Arrows”, A. Megacz.
26. Procedure Typing for Scala
Defining procedure categories
We are talking mostly about procedure typing, so we are going to
consider some special cases:
Arrow circuitries3 : circuitries generalising =>[Pure] .
Executable categories: categories generalising to =>[Proc] .
Procedure categories: executable cartesian4 procedure circuitries.
3
AKA plain old “arrows” in Haskell and scalaz.
4
i.e. having cartesian product types.
27. Procedure Typing for Scala
Defining procedure categories
trait ArrowCircuitry[F[_,_]] extends Circuitry[F] {
def reify[A, B](f: A =>[Pure] B): A => B
... // With reify we get id and passl for free
}
trait Executable extends Category[_] {
def eval[A, B](f: A => B): A =>[Proc] B
// eval defines the execution strategy
}
trait ProcCategory[F[_,_]] extends ArrowCircuitry[F] with
Executable with Cartesian {
... // Some additional goodies
}
28. Procedure Typing for Scala
Defining procedure categories
It’s time to give a full definition of =>[Logged] :
type Logged[A, B] = (A =>[Pure] (B, String))
object LoggedCircuitryImpl extends ProcCategory[Logged] {
def reify[A, B](f: A =>[Pure] B) = {x: A => (f(x), "")}
def compose[A, B, C](f: B => C, g: A => B) = {x: A =>
val (result1, logOutput1) = g(x)
val (result2, logOutput2) = f(result1)
(result2, logOutput1 + logOutput2)
}
def passr[A, B, C](f: A => B): = {x : (A, C) =>
val (result, log) = f(x._1)
((result, x._2), log)
}
def eval[A, B](p: A => B) = {x: A =>
val (result, log) = p(x)
println(log); result
}
}
29. Procedure Typing for Scala
Defining procedure categories
It’s time to give a full definition of =>[Logged] :
type Logged[A, B] = (A =>[Pure] (B, String))
object LoggedCircuitryImpl extends ProcCategory[Logged] {
def reify[A, B](f: A =>[Pure] B) = {x: A => (f(x), "")}
def compose[A, B, C](f: B => C, g: A => B) = {x: A =>
val (result1, logOutput1) = g(x)
val (result2, logOutput2) = f(result1)
(result2, logOutput1 + logOutput2)
}
def passr[A, B, C](f: A => B): = {x : (A, C) =>
val (result, log) = f(x._1)
((result, x._2), log)
}
def eval[A, B](p: A => B) = {x: A =>
val (result, log) = p(x)
println(log); result
}
}
Wasn’t that easy?
30. Procedure Typing for Scala
Defining procedure categories
Additionally we need a companion object for Logged[_,_] type.
That’s where circuitry-specific primitives should be defined.
object Logged {
val log: Logged[Unit, Unit] = {s: String => ((),s)}
}
31. Procedure Typing for Scala
Defining procedure categories
Other circuitry-specific primitives include:
– throw and catch for =>[Throws[E]]
– shift and reset for =>[Cont]
– match/case and if/else for =>[WithChoice]
– while and recursion for =>[WithLoops]
– etc.
Often they have to be implemented with Scala macros (available in
a next major Scala release near you).
32. Procedure Typing for Scala
Language purification by procedure typing
Note that impure code is localised to the eval method.
Thus, thorough usage of procedure typing localizes
impurities to well-controlled places in libraries.
Except for these, Scala becomes a clean multilevel language,
with effective type systems inside blocks being type-and-effect
systems internal to corresponding circuitries.
33. Procedure Typing for Scala
Language purification by procedure typing
Curry-Howard-Lambek correspondence
relates type theories, logics and categories:
For cartesian closed categories:
Internal logic = constructive proposition logic
Internal language = simply-typed λ-calculus
For locally cartesian closed categories:
Internal logic = constructive predicate logic
Internal language = dependently-typed λ-calculus
...
34. Procedure Typing for Scala
Language purification by procedure typing
Curry-Howard-Lambek correspondence
relates type theories, logics and categories:
For cartesian closed categories:
Internal logic = constructive proposition logic
Internal language = simply-typed λ-calculus
For locally cartesian closed categories:
Internal logic = constructive predicate logic
Internal language = dependently-typed λ-calculus
...
Informally, the work of A. Megacz provides an extension of it:
For arrow circuitries:
Internal logics = contextual logics
Internal languages = type-and-effect extended λ-calculi
35. Procedure Typing for Scala
Language purification by procedure typing
Scala purification/modularization programme
– Design a lattice of procedure categories between Pure and
Proc . In particular, reimplement flow control primitives as
macro5 methods in companion objects of respective categories.
5
One reason for employing macros is to guarantee that scaffoldings will be
completely removed in compile time with no overhead on the bytecode level.
36. Procedure Typing for Scala
Language purification by procedure typing
Scala purification/modularization programme
– Design a lattice of procedure categories between Pure and
Proc . In particular, reimplement flow control primitives as
macro5 methods in companion objects of respective categories.
– Implement rules for lightweight effect polymorphism using a
system of implicits à la Rytz-Odersky-Haller (2012)
5
One reason for employing macros is to guarantee that scaffoldings will be
completely removed in compile time with no overhead on the bytecode level.
37. Procedure Typing for Scala
Language purification by procedure typing
Scala purification/modularization programme
– Design a lattice of procedure categories between Pure and
Proc . In particular, reimplement flow control primitives as
macro5 methods in companion objects of respective categories.
– Implement rules for lightweight effect polymorphism using a
system of implicits à la Rytz-Odersky-Haller (2012)
– Retrofit Akka with circuitries internalizing an appropriate actor
calculus + ownership/borrowing system (Haller, 2010).
5
One reason for employing macros is to guarantee that scaffoldings will be
completely removed in compile time with no overhead on the bytecode level.
38. Procedure Typing for Scala
Comparing with other notions of computation
How do circuitries compare to
other notions of computation?
39. Procedure Typing for Scala
Comparing with other notions of computation
Type-and-effect systems
Type-and-effect systems are the most well studied approach to
procedure typing:
40. Procedure Typing for Scala
Comparing with other notions of computation
Type-and-effect systems
Type-and-effect systems are the most well studied approach to
procedure typing: effects are specifiers as annotations for
“functions”; type system is extended with rules for “effects”.
41. Procedure Typing for Scala
Comparing with other notions of computation
Type-and-effect systems
Type-and-effect systems are the most well studied approach to
procedure typing: effects are specifiers as annotations for
“functions”; type system is extended with rules for “effects”.
Circuitry formalism is not an alternative, but an enclosure for
them.
42. Procedure Typing for Scala
Comparing with other notions of computation
Type-and-effect systems
Direct implementation of type-and-effect systems
– is rigid (hardly extensible) and
– requires changes to the typechecker.
43. Procedure Typing for Scala
Comparing with other notions of computation
Type-and-effect systems
Direct implementation of type-and-effect systems
– is rigid (hardly extensible) and
– requires changes to the typechecker.
Embedding effects into the type system by means of
the circuitry formalism resolves the issues above.
44. Procedure Typing for Scala
Comparing with other notions of computation
Monads
Arrows generalise monads
In Haskell, monads are used as basis for imperative programming,
but they are often not general enough (see Hughes, 2000).
Monads are similar to cartesian arrow circuitries. The only
difference is that they are not equipped with non-linear composition.
45. Procedure Typing for Scala
Comparing with other notions of computation
Monads
Monads
– do not compose well,
– prescribe rigid execution order,
– are not general enough for concurrent computations.
46. Procedure Typing for Scala
Comparing with other notions of computation
Monads
Monads
– do not compose well,
– prescribe rigid execution order,
– are not general enough for concurrent computations.
Circuitries were invented to cure this.
47. Procedure Typing for Scala
Comparing with other notions of computation
Applicatives
Applicatives are a special case of arrows...
If procedures of type =>[A] never depend on effects of other
procedures of the same type, A is called essentially commutative.
Example
=>[Reads(config), Writes(log), Throws[NonBlockingException]]
Essentially commutative arrows arise from applicative functors.
They are flexible and easy to handle: you don’t have to propagate
effects, just accumulate them behind the scenes.
48. Procedure Typing for Scala
Comparing with other notions of computation
Applicatives
...but not a closed special case!
Composing applicatives may produce non-commutative circuitries
like =>[Reads(file), Writes(file)] .
Procedures of this type are no longer effect-independent: effect of
writes have to be passed to subsequent reads.
Besides these, there are also inherently non-commutative arrows
such as those arising from monads6 , comonads and Hoare triples7 .
6
e.g. Tx = transaction monad, Cont = continuation passing monad.
7
pre- and postconditioned arrows.
49. Procedure Typing for Scala
Comparing with other notions of computation
Traditional imperative approach
Can we do everything available in imperative
languages with arrows and circuitries?
50. Procedure Typing for Scala
Comparing with other notions of computation
Traditional imperative approach
Can we do everything available in imperative
languages with arrows and circuitries?
Any imperative code can be reduced to compose and affix.
51. Procedure Typing for Scala
Comparing with other notions of computation
Traditional imperative approach
Can we do everything available in imperative
languages with arrows and circuitries?
Any imperative code can be reduced to compose and affix.
The reduction process is known as variable elimination, it can be
understood as translation to a concatenative language like Forth.
52. Procedure Typing for Scala
Comparing with other notions of computation
Traditional imperative approach
Can we do everything available in imperative
languages with arrows and circuitries?
Any imperative code can be reduced to compose and affix.
The reduction process is known as variable elimination, it can be
understood as translation to a concatenative language like Forth.
(The concatenative languages’ juxtaposition is an overloaded operator reducing
to either compose or affix depending on how operands’ types match.)
53. Procedure Typing for Scala
Comparing with other notions of computation
Traditional imperative approach
Can we do everything available in imperative
languages with arrows and circuitries?
Any imperative code can be reduced to compose and affix.
The reduction process is known as variable elimination, it can be
understood as translation to a concatenative language like Forth.
(The concatenative languages’ juxtaposition is an overloaded operator reducing
to either compose or affix depending on how operands’ types match.)
But! Writing code this way can be quite cumbersome.
54. Procedure Typing for Scala
Do-notation
Defining procedure categories is easy
enough. How about using them?
We develop a quasi-imperative notation8 and implement it using
macros.
Our notation shares syntax with usual Scala imperative code...
...but has different semantics: it compiles to a circuit of
appropriate type instead of being executed immediately.
8
Akin to Haskell’s do-notation, but much easier to use.
55. Procedure Typing for Scala
Do-notation
Defining procedure categories is easy
enough. How about using them?
We develop a quasi-imperative notation8 and implement it using
macros.
Our notation shares syntax with usual Scala imperative code...
...but has different semantics: it compiles to a circuit of
appropriate type instead of being executed immediately.
Circuit notation for Scala is the topic of the part II...
8
Akin to Haskell’s do-notation, but much easier to use.
56. Procedure Typing for Scala
Do-notation
Do-notation example
...but here’s a small example to keep your interest
Even pure functions have a side effect: they consume time.
=>[Future] is an example of a retrofitting procedure category9 .
=>[Future] {
val a = alpha(x)
val b = beta(x)
after (a | b) {
Log.info("First one is completed")
}
after (a & b) {
Log.info("Both completed")
}
gamma(a, b)
}
9
its reify is a macro, so any procedures can be retrofitted to be =>[Future].
57. Procedure Typing for Scala
Do-notation
Literature:
– The marriage of effects and monads, P. Wadler, P. Thiemann
– Generalising monads to arrows, J. Hughes
– The Arrow Calculus, S. Lindley, P. Wadler, and J. Yallop
– Categorical semantics for arrows, B. Jacobs et al.
– What is a Categorical Model of Arrows?, R. Atkey
– Parameterized Notions of Computation, R. Atkey
– Multi-Level Languages are Generalized Arrows, A. Megacz
58. Procedure Typing for Scala
Syntax for Circuitires
Part II: Syntax for Circuitires
A cup of coffee?
59. Procedure Typing for Scala
Syntax for Circuitires
Implicit Unboxing
How do you use an arrow (say f: Logged[Int, String] ) in
present Scala code?
println(f(5)) seems to be the obvious way, but that’s
impossible, application is not defined for f.
To facilitate such natural notation, we need implicit unboxing.
60. Procedure Typing for Scala
Syntax for Circuitires
Implicit Unboxing
Preliminaries
A wrapping is a type F[_] equipped with eval[T](v: F[T]): T
and reify[T](expr: => T): F[T] (reify often being a macro) so
that
eval(reify(x)) ≡ x and
reify(eval(x)) ≡ x for all x of the correct type.
61. Procedure Typing for Scala
Syntax for Circuitires
Implicit Unboxing
Preliminaries
A wrapping is a type F[_] equipped with eval[T](v: F[T]): T
and reify[T](expr: => T): F[T] (reify often being a macro) so
that
eval(reify(x)) ≡ x and
reify(eval(x)) ≡ x for all x of the correct type.
A prototypical example where reify is a macro is Expr[T]. Example
with no macros involved is Future[T] (with await as eval).
62. Procedure Typing for Scala
Syntax for Circuitires
Implicit Unboxing
Preliminaries
Implicit unboxing is this: whenever a value of the wrapping type
F[T] is found where a value of type T is accepted, its eval is called
implicitly.
In homoiconic languages (including Scala), all expressions can be
considered initially having the type Expr[T] and being unboxed into
T by an implicit unboxing rule Expr[T] => T .
63. Procedure Typing for Scala
Syntax for Circuitires
Implicit Unboxing
Syntax proposal
Let’s introduce an instruction implicit[F] enabling implicit
unboxing for F in its scope.
Implicit contexts can be implemented using macros:
– macro augments the relevant scope by F.reify as an implicit
conversion from F[T] to T;
– F.eval is applied to every occurrence of a symbol having or
returning type F[T] which is defined outside of its scope.
64. Procedure Typing for Scala
Syntax for Circuitires
Implicit Unboxing
Code that uses futures and promises can be made much more
readable by implicit unboxing.
An example: dataflows in Akka 2.0. Presently they look like this:
flow {
z << (x() + y())
if (v() > u) println("z = " + z())
}
65. Procedure Typing for Scala
Syntax for Circuitires
Implicit Unboxing
Now this can be recast without any unintuitive empty parentheses:
flow {
z << x + y
if (v > u) println("z = " + z)
}
66. Procedure Typing for Scala
Syntax for Circuitires
Implicit Unboxing
Back to our Logged example:
implicit[Logged]
def example(f: Int =>[Logged] String, n: Int): List[String] {
f(n).split(", ")
}
Which translates to:
def example(f: Int =>[Logged] String, n: Int): List[String] {
LoggedCircuitryImpl.eval(f)(n).split(", ")
}
67. Procedure Typing for Scala
Syntax for Circuitires
Purifying Scala
Now, which procedure category should example() belong to?
As it evaluates =>[Logged], it should be =>[Logged] itself. This
allows its reinterpretation without any usage of eval:
def example(f: Int =>[Logged] String, n: Int): List[String] = {
import LoggedCircuitryImpl._
reify{n} andThen f andThen reify{_.split(", ")}
}
This is now a pure code generating a new circuit of the type
=>[Logged] based on the existing one (f) and some pure functions.
68. Procedure Typing for Scala
Syntax for Circuitires
Purifying Scala
Purity Declaration
Let’s introduce @pure annotation which explicitly forbids calling
any functions with side effects and assignments of foreign variables.
This renders the code pure.
Procedure with side effects have to be composed by circuit
composition operations which are pure. The execution of
procedures, which is impure, always lies outside of the scope.
All code examples below are to be read as @pure .
69. Procedure Typing for Scala
Syntax for Circuitires
Purifying Scala
Inside of @pure implicit unboxing for arrows becomes
implicit circuit notation, which is operationally
indistinguishable, but semantically different.
70. Procedure Typing for Scala
Syntax for Circuitires
Circuit notation
Circuit notation, general idea:
– write circuitry type like =>[X] in front of a braced code block;
– the code block will be reinterpreted as a circuitry of the given
type (via macros).
72. Procedure Typing for Scala
Syntax for Circuitires
Circuit notation
In presence of implicit[X] every free braced block {...}
which uses external symbols of the type =>[X] should be
treated as =>[X] {...} , an implicit form of circuit syntax.
73. Procedure Typing for Scala
Syntax for Circuitires
Circuit notation
The desugaring rules producing operationally indistinguishable
circuits from imperative-style code blocks are quite complicated,
but certainly doable.
To make the other direction possible, we need an additional
operator: after .
74. Procedure Typing for Scala
Syntax for Circuitires
Circuit notation
Consider two arrows f: Unit => Unit and g: Unit => Unit .
They can be composed in two ways: f affix g (out-of-order) and
f andThen g (in-order).
affix in circuit notation will obviously look like f; g , though for
andThen we need some new syntax:
=>[Future] {
val n = f
after(n) g
}
75. Procedure Typing for Scala
Syntax for Circuitires
Circuit notation
Without after , =>[Future] and other similar circuitries respect
only dataflow ordering, but ignore the order of independent effects
(e.g. writing into a log).
By combining usual imperative notation and after ,
any possible circuit configurations can be achieved.
76. Procedure Typing for Scala
Syntax for Circuitires
Circuit notation
Now the example stated above is fully understandable:
=>[Future] {
val a = alpha(x)
val b = beta(x)
after (a | b) {
Log.info("First one is completed")
}
after (a & b) {
Log.info("Both completed")
}
gamma(a, b)
}
( after trivially supports any combinations of ands and ors.)
77. Procedure Typing for Scala
Syntax for Circuitires
Circuit notation
Blocks as Objects
For the sake of composability, blocks should be treated as
anonymous classes extending their arrow type:
=>[Future] {
val result = {
@expose val partialResult = compute1(x)
compute2(partialResult)
}
after (result.partialResult) {
Log.info("Partial result ready")
}
}
The result in the after context is not just =>[Future] Int , but
its anonymous descendant with a public member partialResult .
78. Procedure Typing for Scala
Syntax for Circuitires
Circuit notation
Of course, it should also work for named blocks:
def lengthyComputation(x: Double): Double = {
var _progress = 0.0 // goes from 0.0 to 1.0
@expose def progress = _progress // public getter
... // _progress is updated when necessary
}
val f = future someLengthyCalculation(x)
while (!f.isDone) {
Log.info("Progress: " + f.progress)
wait(500 ms)
}
(This is a perfect example of what can easily be done with macros.)
79. Procedure Typing for Scala
Syntax for Circuitires
Circuit notation
The exact desugaring rules are quite complex (but perfectly real).
We hope these examples gave you some insight how everything
might work.
Thank you!