Lambda the Ultimate

We very recently published a long-ish article on the ParaSail programming language (ParaSail = Parallel Specification and Implementation Language) in the relatively new Journal on the Art, Science, and Engineering of Programming, Volume 3, Issue 3:

ParaSail: A Pointer-Free Pervasively-Parallel Language for Irregular Computations

There is also a new (version 8.0) release of the ParaSail binaries (Linux, Mac, and partial Windows) and sources at:

http://parasail-lang.org

A direct download is available at: http://bit.ly/psl8rel

DZone has published 3 my articles:

• Abstraction Tiers of Notations (Part 1)
• A New Generation of Programming Languages (Part 2)
• On Evolution of Database Languages, Part 3

Few key points from them:

• Abstractions are not created equal and they could be sorted by tiers depending on structural elements they use and the way these elements are used.
• The tiers are closely tied to cognitive development stages as described by J. Piaget and M.L. Commons.
• Each new tier of the abstractions is built upon constructs of the previous tier.
• Adoption of new tier causes major generation of the general-purpose programming language to appear.
• Basing on the model, the next generation of general-purpose programming languages will be likely System-Oriented Programming. That will use ‘system’ as a new category of type that could be instantiated. Current dependency injection frameworks are early and incomplete attempts to implement this new abstraction.
• Basing on the model, the evolution of the database languages should be parallel to the evolution of general-purpose programming languages, with the same abstraction tiers adopted.

Note, I’ve described some elements of this model in some discussions on LtU previously.

Hello,

I am looking for papers and a particular paper I used to have on covariance and contravariance.

The paper I used to have many years ago probably about 2006 or 2007 when I originally started looking into type theory and did not realize its relevance had many inference rules for covariance and contravariance using plus and minus symbols within the inference rules.

I am now researching this area and am interested in any papers on this topic.

Many thanks in advance,

Aaron Gray

Recently, while re-reading through the Haskell Typeclassopedia I thought it would be a good exercise to map the structure of software design-patterns to the concepts found in the Haskell type class library and in functional programming in general.

By searching the web I found some blog entries studying specific patterns, but I did not come across any comprehensive study. As it seemed that nobody did this kind of work yet I found it worthy to spend some time on it and write down all my findings on the subject.

I think this kind of exposition could be helpful if you are either:

- a programmer with an OO background who wants to get a better grip on how to implement complexer designs in functional programming
- a functional programmer who wants to get a deeper intuition for type classes.

I have set this up as a GitHub project with full sourcecode for all examples:

The Patternopedia

POLA Would Have Prevented the Event-Stream Incident by Kate Sills

The JavaScript world was rocked this week by news that the popular npm package event-stream included malicious code that attempted to steal the private keys of certain Bitcoin users.

Since the attack was discovered, both the JavaScript community and the cryptocurrency community have been passionately debating how to prevent such an attack. At Agoric, we think this attack was entirely preventable, and the answer is POLA, the Principle of Least Authority.

This npm / event-stream debacle is the perfect teaching moment for POLA (Principle of Least Authority), and for the need to support least authority for JavaScript libraries. My talk Securing EcmaScript, presentation to Node Security explained many of these issues prior to this particular incident.

For LtU, my best explanation of POLA is Verify What? Navigating the Attack Surface given to the "Formal Methods Meets JavaScript" workshop at Imperial College.

https://youtu.be/rp_Eild1aq8

Monads are passé, apparently.

Previously mentioned on ltu rather a long time ago http://lambda-the-ultimate.org/node/5151

I’m looking at type theory from point of view of the general-purpose programming language evolution, and I’ve found something that does not look nice.

There is stage when function pointers like ones in C were introduced to the languages. Differently from lambdas they are stateless and they could be only evaluated using their explicit arguments and using only constants (or global state) and by calling other stateless functions. Their type will be designated as:

T ⇨ A

Now let’s take usual lambdas, their type will be designated as:

T → A

The relationship between these two types is the following:

A → B = ∃ T (T ⨉ (T ⨉ A ⇨ B))
apply:  (A → B) ⨉ A ⇨ B = 𝜆 ((t, f), a), f(t, a) // unpacking existential type here
curry: ((A ⨉ B) → C) ⇨ (A → B → C) = 𝜆(t, f) ((t, f), (𝜆((t1, f1),  a1) ((t1, f1, a1),  (𝜆((t2, f2, a2), b2)  f2(t2, (a2, b2))))))

Such definition is needed to support currying and to capture implicit environment, and it reflects what is actually happens in the code. Every function from T ⇨ A could be trivially converted to T → A, however stateless functions have different set operations supported. Particularly, currying is not supported. So, it is not subclass, but a separate entity type.

This existential type captures difference between structured programming paradigm and object-oriented or functional programming paradigms. So, theoretically, when we would try to study paradigms, we would also need to make this distinction.

I’m interested if there are some research papers that describe this distinction. The discussion in the TaPL book is somewhat unsatisfying because explicit existential types are defined using implicit existential types. Theoretically, the type theory should start from stateless functions to reflect evolution path rather than in reverse direction. Such point of view might be also useful for the compiler transformation reasoning, so there might be papers on such equivalence in that area too.

Golly, how did I never hear of this before?

Flix is a declarative language for specifying and solving fixed-point computations on lattices, such as static program analyses. The syntax and semantics of Flix are inspired by Datalog, but extended to support user-defined lattices and monotone functions. Flix is open-source and available on GitHub.

Static analyzers implemented in general-purpose languages, such as C++ or Java, can be difficult to understand and maintain. A more elegant approach is to express the mutual dependencies of a fixed-point computation in a declarative manner. Thus, there is interest in using a declarative language such as Datalog to implement pointer analyses.

However, Datalog does not support lattices or functions, which limits its expressivity. While it is sometimes possible to work around these limitations, it can be slow and cumbersome. Furthermore, most Datalog implementations have poor integration with existing tools.

Flix allows users to define their own lattices and functions. Rules over relations and lattices are expressed in a logic language with Datalog-like syntax, while functions are written in a pure functional language with Scala-like syntax. The functional language, while small, supports algebraic data types, sets, and pattern matching. Flix also supports interop with JVM languages.

Flix is implemented in Scala, with a standard front-end for parsing, weeding, resolving, and typechecking. The back-end has two components, a solver for the logic language and an interpreter for the functional language. As an initial step to improve performance, we have implemented a bytecode generator to replace the interpreter.

I thought I'd let you all know about a video lecture I gave on Scheme continuations, and how they can be used to generate all sorts of control structures. Enjoy!

Continuations: The Swiss Army Knife of Flow Control

My old half-baked idea/dream of a cranky day job programmer who doesn't really know what he's talking about:

• Convert everything in to CPS.
• Each function call is a new continuation.
• Have a top level 'event loop' that runs the next continuation one at a time.
• The runner checks the signature of the next function vs. a lookup table for hooks to run before and/or after the invocation.

This gives super powers like:

• AoP join points at every function. In languages that are more expression than statement oriented, more pure fp style, then that means there's a lot of opportunity for join points.
• Logging is more flexible, at any join point, dynamically adding/removing/tweaking at runtime.
• Ability to run prod & test versions of any function side by side and compare behaviour.

Code would still be interacted with by developers in original format. Since e.g. hypothetically anything can be converted from imperative to monadic pure fp style then e.g. Java could be set up this way. The UX for adding hooks would be nice and all at a high level, looking like source code, not some internal runtime CPS hell.