Unix tower of babble tcl/awk/perl -- why not just lisp?
Aaron Watters
I've been toying with the idea of coming up to speed with
various hot trends in the unix world: tcl, perl, whatnot.
I'm finding this difficult because I'm an old lisp enthusiast and it
irks me to distraction that these peculiar little languages do neat
little tricks that could be easily accomplished in lisp -- without
having to learn a different syntax for each functionality, and without
the weird hobbled type system limitations, and with polymorphism
and macros etcetera etcetera etcetera....
Is there any *real* reason that a combination of GCL+CLX+GLUE+POSIX
hooks with some neat add-on packages couldn't replace all this gunk?
Maybe you can never get around the C-syntax chauvinism problem
but if the only other problem is program size or speed, can't we
expect the difficulty to go away as hardware cheapens?
Comments? -aaron
PS: I don't mean to detract from the accomplishments of the developers
of tcl, perl, and company -- congratulations guys, quite impressive
-- but do we really need a new language paradigm every time?
C. Titus Brown
Aaron Watters <aa...@funcity.njit.edu> wrote:
>
>I've been toying with the idea of coming up to speed with
>various hot trends in the unix world: tcl, perl, whatnot.
>
>I'm finding this difficult because I'm an old lisp enthusiast and it
>irks me to distraction that these peculiar little languages do neat
>little tricks that could be easily accomplished in lisp -- without
>having to learn a different syntax for each functionality, and without
>the weird hobbled type system limitations, and with polymorphism
>and macros etcetera etcetera etcetera....
LISP isn't ideal for everything, either; the reasons all of these languages
proliferate is because people like them and use them (sorry, that was
probably too obvious :). I've seen LISP, and I'm planning to delve into
it soon, but it can be a fairly annoying language to work with (from
reports, at least).
Competition is good :). If we all stuck with LISP-like languages, then
we'd have a pretty non-diverse set of languages...
>Is there any *real* reason that a combination of GCL+CLX+GLUE+POSIX
>hooks with some neat add-on packages couldn't replace all this gunk?
>Maybe you can never get around the C-syntax chauvinism problem
>but if the only other problem is program size or speed, can't we
>expect the difficulty to go away as hardware cheapens?
This is one reason I chose Tk/Tcl for my application; quick prototyping speed,
fast runtime, easy integration into speedy C (OK, I just threw the last in :).
While in the future computers may become fast enough, I really would like
to get something done *now*. 'sides, we can expect things to grow ever more
hoggy and slower as hardware gets faster... It's been the nature so far.
Cheers,
--titus
--
C. Titus Brown <- http://www.krl.caltech.edu/~brown/plan.html -> br...@reed.edu
--> GCS/GSS:@d--,-p+,c++++,l,u(++),e+,m+,s+/,n+,h+,f+,g+,w+,t-,r-,y? <--
Sysadmin at Caltech KRL / Guest sysadmin at Reed College
Member of the Avida Artificial Life research group
Jacob Hallen
>various hot trends in the unix world: tcl, perl, whatnot.
>
>I'm finding this difficult because I'm an old lisp enthusiast and it
>irks me to distraction that these peculiar little languages do neat
>little tricks that could be easily accomplished in lisp -- without
>having to learn a different syntax for each functionality, and without
>the weird hobbled type system limitations, and with polymorphism
>and macros etcetera etcetera etcetera....
There is (if I may say so (and I really hope I may)) a small disadvantage
(maybe not so small either (in fact rather large (not to say huge))) in the
usage of lisp (or scheme (or any other lookalikes)) that readbility is
rather low (very low (if you want my opinion)).
Jacob Hallen
Jonathan Badger
>Aaron Watters <aa...@funcity.njit.edu> wrote:
>>
>>I've been toying with the idea of coming up to speed with
>>various hot trends in the unix world: tcl, perl, whatnot.
>>
>>I'm finding this difficult because I'm an old lisp enthusiast and it
>>irks me to distraction that these peculiar little languages do neat
>>little tricks that could be easily accomplished in lisp -- without
>>having to learn a different syntax for each functionality, and without
>>the weird hobbled type system limitations, and with polymorphism
>>and macros etcetera etcetera etcetera....
Well, another reason is that LISP isn't very popular as a general purpose
language any more. Not that there aren't cases where it is still useful, but
the typical '90s programmer is much more comfortable with C and languages
which try to provide a C-like syntax such as awk, perl, and tcl.
Logan Shaw
> I'm finding this difficult because I'm an old lisp enthusiast and it
> irks me to distraction that these peculiar little languages do neat
> little tricks that could be easily accomplished in lisp
What does the "p" in "perl" stand for? "Practical". For the tasks it's
geared towards, perl is danged practical. It's in the Unix idiom, so those
familiar with Unix can learn to use it relatively easily. It lets you screw
around with text really easily. It's concise. It's efficient -- efficient
enough that you can generally use a decently written perl program without
frequently thinking "Maybe I should re-write this in C."
Perl is a tool. It's well suited for a particular task. Maybe it's
possible to do all that stuff in lisp, but all the convenient stuff like
formats, associative arrays, sockets, split(), join(), s/foo/bar/, `foo`,
dbmopen(), system(), and die() are already in perl. Is there a version of
lisp that has all the convenience features that perl already has? (Actually,
this is an honest question. If there is, it might be interesting.)
> -- without
> having to learn a different syntax for each functionality,
Agreed. This is annoying. It might be worth it, though.
> and without
> the weird hobbled type system limitations,
What limitations? Perl is really pretty good about not imposing arbitrary
limitations.
Adios,
Logan
--
The genius of France can be seen at a glance
And it's not in their fabled fashion scene
It's not that they're mean, or their wine, or cuisine
I refer of course to the guillotine
(the French knew how to lynch)
T-Bone Burnett, "I Can Explain Everything"
Michael Tiller
Good question. I find myself thinking this sometimes. Here is my
explanation...
1) Tcl is small
Common Lisp is *TOO HUGE*. Scheme might work and there have
been some people who have been fiddling with using it with Tk I
think.
2) I can auto-configure Tcl
I used to really enjoy hacking makefiles and such, but now I'm
too old or too busy to really enjoy. Give me a cool package that
configures itself any day.
3) I can build Tcl from scratch in ~5 minutes on anything
I can configure and build the entire Tcl/Tk system from scratch
on most machines in ~10 min, requiring only libX11.a and some header
files. I've built it on Suns (4.x and 5.x), SGIs, HPs and Crays
without a hitch.
Also, I don't need to get three packages from three people and
try to get them to like each other.
4) Tcl (at least to my knowledge) isn't picky about how big my "int"s
are. Several lisps I've seen are picky.
5) As much as I like the unambiguous nature of prefix-notation expressions,
I still can't bring myself to prefer (+ 5 (* 3 4)) over 5+3*4. This
is a biggy for me.
6) I like Tcl. It's simple.
People complain about Tcl's syntax. I didn't like it when I
first started toying with it, but I like it now. The reason I
like it now is that I find that there are a few simple and general
principles that it follows. Everything is handled in a kinda
universal fashion (like scripts being first class) which makes it
very powerful for me. I like the fact that I can write my own
control structions in TCL for example.
I've looked at perl a few times and I don't find it very easy
to understand. No flames please, I'm sure its great and maybe you
can make an argument that it is simple, but it seems to have an
awful lot of built-ins...more than I can keep track of. If I'm
wrong please enlighten me.
7) I'm familiar with Tcl.
I find this a loathsome reason to endorse something. I've
always prided myself on using the best tools available, no
excuses. However, when its neck-and-neck, I go with what I know.
I've got some complaints about Tcl, but they aren't anything major.
Lastly, doesn't Elk (a schemish thingy as I recall) do lots of what
Tcl/Tk do? I seem to recall building Elk once and asking the author
how I could embed Elk in something (or maybe the other way around,
embed something in Elk) and he said he didn't intend it to be used
this way. Tcl works great both ways (although I find it a little
tedious executing Tcl from withing a C program, but I'm probably just
doing it awkwardly).
Mike
Bill Janssen
Perl is a tool. It's well suited for a particular task. Maybe it's
possible to do all that stuff in lisp, but all the convenient stuff like
formats, associative arrays, sockets, split(), join(), s/foo/bar/, `foo`,
dbmopen(), system(), and die() are already in perl. Is there a version of
lisp that has all the convenience features that perl already has? (Actually,
this is an honest question. If there is, it might be interesting.)
ELK (scheme) comes close. It's mainly missing the regex string operators,
the last time I looked (and I don't remember the dbm library, either).
I'm using Python, which has all of the above, and a reasonable syntax to
boot. It also now has Tk, from the Tcl folk.
ELK: ftp://ftp.x.org/contrib/devel_tools/elk-2.2.README
Python: ftp://ftp.cwi.nl/pub/python/ (or see comp.lang.python)
Bill
--
Bill Janssen <jan...@parc.xerox.com> (415) 812-4763 FAX: (415) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
URL: ftp://parcftp.parc.xerox.com/pub/ilu/misc/janssen.html
William Paul Vrotney
>
> I've been toying with the idea of coming up to speed with
> various hot trends in the unix world: tcl, perl, whatnot.
>
> I'm finding this difficult because I'm an old lisp enthusiast and it
> irks me to distraction that these peculiar little languages do neat
> little tricks that could be easily accomplished in lisp -- without
> having to learn a different syntax for each functionality, and without
> the weird hobbled type system limitations, and with polymorphism
> and macros etcetera etcetera etcetera....
>
> Is there any *real* reason that a combination of GCL+CLX+GLUE+POSIX
> hooks with some neat add-on packages couldn't replace all this gunk?
I've suggested a Lisp shell idea in this newsgroup in the past and received
very little enthusiasm and one responder mentioned that someone has already
done something similar, can't remember who (perhaps it's in the FAQ by now).
The basic idea was to organize a Lisp (say Common Lisp) into levels, level
0, level 1 etc. where each level is composed of more abstract Lisp functions
that use the lower levels. Functions in levels above 0 would autoload when
invoked. Level 0 would be very primitive but more powerful in its control
language than say "csh". A Lisp shell, call it "lsh", then would be composed
of Level 0 and an OS package per OS. An alias system would allow brief
commands in the shell interpreter so that instead of entering the OS package
function
(os:set-default-directory "/usr/local/bin")
the user could specify the aliasing in his ".lsh" file so that he could
enter
cd /usr/local/bin
and it would expand correctly. Otherwise the shell interpreter would be a
(print (eval (read))) loop. Shell scripts then would be ordinary Lisp load
files which could also be compiled for faster execution.
A major problem with this idea is that people would be tempted to write
their programs in Lisp! SMILE.
--
Bill Vrotney - vro...@netcom.com
Oliver Laumann
> ELK (scheme) comes close. It's mainly missing the regex string operators,
> the last time I looked (and I don't remember the dbm library, either).
A minor correction:
Elk has a (dynamically loadable) GNU-dbm extension; it has been
contributed by Martin Stut at TU Muenchen. See the initial comment in
src/lib/misc/gdbm.c for a list of functions and types.
(You have to set `gdbm=yes' in the `site file' to compile the extension.
Then try `(load 'gdbmtest.scm)' from the Scheme top-level.)
David Pollen
Can anybody out there in Lisp Land tell us if Perl has any features not
easily implemented in Lisp? And if so what are they? I need to know
about this because I am going to be doing some Perl to Lisp translation
and I was also wondering about it for the reaons that people in this
thread have been and that is of course for the old "Why are people
inventing the new Language ________ (insert name here) when Lisp
can do all that stuff already?"
Thank you,
David Pollen
pol...@netcom.com
-------
In article <Ct09y...@taligent.com> lo...@taligent.com (Logan Shaw) writes:
Miles Bader
>There is (if I may say so (and I really hope I may)) a small disadvantage
>(maybe not so small either (in fact rather large (not to say huge))) in the
>usage of lisp (or scheme (or any other lookalikes)) that readbility is
>rather low (very low (if you want my opinion)).
Compared to _PERL_?!?!
-Miles
[tcl ain't so hot either, if you're doing more than simple sequences of
commands]
--
--
Miles Bader / mi...@eskimo.com / (206) 842-7219
I'd rather be consing.
Bill Birch
>various hot trends in the unix world: tcl, perl, whatnot.
>
>I'm finding this difficult because I'm an old lisp enthusiast and it
>irks me to distraction that these peculiar little languages do neat
>little tricks that could be easily accomplished in lisp -- without
>having to learn a different syntax for each functionality, and without
>the weird hobbled type system limitations, and with polymorphism
>and macros etcetera etcetera etcetera....
>
>Is there any *real* reason that a combination of GCL+CLX+GLUE+POSIX
>hooks with some neat add-on packages couldn't replace all this gunk?
>Maybe you can never get around the C-syntax chauvinism problem
>but if the only other problem is program size or speed, can't we
>expect the difficulty to go away as hardware cheapens?
>
>Comments? -aaron
>
Well perl was supposed to unify these little languages under one roof. But
you are right, it would be fun to have a Lisp dialect shell. I guess that
is why GNU emacs is very popular, because you can do quite a lot with
the elisp.
But seriously, the little languages are usually quite focussed tools,
often written many moons ago. Remember that in the past, UNIX programs
were much smaller than they are today. Some are very specialised for
handling data in particular formats and are not at all bad for what
they do.
Unfortunately in the UNIX world, there seems to be a mentality that
nothing can ever be thrown away. Which means we still get programs and
utilities which nobody wants to use, but everyone is too scared to
delete. It's about time vendors trashed everything above the kernel
level, and started again IMHO. (Yes that's right, no more "vi".)
The GWYDION project, based on Dylan, this may be interesting for you.
Bill
--
bi...@zikzak.apana.org.au Bill Birch on ZikZak (Melbourne, Australia)
{:-) A bas la loi Toubon! {:-)
David G. Boney
|> In article <1994Jul15....@njitgw.njit.edu>,
|> Aaron Watters <aa...@funcity.njit.edu> wrote:
|> >Comments? -aaron
|> >
|> Oldish UNIX programmer responds:
|> It's about time vendors trashed everything above the kernel
|> level, and started again IMHO. (Yes that's right, no more "vi".)
Hey, I use vi and like it ;-)
|> The GWYDION project, based on Dylan, this may be interesting for you.
|>
|>
|> Bill
|>
|>
|> --
|>
|> bi...@zikzak.apana.org.au Bill Birch on ZikZak (Melbourne, Australia)
|>
|> {:-) A bas la loi Toubon! {:-)
--
Sincerely,
David G. Boney AF&AM
American Heart Association Medical Student Research Fellow
Texas Tech School of Medicine
dbo...@cs.ttu.edu Texas Tech University
Ph. 806-742-1191 Department of Computer Science
Fax 806-742-3519 Lubbock, Tx. 79409 USA
Niels P. Mayer
In article <JANSSEN.94...@holmes.PARC.Xerox.Com> jan...@parc.xerox.com (Bill Janssen) writes:
ELK: ftp://ftp.x.org/contrib/devel_tools/elk-2.2.README
Python: ftp://ftp.cwi.nl/pub/python/ (or see comp.lang.python)
In article <Ct09y...@taligent.com> lo...@taligent.com (Logan Shaw) writes:
Perl is a tool. It's well suited for a particular task. Maybe it's
possible to do all that stuff in lisp, but all the convenient stuff like
formats, associative arrays, sockets, split(), join(), s/foo/bar/, `foo`,
dbmopen(), system(), and die() are already in perl.
--------------------
Check out WINTERP 2.0, which has properties similar to Elk, Tcl/Tk,
Python, but is particularly oriented to creating and running graphical UI
applications using an object interface to OSF/Motif and object-oriented
Xtango-based 2.5D graphics/animation. WINTERP 2.0 is based on XLISP-PLUS by
Betz/Almy/Tierney et al -- this is a small, fast, simple, and
easy-to-extend-in-C Lisp interpreter with a smalltalk-inspired object
system.
I too believe in using "the right tool for the job". So If I need the
functionality of Perl (or it's efficiency in blasting through large amounts
of text), I just go ahead and use it as a subprocess from WINTERP. One
particularly useful feature is WINTERP's asynchronous subprocess
facility. This allows you to write parts of the program more suited to
languages like Tcl, Python, Perl or Awk in those languages. Or create
GUI-wrappers to existing interactive unix programs or network services...
WINTERP is available via anonymous ftp from ftp.x.org:/contrib/devel_tools,
file winterp-2.XX.tar.gz (XX==02 currently). You may also retrieve WINTERP
via the WINTERP home page -- http://www.eit.com/software/winterp/winterp.html
------- Forwarded Message
WINTERP -- The OSF/Motif *W*idget *INTERP*reter
Niels Mayer
Enterprise Integration Technologies
800 El Camino Real, Fourth Floor
Menlo Park, CA 94025
e-mail: ma...@eit.com
URL: http://www.eit.com/people/mayer.html
WINTERP is the OSF/Motif *W*idget *INTERP*reter, an application development
environment enabling rapid prototyping of graphical user-interfaces (GUI)
through the interactive programmatic manipulation of user interface objects
and their attached actions. WINTERP is also an excellent platform for
delivering extensible or customizable applications. By embedding a small,
efficient Lisp interpreter with UI primitives within the delivered
application, users and system integrators can tailor the static and dynamic
layout of the UI, UI/application dialogue, and application functionality.
WINTERP is a good tool for learning and experimenting with the capabilities
of the OSF/Motif UI toolkit, allowing UI designers to more easily play
"what if" games with different interface styles. WINTERP's implementation
provides a compromise between the prototyping and extensibility advantages
of Lisp environments, and the inefficiency and expenses of delivering Unix
applications under environments such as Common Lisp. Typically, prototyping
and customization are done entirely in interpreted Lisp; for delivery,
efficiency-critical low-level code may be written in C and is easily
exported to the interpreter as a new primitive.
WINTERP was first made publicly available on the X11r4 "contrib"
distribution and new releases have appeared on the X11r5 and X11r6
distribution. The recent X11r6 release of WINTERP 2.0 significantly
improves on previous releases by providing a variety of developer tools and
libraries for increased productivity. Improved functionality is delivered
via object-oriented graphics and 2.5D animation, asynchronous subprocesses,
the XmGraph widget (for creating directed acyclic graphs, trees, and
direct-manipulation displays), the Table widget (GUI layout using
tbl(1)-style specifications), GIF support, etc.
WINTERP's interpreter is based on David Betz, Tom Almy, Luke Tierney et
al's XLISP-PLUS. The interpreter's Smalltalk-inspired object system enables
a truly object oriented interface to the X11 toolkit Intrinsics (Xt) and
the OSF/Motif widget set. WINTERP's use of a real programming language for
customization/prototyping allows WINTERP based applications to be much more
flexible than applications using lower-level and less-general languages
provided by the X resource database, Brunecky&Smythe's Widget Creation
Library (WCL), OSF/Motif's UIL (user interface language), and Ousterhout's
TCL/Tk. Furthermore, the use of object-orientation at a fundamental level
within the application UI code allows WINTERP-based applications to scale
more effectively than other languages.
WINTERP 2.0 features an object-oriented 2.5D graphics and animation
"widget" based on John Stasko's Xtango path transition paradigm. Both for
static and dynamic graphics, this high-level interface simplifies and
abstracts away much of the low-level drudgery required to create 2.5 D
graphics interfaces -- smooth, flicker free display updates occur as
complex nonrectangular graphical objects move around and obscure and
uncover each other. Animation composition operations allow multiple
individual shapes to all move "simultaneously" through sequences of
animation frames. The graphics are pixel-independent and easily resizeable,
scalable and zoomable. Each primitive graphics image class supports its own
set of class specific animation and movement methods, while some operations
(e.g. movement, fill, etc) are polymorphic. The following primitive objects
are supported:
* Line (w/ color, forward-arrow, backward-arrow, bidirectional-arrow,
thickness, and style options);
* Rectangle (w/ color, fill options);
* Circle (w/ color, fill options);
* Ellipse (w/ color, fill options);
* Polygon (w/ color, fill options);
* Polyline (w/ color, forward-arrow, backward-arrow, bidirectional-
arrow, line style, line-thickness options);
* Spline (w/ color, line-style and line-thickness options)
* Text (w/ font, color, and centering options)
* Bitmaps and Bitmap movies
* GIF images.
The primitive graphics classes may also be contained in a composite image
class, which provides a grouping and layering principle for new classes
presenting multiple images. Composite images allow the construction of
independent layers of animation objects which may be operated on in groups.
WINTERP's graphics capabilities enable simple game-style animation,
employing multiple layers of arbitrarily shaped objects. Furthermore,
application-specific interactive-graphics capabilities may be encapsulated
into a new Widget-Class. This significantly simplifies the creation and
integration of new graphics widgets into the system -- these special
widgets look like normal Motif widgets to the rest of the system.
To enable GUI-applications based on existing Unix facilities, WINTERP
provides primitives for collecting data from Unix processes, and facilities
for interacting with other Unix processes. These facilities make it
possible to glue together existing Unix functionality into a GUI based
application with a relatively small amount of WINTERP-Lisp "glue". WINTERP
2.0 features the ability to run multiple interactive, asynchronous Unix
subprocesses without blocking GUI interactivity. This feature is useful for
creating GUI interfaces to existing terminal-based programs, and can also
be used for connecting to interactive network services and databases.
An environment similar to WINTERP's already exists in the Gnu-Emacs text
editor -- WINTERP was strongly influenced by Gnu-Emacs's successful
design. In Gnu-Emacs, a mini-Lisp interpreter is used to extend the editor
to provide text-browser style interfaces to a number of Unix applications
(e.g. e-mail user agents, directory browsers, debuggers, etc.). Whereas
Emacs-Lisp enables the creation of new applications by tying together C
Implemented primitives operating on text-buffer UI objects, WINTERP-Lisp
ties together operations on graphical UI objects implemented by the Motif
widgets. Both achieve a high degree of customizability that is common for
systems implemented in Lisp, while still attaining the speed of execution
and (relatively) small size associated with C-implemented applications.
WINTERP features:
*** Free with non-restrictive copyright -- available via anonymous
ftp from ftp.x.org, directory contrib/devel_tools, file
winterp-2.XX.tar.gz.
*** Portable -- entirely implemented via machine independent C
source and X11/Xt/Motif libraries.
*** OSF/Motif widgets are real XLISP objects widgets can be specialized
via subclassing, methods added or altered, etc.
*** Automatic storage management (via garbage collection) of Motif/Xt/X
data, animation and graphics data, and application resources.
*** Contains facilities for simple "direct manipulation" of UI
components.
*** Interface to Gnu Emacs's lisp-mode allows code to be developed and
tested without leaving the editor.
*** Interactive programing also available in the "WINTERP Control Panel",
with editing taking place in a Motif text widget controlled by
WINTERP.
*** Built-in RPC mechanism for inter-application communications,
implemented via serverized, event-driven Lisp interpreter.
*** XmGraph widget for creating directed acyclic graphs, trees, and
direct-manipulation displays.
*** Table widget allows constraint-based GUI static layout
using tbl(1)-style specifications.
--------------------
An old paper on WINTERP version 1.X may may be obtained via
World-Wide-Web/Mosaic:
WINTERP paper from Motif '91, First Annual Intl. Motif Users
Meeting (postscript) (226756 bytes):
ftp://www.eit.com/pub/winterp/doc/papers/winterp.PS
Screen Dump, page 3 (postscript) (157936 bytes):
ftp://www.eit.com/pub/winterp/doc/papers/page3.PS
Hybrid Application Architecture Diagram, page 3 (postscript)
(16505 bytes):
ftp://www.eit.com/pub/winterp/doc/papers/arch.PS
Diagram of RPC Architecture, page 10 (postscript) (16686 bytes):
ftp://www.eit.com/pub/winterp/doc/papers/RPC-Arch.PS
Screen Dump, page 25 (postscript) (145444 bytes):
ftp://www.eit.com/pub/winterp/doc/papers/page25.PS
Screen Dump, page 26 (postscript) (135663 bytes):
ftp://www.eit.com/pub/winterp/doc/papers/page26.PS
--------------------
Further information on WINTERP may be obtained via World-Wide-Web/Mosaic:
The WINTERP Home Page:
http://www.eit.com/software/winterp/winterp.html
WINTERP 2.0 documentation (plain-text) (652268 bytes):
ftp://www.eit.com/pub/winterp/doc/winterp.doc
XLISP-PLUS documentation (plain-text) (211733 bytes):
ftp://www.eit.com/pub/winterp/doc/xlisp.doc
Xtango Path Transition Animation (postscript) (588746 bytes):
ftp://www.eit.com/pub/winterp/doc/xtangodoc.ps
EIT's WINTERP-based World-Wide-Web Multimedia Authoring Environment:
http://www.eit.com/papers/gpware94/paper.html
--------------------
References on WINTERP, and its components:
David Michael Betz. "XLISP: An Object-oriented Lisp (version 2.1)"
Unpublished documentation accompanying the public release of Xlisp
software. David Michael Betz, P.O. Box 144, Peterborough, NH 03458,
April, 1989.
Olaf Heimburger. "Elche Im Winter -- Interaktive X-Applicationbuilder
unter Lisp -- Elk und WINTERP." iX, July 1991, pp 64-68.
Niels P. Mayer, Allan W. Shepherd and Allan J. Kuchinsky. "Winterp:
An object-oriented, rapid prototyping, development and delivery
environment for building extensible applications with the OSF/Motif
UI Toolkit." In Proceedings Xhibition '90, X Window System and Open
Systems Technical Conference, San Jose, CA, May 1990, pp 49-64.
Niels P. Mayer, Allan W. Shepherd and Allan J. Kuchinsky. The
WINTERP Widget INTERPreter -- An Application Prototyping and
Extension Environment for OSF/Motif. In Proceedings X Into The Future,
The European X Users Group Autumn Conference 1990, Surrey, UK,
September 1990, pp. 33-55.
Niels P. Mayer. The WINTERP Widget INTERPreter -- A Lisp Prototyping
and Extension Environment for OSF/Motif-based Applications and
User-Interfaces. Lisp Pointers, ACM SIGPLAN, Volume IV, Number 1,
pp 45-60.
Niels P. Mayer. The WINTERP OSF/Motif Widget INTERPreter -- A
graphical user-interface language for rapid prototyping and
delivering extensible applications. In Proceedings Motif '91,
First Annual International Motif Users Meeting, Washington DC,
December 1991, pp. 248-269.
John T. Stasko. The Path-Transition Paradigm: A Practical Methodology
for Adding Animation to Program Interfaces. Journal of Visual
Languages and Computing. (date, volume, page, publisher info unknown).
Don Libes. Expect: Curing Those Uncontrollable Fits of Interaction,
Proceedings of the Summer 1990 USENIX Conference, Anaheim, CA, June
11-15, 1990.
Papers describing applications written using WINTERP:
Allan Shepherd, Niels Mayer, and Allan Kuchinsky. STRUDEL: An
Extensible Electronic Conversation Toolkit. In David Marca and
Geoffrey Bock, editors, GROUPWARE: Software for Computer-Supported
Cooperative Work, IEEE Computer Society Press, 1992, pp. 505-518.
(originally, in proceedings Conference on Computer-Supported
Cooperative Work, Los Angeles, October 1990, pp. 93-104.)
Jay Glicksman, Glenn Kramer, and Niels Mayer. "Internet Publishing via
the World Wide Web". In proceedings Groupware '94, August 1994. San
Jose, CA.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
= Niels Mayer ..... ma...@eit.com .... http://www.eit.com/people/mayer.html =
= Multimedia Engineering Collaboration Environment (MM authoring for WWW) =
= Enterprise Integration Technologies, 459 Hamilton Ave, Palo Alto CA 94301 =
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
------- End of Forwarded Message
Lawrence G. Mayka
1) Tcl is small
Common Lisp is *TOO HUGE*. Scheme might work and there have
been some people who have been fiddling with using it with Tk I
think.
The delivery tools available for commercial Common Lisp
implementations can much improve the footprint situation. Among
free-of-charge implementations, CLISP's full runtime and image add up
to scarcely more than a megabyte. And as others have suggested, other
(smaller) choices in the Lisp family, such as WINTERP, may be
appropriate in some situations.
4) Tcl (at least to my knowledge) isn't picky about how big my "int"s
are. Several lisps I've seen are picky.
Of course, the standard Common Lisp INTEGER class has no practical
upper bound. Unless, perhaps, you're referring to the source code
itself (of a free-of-charge CL implementation).
5) As much as I like the unambiguous nature of prefix-notation expressions,
I still can't bring myself to prefer (+ 5 (* 3 4)) over 5+3*4. This
is a biggy for me.
Perhaps I don't do as much heavily numerical programming as other
people; but as I see it, C statements and expressions like 'if',
'for', 'switch', and 'putchar(c)' are using prefix notation just as
Lisp does, except that Lisp's syntax is much more regular and more
amenable to programmatic manipulation.
6) I like Tcl. It's simple.
People complain about Tcl's syntax. I didn't like it when I
first started toying with it, but I like it now. The reason I
like it now is that I find that there are a few simple and general
principles that it follows. Everything is handled in a kinda
universal fashion (like scripts being first class) which makes it
very powerful for me. I like the fact that I can write my own
control structions in TCL for example.
If only everyone were as open-minded about syntax as you are.
--
Lawrence G. Mayka
AT&T Bell Laboratories
l...@ieain.att.com
Standard disclaimer.
Lawrence G. Mayka
I've suggested a Lisp shell idea in this newsgroup in the past and received
very little enthusiasm and one responder mentioned that someone has already
done something similar, can't remember who (perhaps it's in the FAQ by now).
The basic idea was to organize a Lisp (say Common Lisp) into levels, level
0, level 1 etc. where each level is composed of more abstract Lisp functions
that use the lower levels. Functions in levels above 0 would autoload when
invoked. Level 0 would be very primitive but more powerful in its control
language than say "csh". A Lisp shell, call it "lsh", then would be composed
of Level 0 and an OS package per OS. An alias system would allow brief
commands in the shell interpreter so that instead of entering the OS package
function
(os:set-default-directory "/usr/local/bin")
the user could specify the aliasing in his ".lsh" file so that he could
enter
cd /usr/local/bin
and it would expand correctly. Otherwise the shell interpreter would be a
(print (eval (read))) loop. Shell scripts then would be ordinary Lisp load
files which could also be compiled for faster execution.
- Division of an industrial-strength Lisp into multiple levels is one
of the goals of Eulisp, I think.
- An alternative to your "Lisp shell" idea is a command processor such
as is offered by CLIM. CLIM's command processor will take
parenthesized Lisp expressions (if you want it to), but its ordinary
syntax is more like ordinary English commands. Typing can be very
terse due to automatic command completion, but without the need to
memorize a sea of cryptic and unpronounceable 2- and 3-letter
combinations. Helpful but unintrusive feedback, such as prompts and
menus for command arguments, is provided or available at every step.
The suggested response is typically the last one of that type
previously input. All in all, it has about everything you could want
from a command-line interface--plus automatic generation, if you wish,
of corresponding gadget-based dialogs for those who prefer that style.
Christophe Muller
> 6) I like Tcl. It's simple.
I find this a *major* reason explaining the success of Tcl, and not just the
Tk toolkit. Tcl programs are easy to read (unlike C), easy to change, easy to
reuse by somebody else. Furthermore, Tcl is now becoming almost as mainstream
as C (Perl also) and so more and more people will be able to "understand" Tcl.
It's not that I consider Lisp syntax to be unclear. Personally, I like it a
lot, and find it very elegant; but most of the people I work with hate it..
and this is what counts! I can get them to learn Tcl, or Shell, but not Lisp.
Somebody posted a message asking to "liberate" Tk so that it can be used in
other languages, (which is almost the case anyway: Scheme, Perl, Python, Wool,
etc..) but the only question is Why? If you program in Perl or Scheme, etc..
of course you should be able to access Tk's features, but I would certainly
not abandon Tcl. It has its own advantages compared to the others and the
simplicity/popularity that makes it -IMHO- more interesting (same reason
probably of a great success of "Basic" in other places..).
Cheers,
Christophe.
= How many Bell Labs Vice Presidents does it take to change a light bulb? =
= That's proprietary information. Answer available from AT&T on payment =
= of license fee (binary only). Of course, this license applies only if =
= you have AT&T light bulbs; if you have someone elses light bulbs then =
= you have to pay both their license fee and ours. =
Barry Margolin
>Can anybody out there in Lisp Land tell us if Perl has any features not
>easily implemented in Lisp?
How "easily implemented" does it have to be? The only Lisp I'm familiar
with that has a regular expression facility built-in is GNU Emacs Lisp.
And Perl's regexp's are a little different from Emacs's. Perl also
optimizes multiple regular expression comparisons against the same string
(i.e. when you have an if/then/elsif/elsif/.../else sequence it compiles
this into a single match that classifies the string and determines which is
the first matching branch).
I love Lisp, but I have to admit that for the kinds of things I use Perl
for, it's damned convenient. $str = `foo bar baz` is much more concise
than
(with-open-stream (str (run-unix-program "foo" :arguments '("bar" "baz")
:output :stream))
(let ((result "")
(newline (make-array 1 :element-type 'character
:initial-element #\newline)))
(loop
(multiple-value-bind (line eof-p) (read-line str nil nil)
(when line
(setq result (concatenate 'str result temp-str
(if eof-p "" newline))))
(when (or (null line) eof-p)
(return result))))))
Of course, I could easily write a function that does this. The point of
Perl (and Tcl, Python, and even sed and awk) is that all these convenience
operators for scripting, regular expression handling and simple output
parsing are already provided.
--
Barry Margolin
System Manager, Thinking Machines Corp.
bar...@think.com {uunet,harvard}!think!barmar
Paul Alexander
|> In article <306qsm$g...@ef2007.efhd.ford.com> til...@solace.me.uiuc.edu (Michael Tiller) writes:
|>
|> > 6) I like Tcl. It's simple.
|>
|> I find this a *major* reason explaining the success of Tcl, and not just the
|> Tk toolkit. Tcl programs are easy to read (unlike C), easy to change, easy to
|> reuse by somebody else. Furthermore, Tcl is now becoming almost as mainstream
|> as C (Perl also) and so more and more people will be able to "understand" Tcl.
|>
|> It's not that I consider Lisp syntax to be unclear. Personally, I like it a
|> lot, and find it very elegant; but most of the people I work with hate it..
|> and this is what counts! I can get them to learn Tcl, or Shell, but not Lisp.
|>
|> Somebody posted a message asking to "liberate" Tk so that it can be used in
|> other languages, (which is almost the case anyway: Scheme, Perl, Python, Wool,
|> etc..) but the only question is Why? If you program in Perl or Scheme, etc..
|> of course you should be able to access Tk's features, but I would certainly
|> not abandon Tcl. It has its own advantages compared to the others and the
|> simplicity/popularity that makes it -IMHO- more interesting (same reason
|> probably of a great success of "Basic" in other places..).
|>
|> Cheers,
|> Christophe.
|>
(physical scientists doing image and data processing) like to have both a
command-line interface as well as an X interface to the same application.
Tcl allows me to create a user-friendly command interface which is used
simultaneously with the X interface; this would not be viable if tcl was
not basically shell-like; in fact naive users don't really know that they
aren't just using the shell as the commands have a simple UNIX-like syntax
which is encouraged by Tcl's design. In fact I did extend things a bit to
make it a really user-friendly environment by adding the ability to have
minimal-matched long command (e.g. this-is-a-long-command can be matched by
th-i-a-l-c etc.) --- this was achieved by a fairly trivial modification to
thge unknown procedure and about 30 lines of tcl. No doubt other languages
have advantages for coding of Tk applications but if you want J. Bloggs to
write some code or use a user-interface tcl would be my first choice.
Paul Alexander
Department of Physics, University of Cambridge, Cambridge, UK.
Tom Tromey
[ deletia regarding simplicitly of Tcl ]
Christophe> I find this a *major* reason explaining the success of
Christophe> Tcl, and not just the Tk toolkit. Tcl programs are easy to
Christophe> read (unlike C), easy to change, easy to reuse by somebody
Christophe> else. Furthermore, Tcl is now becoming almost as
Christophe> mainstream as C (Perl also) and so more and more people
Christophe> will be able to "understand" Tcl.
I don't think readability is a property of the Tcl language. I've
generally found readability to be linked to the original programmer's
skill, and to my own familiarity with the language. You can write
unreadable code in any langauge, and code in a language you don't know
is always unreadable.
I also don't think that Tcl and Perl are as mainstream as C.
Christophe> It's not that I consider Lisp syntax to be
Christophe> unclear. Personally, I like it a lot, and find it very
Christophe> elegant; but most of the people I work with hate it.. and
Christophe> this is what counts! I can get them to learn Tcl, or
Christophe> Shell, but not Lisp.
There seems to be a fixation on syntax in this thread. I don't see
what the big deal with syntax is. Generally it is the model of the
language that is important. You can change the syntax of many
languages by just using some sort of macro preprocessor -- surely
we've all seen C programs that look like Pascal because of the (silly)
use of macros like:
#define BEGIN {
#define END }
etc.
I think one reason that Tcl is more popular as an extension language
than say Scheme is that Tcl is closer to the familiar C programming
model.
Tom
--
tro...@cns.caltech.edu
"In a riddle whose answer is chess, what is the only prohibited word?"
I thought a moment and replied, "The word chess".
-- Jorge Luis Borges
Aaron Sherman
>>>>> On 17 Jul 1994, bi...@zikzak.apana.org.au (Bill Birch) said:
Bill> In article <1994Jul15....@njitgw.njit.edu>,
Bill> Aaron Watters <aa...@funcity.njit.edu> wrote:
Bill> Unfortunately in the UNIX world, there seems to be a mentality
Bill> that nothing can ever be thrown away. Which means we still get
Bill> programs and utilities which nobody wants to use, but everyone
Bill> is too scared to delete. It's about time vendors trashed
Bill> everything above the kernel level, and started again IMHO. (Yes
Bill> that's right, no more "vi".)
This seems to be the usual response to any conflict between existing
systems, "throw it all out we'll just write another one".
I have a few questions to pose on this point, though:
1. What's wrong with od? fsck? rm? cat? (well, cat has too
many dang arguments...)
2. Why wouldn't you throw out the kernel?
3. What do you propose to replace it all/why is it any better?
4. Will you throw out what you come up with when it conflicts
with someone else's idea?
5. What makes you think that anyone would use it?
6. Who's going to do all of the training?
I think that any UNIX vendor is going to have to ask 3-6. 1-2 are just
practicality questions. In reality, these are the kinds of things that
Microsoft is realizing in trying to convert UNIX people to NT.
-AJS
--
Aaron Sherman I-Kinetics, Inc.
Systems Engineer "Open Systems Stepstones"
Voice: (617)661-8181 (x230) 19 Bishop Allen Dr.
Fax: (617)661-8625 Cambridge, MA 02139
Pager: (508)545-0584 ashe...@i-kinetics.com
Key fingerprint = 62 6A 5E EB 6B 2A 46 48 3D 06 01 79 66 A2 87 0C
Mark S. Riggle
In article <Ct1M7...@eskimo.com>, mi...@eskimo.com (Miles Bader) writes:
|> In article <307cdd$g...@nyheter.chalmers.se>, Jacob Hallen <ja...@cd.chalmers.se> wrote:
|> >There is (if I may say so (and I really hope I may)) a small disadvantage
|> >(maybe not so small either (in fact rather large (not to say huge))) in the
|> >usage of lisp (or scheme (or any other lookalikes)) that readbility is
|> >rather low (very low (if you want my opinion)).
|>
|> Compared to _PERL_?!?!
|>
Come on, Perl is just about the only language that remains
as readable under ROT_13 as before.
--
=========================================================
Mark Riggle | "Give me LAMBDA or
sas...@unx.sas.com | give me death"
SAS Institute Inc., |
SAS Campus Drive, Cary, NC, 27513 |
(919) 677-8000 |
Michael Tiller
|>
|> In article <306qsm$g...@ef2007.efhd.ford.com> til...@solace.me.uiuc.edu (Michael Tiller) writes:
|>
|> 1) Tcl is small
|>
|> Common Lisp is *TOO HUGE*. Scheme might work and there have
|> been some people who have been fiddling with using it with Tk I
|> think.
|>
|> The delivery tools available for commercial Common Lisp
|> implementations can much improve the footprint situation. Among
|> free-of-charge implementations, CLISP's full runtime and image add up
|> to scarcely more than a megabyte. And as others have suggested, other
|> (smaller) choices in the Lisp family, such as WINTERP, may be
|> appropriate in some situations.
Well, I went out and got the clisp binaries from gatekeeper.dec.com.
4.5Mb is not scarcely a megabyte. Now I don't know whats needed you
might be able to trim it, but I wouldn't know what I can trim (and
shouldn't need to). In addition, the text mentions says...
"CLISP is mostly CLtL1 compliant, with some CLtL2 additions, including a
CLOS subset. Many features of CLtL2 or dpANS CL are currently not supported."
My remarks were about Common Lisp. This is only a subset of Common
Lisp (and it is still pretty big).
|>
|> 4) Tcl (at least to my knowledge) isn't picky about how big my "int"s
|> are. Several lisps I've seen are picky.
|>
|> Of course, the standard Common Lisp INTEGER class has no practical
|> upper bound. Unless, perhaps, you're referring to the source code
|> itself (of a free-of-charge CL implementation).
I was talking about the source code itself.
|>
|> 5) As much as I like the unambiguous nature of prefix-notation expressions,
|> I still can't bring myself to prefer (+ 5 (* 3 4)) over 5+3*4. This
|> is a biggy for me.
|>
|> Perhaps I don't do as much heavily numerical programming as other
|> people; but as I see it, C statements and expressions like 'if',
|> 'for', 'switch', and 'putchar(c)' are using prefix notation just as
|> Lisp does, except that Lisp's syntax is much more regular and more
|> amenable to programmatic manipulation.
I was talking about *expressions*. In C, "if" is part of an
expression (although I realize in Lisp it is). In C you still use
5+3*4 to calculate 17. Agreed, C syntax is ugly and irregular.
However, the discussion was Lisp vs. TCL.
|>
|> 6) I like Tcl. It's simple.
|>
|> People complain about Tcl's syntax. I didn't like it when I
|> first started toying with it, but I like it now. The reason I
|> like it now is that I find that there are a few simple and general
|> principles that it follows. Everything is handled in a kinda
|> universal fashion (like scripts being first class) which makes it
|> very powerful for me. I like the fact that I can write my own
|> control structions in TCL for example.
|>
|> If only everyone were as open-minded about syntax as you are.
I'm not sure if this is meant as sarcasm :-)
|> --
|> Lawrence G. Mayka
|> AT&T Bell Laboratories
|> l...@ieain.att.com
|>
|> Standard disclaimer.
Remember, I was only responding to why some people prefer TCL to Lisp
or Perl or whatever. I'm not going to argue which language is
technically superior...lisp would probably win. I've used lisp and I
like it, but that isn't what we are discussing...We are discussing why
lots of people like TCL, which is a purely subjective topic.
Michael Tiller
University of Illinois
(til...@solace.me.uiuc.edu)
Wittenberger
Is it really worth to take so much bandwith for that thread?
LISP will never serve all requirements. No language will ever do.
But consider the question "Why does all these people invent all these
languages?" The answer is simple: It's the natural way to solve
decriptive problems. Evereybody who describes something complex goes
on to invent a problem-oriented language. So you better ask why we
should damm that for computer-languages?
LISP is very good for programming close to some theorie. But doesn't
check the syntax (except for the balanced "()").
Moreover LISP is interpreted --> relativ slow. That will never go away
when hardware gets cheaper. Cause than someone will write somthing
more complex with a full or half-compiled system. This srew never ends.
So we better select the best language for a particular problem.
The only importend thing in this sence is:
All these languages reinvent the wheel.
They all share some constucts (like if) with the same semantic and
give them a little different syntax. So everybody new to a particular
language have to learn a lot redundant stuff. (Moreover the users of
the languages get involved in religious wars about the (non-existent)
one and only true syntax, refer to all the "python is not C"-statments
in c.l.python for instance.)
But the only one answer to that I have (and it's not supposed to be
the best you can find) is to invent more and more languages wich are
as similar to eachother as possible and program with them. The best
would be to invent a language wich give you both: the freedom to
invent a new syntax (like LISP, FORTH etc.) and the power to enforce
this new syntax by the interpreter/compiler (like the EBNF-described
languages).
--
-----------------------------------------------------------------------------
Joerg Wittenberger
Rietzstr. 32b
01139 Dresden
Germany
email: j...@ibch50.inf.tu-dresden.de
j...@mail.inf.tu-dresden.de
WWW: <a href=http://www.inf.tu-dresden.de:8002/people/jw6/top.html>jerry</a>
PGP PUBLIC KEY: available on request or by finger
Shannon Hendrix
: Unfortunately in the UNIX world, there seems to be a mentality that
: nothing can ever be thrown away. Which means we still get programs and
: utilities which nobody wants to use, but everyone is too scared to
: delete. It's about time vendors trashed everything above the kernel
: level, and started again IMHO. (Yes that's right, no more "vi".)
But then, sometimes those programs are simply the best way of doing
things. What exactly would you replace awk with? For what it is good
at, nothing else is better. I don't use it because I'm afraid to delte
it. I use it because it's often the #1 tool for the job at hand.
No more vi? Why? It and Emacs are two of the most powerful editors
ever written. I've yet to see anything new that offered much beyond
being easier to learn. In addition, none of the new ones have the power
of something like vi. I almost lose my mind trying to use some editor
like Borland's IDE stuff or some other so-called programmers editor.
Your idea of cutting off above the kernel is good in a way and I wouldn't
mind seeing it happen. However, some tools cannot be improved upon.
They are simply great just how they are.
Finally, what tools would replace all the functions necessary on a UNIX
system? What shell would you suggest replace Bourne for the kernel?
What editor to replace vi? How can we replace:
#!/bin/nawk -f
/^SECTION/ {
print "#define",$2,section++ > "catalog.h"
}
/^ENTRY/ {
print "#define",$2,entry++ > "catalog.h"
}
???????????????? IMO, nothing could replace the above and be better
in any way. It's just so simple and perfect. It does *EXACTLY* what
I want and nothing more.
Anyway, I sometimes get frustrated by all the extra baggage of UNIX but
at the same time I cringe when I see some new OS that just doesn't have
any decent tools available for it and those that do come out are
binary-only proprietary stuff where each system's tools are different
from any other. At least with this old-clunky UNIX stuff I can write
things that I know will run on all the other systems I use. If I get
a tool for OS/2 I have absolutely no idea wether or not I'll find the
same thing for Windows NT or, God forbid, the Macintosh. Unless of
course I port over some of those old UNIX programs! :-)
: The GWYDION project, based on Dylan, this may be interesting for you.
What's that?
: Bill
: --
: bi...@zikzak.apana.org.au Bill Birch on ZikZak (Melbourne, Australia)
: {:-) A bas la loi Toubon! {:-)
--
csh
---------------------------------------------------------------------------
shen...@escape.widomaker.com (UUCP) | Amd486/40 Linux system
shen...@pcs.cnu.edu (Internet) | Christopher Newport University
Lawrence G. Mayka
Well, I went out and got the clisp binaries from gatekeeper.dec.com.
4.5Mb is not scarcely a megabyte. Now I don't know whats needed you
might be able to trim it, but I wouldn't know what I can trim (and
shouldn't need to). In addition, the text mentions says...
The original source of CLISP, 'ma2s2.mathematik.uni-karlsruhe.de', has
images prebuilt for popular platforms. The two files necessary for
execution, "lisp.run" and "lispinit.mem", total about 1.2 MB on
Solaris 2.3. I think the rest of the distribution is only necessary
for those who want to rebuild CLISP themselves, examine the source,
etc.
"CLISP is mostly CLtL1 compliant, with some CLtL2 additions, including a
CLOS subset. Many features of CLtL2 or dpANS CL are currently not supported."
My remarks were about Common Lisp. This is only a subset of Common
Lisp (and it is still pretty big).
Yes, CLISP doesn't support all of ANSI Common Lisp yet. The most
obvious omission appears to be the extended LOOP macro (which,
fortunately, is available elsewhere as a free-of-charge add-on). But
as far as image size is concerned, the missing constructs shouldn't
add much bulk percentagewise.
I'm not sure if this is meant as sarcasm :-)
No, not at all. Your willingness to learn new syntax shows more
open-mindedness than so many others appear able to muster.
Lawrence G. Mayka
How "easily implemented" does it have to be? The only Lisp I'm familiar
with that has a regular expression facility built-in is GNU Emacs Lisp.
Lisp systems that contain an embedded Emacs editor certainly have this
capability, but it unfortunately is not typically made conveniently
available to programmers. And the publicly available 'match' facility
is too verbose for most people's taste.
I love Lisp, but I have to admit that for the kinds of things I use Perl
for, it's damned convenient. $str = `foo bar baz` is much more concise
than
(with-open-stream (str (run-unix-program "foo" :arguments '("bar" "baz")
:output :stream))
(let ((result "")
(newline (make-array 1 :element-type 'character
:initial-element #\newline)))
(loop
(multiple-value-bind (line eof-p) (read-line str nil nil)
(when line
(setq result (concatenate 'str result temp-str
(if eof-p "" newline))))
(when (or (null line) eof-p)
(return result))))))
I myself would write
(string-trim '(#\Newline #\Space #\Tab)
(with-output-to-string (*standard-output*)
(foreign:call-system-showing-output "foo bar baz"
:prefix ""
:show-cmd nil)))
on LispWorks.
But I agree that we could use a de-facto-standard library of
shell-like capabilities such as this one.
Of course, I could easily write a function that does this. The point of
Perl (and Tcl, Python, and even sed and awk) is that all these convenience
operators for scripting, regular expression handling and simple output
parsing are already provided.
I think the original question that started this thread was, "Why did
people go to the trouble of designing a whole new language for these
operations when it would have been so much easier to just graft them
into Lisp?" Perhaps part of the answer is simply, "Because they
didn't know about CLISP."
Lawrence G. Mayka
Is it really worth to take so much bandwith for that thread?
We'll stop soon. :-)
But consider the question "Why does all these people invent all these
languages?" The answer is simple: It's the natural way to solve
decriptive problems. Evereybody who describes something complex goes
on to invent a problem-oriented language. So you better ask why we
should damm that for computer-languages?
The Lisp community's argument is that it's much easier to write a
problem-oriented language on top of Lisp--incrementally as you need it
and integrated smoothly with the base language and other
problem-oriented languages--rather than to design and implement it
from scratch, totally divorced from the base language and all the
other problem-oriented languages people have written.
Moreover LISP is interpreted --> relativ slow. That will never go away
when hardware gets cheaper. Cause than someone will write somthing
more complex with a full or half-compiled system. This srew never ends.
Correction: Commercial Common Lisp systems compile to machine code.
One can optimize time-critical code legs by adding (optional) type
declarations.
Needless to say, a commercial Common Lisp compiler generally enforces
the language's compile-time rules on a program, otherwise the compiler
could not generate correct machine code for that program. (A run-time
rule such as "don't call a function that hasn't been defined" can only
be enforced at run time via the condition system, although most CL
compilers will print some kind of information message if a referenced
function has not yet been defined.)