Older blog entries for rotty (starting at number 2)

Scheme48 fork update

Mike Sperber finally reviewed my patches; they unfortunatly were not deemed appropriate for the Scheme48 distribution, see this thread. Hopefully these issues can be sorted out in the not-to-far future. If you also need the one or other features from my hacks so far, and are adventurous, you can conact me on #scheme on freenode for help with getting and building my fork.

Writing portable Scheme programs with scmxlate and spells

For the conjure project, we are using scmxlate to make it portable across multiple Schemes. For that purpose, I slightly extended scmxlate and built a kind of meta-module system on top of it. Here is how that looks like:

You write a description of the modules your application or library is made of; this is done in a sightly extended subset of the Scheme48 configuration language. For example (from this page, see there for more details):

 (define-structure conjure.foo.bar (export qux baz
					  ((froboz fribnitz)
  (open scheme srfi-1 srfi-13 conjure.util.files)
  (dialect (guile (open ice-9.syncase))
           (scheme48 (open extended-ports)))
  (files (foo basic-bar)
         (foo bar)))

This defines the module conjure.foo.bar, which exports the identifiers qux and baz, as well as the macros froboz and fribnitz. The open clause means: this module is written in R5RS Scheme (scheme), plus additionally using srfi-1, srfi-13 and the conjure.util.files module. The dialect clause can be used for specifiying additional modules needed for the dialect-specific code for the module. Finally, the files clause tells us that this module consists of the files foo/basic-bar.scm and foo/bar.scm.

This file then gets processed by scmxlate, generating a file with the right module definitions for the selected target dialect, e.g.:

(define-module (conjure foo bar)
  #:use-module (srfi srfi-1)
  #:use-module (srfi srfi-13)
  #:use-module (conjure util files)
  #:use-module (ice-9 syncase)

#:export (qux baz) #:export-syntax (froboz fribnitz))

;; code for foo/basic-bar.scm and foo/bar.scm follows

will be generated for Guile.

We recently split scmxlate and the meta-module systeem out of conjure, see the scmxlate category in the conjure archive, so it is available for other projects. Now the split-out of the general purpose modules into a separate project -- SPELLS, (S)pell's a (P)ortability (E)nvironment (L)ibrary for (L)ots of (S)chemes -- is in preparation. This library will further aid writing portable code, by providing a consistent interface to functionality that has different APIs in different Schemes. These modules are already there:

  • spells.util.pregexp: Dorai Sitaram's portable regular expressions
  • spells.util.named-args: Conviniently create procedures with named arguments
  • spells.util.table: Hash tables
  • spells.util.condition: SRFI 34 and SRFI 35
  • spells.system.file: Lots of file-related proedures, e.g. copy-file, directory?, ...

All of those are implemented for all of mzscheme, Guile, Scheme48 and Gauche, using native functionality where available. Other modules will surely follow, a project has been requested at Gna! to facilitate contribution. The spells library will also be used by my upcoming port of G-Wrap to Scheme48.

Status of Scheme48 hacking

Over the last months, I've started several hacks on Scheme48. My interest in Scheme48 was initially sparked by Jivera, who started to bring a Pika-style C API to Scheme48.

The features/projects I've been working on:

  • The new buildsystem: it is now easily possible to build Scheme48 completely from scratch, bootstrapping it with another Scheme48 installation.
  • R5RS-compatible keywords (e.g. #:foo). There seems to be some controversy about the usefulness and "good taste" of keywords, but I need them for my GOOPS-compatible TinyCLOS version.
  • Relaxed string escaping, i.e. allow e.g. (display "Hello World!\n").
  • A scheme48 executable that allows command-line access to the exec language; you can do

    scheme48 -cl packages.scm -o mystructure

    which is equivalent to typing:

    ,config ,load packages.scm
    ,open mystructure

    at the Scheme48 prompt.

  • Some initial work on a PLTish FFI. See Foreign Interface for PLT Scheme for how this FFI looks like. The cool thing about it is that you don't have to delve into C for creating bindings anymore.
  • Porting Kali Scheme. This has just started; so far, I've been able to get the Kali VM to build on top of Scheme48 1.2, but it is probably far from working.

Most of the above is still not polished and not ready for release or even sending patches upstream. I have, however, submitted some very simple patches to the Scheme48 mailing list, and got no response from the maintainers. Should working with them not work out, I might have to create my own fork of Scheme48. In fact I have forked already, but if I can't get (parts) of my stuff into mainline Scheme48, I might start to actively push my fork as "extended Scheme48" or with a new name.

13 Jun 2005 (updated 13 Jun 2005 at 21:27 UTC) »
GNOME for Scheme48

I've decided to laying the foundation for creating bindings of the GNOME software stack for Scheme48, specifically: create bindings for GLib/GObject.

At the core of GNOME, there is the GLib Object System (GObject), on top of which GTK+ and the rest of the developer platform are built. Thanks to the header scanning tool h2def.py, which creates a S-Expression representation of the API, you are able to create bindings for any GObject-based library, once you got the core bindings right.

I have a rough plan how to do this; basically I plan to fork guile-gnome and reuse the existing infrastructure (e.g. .defs processing). The Guile-GNOME fork will drive a G-Wrap that's capable of emitting code for the upcoming Scheme48 FFI. Work on G-Wrap/Scheme48 has already progressed to a degree where it's possible to turn to the GObject bindings and fill out the holes as needed in the process.

The plan is also to make the resulting bindings "mostly compatible", so that programs written for Guile-GNOME will also work with Scheme48-GNOME and vice versa. Since Scheme48 has no built-in object system, and the object system would have to be compatible with GOOPS (Guile's object system) anyway to achieve source-compatibility between the bindings, I started working on a GOOPS-compatible version of TinyCLOS.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!