Lambda the Ultimate

A blog post on the Racket Blog describes Racket newly-added submodules, along with interesting use cases.

Submodules provide nested namespaces, but that kind of nesting is already available through forms like define-package. The power of submodules is that they can be separately loaded and separately run relative to their enclosing modules, in the same way that top-level modules can be separately load and run. This separation of dependencies means that submodules can be used to add code and information to modules—such as tests, documentation, and parsing information—that is loaded only when specifically requested.

[...]

At some level, syntactic nesting of modules is an obvious feature to include in a module system. Nevertheless, Racket’s submodules are not like nested modules most languages—including Python, Chez, or ML—where nesting is for namespace management and nested modules are always instantiated in along with the enclosing module. Racket submodules can be used in a similar way, but the fact that submodules are separately loadable makes them available to solve a larger class of problems.

If I had to pick just one analogy, I’d say that submodules are most like a generalization of annotations in the Java sense. Java annotations allow the decoration of code with metadata, and the annotations are preserved through run time, so that annotations can be inspected in source, in compiled code, or reflectively at run time. Java annotations are limited to data, so that any abstraction or programatic interpretation of the data depends on yet another external tool and language, or else the code part (such as test to run for a @Test annotation) is difficult to separate from the main program. C# attributes are slightly more general, in that the data can have associated methods, but attribute code is still mingled with run-time code. Submodules generalize annotations to make them “live,” so that the language of annotations can include expressions, functions, and even syntactic extensions, while allowing the annotation/submodule code to stay separate from the base code.

Talents: Dynamically Composable Units of Reuse by Jorge Ressia, Tudor Gîrba, Oscar Nierstrasz, Fabrizio Perin, and Lukas Renggli. Proceedings of International Workshop on Smalltalk Technologies (IWST 2011), p. 109—118, 2011.

Reuse in object-oriented languages typically focuses on inheritance. Numerous techniques have been developed to provide finer-grained reuse of methods, such as flavors, mixins and traits. These techniques, however, only deal with reuse at the level of classes. Class-based reuse is inherently static. Increasing use of reflection and meta-programming techniques in real world applications underline the need for more dynamic approaches. New approaches have shifted to object-specific reuse. However, these techniques fail to provide a complete solution to the composition issues arising during reuse. We propose a new approach that deals with reuse at the object level and that supports behavioral composition. We introduce a new abstraction called a talent which models features that are shared between objects of different class hierarchies. Talents provide a composition mechanism that is as flexible as that of traits but which is dynamic.

A pretty funny video by Gary Bernhardt on some surprising behaviour in Ruby and JavaScript. I think Wat as a term of art for this phenomenon is quite appropriate.

There's also a follow-up blog post by Adam Iley explaining some of the behaviours in JS seen in that video, if anyone wants to understand the underlying semantics behind these behaviours.

Since we're all PL enthusiasts here, I expect everyone here will have their own lessons to take from this 4 minute video. Myself, it seems a perfect example of the dangers of implicit conversions and overloading. Stuff like this makes we want to crawl back to OCaml where overloading is forbidden.

Hi All,

Pythonect is almost two months old and I think it's a good time to promote a design discussion on the language syntax.
The current syntax works great, but it is limited, and makes writing complex programs difficult. For example:


range(99, 0, -1) | str -> _ + " bottle(s) of beer on the wall," -> print -> _.split(" on")[0] + '.' -> print -> print("Take one down, pass it around,")


This is a variant of '99 Bottles of Beer' program written in Pythonect, and it's not the easiest code to read and understand.

I am looking for syntax proposals to complement Pythonect syntax, and I have started a wiki page for it at:


https://github.com/ikotler/pythonect/wiki/Call-For-Syntax


Anyone can edit the syntaxes wiki page and add a new syntax proposal. A proposal can be a new idea, based on another, or mix-up of two or more.
Also, please include with each proposal (in the wiki) the following programs written in the proposed syntax:

* Hello World program
* 99 Bottles of Beer program
* Multithread Counter (a simple loop that prints from 1 to 10 in each thread) program

This will help show the look and feel of the proposed syntax, as well as to be able to compare it to another proposal.


