Lambda the Ultimate

I have put a C++ parser combinator library on GitHub https://github.com/keean/Parser-Combinators. There is an example to show how it is used, and there is a simple recursive decent parser for comparison. The parser-combinators benchmark 20% faster than the simple parser. I would appreciate comments on the code, the choice of combinators (I want to keep the number to a minimum without compromising usefulness), and the comparative readability of code using the combinators vs the simple parser, or any other thoughts.

There are two basic string recognisers ('accept', 'expect'), two nullary parsers ('succ', 'fail'), and two parser-constructors ('all', 'any') that take a user supplied functor and a variadic argument list of parsers or recognisers. The functor for the parser constructors is variadic, so it is passed one result argument for each parser, 'all' only calls the functor if all the parsers succeed and provides all arguments, 'any' calls the functor as soon as the first parser from the left succeeds with an index number indicating which argument has the valid result (the remaining arguments are initialised with the default constructor). Finally there are four combinators that can be used on both recognisers and parsers '&&', '||' which behave as they do in boolean logic (with short-circuit evaluation), 'many' and 'discard'.

Edit: The latest version of this library supports full backtracking parser combinators, and is different from other C++ parser combinator libraries because it separates static and dynamic polymorphism. By limiting dynamic polymorphism to only where actually needed, the compiler can inline the combinators (which are function-objects) resulting in performance better than the non-combinator hand-written recursive descent parsers.

The third annual ACM conference on High Integrity Language Technology (HILT 2014) call-for-papers is available, with a deadline of June 7th for regular papers, experience reports, and extended abstracts. For more info, see:
  HILT2014-CFP.pdf
The conference website is:
  HILT 2014 Website
We hope readers of LtU will consider submitting a paper, and will encourage your colleagues to do the same. Accepted papers will be published in the conference proceedings, and appear in the ACM Digital Library for wide visibility. We are pleased to be co-located with SPLASH/OOPSLA this year in Portland, OR, with technical sessions being on Monday, Tuesday, and part of Wednesday morning, Oct 20-22.

Since the CfP was produced, we can announce that Peter Feiler of SEI/CMU has agreed to be our invited speaker to introduce the sessions on Model-Based Engineering. In addition, we are putting together a panel on new safe parallel programming languages, tentatively entitled: "Finding Safety in Numbers -- New Languages for Safe Multicore Systems Programming," with three panelists already lined up. We are also coordinating our program further with SPLASH/OOPSLA, so HILT attendees can attend the Wednesday SPLASH keynote, and SPLASH attendees can attend the Tuesday HILT keynote (Tom Ball of Microsoft Research). We are also considering making the above mentioned panel a joint HILT/OOPSLA activity.

I'd like to explore the topic of argument-dependent lookup (a.k.a. Koenig lookup), and in particular I'd be interested to find out what people think is the "state of the art" when it comes to resolving unqualified identifiers.

It's my opinion that one of the primary motivations for ADL is to support operator overloading. The function of ADL is to resolve unqualified names, and operators are essentially functions with unusual unqualified names. For functions that have regular names and which are not operators, it's often not a huge burden to explicitly qualify the name, or to manually import it into the current scope. But for operators this destroys their brevity and convenience.

There are many supporters and detractors of ADL and I won't try and repeat all the arguments here. The common theme is that ADL leads to surprise. However, one limitation that interests me is that the methods which operate on the arguments must live in the same namespace with the definitions of those types. This is not such a hardship in languages like C++ where there's no enforced relationship between the namespace hierarchy and the organization of modules and source files, where any header file can append to any namespace. But for many modern languages that's not the case, the package hierarchy is much more rigid (often with good reason.)

I can imagine scenarios where the co-location of operations and types within the same module would be overly restrictive - you might want to extend the set of operations for some set of types (think of a vector math library) without re-defining those types.

So what are the alternatives? I can think of several. The simplest one is to require that unqualified name definitions be explicitly imported into the module's namespace. This has the benefit of being easy to understand, but I'm not sure how well this scales to large programs - you risk polluting your namespace with a lot of symbols.

