06:02 pm, 19 Sep 08
de facto
I enjoyed reading this interview of Simon Peyton-Jones of Haskell fame. He comes across as so humble and good-natured, and uses "jolly" as an intensifier. This especially resonated:
One way that this [discussion about writing down a new shared standard for recent Haskell developments] has come about, is that the compiler I am responsible for (the GHC or Glasgow Haskell Compiler), has become the de facto standard. There are lots of people using that, so if you use GHC then your program will work.I've seen it over and over -- no matter how well-intentioned the stewards of a standard are, when you only have one implementation you end up getting tied to unintentional details.
I don’t think that’s a good thing in principle, however, for a language to be defined by an implementation. Haskell is based whatever GHC accepts right now, but it [Haskell] should have an independent definition. So I would like to see Haskell Prime [their upcoming language spec] happen because I think it’s healthy to see an independent definition of the language rather than for it to be defined by a de facto standard of a particular compiler.
:(
(jesus, did I just say that?)
In Perl 6, there is one official test suite. Anything that passes it is Perl 6; arguably there are too many efforts trying to do that.
At least in the web world, we're long past that. You can scream about the Javascript standard 'till you're hoarse but it won't change "my page loads fine in all other browsers but doesn't load in yours".
But the Jones interview on Haskell made me confused. No ... record system? Does that mean what I think it means? No aggregate data types? In Perl I would just turn to string-indexed hash tables. Certainly Haskell must have those(?) The alternative is lists with a plethora of integer indexes. At the low level where C is most firmly rooted, a tight record system is absolutely essential or you are wasting space and time in inner loops. And if there's no way to profile to see where your inner loops are, then there's often no way to optimize past a certain point.
The lack of a module system is less important. Perl 4 has almost everything I need. My typical Perl script loads from zero to four modules, maybe five but not often. I am still looking forward to Perl 6, because of optional static types, and named function call parameters, some smoothing of the harsh prefix character (sigil) syntax,
Here is how I've been calling C from Perl: A named pipe to a separate process. Fast stream I/O from the kernel is easier than trying to figure out linking, heap cooperation, and every other aspect of the foreign function calls, even between C and Perl. It is also, in my case, a huge memory win because I need to pre-compute about 40 MB of tables in the low-level C, and I'd rather have Perl not have to fork() with something along the lines of Apache's mod_perl, but with copy-on-write I've never had enough load to need to even worry about that. The inner loops at the C level, though, where the number crunching happens, can make or break my performance. They take thousands of times the megabyte-cycles of the string slinging that goes on in Perl each session (page view.)
The record system they provide is more or less equivalent to C's "struct" (with a few aspects that make it simpler and a few that are worse). It's about as simple as you can get while still being able to write real programs.
The reason he describes it as "no" record system is that he's a researcher: there are many more interesting things could be done (subtyping, type inference) but none of them are obviously correct enough to integrate into the core language. Haskell's module system is also similar (as least syntactically) to Python's, but the same reasoning applies there.
As an example of a more fancy module system, consider this overview of O'Caml's, which at least allows definitions of interfaces and parameterized modules.