To kick off the discussion, I have added 4 potential syntaxes (Python-like, C-like, Musical notation like, and F#-like) to the wiki page, and I am looking forward to have them reviewed.


All feedback and comments are appreciated.

Itzik Kotler

Order structures seem to be abstract concepts of theoretical mathematics with
minor practical importance. But this is just at first glance. A closer look
reveals that many data types have order structure.

• The basic types NATURAL, INTEGER, FLOAT etc. have a total order
• The type SET[T] has a partial order with "is_subset" playing the role of
  "<=".
• All inductive types have a partial order where "a<=b" means "a has been used
  directly or indirectly in the construction of b". E.g. any subtree of a tree
  is smaller than the tree.
• The nodes in a graph have a preorder relation with "a<=b" meaning "a can
  reach b".
• The functions "f:A->B" have a partial order where the "smaller" function has
  the same values as the "greater" function but has a restricted domain.
• The predicates "p:T?" have a partial order where "a<=b" meaning "a" is
  stronger than "b", i.e. "a" has less elements for which it is true than "b".

The article Order structure, an excercise in abstraction and multiple inheritance
describes preorders and partial orders together with the basic assertions which can
be derived from the basic structure and its functions.

Why is it interesting to carve out the order structure?

It is possible to prove a lot of properties by just using the definition of
the functions of order relations. Any structure which inherits the appropriate
order relation has access to all already proved asssertions. The order classes
act as an "assertion library" and inheritance is reuse of these assertions.

The May issue of Journal of Software contains a paper that applies dependent type theory to component-based programming.
The paper is potentially interesting to people interested in extending Haskell's type system in various directions.

Abstract
Hancock and Setzer describe how Haskell’s monolithic IO monad can be decomposed into worlds when working in a dependently typed language, like Martin-Löf’s type theory.

This paper introduces the notion of world map and shows that worlds and world maps form a category with arbitrary products. The construction of the category is carried out entirely in type theory and directly implementable in dependently typed programming languages.

If we let the notion of world replace the standard notion of interface, and the notion of world map replace the standard notion of component, we get a rigorous paradigm for component-based development. This new paradigm is investigated and several applications are given. For example, the problem of session state is given a very clean solution.

The paper has open access and is available from here.

PDF direct link.

Here is an interesting construct I'm working with recently. Say we have an abstract class (trait) with one abstract method do:

trait A {
  abstract void do();
}

Now say we have two implementations:

trait B : A {
  override void do() { ... }
}
trait C : A {
  override void do() { ... }
}
object myUnderspecifiedA : A { ... }

Given an under specified object that extends A, the compiler could choose either B or C to "complete" it; perhaps we have a model that expresses that an object that extends A more often extends B rather than C, so why not just select that? Also, the object might only be able to extend one trait and not the other to implement "do," consider:

trait D : A {
  abstract void bar();
}
trait E : D {
  override void bar() { ... }
}
trait F : D {
  override void bar() { ... }
}
trait B : E {
  override void do() { ... }
}
trait G : A {
  abstract void foo();
}
trait C : F, G {
  override void do() { ... }
}
trait H : G {
  override void foo() { ... }
}

object myUnderspecifiedAWithF : A with F { ... }

In this case, the compiler could have the object extend C but not B, since in the latter case the bar method would be implemented in two different ways. Now, the completion of an object with additional traits is recursive: because we have the object extend C, we must now find a trait to implement the abstract foo method from an extended G trait, so we then also choose H (the final solution includes A, F, C, H). Finding a solution for the object then involves finding a trait that implements an abstract method, adding that trait to the extend list, then solving for additional abstract methods; the solution could always dead-end and require backtracking, so this algorithm kind of looks like a Prolog solver.

Has anyone heard of a class system like this before? My goal is to have a language where you can under specify a program and the compiler will fill in the gaps by finding traits to implement abstract methods that maintains consistency. A "best" solution could be chosen based on a model that includes "can-be" probabilities.

A quite interesting and definitely LtU-relevant blog post on "Crowd documentation". Which is actually just a good sales pitch for the following technical report: Crowd Documentation: Exploring the Coverage and the Dynamics of API Discussions on Stack Overflow

Chris Parnin, Cristoph Teude, Lars Grammel and Margaret-Anne Storey (2012)

Traditionally, many types of software documentation, such as API documentation, require a process where a few people write for many potential users. The resulting documentation, when it exists, is often of poor quality and lacks sufficient examples and explanations. In this paper, we report on an empirical study to investigate how Question and Answer (Q&A) websites, such as Stack Overflow, facilitate crowd documentation — knowledge that is written by many and read by many. We examine the crowd documentation for three popular APIs: Android, GWT, and the Java programming language. We collect usage data using Google Code Search, and analyze the coverage, quality, and dynamics of the Stack Overflow documentation for these APIs. We find that the crowd is capable of generating a rich source of content with code examples and discussion that is actively viewed and used by many more developers. For example, over 35,000 developers contributed questions and answers about the Android API, covering 87% of the classes. This content has been viewed over 70 million times to date. However, there are shortcomings with crowd documentation, which we identify. In addition to our empirical study, we present future directions and tools that can be leveraged by other researchers and software designers for performing API analytics and mining of crowd documentation.

D3 is a popular HTML5 visualization framework. While similar to other JS frameworks in its exposure of CSS/SVG, its enter()/exit() abstraction is an elegant leap for structuring code. Check out Mike Bostock's short and direct explanation Thinking with Joins:

Say you’re making a basic scatterplot using D3, and you need to create some SVG circle elements to visualize your data. You may be surprised to discover that D3 has no primitive for creating multiple DOM elements. WAT?

I particularly appreciated the practicality of this model for designing animated transitions. You can also check out the beautiful gallery of examples.

Has there been any PL research into languages where every semantically distinct program has exactly one representation in the source language? In other words, a language where for any given set of inputs, any change in the source text will create a program that for the same set of input produces a different set of outputs than the original program. Basically taking Python's "there should be one-- and preferably only one --obvious way to do it" philosophy to its logical extreme. I'm interested in how limiting this is on what you can express, since for any two equivalent algorithms only one of them could be written in the language. Is there an established technical term for this I can Google?