Another solution is to allow a more limited kind of namespace extension. Some languages have syntax that allows adding methods and definitions to classes only (not namespaces or packages), usually with keywords like "extends" or "extension". This requires that the unqualified names be defined within the class, rather than outside it, which usually implies that the enclosing class "owns" the definitions or at least has special status. In a single-dispatch world, of course, these definitions are methods, which means you run into the "binary operator" problem - who owns the definitions of A+B, is it A or B?

A third approach is to completely give up on static scoping and use dynamic dispatch - i.e. if there's a definition of A+B anywhere in the program, it will be used, even if it's not visible at the call site. However, while dynamic multi-argument dispatch is a valuable technique, it is not without it's set of costs. One that I'm particularly interested in is the "plugin problem", which is that if you are Adobe Photoshop and you load some filter plugin that happens to contain a new definition of the plus operator, does it suddenly change the behavior of your whole program? Or on the opposite extreme, does the plugin contain its own sandboxed versions of all the operators and type definitions? Neither seems desirable to me - the plugin needs at minimum to implement some interface defined outside of the plugin, but its effects need to be limited and predictable.

The benefit of static scoping is that the conceptual search space for unqualified name lookups is smaller and more predictable, and thus easier to reason about - a programmer need only look at the set of imported symbols and their transitive dependencies, instead of having to search a universe of code.

Anyway, I'm interested to know if there's anything out there that's clearly better than the techniques that I've described.

The Avail programming language was released yesterday, but it didn't receive the attention it deserves.

Avail is a multi-paradigmatic general purpose programming language whose feature set emphasizes support for articulate programming
I believe the authors are being a bit modest!

The most interesting thing about Avail is it's programmable (turing-complete) type system that enables strongly typed multiple method dispatch. To me, Avail appears to be a happy marriage between smalltalk, maude, and (dare i say) coq?

Although, I'm not totally sold on the persuasive use of unicode - yet.

----------------------------------------------------------------------

CALL FOR TALK PROPOSALS

HOPE 2014

The 3rd ACM SIGPLAN Workshop on
Higher-Order Programming with Effects

August 31, 2014
Gothenburg, Sweden
(the day before ICFP 2014)

http://hope2014.mpi-sws.org

----------------------------------------------------------------------

HOPE 2014 aims at bringing together researchers interested in the
design, semantics, implementation, and verification of higher-order
effectful programs. It will be *informal*, consisting of invited talks,
contributed talks on work in progress, and open-ended discussion sessions.

---------------------
Goals of the Workshop
---------------------

A recurring theme in many papers at ICFP, and in the research of many
ICFP attendees, is the interaction of higher-order programming with
various kinds of effects: storage effects, I/O, control effects,
concurrency, etc. While effects are of critical importance in many
applications, they also make it hard to build, maintain, and reason
about one's code. Higher-order languages (both functional and
object-oriented) provide a variety of abstraction mechanisms to help
"tame" or "encapsulate" effects (e.g. monads, ADTs, ownership types,
typestate, first-class events, transactions, Hoare Type Theory,
session types, substructural and region-based type systems), and a
number of different semantic models and verification technologies have
been developed in order to codify and exploit the benefits of this
encapsulation (e.g. bisimulations, step-indexed Kripke logical
relations, higher-order separation logic, game semantics, various
modal logics). But there remain many open problems, and the field is
highly active.

The goal of the HOPE workshop is to bring researchers from a variety
of different backgrounds and perspectives together to exchange new and
exciting ideas concerning the design, semantics, implementation, and
verification of higher-order effectful programs.

We want HOPE to be as informal and interactive as possible. The
program will thus involve a combination of invited talks, contributed
talks about work in progress, and open-ended discussion
sessions. There will be no published proceedings, but participants
will be invited to submit working documents, talk slides, etc. to be
posted on this website.

-----------------------
Call for Talk Proposals
-----------------------

