wingologA mostly dorky weblog by Andy Wingo2007-11-15T04:32:24Ztekutihttps://wingolog.org/feed/atomAndy Wingohttps://wingolog.org/the wax wing bitshttps://wingolog.org/2007/11/14/the-wax-wing-bits2007-11-15T04:32:24Z2007-11-15T04:32:24Z

Inspired by the birth of Abdulaziz Ghuloum's baby, Ikarus Scheme, allow me to spend electrons on the latest Scheme standard, R6RS.

I can imagine three camps into which you might fall. Members of the first have read Ghuloum's tantalizing 2006 paper, An Incremental Approach to Compiler Construction, and since have been wondering what this guy was up to. The second camp needs to read the aforementioned paper. Folks in the third group don't give a shit about hacking, but that's cool, diffrent strokes diffrent fokes and such.

So in answer to the first group, Ghuloum recently released his incremental, optimizing compiler for R6RS Scheme. Among other reasons, Ikarus promises to be important for its lucid synopsis of the new Scheme standard in its User's Guide. I quote, verbosely:

The major difference between R5RS [the last scheme revision] and R6RS is the way in which programs are loaded and evaluated.

In R5RS, Scheme implementations typically start as an interactive session (often referred to as the REPL, or read-eval-print-loop). Inside the interactive session, the user enters definitions and expressions one at a time using the keyboard. Files, which also contain definitions and expressions, can be loaded and reloaded by calling the load procedure. The environment in which the interactive session starts often contains implementation-specific bindings that are not found R5RS and users may redefine any of the initial bindings. The semantics of a loading a file depends on the state of the environment at the time the file contents are evaluated.

R6RS differs from R5RS in that it specifies how whole programs, or scripts, are compiled and evaluated. An R6RS script is closed in the sense that all the identifiers found in the body of the script must either be defined in the script or imported from a library. R6RS also specifies how libraries can be defined and used. While files in R5RS are loaded imperatively into the top-level environments, R6RS libraries can be imported declaratively in scripts and in other R6RS libraries.

I got through most of the standard on plane rides last month, and had been meaning to write about it, but he does so better than I would have. The upshot is that R6RS is a kind of "static scheme", not really the minsky-style programming that has been the hallmark of Lisp.

I don't know how I feel about this. On the one hand, the editors appear to have done an excellent job specifying a system of libraries that will allow incremental, separate compilation, that interacts well with macros, and that even allows libraries to be loaded into read-only memory, shared across processes. On the other, they completely neglected the dynamic roots of the language.

In the R6RS rationale document, the editors choose to spin the lack of specification the other way:

Tightening the specification of programs from R5RS would have been possible, but could have restricted the design employed by Scheme implementations in undesirable ways. Moreover, alternative approaches to structuring the user interface of a Scheme implementation have emerged since R5RS. Consequently, R6RS makes no attempt at trying to specify the semantics of programs as in R5RS; the design of an interactive environment is now completely in the hands of the implementors.

The reaction of the internet to the R6RS process has been mixed, but largely negative. I believe that this is mostly because of dissenters being more vocal than proponents, who had the inertia of process on their side; that, and pissants that write more than they hack.

Still, when the picture is presented as clearly as Ghuloum does, the R6RS proposal has an enormous gaping hole, viz. how to interactively develop programs. No long-running web servers, interactively added to over the course of a year; nothing that would make SLIME for Scheme possible; even the REPL itself is undefined in the new standard.

What happens now will largely be a social phenomenon, I think. Those that develop "statically" are probably happy with R6. Those that develop more dynamically either fork, switch languages, or find a way to reintroduce dynamism into the subset of the community that produced R6. Those in the middle... well, you're in good company, I guess.

tunes

Depends on your mood, but Death From Above 1979 has fit mine in recent days. "Going Steady" rocks out.

Andy Wingohttps://wingolog.org/-*- text -*-https://wingolog.org/2007/05/22/text2007-05-23T00:11:49Z2007-05-23T00:11:49Z

Hey hey hey!

recently

jao turns out to be quite the interesting person, in person, despite having recently been seduced by the googlopolis. R6RS will be voted by alist. I have a phone contract now, but Vodafone should be warned that I'm no good at relationships. I signed up for a sailing course. The season of barbecue and fiestas mayores is upon us. A crack appeared in my bike's headset, which was fixed with welding. Ellen graduated. It rained dirt.

hack

I wrote wrappers for Cairo in Guile. Yay scheme.

Jao and I talked loads about various Scheme implementations; none of them is good in everything. They're all compromises. He has a much more open mind about these things, changing from one implementation to the next for different projects, but given my past investment in Guile it would take a lot to change my implementation.

Jao also mentioned a really good point, that the more you like Scheme, the less you like Guile. Ah well, I have a foot in the C world still. The applications that I work on use Gtk and GStreamer, for which I have made pretty good bindings. Still, pretty irritating as a Schemer to see what Common Lisp people have -- portable libraries, excellent implementations, and excellent development environments. Yet another Guy Steele-fostered standard that has lasted. Maybe before switching Schemes I could look at CL.

I'm currently updating guile-gnome to cover the GNOME 2.16 platform. I have the stack updated up to GTK+, including pangocairo and the cairo parts of gdk. A fair bit of work, but I'm managing.

I should decide on a spelling for guile-gnome and stick to it.

time

I have slid back to my old habits a bit, since thinking I was in control of my email a while back. More email out == more email in. I yet harbor hope.

Andy Wingohttps://wingolog.org/exciting papers!https://wingolog.org/2006/09/18/exciting-papers2006-09-18T13:08:12Z2006-09-18T13:08:12Z

I am currently very plussed by three excellent papers.

The first is important, bringing the Scheme up to speed with the implementations, and a bit beyond as well: unicode, a standard compilation-friendly library mechanism (finally!), standard support for #!-style scripting, byte vectors, records, standardized exception and condition handling, byte-based i/o, fixnums, quasisyntax (!!!), and more.

The bit about library support is key. Libraries are especially difficult in languages with macros (see Composable and compilable macros:: you want it when?). Yay. Yay!

The other papers are more relevant to my current line of work, building distributed systems for Fluendo. It's really interesting to see what kinds of reusable pieces Google has managed to factor out of their applications, and the practical experience building tools to make a Google application. From what I can see from these two papers and the previous ones at their papers page, they have an extremely strong platform. It is enviable.

I still feel like Google is a fortress. This time in addition to the processional desire, paper releases are pushed by their recruiting department as well -- see the conspicuous "Why work at Google?" link once you have finished digesting their papers.

I've been thinking a bit about how to build a distributed "Web 2.0" app using peer-to-peer technologies. You would need what they have, a mapreduce/sawzall approach to data processing, but instead of bigtable/gfs you would need freenet. You might even have to give up on locking completely. Then on the presentation side, each node would have to serve web pages using this store, running distributed programs on a safe VM.

Among other lessons, the Google papers show that if you have the platform, the applications come a lot easier. That their subversion code hosting uses Bigtable as a backend is a no-brainer.

Well. Enough incoherent babbling for one morning!