Tim Bradshaw <t...@tfeb.org> writes: > * Christopher R Barry wrote: > > sams...@panix.com writes: > > Zmacs, the editor of the Symbolics Lisp Machine, does not > > support TTY operation, and it's been around since the early 80s.
> I think it does actually.
How do you use it then? I can't find mention of TTY or terminal support anywhere in the Genera docs and if I telnet to the XL1201 and try to do :Select Activity Zmacs I just go into the debugger.
I'm pretty sure it doesn't, but the Zwei predecessor perhaps did. Zwei is no longer considered an editor nor actually still one itself though; It is now "a system on which other text editors are implemented."[1]
> How do you use it then? I can't find mention of TTY or terminal > support anywhere in the Genera docs and if I telnet to the XL1201 and > try to do :Select Activity Zmacs I just go into the debugger.
I forgot you had a machine to hand (:-). I was assuming that if you telnetted then it would work, but I guess it doesn't.
In article <rnbpv2v5ejh....@nortelnetworks.com>, Chris Ebenezer <chri...@nortelnetworks.com> wrote:
>thorn...@visi.com (David Thornley) writes: >: >Why use TK at all ? Once you are using scheme anyway there are nicer >: >widget toolkits to use (from a point of view of more "normal" looking >: >toolkits that don't suffer from color allocation problems), there are >: >bindings for guile and gtk and guile and Qt. >: > >: The attraction, to me, would be that Tk is a free, open-source >: graphics environment that will run on Unix with X-Windows, the >: Macintosh, and Microsoft Windows. CLIM is commercial, Garnet last
I haven't gotten any responses that indicate that there's anything besides Tk that meets the requirements I've specified: free (in some sense or another), open source (in some sense or another) and running on MacOS, Microsoft Windows and X Windows. Apparently Qt is free in a very restricted sense, and doesn't run on MacOS.
>Hi David,
>If you want something that is completely free (in the GNU sense) go to >http://www.gtk.org/, scroll down until you reach the bit on the sidebar >that reads "Language Bindings". You should be able to get guile-gtk >from there.
I'm willing to consider free in the GNU sense, but GTK claims to be for X under Unix. I didn't see anything about GTK for the Macintosh (yes, I have heard RMS discuss Apple Corporation) or Microsoft Windows, aside from a note from somebody porting it in his spare time. Given that I have limited spare time, I'm interested in a toolkit that I can use on the Mac without doing my own port first. (Besides, the impression I get from the discussion on the MS Windows port is that GTK was designed for X Windows and Unix, and is unnecessarily hard to port compared to a toolkit designed with a wider focus to begin with.)
It still looks like Tk is the best available graphics package for my purposes.
> I'm trying to collect a list of all the _current_ issues making tcl > a bad language choice...
Because it necessarily parses strings. Been there, done that, have the scars to prove it.
-- -russ nelson <rn-...@crynwr.com> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | Government schools are so 521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | can outdo them. Homeschool!
> > I'm trying to collect a list of all the _current_ issues making tcl > > a bad language choice...
> Because it necessarily parses strings. Been there, done that, have > the scars to prove it.
What do you mean by "necessarily parses strings" ?
-- Paul Duffin DT/6000 Development Email: pduf...@hursley.ibm.com IBM UK Laboratories Ltd., Hursley Park nr. Winchester Internal: 7-246880 International: +44 1962-816880
> > I'm trying to collect a list of all the _current_ issues making tcl > > a bad language choice...
> Well, the troll aside, I do have quite a lot of experience with Tcl. Among > other things, I've written a workflow system on the Macintosh for generating > technical book catalogs using a combination of a relational database (4th > Dimension), image processing applications (Photoshop, NIH Image), page > layout and database publishing software (FrameMaker MIF) and other apps. Tcl > was used extensively as glue for doing things like process control and > analyzing Encapsulated Postscript files. The Tcl I used is the one embedded > in Pete Keleher's Alpha text editor, which is a real joy to use. I wish we > had something like it on NT. I've also used standalone versions of Tcl with > and without Tk. I worked with it a lot from about 1992 - 1996, writing many > useful apps. I've kept an eye on the language since then, and while I'm no > longer very Tclish, I reckon my basic take is still valid.
> My opinions are, of course, shaped by the way I work. I lean towards > practical applications that one person can write and maintain and still have > a life. Most of the time I find myself practicing the Mad Max > post-apocalyptic school of programming, that is, cobbling together > interesting artifacts that come my way from both commercial and > non-commercial sources. I'm lazy -- I try to write only what I have to, and > then I look for the easiest tools to use to do it. I'm a businessman, so I'm > always balancing cost, productivity, and performance. I'm also aware that an > attractive solution may carry many hidden costs. I'm not going to get into > much academic hair-splitting here. For my purposes I judge language > environments by how easy it is to get things done in them, not by whether > they have a recursively bi-directed optimizing monkee gland compiler. YMMV.
> Since the late 60's I've done practical programming in over 60 languages, > from FORTRAN, TECO, and microcode to Java, Python, and *Lisp, with many fun > stops in between (pause for chest-thumping and vine-swinging ;>), which > either makes me experienced or a fossil, depending on your point of view. > That said, here's my take on Tcl.
> What I like:
> Very readable syntax. A great language for writing more or less > self-documenting "dumb" code that you can come back 6 months or a year later > and still understand and modify. This is hard to overemphasize: clever > things _will_ be forgotten!
> It's super when embedded in a text editor. Alpha is a great example.
> It's a very nice hackery language. You can just whack away at things until > they do what you want. You don't have to be feeling sharp and clever on days > when you use it.
> The language itself is pretty stable, that is, it doesn't usually crash in > bad ways.
> It's one of the better languages for text processing. Not as nice as Perl, > but pretty darn good. Good regexp support. Lots of easy and elegant string > munging built in.
> Support for lists, while not deep, is elegant and simple as far as it goes. > I don't like it when languages make list operations a big cumbersome deal, > so I appreciate Tcl's elegance here.
> Support for hash tables (associative arrays, whatever...) is also elegant.
> These three things: clean support for lists, hash tables, and regular > expressions are enough in themselves to make a language attractive. They > just make life much easier for a practical programmer.
> GUI support via Tk is nice. It's a bit ideosyncratic, but good for many > things. It's not shrinkwrap-quality stuff, but think of all the great > languages whose inexpensive implementations are crippled by having little, > if any, support for GUI (Perl until recently), produce GUIs that feel slow > and clunky (Java), or make it cumbersome (like the joys of COM/IDL).
> Wiser folk than I have said a good language should make doing simple things > simple. Tcl succeeds in this.
> Good support for file system ops.
> Straightforward interfaces to C etc. are a good thing.
> Intangible fun factor. Tcl puts you in a good mood. It's easy. You feel like > you're cheating. You concentrate on the problem domain. You still feel good > when you look at the code six months later.
> Now the cold slimy part:
> Tcl scales very badly. All the same things in Tcl that make simple things > simple make complex things hard. Tcl is broad and shallow (which is not > always a bad thing). List structure doesn't really scale. There is no OOP > support to speak of, and although various people have hacked quick and dirty > examples, it's not something you would really want to build on. The very > brainlessness of Tcl is part of its appeal, but this is part of the price. > This is a _procedural_ language, which is actually nice on days when you are > too fuzzed out to think like a computer professional. It's not CLOS or > Eiffel, folks. It's not even Java.
Actually since version 8.0 Tcl has scaled quite nicely thank you, 8.1 has reduced the scalability of string operations due to a naive implementation of Unicode / UTF8 support but that will be fixed soon.
> The cute hacks that make string munging kind of cool can also be confusing. > You tend to spend a fair amount of time (by Tcl standards) finding subtle > bugs in the way you expressed complex string concatenations and such. It's > not that the language is buggy in this regard. The rules are relatively > simple. But the subtleties are hard to keep in mind. Tcl makes string > processing so easy that you tend to quickly give yourself enough rope to > hang yourself with. Easy debugging takes some of the sting out.
> Tcl is slow. Oh, I know that's relative. For many applications it will be > fine. But complex parsing on large amounts of text can really drag. In one > application I needed to parse FrameMaker MIF files. These are SGML-like > ASCII files that often stretch to 600k or more, and which give FrameMaker a > lot of its power as a database publishing platform. Tcl was dog-slow. Perl > was about an order of magnitude faster than Tcl. C++ using the STL was a bit > faster than Perl, but still distressingly slow. I ended up using "cheating > C++", which is C++ with a lot of C standard library calls in it. The C was > about another order of magnitude faster than Perl. Tcl is great for nabbing > some text out of a file and doing some clever things with it (like nipping > the image size data out of an EPS file), but a cruncher it's not.
Tcl can be used to crunch stuff but you just have to be very careful how you go about doing it. I have written a Tcl program to analyse the whole Tcl source which is nearly 5MB and it did it very fast indeed.
> Perl can be much better for industrial-strength text processing. Perl has > better regexp handling than Tcl, in fact it's usually held up as the
Tcl 8.1 now has the same (bar a few weird hacks) regular expression package that Perl has.
> standard by which other regular expression packages are judged. Perl is much > faster than Tcl. Perl 5 has rudimentary OOP support, which is a lot better > than nothing and allows Perl to scale in ways Tcl can't. The comparisons
OOP support doesn't imply scalabity does it ?
> with Perl are important because Perl does a lot of the same things Tcl does > and more. For a long time the dilemma was that Perl was the better language, > but Tcl had a GUI. Now Perl has a Tk interface (I haven't used Tk from Perl, > so I can't vouch for its elegance). After a while, as I developed more > complex applications in the languages, I found myself abandoning Tcl in > favor of Perl because of the performance and scalability. Perl code lacks > the beautiful brainless stickiness of Tcl, though. Perl is a "clever" > language, with what many would describe as "line noise" syntax. Cleverness > is dreadful when you have to look at it six months later. Tcl is the glory > of "stupid" programming, which I lean towards whenever possible. But it will > drive you crazy the minute you need speed or want to encapsulate something.
It sounds as though you are being a bit unfair with Tcl. You seem to invest an awful lot of brainpower in Perl (not to deal with the problem but to deal with the language) but you don't spend any on Tcl because it is so simple. If you invested as much time learning how to program efficiently in Tcl as you do in Perl you would soon be able to match performance.
> Tcl, Perl, and Python all hold out the promise of transcending the speed > problem via extensions written in C or another compiler language. This is > fine as far as it goes, but in the real world it's often difficult to fully > encapsulate speed-critical bits in separate modules (this could be the topic > of a whole thread). It's also somewhat complicated. Tcl makes it as easy as > anybody, but by the time you are organizing your work to the point where > you're designing a full component architecture, you're probably going to > find yourself thinking about using high-level compiler languages that let > you keep it all under one roof.
> Tk ports are slow to arrive on some platforms and are buggy for a while. It > took years for heroic volunteers to get a workable Tk on the Mac. I think > Tcl helped show the way, but many of its enthusiasts have drifted away as > more alternatives have become available.
> If you want to grind text, why not use Perl? If you want a slow, essentially > free hacking language with all the features of Tcl and very good OOP > support, why not use Python? And if you want a faster "scripting" language > based on the "Boy in the Bubble"* architecture, with built-in GUI, much > wider support, and a religion, there's always the J-word.
-- Paul Duffin DT/6000 Development Email: pduf...@hursley.ibm.com IBM UK Laboratories Ltd., Hursley Park nr. Winchester Internal: 7-246880 International: +44 1962-816880
> Greg Ewing <greg.ew...@compaq.com> writes: > ... > | In my experience, I find that I can do with Python everything > | that Tcl was designed for, do it more easily, do a lot > | more besides, and have more fun in the process. I believe > | the reason for this is rooted in some fundamental design > | features of these languages, which I have sketched above. > | I think that's about as close as one can get to providing > | an objective argument as to whether one language is better > | than another for a given purpose.
Actually you find that you can do everything that YOU want to in Python and YOU find it easier than doing it in Tcl. I do not believe that you can do everything in Python that you can do in Tcl (at least as regards extending the language itself).
> How about Expect as an example? I don't mean to criticize the > existing Python Expect implementation(s), have no idea where the > state of the art is on that. I just remember trying to think of > a natural Python idiom that would replace the "expect" verb's case > switch flow of control.
> My experience is more or less the same as yours - rewrote Tcl > software in Python and was henceforth a convert. But I think > Tcl is syntactically more adaptable, where Python kind of makes > a virtue of its fixed ways.
Correct. With Tcl you can create new control structures which are indistinguishable from the built in ones, you cannot do that in Python. Python is much more rigid in its syntax although it does have a lot of nice hooks to allow objects to behave in different ways.
-- Paul Duffin DT/6000 Development Email: pduf...@hursley.ibm.com IBM UK Laboratories Ltd., Hursley Park nr. Winchester Internal: 7-246880 International: +44 1962-816880
Paul Duffin <pduf...@mailserver.hursley.ibm.com> writes:
...
> Correct. With Tcl you can create new control structures which > are indistinguishable from the built in ones, you cannot do > that in Python. Python is much more rigid in its syntax although > it does have a lot of nice hooks to allow objects to behave > in different ways.
But you can do that much more easily and elegantly in the L-word language :)
Cheers
-- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa
Marco Antoniotti <marc...@copernico.parades.rm.cnr.it> writes: > Paul Duffin <pduf...@mailserver.hursley.ibm.com> writes:
> ...
> > Correct. With Tcl you can create new control structures which > > are indistinguishable from the built in ones, you cannot do > > that in Python. Python is much more rigid in its syntax although > > it does have a lot of nice hooks to allow objects to behave > > in different ways.
> But you can do that much more easily and elegantly in the L-word > language :)
It can be done best in the Scheme, by means of the almighty call-with-current-continuation, the best of all control structures, and define-syntax on top of it.
> Actually you find that you can do everything that YOU want to > in Python and YOU find it easier than doing it in Tcl. I do not > believe that you can do everything in Python that you can do > in Tcl (at least as regards extending the language itself).
I meant that Python addresses all the major areas of application that Tcl's designer claims Tcl was designed for.
I don't regard extending Tcl as an "application" of Tcl -- it's just a means to an end. Python achieves many of the same ends as Tcl using different means.
> Marco Antoniotti <marc...@copernico.parades.rm.cnr.it> writes:
> > Paul Duffin <pduf...@mailserver.hursley.ibm.com> writes:
> > ...
> > > Correct. With Tcl you can create new control structures which > > > are indistinguishable from the built in ones, you cannot do > > > that in Python. Python is much more rigid in its syntax although > > > it does have a lot of nice hooks to allow objects to behave > > > in different ways.
> > But you can do that much more easily and elegantly in the L-word > > language :)
> It can be done best in the Scheme, by means of the almighty > call-with-current-continuation, the best of all control structures, > and define-syntax on top of it.
Both Tcl and Scheme can do it, "best" is subjective.
-- Paul Duffin DT/6000 Development Email: pduf...@hursley.ibm.com IBM UK Laboratories Ltd., Hursley Park nr. Winchester Internal: 7-246880 International: +44 1962-816880
Nope. *best* is the Common Lisp Macro system, with Scheme/Dylan syntax stuff a second best. The notion of 'upvar' in Tcl makes my head spin. :) Finally, AFAIU, a Tcl "macro" must run as an interpreter of the spec. A Common Lisp (Scheme) macro is compiled into regular code by read-time expansion.
Cheers
-- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa
In article <lw67471fyi....@copernico.parades.rm.cnr.it>, Marco Antoniotti <marc...@copernico.parades.rm.cnr.it> wrote: . . .
>spin. :) Finally, AFAIU, a Tcl "macro" must run as an interpreter of >the spec. A Common Lisp (Scheme) macro is compiled into regular code >by read-time expansion.
. . . Are you making a semantic point, or arguing on the basis of implementation-specific per- formance? If the latter, please be aware that the Tcl community is actively investi- gating dramatic speedups of [eval]. --
> In article <lw67471fyi....@copernico.parades.rm.cnr.it>, > Marco Antoniotti <marc...@copernico.parades.rm.cnr.it> wrote: > . > . > . > >spin. :) Finally, AFAIU, a Tcl "macro" must run as an interpreter of > >the spec. A Common Lisp (Scheme) macro is compiled into regular code > >by read-time expansion. > . > . > . > Are you making a semantic point, or arguing > on the basis of implementation-specific per- > formance?
It is (mostly) a semantic point.
> If the latter, please be aware > that the Tcl community is actively investi- > gating dramatic speedups of [eval].
I have no problems with that. But the following example is pretty hard to beat. :)
>Of course I could have defined a much more intricated macro.
. . . As it happens, there's very good work going on just now to beef up Tcl's introspective capabilities. Is *that*-- introspection--the real content of your preference? Incidentally, many of the same ideas and possibilities are available to Python, although I don't know of anyone actively pursuing them for Python. While Tim Peters im- presses me with, among much else, his ability to code clever little methods that tease all sorts of informa- tion from a Python interpreter, I occasionally argue that 'twould be worth the effort to do introspection for Py- thon in a more unified way. --
cla...@Starbase.NeoSoft.COM (Cameron Laird) writes: > >Of course I could have defined a much more intricated macro. > . > . > . > As it happens, there's very good work going on just now > to beef up Tcl's introspective capabilities. Is *that*-- > introspection--the real content of your preference?
Nope, you must correct me if I am wrong, but in Tcl, you set up a new 'form' by writing a "proc". This "proc" takes some Tcl 'list' (with strings as leaves) and produces another list (with strings as leaves).
When "proc" is used within some code, its code is executed at runtime. This is not what happens in Lisp, Scheme and Dylan, where macros are evaluated at read-time. This is pure code transformation, which when fed in the Common Lisp *compiler* produces inlined code.
Introspection is not something I was very interested in when making my point. I just wanted to point out that with Common Lisp (and Scheme, and Dylan) you get a native compiler.
If we want to talk about introspection, have you ever seen a Common Lisp inspector? It is based on a lot of "introspective" functions, which were present in Common Lisp in 1984, 15 years ago.
> Incidentally, many of the same ideas and possibilities > are available to Python, although I don't know of anyone > actively pursuing them for Python. While Tim Peters im- > presses me with, among much else, his ability to code > clever little methods that tease all sorts of informa- > tion from a Python interpreter, I occasionally argue that > 'twould be worth the effort to do introspection for Py- > thon in a more unified way.
As Common Lisp does? (sorry, I couldn't resist :) )
Cheers
-- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa
* Cameron Laird | | As it happens, there's very good work going on just now to beef up | Tcl's introspective capabilities. Is *that*-- introspection--the | real content of your preference?
I don't know exactly what Marco had in mind, but this is certainly not the main value of the Common Lisp macro facility. The main value lies in being able to extend the language seamlessly with no run-time costs.
Things like the while loop (which does not exist in CL), the Common Lisp Object System and programming by contract features can be built on top of the Lisp core using nothing but CL primitives. Personally, I dream of finding the time to toy with Aspect-Oriented programming in CL through extension macros.
I know tcl has a similar capability, but I'm unsure whether it is of comparable power and convenience.
[From your first posting in this sub-thread]
| Are you making a semantic point, or arguing on the basis of | implementation-specific performance?
Is there more than one implementation of tcl? If so, does any of them do macro expansions at compile-time? If not, I think arguments based on performance also carry considerable weight.
I doubt that you would disagree that C++ has better performance than does tcl. Given than CL achieves comparable performance to C++ a conclusion seems near at hand. :)
(BTW, I don't know if you're aware of this, but Dylan, which you wrote an excellent article on[1] is essentially Common Lisp bereft of one of its major features, the S-expression syntax.)
| Incidentally, many of the same ideas and possibilities are available | to Python, although I don't know of anyone actively pursuing them | for Python.
Actually, macros, performance and S-expressions are among the things I miss the most in Python. bytecodehacks, although certainly cool, are just a pale shadow of what CL macros provide.
As for introspection, Common Lisp has good support for that as well, although I very much doubt that that was Marco's point.
| [...] I occasionally argue that 'twould be worth the effort to do | introspection for Python in a more unified way.
'twould indeed, but I find other issues more pressing.
Marco Antoniotti <marc...@copernico.parades.rm.cnr.it> writes: > When "proc" is used within some code, its code is executed at > runtime. This is not what happens in Lisp, Scheme and Dylan, where > macros are evaluated at read-time. This is pure code transformation,
Only reader-macros are evaluated at read-time. Normal macros are evaluated at compile time. (I know Marco knows this, just to make sure those without CL knowledge aren't confused.).
> which when fed in the Common Lisp *compiler* produces inlined code.
What I find more interesting than the fact that you get inlined code, is the possibility that compile-time evaluation affords you: In effect macros (and compiler-macros) let you extend and use the normal CL compiler to do most of the dirty work for you in many situations. IMHO CL's macros are _the_ most important reason that makes CL so good at embedding domain-specific languages.
Take for example Harlequin's Common SQL, which embeds SQL in CL (without any ugly pre-processors, or other evil stuff, such as C needs):
This maps name over the tuples returned by the query and prints them. The important wrinkle: The query expression gets optimized and compiled as part of the normal CL compilation process. Here do-query is implemented as a macro, the special SQL-syntax using [] is implemented as reader-macros on [ (and ]).
Or take this silly macro definition (yes, this would need to pass around a tcl environment object and probably do a number of other things, but for simplicity):
(defun compile-tcl-to-lisp (exp) "Compiles a TCL expression in Lisp syntax into optimized Common Lisp code for run-time execution." ...)
Given this (and a suitably lispified TCL syntax, i.e. one which used sexps as basic units), I could now write embedded TCL in my CL programs, which would get compiled to optimized native code along with my normal code. And this works for any language for which you can dream up an apropriate sexp syntax. If done correctly, I can let the embedded language access and modify the normal CL environment.
And all of this is done at the level of CL itself, that is all of this can be written as portable ANSI Common Lisp code, without ever having to open up the implementation, or resort to things like C...
Regs, Pierre.
PS: Since I still think that this thread should never have been started, especially as a cross-posted one, I've changed the subject line and set a follow-up to comp.lang.lisp, where the possibilities of Common Lisp in this area can be suitably discussed. Anyone who disagrees with this judgement may of course ignore the F'up header...
-- Pierre Mai <p...@acm.org> PGP and GPG keys at your nearest Keyserver "One smaller motivation which, in part, stems from altruism is Microsoft- bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
* cla...@Starbase.NeoSoft.COM (Cameron Laird) | If the latter, please be aware that the Tcl community is actively | investi- gating dramatic speedups of [eval].
I used to say "those who do not know Lisp are doomed to reimplement it" and mean it humorously. maybe it's the truth and not funny at all. sigh.
#:Erik -- @1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
