Lambda the Ultimate

Can anyone point me to any work on declarative languages for user interfaces? I'm aware of the plethora of XML languages, a favourite of web frameworks in particular. I mean a more concise declarative UI or layout language.

I've built a small declarative library which outputs HTML, but I'm not really satisfied with it, so I'm wondering what other work has been done here for describing the high-level user-interface structure.

Share your experiences of Model-Driven Software Development at our 3rd annual conference. Accepted speakers have their conference fees waived.

Call for Speakers:
Submission Deadline: Friday January 18th 2008

We are currently seeking high-quality session proposals covering topics in model-driven software development (including Domain-Specific Languages (DSLs), Model-Driven Architecture (MDA), Executable UML, Eclipse Modelling Tools, Software Factories, Generative Programming, Software Product Lines and related areas).

Sessions could cover topics such as:
- Tool and technology adoption
- Code Generation and Model Transformation tools and approaches
- Defining and implementing modelling languages
- Domain Analysis and Domain Engineering
- Language evolution and modularization
- Meta Modelling
- Runtime virtual machines versus direct code generation

Real-world case studies based on any aspect of these and related approaches are particularly encouraged although more theoretical sessions are also welcome.

Take part in Code Generation 2009 and find out why industry observers think that Code Generation is the next evolutionary step in Software Development.

Code Generation 2009 takes place in Cambridge, UK from 16th - 18th June 2009. The event is supported by IASA and OMG.

For more information on proposing a session please visit:
http://www.codegeneration.net/cg2009/speak.php

"The combined—for that matter, individual—expertise present was remarkable, and presented a tremendous opportunity for knowledge exchange."

"[A] great opportunity to meet with influential practitioners in the field."

I'd like to announce the first alpha release of a compiler for the Ur/Web programming language, available with an interactive demo at:

http://www.impredicative.com/ur/

Ur is a programming language designed to introduce richer type system features into functional programming in the tradition of ML and Haskell. Ur is functional, pure, statically-typed, and strict. Ur supports a powerful kind of metaprogramming based on row types.

Ur/Web is Ur plus a special standard library and associated hints for parsing, type inference, and optimization. Ur/Web supports construction of dynamic web applications backed by SQL databases. The signature of the standard library is such that well-typed Ur/Web programs "don't go wrong" in a very broad sense. Not only do they not crash during particular page generations, but they also may not:

• Suffer from any kinds of code-injection attacks
• Return invalid HTML
• Contain dead intra-application links
• Have mismatches between HTML forms and the fields expected by their handlers
• Attempt invalid SQL queries
• Use improper marshaling or unmarshaling in communication with SQL databases

This type safety is just the foundation of the Ur/Web methodology. It is also possible to use metaprogramming to build significant application pieces by analysis of type structure. For instance, the demo includes an ML-style functor for building an admin interface for an arbitrary SQL table. The type system guarantees that the admin interface sub-application that comes out will always be free of the above-listed bugs, no matter which well-typed table description is given as input.

The Ur/Web compiler also produces very efficient object code that does not use garbage collection. These compiled programs will often be even more efficient than what most programmers would bother to write in C. For example, the standalone web server generated for the demo uses less RAM than the bash shell.

Following this thread, here is my review of Practical API Design.

Jaroslav Tulach is the founder and original architect of the NetBeans project.

Practical API Design is a book with apparently one bold aim: to be the book that gets people thinking seriously about the topic of API design -- in particular the maintenance of backwards compatibility in APIs -- and kick-starts an API design revolution, with more books and university courses to follow in its wake. Incidentally, it can also be a highly readable introduction to API design, a thought-provoking set of warnings to experienced engineers embarking on managing a growing API and an entertaining odyssey through the development of the NetBeans API. With regard to the main aim again, we must hope that more books and papers are indeed written developing this theme, as this book cannot do it all by itself; more on that topic later.

