david@twg.com (David S. Herron) (07/12/90)
[...For those who aren't already familiar with it...] Briefly speaking .. WINTERP (Widget INTERPretor) is a user interface language for windowing systems. It allows rapid prototyping, for application specific primitives to be built in C (or some other compiled language), and very importantly for end users to potentially have control over how the application is presented to them. All of this is good. A bad thing, arguably, is that at the moment it is Motif based. There's an awful lot of Mac's and IBM PeeCee's and Amiga's out there y'see. It would be nice to have the same sort of capability on those platforms. To build some specific application with winterp one builds some modules in C for running application specific data structures and OS interface. Then one builds the xlisp/winterp necessary to drive those data structures and the application. I don't think it would be necessary to have the exact same lisp on each platform. That might be too big a problem to chew comfortably. Instead what I envisioned in the shower this morning :-) is to repeat the same basic project of doing an interface between xlisp and the native windowing system on each platform. (or in the case of PeeCee's one might have to create a windowing system...) To port an application one would still have the back-end code already written and assumably portable enough that it would work across OSes. All that would have to be repeated is the lisp driving the front-end. Hopefully the lisp would be similar enough across window systems that the translation would be moderately easy. A closely related question: Suppose you really dislike the Motif widget set but still want to use X & winterp. It's just a matter of doing the widget class mappings for the other widget set, right? -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
peter@ficc.ferranti.com (Peter da Silva) (07/13/90)
Xlisp is a fairly sizable chunk to start building into window programs. How about something a little simpler... like Postscript? There is precedent, after all, and at least two sets of Postscript source code running around. Then there's John Ousterhout's TCL. We've already got it running as a shared library under AmigaOS. -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (07/20/90)
In article <C+M4_C2@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >Xlisp is a fairly sizable chunk to start building into window programs. I don't see David Betz's xlisp as being that sizeable a chunk, given the amount of functionality it gives. The xlisp binary used by winterp is not that big: -rwxr-xr-x 1 root other 159744 Jun 20 19:49 /usr/local/bin/xlisp (Especially when you compare it to the whopping size of X11/Xt/Motif) >How >about something a little simpler... like Postscript? There is precedent, >after all, and at least two sets of Postscript source code running around. I think the biggest problem in making NeWS acceptable was its use of postcript as the interpreter. Postscript is fine and dandy, a really neat language, etc. But it is a total pain in the ass to program in. Afterall, is SUN expecting developers to program in postscript or in tNt?? Lisp variants have shown themselves to be extremely successful customization languages, setting a much stronger precedent than postscript. A few successful lisp customizable systems off the top of my head: Gnu Emacs, Gosling Emacs, AutoCAD, Interleaf (??), The Interlisp-D programming environment, Symbolics programming environment, Personal Composer (or is it professional composer, i can't remember), etc. You want more than just a simple customization language -- anybody can write a simple customization language in N lines of code... I mean how hard is it to come up with a language that handles some assignment and control flow? Along with the customization language, some baggage needs to be incorporated in order to make the system useful and useable, eg. debugging support. Unless you like the tedium of making a customization and reloading/rerunning the program for each change, you'll probably want a language that supports interactive and incremental changes. And then there's symbol manipulation, datastructures, lists, arrays, strings, an object system, ... Oh yeah: whatabout memory management -- I'll be damned if I expect system customizers to want to worry about memory allocation and deallocation. You can easily come up with an arbitrarily minimal language that will force people to add/hack on the necessities. Why not use a language with proven clean semantics, a proven track record as a powerful customization and programming language. With lisp systems, you can go too far in forcing excess baggage to appear with the deliverable -- Common Lisp is afterall the excess baggage poster child. With WINTERP and Xlisp, I hoped to gain some of the features of a Lisp-customizable system but without the excess baggage, slow execution, and huge memory consumption that plagues Common Lisp. Scheme is more of a minimal system -- too minimal for my tastes. But I'd better stop before this turns into a language war... >Then there's John Ousterhout's TCL. We've already got it running as a shared >library under AmigaOS. TCL is certainly inrteresting, and smaller than XLISP. How does it fare against some of the criteria mentioned above? TCL's one big advantage is political -- everybody "out there" is a C programmer, so at least people will be working with a familiar syntax... When introducing new languages, there is the big problem that you can't teach old dogs new tricks.... But of course, you can get old dogs to roll over, play dead, and jump through arbitrarily hairy hoops by introducing brand new "languages" with familiar syntax but convoluted semantics -- just use those curly brackets, use semicolons as separators, and make sure the parentheses come after the function and they'll think they're using a C like language. (Note, this paragraph is not in reference to TCL -- at least TCL is a real language, unlike <censored>, which is the "language" i'm thinking about.) ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
oz@yunexus.yorku.ca (Ozan Yigit) (07/20/90)
In article <5626@hplabsz.HPL.HP.COM> mayer@hplabs.hp.com (Niels Mayer) writes: > Why not use a language with proven >clean semantics, a proven track record as a powerful customization and >programming language. I don't know about "proven track record", but if you want power and clean semantics, try Scheme. There are implementations smaller than xlisp. >Scheme is more of a >minimal system -- too minimal for my tastes. I am not sure what you mean by "too minimal": It can have as much baggage as you like to add :-). Kitchen-sinks are nothing new. There are implementations of the language ranging from 30K to 10megs. Take your pick. >But I'd better stop before this turns into a language war... Too late :-) :-) >TCL's one big advantage is political -- everybody "out there" is a C >programmer, so at least people will be working with a familiar syntax... TCL has no more "advantage" than anything else. People are quite ready to abandon whatever gadget they like today as soon as they find something they like better. The trick is to give them something they really like. [A converter would help too :-)] >... jump through arbitrarily hairy hoops by introducing >brand new "languages" with familiar syntax but convoluted semantics -- just >use those curly brackets, use semicolons as separators, ... >... at least >TCL is a real language, unlike <censored>, which is the "language" i'm >thinking about.) Oh uh... dive for cover, don your asbestos suit :-) :-) oz --- First learn your horn and all the theory. Internet: oz@nexus.yorku.ca Next develop a style. Then forget all that uucp: utzoo/utai!yunexus!oz and just play. Charlie Parker [?] York U. CCS: (416) 736 5257