Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!quiche!dean From: dean@cs.mcgill.ca (Dean NEWTON) Newsgroups: comp.graphics Subject: Re: Scene Description Standard Summary: Consider using Elk (Scheme) Message-ID: <1991May1.211220.29750@cs.mcgill.ca> Date: 1 May 91 21:12:20 GMT References: <1991Apr30.003612.16050@mks.com> <30137@rouge.usl.edu> Sender: news@cs.mcgill.ca (Netnews Administrator) Distribution: na Organization: SOCS, McGill University, Montreal, Canada Lines: 84 In article matt@mandala.think.com (Matt Fitzgibbon) writes: >In article <30137@rouge.usl.edu> msr@gator.cacs.usl.edu (Srinivas R. Manapragada) writes: > > Yes it would be nice to have a standard. However it should be more > expressive > and powerful than the language of say rayshade, which allows hierarchical > objects to be defined rather easily. However one should also have some > kind of procedural features. > >Rather than define another new language, has anyone explored using >Lisp or some subset as a geometric description language? > You may want to consider using scheme for this purpose. I have appended a brief description of the Elk (Extension Language Kit) scheme interpreter at the end of this message. Since scheme is a general-purpose interpreted language, embedding Elk into your system not only gives you a language for storing scenes, but you also get: -- an interpreted command language -- a cleaner (than the C binding) interface to Xlib/Xt/Motif -- an interpreter to Xlib/Xt/Motif In fact, this will completely eliminate the dichotomy between "scene description files" and "programs". Elk is available for anonymous ftp from export.lcs.mit.edu Enjoy, Kaveh Kardan Taarna Systems, Inc. Montreal Quebec Canada (posting from a friend's account) ---------------------------------------------------------------------------- Implementation: Elk Implemented by: Oliver Laumann Hardware: VAX, Sun-3, Sun-4, ISI 680x0, Intel 80386, Mips, IBM/RT, and others Operating Systems: UNIX/SunOS/Ultrix Price/Availability: Free. Available as source code through the usual sources archives and by e-mail from the author Intended Use: Primarily as a general extension language Elk (Extension Language Kit) is a Scheme interpreter intended to be used as a general extension language; it is also useful as a stand-alone implementation of Scheme. One purpose of the Elk project is to end the recent proliferation of mutually incompatible Lisp-like extension languages. Instead of inventing and implementing yet another extension language, application programmers can link the Scheme interpreter into their application in order to make it extensible and highly customizable. The Elk project was started in 1987 to support ISOTEXT, an ODA-based document system (a WYSIWYG editor) that is being developed at the Technical University of Berlin. Elk has been successfully demonstrated as the extension language kernel of ISOTEXT, e.g. at the Hanover Fair 1989. The Elk Scheme interpreter is R^3RS compatible (with some minor exceptions listed in a separate document); future releases will conform to the R^4RS and/or P1178 as soon as the respective standards become available. Non-standard features of the Scheme implementation include: o dynamic loading of object files o creation of an executable image from the running interpreter (``unexec'') o a macro facility o environments as first-class objects o dynamic-wind, fluid-let o autoloading, provide/require The Scheme interpreter can easily be extended by application-specific new types and primitive procedures. Such extensions are typically written in C or C++ and dynamically loaded into the running interpreter. The current release of Elk includes several such extensions, e.g. interfaces to the X11 Xlib and to the application programmer interface of the Xt intrinsics, and interfaces to the Athena, HP, and Motif widget sets.