Here are notes on some of my favorite talks at POPL, Plan-X, and FOOL.
Plan-X, 11 Jan 2005.
Michael Carey, BEA, on BEA Liquid Data, an approach to data integration. He notes that BEA developers tend to ignore the strong typing features of XQuery, for two reasons, one trivial and one material. Trivial: developers find it inelegant to have to validate the data after it is created in order to attach type information to it. This is just a matter of writing "validate { ... }" around the XML that creates the data, but they strong resist this. Material: validation can change the data in various corner cases, and so interferes heavily with optimization. I took two points away from this. First, XQuery seems to have failed in the goal of integrating types with queries -- trying to fit well with Schema has inevitably thrown up a lot of road blocks. Second, sometimes seemingly trivial points can be just as significant as material ones; another example of this is how the C-like syntax of C++ and Java helped these languages to spread rapidly.
Alan Schmitt on Xtatic. The pattern matching style of Xduce/Xtatic does not do well with data evolution, unlike XPath, as adding more elements to the data causes matching to fail. I would have thought of this as a bad thing, but Schmitt claims it is good, as the failure tells you where you need to change your code.
The demo session worked well. I particularly liked Fisher and Fernandez's PADX, which I had not seen before.
POPL, 12-14 Jan 2005.
Rob Pike on a programming language for searching Google's data. His neatest example was an animated map, with one pinprick of light for each query sent to Google in one day, correctly located in space and time -- one could watch the pattern of queries flow across the world. The data for the map was generated by a program just a few tens of lines long. The key to the query language is, as Rob noted, a simple idea from the functional programming community: use map and fold as the basis of parallel programming, where the fold is over over associative and commutative operators. Pike's language is based on Google's map-reduce system. (Added 27 Aug 2007: Pike's language is called Sawzall. Later a paper on it appeared here.)
Peter Selinger on a quantum programming language. A lovely presentation of tricky ideas, the first time I had made it through to the end. I finally understood that quantum programming involves two levels of probability, within a state there is the probability attached to each qbit, and then there is the probability of being in a particular entangled state. Selinger explained a clever matrix representation due to von Neuman that captures both levels. He gave a nice explanation of quantum teleportation/quantum compression as two halves of a "use once" isomorphism -- a pair of inverse functions that contain a free linear variable so each can be used only once, where the order of composition determines whether one has teleportation or compression. When I asked him why one should bother with programming languages for computers that might never be built, he pointed to the ability of the language to give precise descriptions of tricky thought experiments, as in the teleportation/compression example.
Pat Hanrahan argued that game processors pose a worthy challenge for language designers. He observes that game processors have a steeper "Moore's law" curve than traditional processors, and hence will outperform them by an exponentially increasing factor.
Dinner on the Queen Mary was fun. Mads Tofte hasn't been active in research lately, and it was great that he showed up to receive the award for Most Influential POPL paper of 1994, for his work on regions.
FOOL, 15 Jan 2005.
There was some question as to whether FOOL would continue after this year, but the meeting was lively and there was a strong concensus in favor of continuing. Benjamin Pierce commented "Most years there is at least one talk at FOOL that, after you hear it, you wish it wasn't accepted. But that wasn't the case this year." Special thanks to Benjamin for serving as chair of the FOOL steering committee for many years, and to Kathleen Fisher for picking up this role going forward.
My two favorite comments, both from the final panel on "Extreme Typing".
Robby Findler: Programmers are motivated to write strong contracts, because the stronger the contract the more likely that blame for a failing program will be assigned to the other guy. This explains why the notion of blame attached to higher-order contracts is important.
Jan Vitek: A recipe for stealth adoption: don't change the syntax of the language, but reinterpret the semantics of the existing constructs. (No one will notice the change anyway!) He was following the mandate to be provocative, but there is a knotty kernel of truth here.
10.3.05
Yet another Links comment.
A Links comment from Chui Tey. Pat Hanrahan of Stanford gave an invited talk at POPL 2005 on a similar theme, arguing that game processors ose a worthy challenge for language designers. He observes that game processors have a steeper "Moore's law" curve than traditional processors, and hence will outperform them by an exponentially increasing factor.
----
Another area worthwhile looking at is in designing languages for the current generation of game machines, where parallelization is important.
It is worthwhile because:
1) Computer game development do not suffer the constraints of corporate programming, and are more adventurous with tools. A lot of games run with embedded scripting languages. Why not have highly parallelizable functional languages for computer generated graphics?
2) Existing languages are inadequate, and it has taken several years for developers to learn how to squeeze performance from the Sony PS2 architecture.
3) Computer gaming is a big industry, so there will be sufficient commercial interests in the project
4) Specfic target constituency. It's not as important to have broad library support compared to a language targeted for general purpose use. Our baby language needs a niche to survive and prosper. Most of the goals mentioned do seem to fit this market.
5) Avoiding hard things. Programming for the business processes in the real world is hard. It's full of non-strictly typed interactions and full of side-effects. LISP picked up a bad name because AI was too nebulous an aim.
6) Cell processors - we need new languages for them. Once proven, there is a general future for this language.
7) The coolness factor associated with computer games can accelerate the adoption of a language
# posted by Chui Tey : 1:43 AM
Another area worthwhile looking at is in designing languages for the current generation of game machines, where parallelization is important.
It is worthwhile because:
1) Computer game development do not suffer the constraints of corporate programming, and are more adventurous with tools. A lot of games run with embedded scripting languages. Why not have highly parallelizable functional languages for computer generated graphics?
2) Existing languages are inadequate, and it has taken several years for developers to learn how to squeeze performance from the Sony PS2 architecture.
3) Computer gaming is a big industry, so there will be sufficient commercial interests in the project
4) Specfic target constituency. It's not as important to have broad library support compared to a language targeted for general purpose use. Our baby language needs a niche to survive and prosper. Most of the goals mentioned do seem to fit this market.
5) Avoiding hard things. Programming for the business processes in the real world is hard. It's full of non-strictly typed interactions and full of side-effects. LISP picked up a bad name because AI was too nebulous an aim.
6) Cell processors - we need new languages for them. Once proven, there is a general future for this language.
7) The coolness factor associated with computer games can accelerate the adoption of a language
----
Another area worthwhile looking at is in designing languages for the current generation of game machines, where parallelization is important.
It is worthwhile because:
1) Computer game development do not suffer the constraints of corporate programming, and are more adventurous with tools. A lot of games run with embedded scripting languages. Why not have highly parallelizable functional languages for computer generated graphics?
2) Existing languages are inadequate, and it has taken several years for developers to learn how to squeeze performance from the Sony PS2 architecture.
3) Computer gaming is a big industry, so there will be sufficient commercial interests in the project
4) Specfic target constituency. It's not as important to have broad library support compared to a language targeted for general purpose use. Our baby language needs a niche to survive and prosper. Most of the goals mentioned do seem to fit this market.
5) Avoiding hard things. Programming for the business processes in the real world is hard. It's full of non-strictly typed interactions and full of side-effects. LISP picked up a bad name because AI was too nebulous an aim.
6) Cell processors - we need new languages for them. Once proven, there is a general future for this language.
7) The coolness factor associated with computer games can accelerate the adoption of a language
# posted by Chui Tey : 1:43 AM
Another area worthwhile looking at is in designing languages for the current generation of game machines, where parallelization is important.
It is worthwhile because:
1) Computer game development do not suffer the constraints of corporate programming, and are more adventurous with tools. A lot of games run with embedded scripting languages. Why not have highly parallelizable functional languages for computer generated graphics?
2) Existing languages are inadequate, and it has taken several years for developers to learn how to squeeze performance from the Sony PS2 architecture.
3) Computer gaming is a big industry, so there will be sufficient commercial interests in the project
4) Specfic target constituency. It's not as important to have broad library support compared to a language targeted for general purpose use. Our baby language needs a niche to survive and prosper. Most of the goals mentioned do seem to fit this market.
5) Avoiding hard things. Programming for the business processes in the real world is hard. It's full of non-strictly typed interactions and full of side-effects. LISP picked up a bad name because AI was too nebulous an aim.
6) Cell processors - we need new languages for them. Once proven, there is a general future for this language.
7) The coolness factor associated with computer games can accelerate the adoption of a language
6.3.05
Xcaml
Xcaml is an extension of Caml for web applications, overlapping with Links in goals and methods.
Links update
Two updates on Links.
(1) The meeting will be 9.30--17.30 Wednesday 6 April 2005, in the Conference Suite, School of Informatics, 2 Buccleuch Place. After the meeting, we will adjourn for a drink in The Links Bar, Bruntsfield. As before, let me know if you want to attend.
(2) The Links meeting is colocated with ETAPS. There is no requirement to register for ETAPS to attend Links, but you may wish to do so. Please note that ETAPS registration fees increase after Monday 7 March. (Apologies for the late notice, but the venue was confirmed only recently.)
http://www.etaps05.inf.ed.ac.uk/
Cheers, -- P
(1) The meeting will be 9.30--17.30 Wednesday 6 April 2005, in the Conference Suite, School of Informatics, 2 Buccleuch Place. After the meeting, we will adjourn for a drink in The Links Bar, Bruntsfield. As before, let me know if you want to attend.
(2) The Links meeting is colocated with ETAPS. There is no requirement to register for ETAPS to attend Links, but you may wish to do so. Please note that ETAPS registration fees increase after Monday 7 March. (Apologies for the late notice, but the venue was confirmed only recently.)
http://www.etaps05.inf.ed.ac.uk/
Cheers, -- P
3.3.05
2.3.05
Three links from Will Partain
Tim O'Reilly on The Open Source Paradigm Shift
http://tim.oreilly.com/opensource/paradigmshift_0504.html
The magic behind google maps
http://jgwebber.blogspot.com/2005/02/mapping-google.html
For ideas about applications students will want to work on,
see Jamie Zawinski's recent rant on "groupware":
http://jwz.livejournal.com/444651.html
http://tim.oreilly.com/opensource/paradigmshift_0504.html
The magic behind google maps
http://jgwebber.blogspot.com/2005/02/mapping-google.html
For ideas about applications students will want to work on,
see Jamie Zawinski's recent rant on "groupware":
http://jwz.livejournal.com/444651.html
23.2.05
17.2.05
More Links comments
More comments, from Tony Hoare and Joachim Durchholz.
--------
From Tony Hoare
Dear Phil,
Thanks for the note. I'm afraid I can't get to Edinburgh on April 6th.
But I hope your discussions go well.
I would recommend that you concentrate initially on a clear definition
of the purely scientific, possibly long-term, challenges of expressing
web applications in a transparent functional style. As a result, even
if you never get as popular in the short term as python (let alone
Visual Basic, with its four million programmers), your project will
represent a significant step forward in our understanding of the
principles of programming and programming language design.
Your long list of existing languages is essential as a summary of
sources of experimental data for evaluating and evolving any emerging
language and implementation by application to realistic examples; I
think this is your intention. Otherwise your project may just
degenerate into an attempt to throw everything into one unholy stew.
Leave that kind of cookery to the standardisation bodies who made the
mess: the scientific method has no particular contribution to make to
clearing it up.
My last two paragraphs have described two extremes. Most people engaged
in your project will take a position somewhere between them. Perhaps
no-one would or should embrace solely the scientific ideals. A most
fruitful outcome of your meeting would be to define a framework within
which scientists can collaborate in working towards a long-term goal,
while competing in achievement of shorter term milestones.
Now let me add my own bit of gristle to the stew. A modern language for
Web Services should surely incorporate the concept of a long-running
transaction, as in languages such as BPEL or Microsoft's XLANG.
Please circulate this note if you think it will contribute.
Yours,
Tony.
--------
From Joachim Durchholz
Dear all,
as the response to the above message in the comp.lang.functional newsgroup has shown, there's an immense interest in this project.
The announcement also sparked a rather extensive discussion on the features that such a language should (or should not) have. However, the discussion suffered from the typical newsgroup syndrome: no consensus, threads dropping off into silence, etc.
Since I know that WikiWiki webs have a better track record in this regard, I have set up one at
http://durchholz.org/jo/links/wiki/pmwiki.php
(For those who don't know what a WikiWiki web is: it's a web site where anybody can edit the pages. Since the pages are versioned, it's easy to revert accidentally or maliciously defaced pages to the last known good state.)
I have already added some of my personal pet peeves, but I sincerely hope that others will contribute as well, with additional proposals or critiques.
Enjoy!
Jo
--------
--------
From Tony Hoare
Dear Phil,
Thanks for the note. I'm afraid I can't get to Edinburgh on April 6th.
But I hope your discussions go well.
I would recommend that you concentrate initially on a clear definition
of the purely scientific, possibly long-term, challenges of expressing
web applications in a transparent functional style. As a result, even
if you never get as popular in the short term as python (let alone
Visual Basic, with its four million programmers), your project will
represent a significant step forward in our understanding of the
principles of programming and programming language design.
Your long list of existing languages is essential as a summary of
sources of experimental data for evaluating and evolving any emerging
language and implementation by application to realistic examples; I
think this is your intention. Otherwise your project may just
degenerate into an attempt to throw everything into one unholy stew.
Leave that kind of cookery to the standardisation bodies who made the
mess: the scientific method has no particular contribution to make to
clearing it up.
My last two paragraphs have described two extremes. Most people engaged
in your project will take a position somewhere between them. Perhaps
no-one would or should embrace solely the scientific ideals. A most
fruitful outcome of your meeting would be to define a framework within
which scientists can collaborate in working towards a long-term goal,
while competing in achievement of shorter term milestones.
Now let me add my own bit of gristle to the stew. A modern language for
Web Services should surely incorporate the concept of a long-running
transaction, as in languages such as BPEL or Microsoft's XLANG.
Please circulate this note if you think it will contribute.
Yours,
Tony.
--------
From Joachim Durchholz
Dear all,
as the response to the above message in the comp.lang.functional newsgroup has shown, there's an immense interest in this project.
The announcement also sparked a rather extensive discussion on the features that such a language should (or should not) have. However, the discussion suffered from the typical newsgroup syndrome: no consensus, threads dropping off into silence, etc.
Since I know that WikiWiki webs have a better track record in this regard, I have set up one at
http://durchholz.org/jo/links/wiki/pmwiki.php
(For those who don't know what a WikiWiki web is: it's a web site where anybody can edit the pages. Since the pages are versioned, it's easy to revert accidentally or maliciously defaced pages to the last known good state.)
I have already added some of my personal pet peeves, but I sincerely hope that others will contribute as well, with additional proposals or critiques.
Enjoy!
Jo
--------
14.2.05
Links comments
I received useful comments on Links from Garry Hodgson, Amanda Clare, and Rodrigo Barnes. (Posted with permission.)
--------
From Garry Hodgson
i hope you are successful. i worry, though, that much of the focus in your outline is on the language technology, and not on the ecosystem surrounding the language which, i believe, is what will make it "as widely used as python" or not. perl, python, java, etc. are not popular primarily based on their language design.
everyone on this list uses highly advanced languages on a daily basis. but if i want to write a mail or http client or server, or parse or generate xml, or run a unix process and gets its exist code and output, or whatever, how do i do that? yes, there are libraries out there, but i have to go find them, and build them, and integrate them, etc. and this raises the threshold of pain sufficiently high that it's usually easier to just use what i've got.
mind you, i'm a big fan of FP. i use erlang and ocaml whenever i can. but it costs me a lot of effort to do so, both in finding what i need and in justifying the decision. if you want to read the vast majority of users who don't already want to use FP, you'll need to make it easy to do so.
a while back, python was using the slogan "batteries included" to get this idea across. while y'all are designing the ultimate "take over the world" functional language, please don't forget the batteries.
-- Garry Hodgson, Technical Consultant, AT&T Labs
--------
From Amanda Clare
I'll be busy attending NESC's Globus Week in Edinburgh on that date, so won't be able to come (I'm not a language designer anyway, so wouldn't have been much use at this stage). But I love the idea and would be happy to be a real-world user to test any system you make. Python usually wins out over Haskell nowadays for me for most apps I have to say for practical reasons.
Currently my project involves Grid technology - Java-based Globus, to grid-enable laboratory automation systems. The object oriented approach the Globus team have taken to the whole Grid and web services concept (and the WSRF team as well) frequently have me amazed at how complicated they have to make it all.
Just to give an example from Borja Sotomayor's excellent tutorial
(http://gdp.globus.org/gt4-tutorial/):
> Whoa! Three Java classes to implement something as simple
> as addition and subtraction? Yes, it's true. But that's simply
> the price you have to pay for statefulness. Before looking at
> the Java code, let's make sure we understand how these three
> implementation files are related.
(and this is step 2 of a 5 step process to make a web service)
There has to be a better way. Even if in future they automate some of the steps (eg automatically generate WSDL so that I don't have to remember to name my Java get/set methods exactly the same as the resource properties in the WSDL file, and so on), I just feel less and less like I'm in control or have a good feel for what's happening, or understand the interactions and errors.
On the plus side I was interested to see that Polar Humenn had used Haskell as a language for describing XACML policies, so maybe Haskell ideas will sidle into Grid/Globus in the future.
Amanda Clare
--------
From Rodrigo Barnes
I've spent quite a bit of time (8+ years) developing and managing development of networked applications which can be a painful thing! Clearly anything that could make it a more pleasant experience would be worthwhile. On top of that the possibility of developing a new language (in the broadest sense) for this purpose would be interesting in its own right.
As an aside - on the J2EE front have you tracked the workings of http://www.springframework.org ? We've used it in our latest project and it's certainly made some aspects nicer as well as clearer and easier to maintain. Spring + Hibernate (http://www.hibernate.org) is proving a popular complement and/or alternative to the J2EE stack (EJBs and the like).
In general, my concern with such a project, having also spent quite a bit of time developing tools in academia, is that it aims to prove points rather than developing industrially viable tools (witness e.g. some of the problems in getting e-science tools to market). Having said that you only get the chance to develop this sort of innovation in a research context.
Another idea that might appeal to the group is to look at development tools, such as IntelliJ IDEA (http://www.jetbrains.com/) which along with Eclipse (http://www.eclipse.org) made refactoring tools easy to use for the working Java programmer. When I first saw IDEA it struck me they just went through Martin Fowler's 'Refactoring' book and used it as a requirements doc. So if you took his Patterns of Enterprise Application Architecture book (http://www.martinfowler.com/books.html#eaa) what tool would you get?
-- Rodrigo Barnes
--------
--------
From Garry Hodgson
i hope you are successful. i worry, though, that much of the focus in your outline is on the language technology, and not on the ecosystem surrounding the language which, i believe, is what will make it "as widely used as python" or not. perl, python, java, etc. are not popular primarily based on their language design.
everyone on this list uses highly advanced languages on a daily basis. but if i want to write a mail or http client or server, or parse or generate xml, or run a unix process and gets its exist code and output, or whatever, how do i do that? yes, there are libraries out there, but i have to go find them, and build them, and integrate them, etc. and this raises the threshold of pain sufficiently high that it's usually easier to just use what i've got.
mind you, i'm a big fan of FP. i use erlang and ocaml whenever i can. but it costs me a lot of effort to do so, both in finding what i need and in justifying the decision. if you want to read the vast majority of users who don't already want to use FP, you'll need to make it easy to do so.
a while back, python was using the slogan "batteries included" to get this idea across. while y'all are designing the ultimate "take over the world" functional language, please don't forget the batteries.
-- Garry Hodgson, Technical Consultant, AT&T Labs
--------
From Amanda Clare
I'll be busy attending NESC's Globus Week in Edinburgh on that date, so won't be able to come (I'm not a language designer anyway, so wouldn't have been much use at this stage). But I love the idea and would be happy to be a real-world user to test any system you make. Python usually wins out over Haskell nowadays for me for most apps I have to say for practical reasons.
Currently my project involves Grid technology - Java-based Globus, to grid-enable laboratory automation systems. The object oriented approach the Globus team have taken to the whole Grid and web services concept (and the WSRF team as well) frequently have me amazed at how complicated they have to make it all.
Just to give an example from Borja Sotomayor's excellent tutorial
(http://gdp.globus.org/gt4-tutorial/):
> Whoa! Three Java classes to implement something as simple
> as addition and subtraction? Yes, it's true. But that's simply
> the price you have to pay for statefulness. Before looking at
> the Java code, let's make sure we understand how these three
> implementation files are related.
(and this is step 2 of a 5 step process to make a web service)
There has to be a better way. Even if in future they automate some of the steps (eg automatically generate WSDL so that I don't have to remember to name my Java get/set methods exactly the same as the resource properties in the WSDL file, and so on), I just feel less and less like I'm in control or have a good feel for what's happening, or understand the interactions and errors.
On the plus side I was interested to see that Polar Humenn had used Haskell as a language for describing XACML policies, so maybe Haskell ideas will sidle into Grid/Globus in the future.
Amanda Clare
--------
From Rodrigo Barnes
I've spent quite a bit of time (8+ years) developing and managing development of networked applications which can be a painful thing! Clearly anything that could make it a more pleasant experience would be worthwhile. On top of that the possibility of developing a new language (in the broadest sense) for this purpose would be interesting in its own right.
As an aside - on the J2EE front have you tracked the workings of http://www.springframework.org ? We've used it in our latest project and it's certainly made some aspects nicer as well as clearer and easier to maintain. Spring + Hibernate (http://www.hibernate.org) is proving a popular complement and/or alternative to the J2EE stack (EJBs and the like).
In general, my concern with such a project, having also spent quite a bit of time developing tools in academia, is that it aims to prove points rather than developing industrially viable tools (witness e.g. some of the problems in getting e-science tools to market). Having said that you only get the chance to develop this sort of innovation in a research context.
Another idea that might appeal to the group is to look at development tools, such as IntelliJ IDEA (http://www.jetbrains.com/) which along with Eclipse (http://www.eclipse.org) made refactoring tools easy to use for the working Java programmer. When I first saw IDEA it struck me they just went through Martin Fowler's 'Refactoring' book and used it as a requirements doc. So if you took his Patterns of Enterprise Application Architecture book (http://www.martinfowler.com/books.html#eaa) what tool would you get?
-- Rodrigo Barnes
--------
1.2.05
Links meeting at ETAPS
Taking advantage of the fact that the world will be visiting my
doorstep, with the help of some colleagues I am organizing a
meeting on Links for 6 April 2005, to overlap with ETAPS.
The meeting is by invitation only --- please
let me know if you would like to be invited!
Dear Colleagues,
If we bent our minds to it, could we produce a functional language
that was as widely used as Python? There is reason to believe that
functional languages are particularly well suited to building web
applications.
* Databases. Kleisli and Mnesia (not to mention SQL and
XQuery) have demonstrated the value of functional languages as query
languages.
* XML. Xduce, Cduce, Bigwig (not to mention XSLT and XQuery)
have demonstrated the value of functional languages for manipulating
XML.
* Continuations. PLT Scheme and WASH have demonstrated the value of
functional languages for structuring CGI interfaces.
* Distribution. Erlang and JoCaml have demonstrated the value of
functional languages for distribution and mobility.
The technique of building a coalition to design, implement, and
promote a general-purpose programming language has proven
spectacularly successful for ML and Haskell. Can we apply this
technique again, this time aimed at an application domain?
ETAPS will attract a large number of researchers to Edinburgh, and
seems an appropriate point for launching this project. We propose
to meet on *** Wednesday 6 April 2005 in Edinburgh ***. We hope you
can come.
The working name for this project is Links. A quarter of a century
ago, Burstall, MacQueen, and Sannella introduced Hope, the source of
the algebraic types of ML and Haskell. Hope was named after Hope Park
Square, located near Edinburgh University on the Meadows. Links is
named after the Bruntsfield Links, located at the other end of the the
Meadows and site of the first public golf course.
Points to be discussed at the Links meeting include:
* Presentations on work to date -- we hope you will contribute to this.
* Types. The type system of Haskell and the module system of ML
are both extremely powerful, but quite different. Regular expression
types for XML are also powerful, but it is unclear how to combine
these with polymorphism or higher-order functions. Further, to be
successful, any new language must play well with SOAP, Java, and C#,
at a minimum; how do we integrate OO and FP types?
* Effects. It is proposed that the language be strict, with an effect
type system (combining the advantages of Haskell monads with ML effects).
What variety of effects should be supported? Can we provide support for
laziness within this framework? (See Wadler and Thiemann for
relations between monads and effect type systems, see Wadler, Taha, and
MacQueen for a proposal to support laziness in a strict language.)
* Targets. Web applications are often structures as three tiers:
browser (running HTML, XML, Javascript, Flash, Java), server
(running Java, C#, Python, Perl), and database (running SQL or XQuery).
We hope to compile code to run in all three tiers from a single source.
How can a compiler framework support multiple targets of this kind?
(See Thiemann on generating multi-tier programs from a single source.)
* Organization. How to structure the work? Should we put in for
European and/or US grants?
Volunteers for presentations and suggestions as to topics and organization
would be most welcome.
We look forward to hearing from you!
Yours sincerely,
Xavier Leroy
Simon Peyton Jones
Benjamin Pierce
Philip Wadler
doorstep, with the help of some colleagues I am organizing a
meeting on Links for 6 April 2005, to overlap with ETAPS.
The meeting is by invitation only --- please
let me know if you would like to be invited!
Dear Colleagues,
If we bent our minds to it, could we produce a functional language
that was as widely used as Python? There is reason to believe that
functional languages are particularly well suited to building web
applications.
* Databases. Kleisli and Mnesia (not to mention SQL and
XQuery) have demonstrated the value of functional languages as query
languages.
* XML. Xduce, Cduce, Bigwig (not to mention XSLT and XQuery)
have demonstrated the value of functional languages for manipulating
XML.
* Continuations. PLT Scheme and WASH have demonstrated the value of
functional languages for structuring CGI interfaces.
* Distribution. Erlang and JoCaml have demonstrated the value of
functional languages for distribution and mobility.
The technique of building a coalition to design, implement, and
promote a general-purpose programming language has proven
spectacularly successful for ML and Haskell. Can we apply this
technique again, this time aimed at an application domain?
ETAPS will attract a large number of researchers to Edinburgh, and
seems an appropriate point for launching this project. We propose
to meet on *** Wednesday 6 April 2005 in Edinburgh ***. We hope you
can come.
The working name for this project is Links. A quarter of a century
ago, Burstall, MacQueen, and Sannella introduced Hope, the source of
the algebraic types of ML and Haskell. Hope was named after Hope Park
Square, located near Edinburgh University on the Meadows. Links is
named after the Bruntsfield Links, located at the other end of the the
Meadows and site of the first public golf course.
Points to be discussed at the Links meeting include:
* Presentations on work to date -- we hope you will contribute to this.
* Types. The type system of Haskell and the module system of ML
are both extremely powerful, but quite different. Regular expression
types for XML are also powerful, but it is unclear how to combine
these with polymorphism or higher-order functions. Further, to be
successful, any new language must play well with SOAP, Java, and C#,
at a minimum; how do we integrate OO and FP types?
* Effects. It is proposed that the language be strict, with an effect
type system (combining the advantages of Haskell monads with ML effects).
What variety of effects should be supported? Can we provide support for
laziness within this framework? (See Wadler and Thiemann for
relations between monads and effect type systems, see Wadler, Taha, and
MacQueen for a proposal to support laziness in a strict language.)
* Targets. Web applications are often structures as three tiers:
browser (running HTML, XML, Javascript, Flash, Java), server
(running Java, C#, Python, Perl), and database (running SQL or XQuery).
We hope to compile code to run in all three tiers from a single source.
How can a compiler framework support multiple targets of this kind?
(See Thiemann on generating multi-tier programs from a single source.)
* Organization. How to structure the work? Should we put in for
European and/or US grants?
Volunteers for presentations and suggestions as to topics and organization
would be most welcome.
We look forward to hearing from you!
Yours sincerely,
Xavier Leroy
Simon Peyton Jones
Benjamin Pierce
Philip Wadler
Subscribe to:
Posts (Atom)