The book is curiously subtitled "Confessions of a Java API Designer", but due to the individual and highly digressive style (at least in part one) a more apt subtitle may be ""The Life and Opinions of Jaroslav Tulach, Gentleman". It may seem odd at first, but later in the book this style does show its strengths. My experience of trying to find good material on the subject of the maintenance of backwards compatibility is the same as the author's: I can find very little worth reading, and nothing that covers the subject in depth. Therefore the book must take a personal point of view, setting down beliefs and opinions and setting them down strongly in the hope that a reaction is provoked. The areas in which this book lacks are advanced as areas into which you, the reader, might contribute. This is the book as a call to arms rather than an attempt at solid theory. I think the approach works rather well.

The question uppermost on my mind when picking up the book for the first time was, "how Java-specific is this?". Tulach has attempted to push Java specifics into the second of the three parts (the largest), and has mostly succeeded, although some Java-centricity is noticable in part three. That is not to say that the second part is useless to those not using Java; far from it! This section is the practical part-- where the theory was built up and strengthened on the proving-grounds of NetBeans development; as such it is integral to the book whichever language you are using. But if you are using a different language, how much extra work is required? Quite a bit, unfortunately. What you can and cannot do in a compatible way is dependent on the details of the binary interface (which may well be compiler-specific if not laid down in the language or other specification), so there is no way at all that one book can attempt to do this in a generic way. My own point of view is Symbian OS APIs, which are affected by the C++ language in which they are written, the EABI binary interface specification and the decision to use link-by-ordinal -- this combination needs its own careful consideration and results in a different set of emphases to those Tulach advances; for example, the specific technical dos and don'ts require much more effort and explaination in C++, and the idea of a checking tool would warrant more than the four lines it gets in Practical API Design. This means that, if you are using a language other than Java, you must think about each piece of advice with respect to the peculiarities of the languages you are using. Worse than that, of course, you must work out for yourself what sorts of compatibility difficulties you might have that are entirely unmentioned by the book; C++ has many such pitfalls.

All of the code samples are in Java; most are clear and easy to understand, although often too fond of generics to be easily parsed by a newcomer to Java. Tulach also denies us any warm fuzzy feeling when one of his very first examples is a two-page horror involving some subtle implicit effects and highly Java-specific calls that will be totally opaque to the Java neophyte, as well as an apparent instance of double-checked locking and a curious piece of at-first-sight useless code that must be for multi-thread access (p76). Having studied it with some Java expert colleagues, we have convinced ourselves that the code is, in fact, correct. But we have not convinced ourselves that it is "good design". Tulach will retort, as he does many times in the text, that beauty should be sacrificed every time in favour of keeping compatibility, and he is right. So now working out if a nicer solution would have the same benefits is an exercise for the reader; this is not out of keeping with the book as a whole, as much is for the reader to work out. This is not because Tulach has failed to put together a compelling book; he has. It is because he has deliberately overreached in order to present to us a vision of what can be achieved with care, hard work and the right attitude. However, the low-level detailed answers must come from the reader.

As a reader embarking on the beginnings of their own project, the book takes the form of a stern warning of the pitfalls that lies ahead, and sketches some potential solutions. For a project using only Java, the book seems to me (I am no Java expert) a thorough sketch of the territory ahead. Colourful, passionately argued and totally convincing.

As a reader already scarred by the trials of compatibility maintenance, there will be many nods of recognition and some pointers of where the compatibility armour could do with some hardening. The book is a valuable read.

As a reader looking to translate NetBeans' lessons into another (machine) language, there is much more work to do, as I have already mentioned. There is no technical scaffolding against which to build a compatibility policy; no guide or checklist of things to look out for. For example, if one were to attempt to come up with compatibility rules for Haskell, one would have to delve deeply into how each element affects the binary to which others link, and how this linking occurs. Explaining this is not the purpose of the book. It will definately give a head-start as some issues will overlap between your target language and Java, at the expense of having to learn why certain things work and other things do not in Java. This is good education anyway-- I even found a new (somewhat grudging) respect for the language.

As a reader looking for cookbook techniques for the design and maintainance of Java APIs one is likely to be disappointed. The correct way to read Practical API Design seems to be with a notebook in hand, jotting down interesting topics and random thoughts that occur (some of my questions that occurred took many, many chapters to be answered), then re-reading and fleshing out how each topic applies to your situation. If you get that far, maybe you could publish it too as a cookbook! But Practical API Design is not a cookbook.

