Wadler's Blog

Philip Wadler, University of Edinburgh
http://homepages.inf.ed.ac.uk/wadler/

I'm interested in Links because ...
I've helped design Haskell, generic types in Java, and the static type system of XQuery. I'd like to see ideas from functional programming make it into the mainstream. One way to do this is to build a functional programming language that excels at some important application domain.

Links can entice users by ...
Providing a single unified approach to all three-tiers of the client-server-database model. Javascript for the front-end and SQL or XQuery for the backend can be generated from a single source.
 

Norman Ramsey, Harvard University, http://www.eecs.harvard.edu/~nr/.

I'm interested in Links because I've been interested in functional programming for 15 years, and this seems like a good time to try to consolidate the best ideas in preparation for another leap forward. I'm especially keen that Links try to steal the best ideas from not only Haskell and ML but also Scheme.

Links can entice users by providing a foreign-function interface so that people writing Perl, Python, and PHP can start to insert Links code into their 'P' programs.

A qualitative improvement I would like to see is support for pattern matching over abstract data types. I know there have been a lot of papers, but I don't understand the barriers to making it real.
 

Joachim Durchholz, free software developer, http://durchholz.org/jo

I'm interested in Links because ...
... I've been on a decade-long "quest for the ideal programming language". Real languages and my dreams have been converging, and the proposed goals for links are right at or very near the convergence spot.

Links can entice users by ...
1. ... providing the advantages of referential transparency and a clean semantics within the framework of an otherwise pretty standard programming language. (Haskell with its lazy semantics isn't "pretty standard", *ML aren't referentially transparent.)
2. ... doing a few things beyond what standard programming languages do, and doing them in a well-defined (hence reliable) way. Some things I can think of are seamless distributed programming, and reasoning over programs (in a way that programmers understand). (Others have proposed databases and XML processing. I think good support for both is possible and should be done, but neither should be tied directly into the language semantics: they are moving targets, albeit slow-moving ones.)
3. ... concentrating on a neglected but innovation-friendly niche first, going to the mainstream later. (Game programming is just such a niche.)
 

While considering m,yself a functional programmer we have gained experience with Apple's WebObjects. This long standing system is currently written in jave, using reflection, casting etc. the main reasonthe system is a joy to work with it that the kind of errors that I usually make and that are detected by my type checker are here prevented because you are using a set of well-designed tools that prevent you from going completely astray.

Contemplatig about this system two questions come into mind:
- how to prevent me from making mistakes in the remaining Java code I have to write? Unfortunately this code is full of downcasts, extremely elaborate for a haskell programmer, and gives me the feeling to be back in the seventies.
- would it have been possible to write sucha system in Haskell. This involves some heavy systems programming, dealing with caching objects, editing contexts dealing with tracking changes to objects, generating correct SQl for the JDBC interface etc.

We have done some work on answering the latter question, but one of my conclusions is here that in order to do things in a type safe way you end up in encoding somehow a partial correctness proof of what you are doing. No longer the resulting code is really nicer or shorter than the Java equivalent, as our religion predicts should be the case.

Unfortunately Generic programming techniques (like Generic Haskell) do not really help a lot, since in general we can only write functions there which re indexed by a single type, and not by e.g. a data base scheme. So either we have to write a seprate generator (an ad hoc genericg programming language) or we have to d a lot of type hacking using Equal types, actually carrying out the proofs that we are not doing anything wrong. Unfortunately it is not very helpful either. Thois wishing to see what kind of work is involved may take a look at our last year Haskell workshop paper in which we describe amongst others left-recusrion removal for combinator parsers. The actual code is quite somewhat more complicated than what you normally find in parser generators, since tha latter happily work in an untyped world.

So the question arises: can types be of some help instead of turning into a burden when building such kind of systems?

To answe Simon;'s question:

What we need is a language that is not designed along the lines that say "If the compiler is not smart enough to find something out and generate the code for you automatically thou shall not write that code either" but instaed follows the policy "It is my pleasure to help you to fill in the laborious, obvious parts of your program, but please help me if it gets complicated. Together we can do a much better job".

So far for this moment.
 

Don Sannella, Edinburgh University,
http://homepages.inf.ed.ac.uk/dts

My background in functional programming is HOPE, SML (where my main interest is the module system), the Extended ML specification framework, and various pieces of work in specification and formal development methods that follow a functional programming world view, including most recently work on resource-aware programming and proof-carrying code.

I'm interested in Links for two main reasons. First, I find Phil's vision of Links as a better way of building client-server-database systems compelling and worth pursuing, and that whole area is pretty exciting. Second, I see it as a possible arena for getting new work on lightweight formal methods and type systems into a real language. This is one area of qualitative improvement that I would like to see - richer type systems, probably several quite different ones for the same language that capture different facets of behaviour, some of which might incorporate checkable logical assertions along lines like those in ESC/Java. Maybe these things won't make their way into the "official" language but even so it is easier to think about them at the design stage than to retrofit them afterwards.
 

I have two answers to SPJ's challenge:

1) Assertions. This has so many advantages, some of them nonobvious, that I have set up a summary.

2) Network transparency. Apart from processing delays and possible failure modes, interprocess communication should be independent of whether it's within the same process, in another process, or on a remote machine.
 

Why are you interested in Links?
ML is my language of choice, but can feel to low level.

Qualitiatively better language feature: More expressive pattern matching.

