greg@vis.UUCP (07/04/90)
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. The c-to-scheme system from DEC Western Research Laboratory provides something particularly nice: a software tool, cdecl, which will parse the header files of C libraries and builds the Scheme structures necessary to link Scheme programs to that library. The mapping between procedure names and between C and Scheme data structures is standardized by this tool. It would be of great benefit to the Scheme community to port this tool as this will give Scheme programs access to the world of libraries and system interfaces available to C including X11. I'm interested to hear what people have to say about this issue, especially people in charge of Scheme implementations. I think that this is an urgent issue. _Greg J. Greg Davidson Virtual Infinity Systems +1 (619) 452-8059 6231 Branting St; San Diego, CA 92122 USA greg@vis.com ucbvax--| telesoft--| vis!greg@nosc.mil decvax--+---ucsd----+--vis vis!greg@ucsd.edu ihnp4--| nosc----|
net@tub.UUCP (Oliver Laumann) (07/05/90)
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