Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!unido!tub!net
From: net@tub.UUCP (Oliver Laumann)
Newsgroups: comp.lang.scheme
Subject: Re: Standard low level X11 bindings for Scheme
Message-ID: <1429@tub.UUCP>
Date: 5 Jul 90 12:42:36 GMT
References: <9007040731.AA00830@vis.>
Reply-To: net@tub.UUCP (Oliver Laumann)
Organization: Technical University of Berlin, Germany
Lines: 82

In article <9007040731.AA00830@vis.> greg@vis.UUCP writes:
> X11 toolkits have been appearing in Scheme lately and and I have
> started to worry about compatibility.  So far I've seen bindings for
> X11 in cscheme 7.0, elk and c-to-scheme and I'm suspect there are
> several more.  I think that its very important to quickly settle on a
> set of standard low-level bindings, otherwise it will soon be
> impossible to port user interface code from one Scheme environment to
> another.

One problem I see here is that it will probably be hard to define an
easy to use set of bindings based on the Scheme standard, i.e. without
exploiting any of the non-standard features that most Scheme
implementations offer (such as macros).

(This is a problem which the Common Lisp community does not have to
face, since CL is such a "rich" language that existing implementations
probably only rarely offer any non-standard features.  But what do I
know -- I'm not a Lisp or Scheme expert.)

Since I don't have access to the Scheme implementations with X11 bindings
you mentioned (I only know CLX), let me give a brief overview over the
design of the low-level X11 bindings in Elk.

When I wrote the Xlib-interface for Elk, I used CLX as a model.
I have to admit, though, that I didn't take this decision with
portability in mind, but rather to avoid re-inventing the wheel.

In Elk, for most CLX functions and special forms there exists a Scheme
function (or special form or macro) with equivalent functionality.
However, the argument passing conventions frequently differ, since
Scheme doesn't have something like Common Lisp's keyword arguments.
For instance, in CLX one would write

   (let ((window (create-window :x 0 :y 0 :background black ...

and in Elk the equivalent expression is

   (let ((window (create-window 'x 0 'y 0 'background black ...

i.e. keyword arguments are simulated by symbol-value pairs (of course,
one could (define :x 'x) etc. to make it look like Common Lisp... :-).

In addition, since Scheme doesn't have "setf", I had to provide
equivalent "set-something!" functions in Scheme; thus the CLX expression

   (setf (drawable-width window) 100)

would read

   (set-drawable-width! window 100)

in Elk.  As a result, the Elk/Xlib-interface has to export gazillions of
"set-object-attribute!" functions.

One important characteristic of the Elk/X11 bindings is that the
underlying data types (such as window, graphics context, font, pixel,
colormap, cursor, etc.) are "full", opaque data types; they are
indistinguishable from the standard Scheme types like integer, vector,
function, etc.  The representation of a type (such as a window's
resource ID) is inaccessible to the user; objects of these types can
only be manipulated through their own sets of functions.

Each such type can register its own "termination function"; this
enables the garbage collector to properly close a window (or font,
display, etc.) when it becomes inaccessible.  For instance, when
evaluating

   (define window
      (create-window 'width 200 'height 100 'background white ...))
   (map-window window)
   (define window #f)

the newly created window would be removed from the screen next time
the garbage collector is run.

--

If you want to know more about the Elk/X11 bindings (or want to donate
a tape with C-Scheme 7.0 on it :-), send me a letter.

    Oliver Laumann, Technical University of Berlin, Germany.
    pyramid!tub!net   net@TUB.BITNET   net@tub.cs.tu-berlin.de