We solicit proposals for contributed talks. Proposals should be at
most 2 pages, in either plain text or PDF format, and should specify
how long a talk the speaker wishes to give. By default, contributed
talks will be 30 minutes long, but proposals for shorter or longer
talks will also be considered. Speakers may also submit supplementary
material (e.g. a full paper, talk slides) if they desire, which PC
members are free (but not expected) to read.

We are interested in talks on all topics related to the interaction of
higher-order programming and computational effects. Talks about work
in progress are particularly encouraged. If you have any questions
about the relevance of a particular topic, please contact the PC
chairs at the address hope2014 AT mpi-sws.org.

Deadline for talk proposals: June 13, 2014 (Friday)

Notification of acceptance: July 4, 2014 (Friday)

Workshop: August 31, 2014 (Sunday)

The submission website is now open:

https://www.easychair.org/conferences/?conf=hope2014

---------------------
Workshop Organization
---------------------

Program Co-Chairs:

Neel Krishnaswami (University of Birmingham)
Hongseok Yang (University of Oxford)

Program Committee:

Zena Ariola (University of Oregon)
Ohad Kammar (University of Cambridge)
Ioannis Kassios (ETH Zurich)
Naoki Kobayashi (University of Tokyo)
Paul Blain Levy (University of Birmingham)
Aleks Nanevski (IMDEA)
Scott Owens (University of Kent)
Sam Staton (Radboud University Nijmegen)
Steve Zdancewic (University of Pennsylvania)

I've been staring a lot at Python code the last couple of days. It suddenly dawned on me that Python is a vindication of Icon's generators. Python's expressivity, as attested by powerful libraries, rests to a large extent on metaprogramming and generators.

Added:Once upon a time we called this sort of thing linguistic abstraction. And people used to have strong arguments against it. I think this is one battle that was decisively won, as usual in favor of the Lisp mindset. Doesn't mean we should strive to make it as safe as possible, but disallowing it is no longer a reasonable approach.

Lang.NEXT is a cross-industry conference on what’s trending in programming languages (optional types, anyone?), occurs every couple of years, and is sponsored by Microsoft. We bring together a broad range of language experts as speakers as well as audience, and focus on a lively and intense exchange of ideas, straddling the usual barriers between different segments of the community, and between academia and industry.

I am very happy to let you know that the 2014 Lang.NEXT conference is now open for registration.

Here is the 2014 program (more details to appear!) which includes keynotes by C++ creator Bjarne Stroustrup and functional programming fundamentalist (reformed?) Erik Meijer. We have a great list of speakers for this iteration of Lang.NEXT. Please join us on May 29-30, 2014 in lovely downtown San Francisco at the Microsoft Office on 835 Market Street. Attendance is free of charge (and there will be free beer, breakfast/lunch and an attendee party - a first for Lang.NEXT!). Registration is required and seating is limited. If you register, then please do actually attend.

Hoping to see you there!

Charles and the Lang.NEXT team (Mads, Dustin, Jonathan and Luke)

- Synopsis -

What is Code Disease?

A code disease is a pervasive property of a code base that harms or destroys basic ease of software development and maintenance. Often propagating problems up to the business execution and strategic levels, code diseases are costly and risk-inducing. As its strong name indicates, a code disease is very serious and potentially threatening, with its first victims the morale and sanity of the developers who live with it daily, and its final victims the customers who are punished for relying on your business’s affected systems.

Please find the PDF here - Diseases in Code (rev. 5)

Note that there was another thread here discussing an earlier version of the paper, but due to the heat generated by problems in the earlier version, as well as a defect in the synopsis, I decided to post in a new thread. The old thread is here - http://lambda-the-ultimate.org/node/4926

Visual Programming Languages is a huge collection of VPLs.

Personally, I find those the most interesting that are closest to text as we know it, but extend it beyond a plain list of characters. Charles Simonyi's projectional editor is an example of this.

An engineer once articulated himself thusly -

"Commercial software complexity behaves like a gas in that it expands indefinitely, eventually filling up whatever available intellectual capacity is allocated to it." *

In your experience, does this ring true? In your opinion, is such expanding complexity inevitable? And if not, what can be done about it?

* that programmer was me on one of my more fatalistic days :/