Perhaps rewriting technology is sufficiently developed that pattern matching on a per datatypes basis could account for associative, commutative, idempotent pattern matching. Maybe it would be useful to remove the linear variable restriction on the lhs in a pattern. I'm no expert, but Maude seems to do what I envision. Of course, you'd probably want some special syntax to indicate the expense of such matching styles, and I haven't any thoughts on how this plays w/ all of ML style features.

Such a feature would allow for some very concise XML and database programs. There are probably gems from the SETL papers that have yet to reach a wide audience.
 

As time goes on, the advantages of restricting side effects become more apparent (deeper memory hierarchies, more concurrency, larger scale), and the disadvantages become more tolerable (performance increases, more expressive languages, education). But richly-typed functional languages are still far from mainstream.

Finding a niche is one way forward; maybe Links will succeed in that way. More generally, I'd like to find ways of building on our strengths; for example, assertions and/or dependent types are wildly under-exploited in our community.
 

John Field, IBM Research
http://www.research.ibm.com/people/j/jfield

Why I'm interested in Links:

At IBM Research, we have recently initiated a new project (the Symbiotic Project) to design and implement a programming model for distributed business applications, including both interactive web applications and non-interactive web services. Our goal is to enable programmers to specify distributed business applications in an intuitive, declarative, and modular way. We take the view that such an application can be treated as a web of constraints among elements of a distributed state. The challenge in this setting is to specify and maintain these constraints in the presence of concurrent interaction and failure scenarios. Although the design of the programming model is evolving, our model currently contains elements of classical process and reactive calculi, as well as novel features specific to the scenarios we wish to support.

The proposed Links goals of providing better support for distribution, databases, and XML are all relevant to the Symbiotic project agenda. Since many of the computations required in business applications are functional in nature (consider, e.g., spreadsheets), it is also natural to adapt ideas from functional languages in this setting.

What facilities could Links provide that would entice users?

In my opinion, all of the following facilities would constitute sigficant advances for developers of distributed business applications:

* The ability to use a uniform mechanism for querying and processing both persisten and non-persistent data. XQuery is an encouraging start in this direction, but neither updates nor other features commonly found in industrial-strength databases are currently supported in XQuery---e.g., integrity constraints and transactions.

* Robust and modular support for managing failures in a dstributed setting; e.g., something like distributed transactions.

* First-class for constraint-like "logical" types, which could, e.g., allow entity-relationship style models to be treated with the same degree of rigor and modularity as found in the more "structural" types of languages such as ML and Haskell.
 

Harry Halpin
University of Edinburgh

http://www.ibiblio.org/hhalpin

*Why are you interested in Links?

A programming language with type inference that allowed me easy distributed programming and access to databases (optimized to boot!) would solve
most of my problems as a webmaster, and PHP allows none of this. A programming language built from the ground up for the Web can move the Web from an universal information space to a universal computing machine.

* Killer app: what facility could Links provide that would entice users?

In AI, KR systems were custom built using logical constraints on programming systems (think KL-ONE on top of LISP). Look at Amazon.com: the future of the Web is in the use of personalised information - personalised knowledge representation. SemWeb is a start here.

Web Service integration is too painful for words. A logical functional language ala Curry could combine the KR via logic and Web Service integration. Bundle in NLP Web Services, and you have instant personalised Web-scale data delivery.

I would like to see the Web where the user wants X and Links gets X regardless of URI Y, not just user types in URI Y and Links helps generate Y from a database. SemWeb and Web Services are two premature efforts in that direction, and a decent programming language could sort things out....think Links: LISP for the Web.
 

My motivation is that having worked on a commercial implementation of ML and also seeing any good ideas coming out of the research community, I want to see a practical language that many people will use. I have wanted to do exactly what Phil is doing, but had neither the time nor the influence to do so. (FWIW, I was also going to name the language after an area of Edinburgh, in this case "Braid", the idea being that the language would bring together several strands of research).

From my experience of working in the Grid world, I think that Web Services would be a good application area for Links. The notion of "service-oriented architectures" (SOA) attempts to exclude stateful interchanges, isolating state in the internal data of each service. This should makes SOA amenable to functional programming techniques. The Web Service community is also open to typeful programming. Web Service implementations might share back ends with the user-oriented web applications that Phil is already considering.


I would like to suggest as a general principle that the language be designed with programming errors in mind. By this I mean that it is not enough for correct programs to be elegant; when people make trivial mistakes, the language should help to find them. For example, in both ML and Haskell a simple syntactic mistake can often result in a complicated error message from the type checker rather than simple error message from the parser. Similarly, if a Haskell, SQL or ML program is running slowly, it can be hard for an average programmer to work out where the problem is. The language needs a reasonable transparent evaluation model.

In general, you can help a language gain popularity by making it easy to:
- write compilers that produce efficient code
- write programs will be compiled efficiently
- know which programs are likely to be compiled efficiently.
 

Your site is amazing!! keep it going. I have found another interesting site on mortgage, check out
Washington Mutual Review | Washington Mutual Home loan Review | Washington Mutual banking Review | Washington Mutual bank Review | Washington Mutual mortgage Review | Scotia Bank Review | Bank of Nova Scotia Review | Wells Fargo Review | Wells Fargo Online Review | Wells Fargo Home Mortgage Review | Wells Fargo Bank Review | Wells Fargo Mortgage Review | SunTrust Bank Review | Wachovia Bank Review | Wachovia Online Review | Wachovia Online Banking Review | Chase Bank Review | Chase Credit Cards Review | Chase Manhattan Bank Review | Chase Online Review | National City Mortgage Review | National City Review | National City Bank Review | First National Bank Review | First National Bank Omaha Review | first time home buyers Review |