A quote from a nice comment from Dave Benjamin on Lambda:

… I really wish Python had gotten a ternary operator; having to abuse “and” and “or” just to embed a conditional in an expression is tacky. I don’t care what the syntax is! Pick one! I feel like that feature died because of the noise, because nobody could agree on anything, and if that’s the direction of Python’s future, it’s a little bit scary.

Look, we’re not all going to agree on anything. I thought that’s why Guido was chosen as “Benevolent Dictator for Life”. Lately, his strategy has been to say something like “Well, I don’t care if we add the feature, and I don’t care if we don’t, but if you all can decide on a syntax, we’ll do it.” I think that this approach is killing progress. Of course we won’t all agree. We’re a bunch of opinionated hackers, and we like things our way. That’s why you’re dictator, Guido. Dictate!

Language is the one concrete dependency that we never seem to be able to abstract away. Changing a language affects more people the more successful a language becomes. Is it the destiny of every language to eventually grind to a halt, for no other reason than people’s inability to agree on the next step for growth? I hope not, but I’m glad we have lots of other languages that are not so constrained.

Totally agreed. Design by committee rarely turns out elegantly.

A snippet from a post by Guy Steele on the ll1-discuss list:

And you’re right: we [the Java language designers] were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren’t you happy?

Spotted this little gem in a thread about programming languages and software engineering, on (where else?) Lambda the Ultimate:

John Reynolds told me that he once described a correctness proof for XORing together pointers in a doubly-linked list to someone. This person asked why he would ever want to prove such a disgustingly nasty hack correct, to which he replied that it was no longer a disgusting hack, because he had a clean proof of correctness for it.

Patrick Logan talks about Yet Another Python implementation named pycore, a Python VM implemented in Smalltalk. Yawn, you say? Well, right now it’s completely unoptimised, and seems to benchmark better than CPython. I can see this giving the much-more publicised IronPython a run for its money. Isn’t it great how Smalltalk can still compete well with today’s modern VMs?

By way of Joel Spolsky, a good article on Great Hacker != Great Hire. (And in case you haven’t guessed yet, I agree with the article by the simple action of linking to it from my blog ;-).

Matthew Thomas writes about the lack of usability advancements in the past two decades in this excellent blog entry. Why, indeed, do we still make people use filepickers at all? (Though, I should note that KDE’s File Open dialog box is actually a fully-embedded Konqueror view, which is a step in the right direction.)

Lambda the Ultimate has some pretty interesting discussion about compile-time checking for taking the tail of an empty list, which is generalisable to compile-time checking of any partial function (functions which are not defined for their domain, i.e. their input values). Some particularly interesting comments I found in that thread:

• “I see the empty list as being like null, which Nice has static checking for”. Wow, impressive (probably not impressive from the type theory angle, but particularly impressive from a practical viewpoint: all NullPointerException exceptions detected at compile-time? Cool indeed. Something tells me I should have a closer look at Nice. Maybe for my Ph.D, I can write a type inference engine for Objective-C. Nehhh …
• [On modifying the tail function to return Maybe [a] instead of just [a]]: “Using Maybe for this is like saying - let’s turn this partial function into a total one by lifting its range to include Nothing. It became total by obtaining permission to return something I have no use of.”
• “My point is that [the] Hindley-Milner type system is not expressive enough to allow two (or more) consent programmers to state their mutual expectations. As an author of tail function I can’t promise to always return list given non-empty list and expect the compiler to reject all programs that try to call tail on empty list. I suspect it’s possible to stretch Haskell a bit to encode this particular constraint, but as you said, dependent types are way to go for those who seek more static expressiveness.”
• “In Epigram type checking is decidable, because all functions are total. Conor McBride plans to add general recursion, but its use would be tracked by the system so that types can only depend on terms from the total fragment.”

And of course, the obligatory type wizardry post from Oleg:

• “I’d like to point out that it is possible in Haskell98 to write non-trivial list-processing programs that are statically assured of never throwing a `null list’ exception. That is, tail and head are guaranteed by the type system to be applied only to non-empty lists. Again, the guarantee is static, and it is available in Haskell98. Because of that guarantee, one may use implementations of head and tail that don’t do any checks. Therefore, it is possible to achieve both safety and efficiency. Please see the second half of the following message: http://www.haskell.org/pipermail/haskell/2004-June/014271.html”.

Wolfgang Thaller’s been working on bringing the Glasgow Haskell Compiler into the 1990s:

Yes. In fact, I already have a “Hello, world” program linked against dynamic libraries libHSrts.dylib, libHSbase.dylib and libHShaskell98.dylib on Mac OS X, and another one doing the same thing on PowerPC Linux.

All I can say is: thank God! Wolfgang, you rule. I can’t wait for this to hit the GHC stable tree!

Martin Pool writes yet another excellent blog entry, this time about Rusty on Interface Simplicity. His OLS 2003 keynote had an “interface simplicity spectrum”, which is so good, Martin reproduced it in his blog, and I’m going to reproduce it in mine, for my own reference:

1. Compiler/linker won’t let you get it wrong.
2. Compiler will warn if you get it wrong.
3. The simplest use is the correct one.
4. The name tells you how to use it.
5. Do it right or it will break at runtime.
6. Follow common convention and you’ll get it right.
7. Read the documentation and you’ll get it right.
8. Read the implementation and you’ll get it right.
9. Read the correct mailing list thread and you’ll get it right.
10. Read the documentation and you’ll get it wrong.
11. Follow common convention and you’ll get it wrong.
12. Do it right and it will break at runtime.
13. The name tells you how not to use it.
14. The obvious use is wrong.
15. Compiler will warn if you get it right.
16. Compiler won’t let you get it right.
17. It’s impossible to get right.

(Obligatory Haskell plug: a nice one-line summary of the Haskell language is that just using it for your code, puts you at #1 on that spectrum an incredible amount of the time.)

Doug Bagley’s most excellenté functional programming koans, courtesy of Sean Seefried. Here’s one example:

The Koan of Lazy Evaluation: Michel Mauny was giving a guest lecture to new computer science students. After the students were seated, Michel pronounced “Today’s lecture will be about Lazy Evaluation”, he paused for a moment then concluded with, “Are there any questions?”

Which OS are You?

Martin Pool has a really nice blog entry on how to use -Wall to turn on all warnings in gcc, and stop it from complaining when you have unused parameters. This is quite a common scenario when you’re using callbacks (a.k.a. delegate or visitor methods).

Lambda the Ultimate has a story on a new CLR (.NET) language named Boo. Ian Bicking’s comparison of Boo vs Python is a nice, succinct summary of it. Looks quite interesting: type inference, duck typing, macros, and string interpolation. Seems that the CLR does seem to be breeding all sorts of new languages …

In imperative languages, you usually get a new random number by calling a function (such as C’s rand(3)) when you need a new one. You can do this in a functional language like Haskell too, but then you’re forced into an imperative style, which isn’t very functional. (An imperative style would be required because generating a new random number depends on the current state of the random number generator.) You can keep a functional programming style by having a random number generator produce a (lazy) list of numbers, rather than a single number: any code which wants a random numbers simply pulls the next one out of the list. I posted some example code to the haskell-cafe mailing list recently to demonstrate this, in answer to a Haskell newcomer’s post. Lazy lists are often also called streams.

Normally, monads are used to encapsulate state changes in Haskell in a purely functional manner, but you can use streams too: any state changes which occur can be represented with new list elements. It’s no coincidence that streams are monads: they’re powerful enough to sequence non-deterministic operations. The Haskell Ports Library gives you even more convenience when working with streams by modelling time as a list, and the awesome iHaskell and Fudgets libraries for Haskell manage to model an entire GUI in a purely functional manner. Just to show that this is also has a practical benefit, the Fudgets code examples show how succinct writing GUI code can be. The Fudgets thesis is a great introduction and explanation to how it all works.

Closely related is the newer concept of arrows, which provide a formal framework to reason about stream-based (and also various other non-stream-based) computations. Anyone up for writing a Haskell library to interface to the gstreamer media framework as an arrow?

Bryn Keller (a.k.a. Xoltar) takes on Bruce Eckel’s comments about Python and static typing, and does a pretty good job at poking all the holes in Eckel’s arguments while remaining objective. Worth a read, especially if you’re wondering what all the hoopla is about Haskell and O’Caml’s type systems.

My Comments

Bryn comments toward the end of his article about how duck typing can lead to ‘dangerous’ situations. He uses the example of a method named draw, which has different semantics for the Gunslinger class (where draw means ‘Bang!’) vs a Artist class (where draw means ‘paint’). While it’s possible to have such name clashes with different semantics, in reality I don’t think it’s a big problem: certainly one not worth spending a few paragraphs on in an article. (When would this situation ever crop up, for example?)

He points out that in the Nice language, you can write a class, and make them part of the interface later. In his words: “We also got additional power in the bargain, because now we can selectively bless any class we like into the Speaker interface, without including classes we don’t want - we can ensure that our Artist doesn’t end up in a gunfight by mistake!”. In languages such as Java or C++, you must declare that a class implements an interface when you write the class: you cannot write a class and declare later that it implements the interface. It is very cool to program in a language which enables you to separate the code you write, from declaring how that code is used as part of your whole system design. Some other examples of this feature in other languages are:

• Haskell, which enables you to declare a type class to capture common functionality provided by different functions. So, you could write a Haskell module which provides a new Hashtable data type, and another Haskell module to provide a new balanced tree data type. You can then later write a type class to capture operations common to such colletion/aggregate types, by writing a new type class that declare type signatures for functions such as inserting objects into the collection, or retrieving objects from the collection. Note that you could have completely different interfaces to the hashtable/tree classes with completely different type signatures: the type class performs the ‘glue’ code necessary to provide one clean, consistent interface to both of them. (Plus, the very small glue code required to do that will be optimised away by any optimising Haskell compiler, such as GHC.) This is the same idea as Nice’s separation of code declaration vs interface declaration, though type classes are a far more powerful and generic concept.
• Objective-C’s categories, which enable you to add new methods to existing classes. You don’t like it how the NSFileHandle class doesn’t have a method to create a new temporary file and return you a file descriptor for it? No problem, just add your own method to do that to the class — no subclassing necessary. Categories are possibly the greatest thing I miss about Objective-C when I use any other language (Haskell included: it would be really cool to be able to extend type classes by adding new methods to them!). C# has a similar feature named partial types, although it’s nowhere near as elegant as categories. Perl 6 takes this idea even further than Objective-C does: it differentiates between open classes, which can have methods added to them, and closed classes, which can’t. The clever bit is that all classes are open by default, but any users of that class will close the class unless it’s specifically declared open. This is really smart because it means that you can have the same flexibility that open classes give you, but you gain all the optimisation opportunities that come with closed classes, such as performing static dispatch rather than dynamic dispatch on a function call, which opens up a whole new set of optimisations that weren’t previously possible, such as inlining.

One of the points of Bryn’s article seems to be that static typing detects different errors from unit tests: while this is true, I’d phrase this a different way. One benefit of unit testing is that it helps you develop your code faster because unit tests enable your code to be more robust as you develop it, saving you from hunting down those stupid bugs later on. Modern static type systems give you different test coverage, and I think they speed up your development even more, because they often pick up a lot more errors than unit tests do. If you’re a Perl programmer, the use strict; pragma that Perl has basically turns on static type checking. Think about how many bugs you’ve found thanks to its warnings and errors, and imagine how much of a nightmare it’d be if you didn’t have that facility at all. Now think about extending Perl’s simple type system (which is limited to only type checking of scalars/arrays/hashes), so that types are pervasive in your program design that enable far better coverage by the type checker, and you’ll hopefully have some idea of what I’m talking about.

He remarks right at the end of his article that “We need both strong testing and strong typing” — I think he means static typing, not strong typing, considering that was what his entire article was about :). Mind you, static and strong typing seems to be confused quite easily: even Guido van Rossum confuses strong typing with static typing. I personally find it a bit worrying that the designer of such a popular (and great!) language gets it wrong, but hey, nobody’s perfect.

Bryn, I think, doesn’t point out the biggest benefit of modern static typing systems: it saves you time because so often, when that anal type checker finally does let your program compile, it just works a really surprisingly large amount of the time. (This is closely related to the increase in productivity that I discussed above, but it’s not quite the same thing.) It’s downright unnerving just how many times your program performs correctly: one thread on the cvs-ghc mailing list gives an anecdote, where most of the Glasgow Haskell Compiler back-end was ripped out and re-written (14000 lines of code!), and the PowerPC code generator worked first-go. I’m yet to nail down whether this phenomenon is only due to the advanced type systems alone, or whether it’s a combination of the powerful type system and a (purely?) functional programming style; I suspect it’s the combination of the two. Programs are much easier to reason about when state changes are made explicit.

iTunes is nice and all, but I wish you could rank a song between 0-6 stars rather than 0-5 stars. That way, you can classify 0-star songs as unrated, and have 5 stars leftover for your own classification, rather than 4, which may be a bit too restrictive. Well, you can do this pretty easily for purposes of including it in a smart playlist, which is all I wanted to do.

How to do it? Easy:

• Rate all your 6-star songs as 5-star, so they’ll be included in any matches that would normally include 5-star songs.
• Add the text “6-star” to the comment of any of the songs you want to rate as 6-star.
• Make a new Smart Playlist, and include the “6-star” text as part of the criteria for the playlist.

That’s it. You can obviously expand the scheme to 69 stars if you want, but 6 is enough for me.

Abstract

As a Linux user or developer, you probably know a few programming and scripting languages: shell scripting, Perl perhaps, Python, C or C++, and maybe Java or XSLT. Once you’ve learnt one systems language or one scripting language, you’ve learnt them all, right? Especially because of that “Turing-complete” thing …

In this talk, I’ll explore the research and developments that have happened outside of mainstream programming languages in the past decade, in languages such as Objective-C, Haskell, O’Caml, and Nemerle. The scope of the talk is broad: I’ll touch on many topics, such as meta-programming, generics, type systems, and proof-carrying code, without going too in-depth into any of them. (Believe me, you don’t want to hear me talk for seventeen hours about type systems.) Most of the topics covered (such as meta-programming) are not language-specific, and can be directly applied to your own work, increasing your own programming expertise and repertoire of techniques.

Download

Slides: Adobe Acrobat PDF

I like Apple’s sense of humour :)

• In one screenshot of the Stock Ticker dashboard app, Microsoft (MSFT) was the only company in the shot which had their stock price going down.

• The calculator app in this Dashboard demonstration shows the number 1.337.

• And, of course, the most excellent Introducing Longhorn poster!

AndrÈ Pang, Don Stewart, Sean Seefried, and Manuel M. T. Chakravarty.

Submitted to the 2004 Haskell Workshop.

Abstract

Extension languages enable users to expand the functionality of an application without touching its source code. Commonly, these languages are dynamically typed languages, such as Lisp, Python, or domain-specific languages, which support runtime plugins via dynamic loading of components. We show that Haskell can be comfortably used as a statically typed extension language, and that it can support type-safe dynamic loading of plugins using dynamic types. Moreover, we discuss how plugin support is especially useful to applications where Haskell is used as an embedded domain-specific language (EDSL). We explain how to realise type-safe plugins using dynamic types, runtime compilation, and dynamic linking, exploiting infrastructure provided by the Glasgow Haskell Compiler. We demonstrate the practicability of our approach with several applications that serve as running examples.

Download

The paper’s official website, where you can download the hs-plugins library and example programs, is at http://www.cse.unsw.edu.au/~dons/hs-plugins/paper/.

12 pages: Postscript (.ps.gz), Adobe Acrobat PDF. The copyright for the papers is held by the authors or by the publisher. The papers are provided for personal use only; other use requires the explicit permission of the copyright holder.

BibTeX Entry

@inproceedings{PSSC04,
 author = {Andr{\'e} Pang and Don Stewart and Sean Seefried and Manuel M. T. Chakravarty},
 title = {Plugging Haskell in},
 booktitle = {Proceedings of the ACM SIGPLAN workshop on Haskell},
 year = {2004},
 isbn = {1-58113-850-4},
 pages = {10--21},
 location = {Snowbird, Utah, USA},
 doi = {http://doi.acm.org/10.1145/1017472.1017478},
 publisher = {ACM Press},
}

Related Webpages

• Citeseer Page

If your Mac OS X application uses a framework, you can embed it in your application even after you’ve built and linked the application against a framework which you’ve installed privately to /Library/Frameworks.

The secret is to use the obscure install_name_tool command. You’ll need to do two things:

1. Change the identification name of the framework itself from Foo.framework/... to @executable_path/../Frameworks/Foo.framework/...
2. Change the application’s main executable dependent shared library list, from Foo.framework/... to @executable_path/../Frameworks/Foo.framework/...

Here’s how to do it:

1. Copy your existing framework first and work on that: the install_name_tool command directly modifies the framework, so you’ll probably want be operating on a copy of it.
2. Run install_name_tool -id '@executable_path/../Frameworks/Foo.framework/...' Foo.framework/Foo
3. Run install_name_tool -change 'Foo.framework/...' '@executable_path/../Frameworks/Foo.framework/...' MyApplication.app/Contents/MacOS/MyApplication

To find out what to put in the ... bit of the commands above, run the otool -L command on the executable or shared library to see the full pathname. It should look something like Versions/A/Foo.

It’s a bit of a pain in the arse, but at least it works. Until I figured this out, it was really a bit of a pain to embed frameworks into applications properly!