I was slightly disappointed by a particular omission; there is no discussion on the circumstances under which one might consider a break acceptable. For example, if you need a new system-wide feature (a multi-module search, for example, whose index would be invalidated by anybody having continuous access to the data), or a new architecture for performance purposes that makes an old API impossible, or an API is found to embody a security problem. Perhaps you just know these issues when you see them and it is acceptable to have little discussion. Tulach's opinion is firm, even with bug-compatibility. He will only admit that fixing a null pointer exception is OK; I can't help feeling that some discussion is warranted here.

There is only one place where I actually found myself outright disagreeing with the author, though. This is in the issue of whether maintaining compatibility of an API by making users enable the new API with an environment variable or other global switch is acceptable. I always argue that this is not OK in Symbian, too, and am routinely ignored, so perhaps Tulach is in good company. I feel that (for some APIs) pushing this decision on to customers (especially as our customers have their own customers to look after) rather than solving it more optimally ourselves is very rude.

At 383 non-index non-contents pages with 20 chapters covering testability, modularity, run-time issues, trust, teamwork and so on divided into 3 parts (basically philosophy, practice and process) it covers the ground very well. Some might find the tone too chatty, although I liked the Jekyll-and-Hyde split between the zealous hardliner of the main text and the practical consensus-builder of the (mostly NetBeans-specific) sidebars.

I enjoyed Practical API Design; I have not come across any book treating the subject of API maintenance in nearly such depth and breadth. Recommended for architects who care about their APIs, especially those using Java. Those using other languages will find much of value also.

I am interested in statically typed OO languages with the property that no variable can be typed as a class. Instead all variables have one or more interfaces as types. Other than performance, what would be lost by taking this approach? Are there languages that do this?(Strongtalk?)

(To be more concrete, I am suggesting in a language such as Java or C#, disallowing any variable from having a concrete type either syntactically, or internally. Classes exist solely to specify how interfaces are to be implemented. All classes would specify at least one interface, namely one with its public methods. All inheritance mechanisms still exist.)

I'm trying to assess several dependently typed languages/platforms in order to select one for a project which is to create a type-level DSEL for reasoning with quite simple formal systems. I began with the intention of doing this in Haskell+GHC extensions, emulating the types I need but I no longer think that will work for me, or rather it may be possible but is a square peg in a round hole...

I'm starting to look at Coq, Agda & Epigram by working through tutorials and putting together some code, and as far as I can see any of these would be sufficient for the task. It's obvious that there are big differences in scope between Coq and the other two on the list. A proof assistant not a programming language, although it's capable of being used as one, by far the most mature, lots of resources, extraction to Haskell/ML...

Can anyone give me a comparison of these and similar systems (Dependent ML? YNot?) w.r.t. their type systems and other capabilities? I'd also like to hear thoughts on their relative maturity, whether you think that should matter very much to me, learning curve, etc?

Thanks!

Hi,

I am writing a Lisp->JavaScript compiler (link), and I am at the point where I want to add defmacro to the language, so that higher-level, convenient operators like let can be added to the language in terms of simpler, core forms.

The boostrap problem is this: the macro bodies need a sizable portion of the language as support code (e.g. AST objects, collections, map, other utilities...), but I don't want to write that part of the language without the convenient operators afforded by macros.

I see a couple of possible solutions:

1. Add a non-turing-complete macro system (e.g. syntax-rules), and write the convenience macros in that system;
2. Write the convenience macros as built-ins in the compiler's host language;
3. Use some kind of external tool, e.g. pipe my S-expressions through a Scheme and utilize its macro system;
4. Bite the bullet and write the defmacro support code without the convenience macros.

Any suggestions? Thanks,

-- Manuel

"... there seem to be clear advantages to informing the design of future languages with evidence drawn by something other than anecdote, personal experience, small-scale observational studies, or personal morality (Dijkstra 1968). Similarly, maintenance and debugging tasks - and even teaching about programming paradigms - would surely benefit from being based in evidence about the world as it is, as well as the world as we would like it to be!"

Multiple Dispatch in Practice, OOPSLA 2008 (pdf)