Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!europa.eng.gtefsd.com!howland.reston.ans.net!EU.net!uunet!sytex!smcl
From: smcl@sytex.com (Scott McLoughlin)
Subject: Re: Scheme GUI support
Message-ID: <99gquc1w165w@sytex.com>
Sender: bbs@sytex.com
Organization: Sytex Access Ltd.
References: <thinmanCy7Avr.5vF@netcom.com>
Date: Tue, 25 Oct 1994 04:06:19 GMT
Lines: 92

thinman@netcom.com (Technically Sweet) writes:

> Attitude copped: X is a massive crock and I refuse to learn it.
> Just let me write graphics in the abstract.  An official Scheme graphics
> should be transparent across platforms.  It's also high time for
> one; students want to write programs like the ones they're used to.
> "Oh look, you can write a 70's style teletype interface!" doesn't
> cut it with someone who started on a Mac at age 10.
> 

Hear, hear! Well put (the part about students, that is).  Minus the
"copped attitude", I think that this is a serious issue:
(1) for the academic community to consider in selection/construction
of tools for pedagogical purposes
(2) for language implementers, researchers, and "promoters"
generally to consider.

It's sad, IMHO, because it can be alot of work to "tack on" GUI
facillities to one's latest and greatest language. Nevertheless,
the lack of such facillities can/do detract from an appreciation
of a new language and/or implementation.

In the DOS/Windows world, it is "trivial" to link call functions
compiled into .DLL's (shared libraries).  You just have to know
the name and expected types. See "Undocumented Windows" by
A. Schulman et. al. and a recent issue of "DOS/Windows
Developers Journal" for examples in both C and assembler. We do
this in our upcoming "LinkLisp" for Windows (plug deleted).

I believe Solaris has shared libraries. Does "Linux" ? I would
think that a little collection of "C" routines for various
machine/os combo's showing how to link shared libraries and
pass arguments from within an interpreter would go a long way
toward eliminating the headache caused by the explosion of
desirable (practically necessary) system level services
provided by now by popular operating systems/environments.

This basic functionality makes it easy to write "wrappers"
around services using basic data types (ints,strings,
doubles,booleans).  Complex data types require extra
facillities.  A simple set of "assembler" primitives for
reading/writing fields in a chunk of binary data (can you
say "Simple-String") can go a long way toward solving
this problem as well.  A macro and structure facillity
can provide a friendlier interface to these low level
primitives.

If the binary data is wrapped in a structure and the
structure primitives type check, then a degree of 
safety is achieved.

Finally, a simple facillity for registering individual
objects for "finalization", as in (finalize-register
object #'cleanup-fn) or whatever, can make manipulating
system resources even safer in an interpreter with
safety oriented ambitions.  In the absence of error,
the coded cleanup code and explicitly "unregister" the
object from the finalization system. Our system makes
it user selectable whether finalization is "automatic"
or under user control.

The problem of integrating "callback" functions,
"thunks", what have you is more trouble. We 
currently require "wrapper" code to be written in
C,Pascal, or any other language that can compile
a .DLL.  We hope to address this in a future version
of our system in a better way by cobling up machine
level "closures" on the fly.  In addition to an
"eval-string" type of interface for doing "callbackgs",
we also provide a simple "FUNCALL" type interface on
symbols that user Lisp programs can "export" to 
Lisp aware C libraries.  We find that this is handy
for "callbacks" that will be called many times in
rapid successesion (no reading/consing). For example,
one can track mouse movements with no noticable
degradation in UI responsiveness (depends on what
you want to _do_ when the mouse moves, of course).

Anyway, I hope this helps other implementers out there
get some sort of FFI/GUI working, even in relatively
"low impact" non-commercial language implementations.
A simple function call/data structure interface can
go a long way.  I would think that Unix, with its
more powerful process control, stream io and
preemptive multitasking features would make this
task _easier_, not harder. Good luck and happing
langauge hacking.

=============================================
Scott McLoughlin
Conscious Computing
=============================================
