archives

"applicative" vs."functional"

Is there any difference between the terms "applicative" and "functional" when applied to programming languages?

As far as I can see from googling a bit, the answer is no, they are used interchangeably, although perhaps applicative is used less frequently. Does applicative reduction order imply strictness? If so, wouldn't it be sensible to have "applicative" to mean "strict functional"? And perhaps "normative" for "nonstrict functional" (assuming normal reduction order implies non-strictness)? Oh well, even if that were a sensible distinction, I guess the ship has sailed.

How To Read a Paper

Some of the papers mentioned recently are quite advanced, and require careful reading.

It occured to me that not everyone here is adept at reading papers of this sort, and that some tips might be helpful.

So if you are one of those who constantly read papers, how about describing your reading habits?

Do you skim first? Do you follow the detailed proofs on first rading? Do you try to execute code?

Specifically, what would you suggest to someone who asks for help reading A Monadic Framework for Subcontinuations?

And no, "go back to school" isn't an acceptable answer...

Static Types vs. Partially Evaluated Latent Types

Here's a question I've promoted from another thread (sorry for the multiple postings).

What's the difference between static type inference (like in Haskell) and a latent (tagged) type system (think Scheme) with a real good partial evaluator? In the type-inference situation, we're using unification to solve a set of constraints. If there's no solution, we give up and say the program was ill-typed. On the other hand, it seems like tag checking code in a latently typed lanugage would be a good candidate to get partially evaluated away at compile time. For example it seems like...

;; typed values are really pairs of values and types
;; e.g. (123 . 'number)
;;      ("abc" . 'string)
(define (isnumber n) (eq? (cdr n) 'number))
(define (add arg1 arg2)
    (if (and (isnumber arg1) (isnumber arg2))
        (machine-add (car arg1) (car arg2))
        (error "not a number")))

(add '(4 . number) '(5 . number))
...should be easily changed into...
(machind-add 4 5)
... And after we're done partially evaluating our source, if we still have left over type-check predicates like 'isnumber' in the code then we again declare that the program is ill-typed. Are the two methods comparable in any way? Is one method more powerful than the other, or are they somehow duals of each other? Are there any papers available discussing this?

Anton van Straaten recommends looking at a previous typing thread, and the paper Types as Abstract Interpretations, as well as a posting of his to the LL mailing list. Any futher thoughts?

Scottish Programming Language Seminar


Scottish Programming Language Seminar
Many thanks to Greg Michaelson and Phil Trinder for organizing this meeting!

This is the third meeting of SPLS, and its great to see that SPLS has already grown into what it was intended to be: a robust forum for language researchers in Scotland (and beyond). We had in attendance thirty or forty programming language researchers, from U of Edinburgh, Heriot Watt, U of Glasgow, Strathclyde, and St Andrews, as well as speakers from Nottingham and Hertfordshire, both of whom had traveled to Edinburgh just for the occasion.

Greg Michaelson noted that, as it happened, none of the speakers was Scottish. (Richard is English, Anne is French, Conor is Irish, De Lesley is American, and Sven-Bodo is German.) I suggested that we parse the name differently, and say that it is a seminar for work on Scottish Programming Languages. With POP2, SASL, Hope, ML, Haskell, and (soon, I hope) Links, we have quite enough to keep us busy!

We were hosted by the International Centre for Mathematical Sciences, which is located in the house in which James Clerk Maxwell was born. I work in The James Clerk Maxwell Building in the north campus of the University of Edinburgh, affectionately known as JCMB to its inmates (and rather a cheek in naming, as Maxwell's main connection to Edinburgh is that they refused to hire him). It was a pleasure to visit the other JCMB, which is more appealing in appearance. Cheers to Greg and Phil for finding a wonderful venue.

Richard Connor, Strathclyde University
Typed vs Untyped: performing a real experiment?

Put forward the excellent idea that we should actually try to experimentally measure what impact type systems have on programmer productivity and program reliability and maintanability. Unfortunately, I suspect this will fall foul of a symptom I noticed years ago in papers that report experiments on programming languages. If the person who wrote the paper believed that imperative languages were better than functional languages, thenthat is what his experiments proved, and if the person who wrote the paper believed the opposite then his experiments proved the opposite. Richard's experiment consists of comparing untyped and typed variants of Javascript. But his untyped variant supports the undefined value and his typed variant does not, so its not clear whether he'll be measuring the effects of typing or of flexible null values. I can suggest a number of different experiments, which I suspect would yield rather different results: compare Java 1.4 and Java 1.5 (with and without generics -- this has the great advantage that it is working with two real languages), compare Haskell with and without types, compare Scheme with and without types (using the type inferencer in Dr Scheme for the typed version, so again you have two real languages).

Anne Benoit, Edinburgh University
Enhancing the performance of Grid Applications with Skeletons and Process Algebras

Skeletons with performance models applied to automatically choose the best implementation. Seems like nice work. Unfortunately, I'm not very familiar with skeletons, so I would have benefited from some simple, complete examples to convey the basic ideas.

Conor McBride, Nottingham University
Idioms

A few years ago, John Hughes noticed that sometimes a monad is too strong, and he introduced a weaker structure called 'arrows' with many interesting applications. (Every monad is an arrow, but not conversely.) Conor has now noticed that there is another useful structure halfway between arrows and monads, which he calls idioms. (Every monad is an idiom and every idiom is an arrow, but not conversely.)


class Idiom i where
k : x -> i x
s : i (x -> y) -> i x -> i y

(To see why these are called k and s, take i x = a -> x.) It was a Pearl of a talk, and I encourage him to write it up as a pearl for JFP.

DeLesley Hutchins, Edinburgh University
Feature Oriented Programming

An object calculus that is good for "deep mixin" combination. Unlike most typed languages it is not stratified -- objects and their types are considered to be the same sorts of things, with the

Sven-Bodo Sholz, University of Hertfordshire
Using Sub-types and Intersection Types to strike the Balance Between Static and Dynamic Typing

An interesting companion to Richard's talk. Sven-Bodo has a functional language for scientific programming with an optimizing compiler that achieves performance comparable to Fortran. (And a compiler consisting of 500K lines of C.) This talk focussed on the type system, which in effect ranges from highly typed to untyped. He has a hierarchy of types for arrays, ranging from no information to specific information.


[*] - any array
[] - any scalar [.] - any vector [.,.] - any matrix
[3] - vector of length 3, [4] - vector of length 4, [2,3] - matrix with 2 rows and 3 columns, ...

The system makes heavy use of intersection types. It tries to give more precise types (lower down in the hierarchy sketched above), but moves up the hierarchy when it is too hard to give a precise type. (It wasn't clear to me under which circumstances it would move up the hierarchy.) This complements Milner's principle: Well-typed programs can't go wrong. In this system, if a program is not well-typed it will typically move up the hierarchy. Hence. one can't guarantee that well-typed programs won't go wrong (unless one inspects them and determines that all subterms are given precise types rather than imprecise types), but one can guarantee that ill-typed programs must go wrong!

A fine day. My thanks to all those who made it happen! The next meetings are scheduled for Strathclyde in September and St Andrews in January.