Why is tcl broken?
Fernando Mato Mira
I'm trying to collect a list of all the _current_ issues making tcl
a bad language choice. I'd like concrete examples, and not just
vague assertions that cannot be put porward honestly. I think
that as is usual in this newsgroups, there's going to be people that
actually know what they are talking about (and even better, experienced)
when referring to a language that is not their favorite.
If you have references to articles of the sort, that will be useful,
too.
Note that I've not listed comp.lang.tcl for increased productivity,
and to avoid starting a flame war. Hopefully some misconceptions
will be filtered down here, and _then_, the summary can be presented
in that newsgroup for their defense.
Thanks in advance,
Laurent POINTAL
On Thu, 10 Jun 1999 11:17:59 +0200, Fernando Mato Mira
<mato...@iname.com> wrote:
for Python vs Tcl
>: If you have references to articles of the sort, that will be useful,
>: too.
See http://www.cwi.nl/~sjoerd/PythonVsTcl.html
I remeber having seen an article of a guy explaining why he switched
from Tcl to Python for a large project... but I loose the URL.
A+
Laurent.
---
Laurent POINTAL - CNRS/LURE - Service Informatique Experiences
Tel/fax: 01 64 46 82 80 / 01 64 46 41 48
email : poi...@lure.u-psud.fr ou lpoi...@planete.net
Cameron Laird
>
> I'm trying to collect a list of all the _current_ issues making tcl
>a bad language choice. I'd like concrete examples, and not just
.
.
I don't entirely understand your intent. <URL:http://
starbase.neosoft.com/~claird/comp.lang.tcl/fmm.html>
details confusions that persistently arise in use of
Tcl. Perhaps that will serve you.
Please give a concrete example of a concrete example.
Commitment to PalmOS for your deliverable is one of
the first issues that comes to my mind; in that case,
Tcl is "a bad language choice", because it's not cur-
rently available for PalmOS. Is that the sort of
thing you have in mind?
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 281 996 8546 FAX
Ian Wild
> I'm trying to collect a list of all the _current_ issues making tcl
> a bad language choice. I'd like concrete examples,
Without knowing what you're choosing it FOR, how
can anyone legitimately say it's a bad choice?
For some problem domains it might well be ideal.
(I mean, it's theoretically possible that, in some
parallel universe, there's a even problem for which
C++ is the ideal choice.)
> Note that I've not listed comp.lang.tcl for increased productivity,
> and to avoid starting a flame war.
Yeah - right. And no Tcl users ever read here?
Fernando Mato Mira
> Fernando Mato Mira wrote:
>
> > I'm trying to collect a list of all the _current_ issues making tcl
> > a bad language choice. I'd like concrete examples,
>
> Without knowing what you're choosing it FOR, how
> can anyone legitimately say it's a bad choice?
Choosing for nothing in particular. It's mainly
a language design question (syntax/semantics).
Although if there're other kinds of problems when
trying to use it in the realm it was designed for, that
would also be interesting.
> > Note that I've not listed comp.lang.tcl for increased productivity,
> > and to avoid starting a flame war.
>
> Yeah - right. And no Tcl users ever read here?
Obviously not. The idea was avoid the usual `Why does XYZ suck' flame
bait on comp.lang.XYZ as far as possible, and not irritate and waste XYZ
users' time on issues that some ABC user will point out as false.
There's some tcl lawyer close to me. That's why I did not ask about
the advantages. But nobody knows everything, so in order to make answers
easier to catalogue, I suggest starting another one, "Why is tcl better"
for that.
Thank you for your help,
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
Paul Duffin
>
> Hello,
>
> I'm trying to collect a list of all the _current_ issues making tcl
> vague assertions that cannot be put porward honestly. I think
> that as is usual in this newsgroups, there's going to be people that
> actually know what they are talking about (and even better, experienced)
>
> when referring to a language that is not their favorite.
> too.
> will be filtered down here, and _then_, the summary can be presented
> in that newsgroup for their defense.
>
I will start by saying that your choice of title and opening statement
was bad and certainly not conducive to a reasoned debate about the
pros and cons of Tcl.
What you are going to end up with from this sort of article is a list of
outdated problems from people who have not touched it for years, plus
a lot of myths and possibly mingled with a few nuggets of useful
information.
Whether the choice of language is a good or bad idea depends entirely on
the context. i.e. environment and job to be done.
You cannot avoid taking into account the context even if you only look
at the language from a semantic / syntactic view point.
--
Paul Duffin
DT/6000 Development Email: pdu...@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880 International: +44 1962-816880
Lars Marius Garshol
* Fernando Mato Mira
|
| I'm trying to collect a list of all the _current_ issues making tcl
| a bad language choice.
You can find three interesting articles on this at
<URL: http://itrc.uwaterloo.ca/~papresco/tcl/>
--Lars M.
Fernando Mato Mira
Paul Duffin wrote:
> Whether the choice of language is a good or bad idea depends entirely on
> the context. i.e. environment and job to be done.
>
> You cannot avoid taking into account the context even if you only look
> at the language from a semantic / syntactic view point.
OK. Let's drop the word `choice'. Why do people think tcl is a bad
language then, strictly from a _design_ viewpoint? Let's assume
imperative languages are OK (responses like "it's not declarative"
are obvious and uninteresting and do not help comparing it to other
imperative languages).
Fernando Mato Mira
Lars Marius Garshol wrote:
Thanks. But the Sah article is not accessible,
and his homepage makes no reference to it.
Regarding the Stallman article, it's a quite vague,
and it's not sure one can extrapolate from their TECO experience
to Tcl.
About the Connoly one, the namespace issue seems to
be solved by [incr Tcl]. But what about that "interpreted
multiple times"? Is it just an efficiency issue, or a semantic
nightmare (maybe both)?
What about dynamic scoping?
BTW, I just found:
http://www.vanderburg.org/~glv/Tcl/war/
http://www.vanderburg.org/~glv/Tcl/war2/
Cameron Laird
.
.
>About the Connoly one, the namespace issue seems to
>be solved by [incr Tcl]. But what about that "interpreted
>multiple times"? Is it just an efficiency issue, or a semantic
>nightmare (maybe both)?
.
.
It's a different, but no less defensible, choice for
quoting rules than the one LISP made.
Michael P. Reilly
: Hello,
: I'm trying to collect a list of all the _current_ issues making tcl
: a bad language choice. I'd like concrete examples, and not just
: vague assertions that cannot be put porward honestly. I think
: that as is usual in this newsgroups, there's going to be people that
: actually know what they are talking about (and even better, experienced)
: when referring to a language that is not their favorite.
: If you have references to articles of the sort, that will be useful,
: too.
: Note that I've not listed comp.lang.tcl for increased productivity,
: and to avoid starting a flame war. Hopefully some misconceptions
: will be filtered down here, and _then_, the summary can be presented
: in that newsgroup for their defense.
I won't go into too many details, it was on an older version of Tcl.
But some years ago, I played around with making C library wrappers
(before SWIG was around) so the developers could write Tcl test scripts
for their libraries.
The problem was that null bytes ('\000') we frequently used in the
code, and Tcl (at the time) could not handle null bytes. I abandoned
the proof-of-concept project for that reason. I did have a little
following of developers who were looking forward to that functionality
tho.
I believe that current releases of Tcl can handle null bytes, but I
have not verified that.
In general, the lack of complex data structures is what I find to be
most troublesome in the Tcl language itself. Beyond lists and
associative arrays (hashes), you have numbers and strings. The
language makes it convenient to pack these (split, join, etc.), but not
always to utilize them (array names, etc.). And evaluation is
sometimes difficult to deal with as part of the language.
But for its problem set, I find Tcl to be flexible, quick and easily
extensible (in C or Tcl).
-Arcege
Bob Techentin
and a byte-code compiler for years.
If you want "current" issues, you might just read comp.lang.tcl, or the
"frequently made mistakes" available from the FAQs at
http://www.tclfaq.wservice.com/tcl-faq/ You'll find complaints about
commenting out blocks of code and accidental conversions to octal.
Fernando Mato Mira wrote:
>
> Lars Marius Garshol wrote:
>
> > * Fernando Mato Mira
> > |
> > | I'm trying to collect a list of all the _current_ issues making tcl
> > | a bad language choice.
> >
> > You can find three interesting articles on this at
> >
> > <URL: http://itrc.uwaterloo.ca/~papresco/tcl/>
>
[snip]
>
> http://www.vanderburg.org/~glv/Tcl/war/
> http://www.vanderburg.org/~glv/Tcl/war2/
--
Bob Techentin techenti...@mayo.edu
Mayo Foundation (507) 284-2702
Rochester MN, 55905 USA http://www.mayo.edu/sppdg/sppdg_home_page.html
Cameron Laird
Michael P. Reilly <arc...@shore.net> wrote:
.
.
.
>I believe that current releases of Tcl can handle null bytes, but I
>have not verified that.
.
.
Fernando Mato Mira
Bob Techentin wrote:
> These flame wars are more than five years old. Tcl has had namespaces
> and a byte-code compiler for years.
I know that. But I see some serious things there (the `call by name' issue,
for example) that give me the impression must be still around unless
the semantics have gone through a major change.
I would cut this thread right here before someone comes up
with some myth. There's enough work for debunkers there.
Thanks,
Paul Duffin
>
> Lars Marius Garshol wrote:
>
> > * Fernando Mato Mira
> > |
> > | I'm trying to collect a list of all the _current_ issues making tcl
> > | a bad language choice.
> >
> > You can find three interesting articles on this at
> >
> > <URL: http://itrc.uwaterloo.ca/~papresco/tcl/>
>
> and his homepage makes no reference to it.
>
> Regarding the Stallman article, it's a quite vague,
> and it's not sure one can extrapolate from their TECO experience
> to Tcl.
>
> be solved by [incr Tcl]. But what about that "interpreted
> multiple times"? Is it just an efficiency issue, or a semantic
> nightmare (maybe both)?
>
>
Dynamic scoping I assume describes the mechanism that Tcl uses
to pass references through to procedures, namely that the calling
procedure passes the name of the variable and the called procedure
creates a link from its stack frame back to the calling procedures
stack frame.
If this is the case then it is just not a problem, unless you use
it badly which of course could be said of just about any programming
construct from "goto" to "multiple inheritance".
Obviously some built in support for passing references would be nice
but the BIG advantage that Tcl has over just about every other language
apart from Lisp is its ability to morph itself (which of course can
also be abused) so it is possible to do this in Tcl itself.
> BTW, I just found:
>
> http://www.vanderburg.org/~glv/Tcl/war/
> http://www.vanderburg.org/~glv/Tcl/war2/
As with most of these articles they are out of date and the authors
tend to have (although not all) an agenda of their own which REQUIRES
that they prove Tcl (or whatever language they are 'analysing') is
"bad".
Take for instance the Connolly article.
"Tcl has one great big huge namespace"
8.0 introduced support for namespaces
"Tcl code is interpreted multiple times during the execution of
a program. There is no intermediate form as in Python and Perl"
8.0 introduced a byte compiler
The Stallman article written in 1994 is also way out of date and
adversely affected by his agenda.
Also considering his complaints about Tcl's syntax I was amazed to find
that he chose Lisp because if you replace the '() with {} and replace
all other () with newlines you end up with a Tcl program (almost).
Paul Duffin
Tcl does not have 'call by name' semantics.
In fact its calling semantics are remarkably like C's.
C only supports call by value
Tcl only supports call by value
In C if you want to pass a "reference" you pass a pointer
In Tcl if you want to pass a "reference" you pass a variable name
"Call by name" has some very particular characteristics the main one
being that you cannot implement "swap". I can assure you that you can
write a swap function in Tcl.
proc swap {&a &b} {
upvar ${&a} a
upvar ${&b} b
set t $a
set a $b
set b $t
Paul Duffin
Obviously I don't it has a few holes in it and some things could be
improved but I don't consider it a "bad" language.
Paul Duffin
>
> In article <mtU73.2731$nn.8...@news.shore.net>,
> Michael P. Reilly <arc...@shore.net> wrote:
> .
> .
> .
> >I believe that current releases of Tcl can handle null bytes, but I
> >have not verified that.
> Yes. Tcl8.0 and after handle null bytes.
> .
> .
> .
Although 8.0 did/does have some holes in its null byte support.
Fernando Mato Mira
Paul Duffin wrote:
> In Tcl if you want to pass a "reference" you pass a variable name
I was refering to this, hence the quotes.
Paul Duffin
Then I can assure you that "dynamic scoping" is not a problem.
Hartmann Schaffer
Paul Duffin <pdu...@mailserver.hursley.ibm.com> writes:
> ...
> "Call by name" has some very particular characteristics the main one
This is news to me. Afair, "call-by-name" was the term for the Algol60
style parameter mechanism, which essentially required each argument
passed by a parameterless function returning a pointer to the passed
value. Parameter swapping (and a few pretty usually pointless tricks
like "Jensen's device"(?)) were quite possible.
> ...
Hartmann Schaffer
Fernando Mato Mira
Cameron Laird wrote:
> www.sunworld.com/swol-11-1998/swol-11-regex.html>. I
> wish the Guile folk well, and certainly RSM and others
> continue to invest energy in it. From my distant ob-
> servation post, it doesn't feel as though it has the
> critical mass of resources necessary to "take off".
Maybe I'm dreaming, but I have the impression we've just passed the global
minimum in the Lisp usage history. With guile as a unification theme, suddenly
it becomes
very interesting to learn scheme, as a lot of folks end up using one or another
GNU tool. As a side effect, some newcomers to Tk that would have normally used
tcl could end up going the STk way
(unfortunately, STk is not publicized enough). Things like Kawa also increase
the feel of security regarding code reusability.
And some of those people will end up wanting to write full-fledged applications
"with parenthesis".
But it's probably more the fact that Java hype has quieted down, which make me
hopeful sooner than expected (although not in the same league, the fact that
surprises
_can_ happen, like the Linux/NT "battle for the enterprise" arriving so fast, is
reassuring).
> OK, that's too coy. I recognize that *I* wanted him
> to have asked that, but he definitely didn't do so.
Well, a hot headline in a classic press trick to attract readers.
Also, the premise was that _I_ believe that it's philosophically broken,
and I wanted to find out whether the disgust for tcl I've seen many people
express had some basis on some generally accepted principles.
[For example, I can think the Eiffel syntax is `philosophically' broken, but
as `infix' syntaxes go, it is not. And it's a good language (I programmed
in it for 2 years (years ago).. But just because I didn't have a CL compiler
then, and I wanted to do OO :-> )].
Fernando Mato Mira
Fernando Mato Mira wrote:
> [For example, I can think the Eiffel syntax is `philosophically' broken, but
> as `infix' syntaxes go, it is not. And it's a good language (I programmed
Actually, it's a _great_ language to learn SE (for OO pretty much too, but of
course only in the restricted
single-dispatch way most people know about. I like to call that "Subject Oriented").
Smalltalk taught me OO.
Occam taught me about concurrency.
Eiffel taught me SE.
CLOS taught me what OO really means.
--
"Object Oriented is to not think only about your `subject' and forget about your
`arguments' - the syntactic objects of your sentence"
Peter
<mato...@iname.com> wrote:
> Smalltalk taught me OO.
> Occam taught me about concurrency.
> Eiffel taught me SE.
> CLOS taught me what OO really means.
If you are a fan of CLOS, you might want to check out the Dylan
programming language.
It is basically a thoroughly modernized descendant of Lisp/CLOS with an
infix instead of prefix syntax. In Dylan, almost everything is an object
including the primitive data types (such as integers). Methods and
classes are also first class objects.
--------------------------------------------------------------------
p h i n e l y @hawaii.edu
Dylan... the high-performance dynamic language
* open-source Unix version: http://www.gwydiondylan.org/
* free Win32 version: http://www.harlequin.com/products/ads/dylan/
---------------------------------------------------------------------
Fernando Mato Mira
Peter wrote:
> If you are a fan of CLOS, you might want to check out the Dylan
> programming language.
>
> It is basically a thoroughly modernized descendant of Lisp/CLOS with an
> infix instead of prefix syntax. In Dylan, almost everything is an object
Although Dylan never really made it into "Fernando's elegibility list"
because
it was not a serious contender against Scheme and CL yet, it definitely got
banished the day the Lisp syntax was dropped. I'm still waiting for the day
when the Dylan fans will reinstate the alternative.
But my dream is a `parenthesized Cecil'
http://www.cs.washington.edu/research/projects/cecil/
or "all you wanted in CLOS (and more) since you got `corrupted' by Eiffel"
;-)
--
Fernando D. Mato Mira
> [For example, I can think the Eiffel syntax is `philosophically' broken, but
> as `infix' syntaxes go, it is not. And it's a good language (I programmed
Correction. There's one thing broken. The Subject Oriented syntax, but as Eiffel
was started in '85, I guess that is understandable.
Ada 95 got this one right. Unfortunately, the semantics qualify as `multiply
broken' regarding this issue:
1. They thought about multiple dispatch, and they broke it on purpose.
2. If you specialize on more than one parameter, it should be the same type
specifier
for all of them, i.e. only applicable to predicates, copying, arithmetic and
things like that,
not useful most of the times one wants several specializers.
3. Worse of all, instead of just adopting a left-to-right precedence rule, one that
looks very
ugly was added, increasing the complexity of a document that is already big
enough.
In '95, at VRAI we refocused our application from AI-oriented to (soft) real-time.
I grabbed the 9X specs, and the initial excitement turned to dissapointment (the
prototype was in CLOS). Moving would have not only meant losing a lot in
flexibility, but, worse of all, we would move only from being third-class to
second-class citizens (SGI platform).
And I would have rather dedicate the extra effort to CL. So after a little
successful experience, and given
the simpler requirements, we went with C++.
Needless to say, the project became a death march. You don't go with C++ unless you
can afford paying 5-10 times more for a lot less functionality.
Andreas Bogk
> Although Dylan never really made it into "Fernando's elegibility list"
> because
> it was not a serious contender against Scheme and CL yet, it definitely got
> banished the day the Lisp syntax was dropped. I'm still waiting for the day
> when the Dylan fans will reinstate the alternative.
This is an age-old flamewar. It just so happens that there are people
who like infix syntax and detest prefix, and then there are people who
love their parens and hate infix.
It's a matter of preferences, I happen to like infix, and I'm not
gonna change.
> But my dream is a `parenthesized Cecil'
You're obviously one of THEM :-).
Andreas
--
Reality is two's complement. See:
ftp://ftp.netcom.com/pub/hb/hbaker/hakmem/hacks.html#item154
Fernando Mato Mira
> This is an age-old flamewar. It just so happens that there are people
> who like infix syntax and detest prefix, and then there are people who
> love their parens and hate infix.
I have no idea what flamewars have been going on in comp.lang.dylan,
as it's the first time I set foot here, so FWIW, here's what I think:
1. The Dylan case is different. It was supposed to have 2 syntaxes.
2. I was not excited about the Dylan effort when it came out, as it the
main motivation was to create a new language for some Apple palmtop,
and this consumed resources that could have been used to improve CL (it
could be argued that it was an `improved Scheme' but how about
supporting EULisp instead?).
3. CMU shuts down CMUCL and starts to work on Dylan. Bad
3. Apple decides to drop the Lisp syntax. Bad.
4. Apple drops Dylan.
5. Open Source community embraces Dylan. Great. Multimethods to the
mainstream.
The question is: what prevents you now from to going back to the
original idea?
[I'm sorry, if I was funded to spend time myself in creating a Lisp
frontend
for something, it would be for Cecil. If CLOS were too heavy for
something,
there's much more to gain over there. And good prototype-based dialect
would
be a more interesting addition to the Lisp family.]
Regards,
Klaus Schilling
> Fernando Mato Mira <mato...@iname.com> writes:
>
> > Although Dylan never really made it into "Fernando's elegibility list"
> > because
> > it was not a serious contender against Scheme and CL yet, it definitely got
> > banished the day the Lisp syntax was dropped. I'm still waiting for the day
> > when the Dylan fans will reinstate the alternative.
>
> This is an age-old flamewar. It just so happens that there are people
> who like infix syntax and detest prefix, and then there are people who
> love their parens and hate infix.
Prefix rocks, infix is crap.
Klaus Schilling
Fernando D. Mato Mira
> Prefix rocks, infix is crap.
Wow, wow, wow. Let's not go there..
Robin Becker
<mato...@acm.org> writes
>Klaus Schilling wrote:
>
>> Prefix rocks, infix is crap.
>
>Wow, wow, wow. Let's not go there..
--
tree searching-ly yrs Robin Becker
Fernando D. Mato Mira
> postfix, prefix, infix etc etc are isosemantic
Yup. But the deal is to be able to write a parser in an hour (say, in
1950something), and
be setup until the next comet hits the Earth.
Not to mention how invaluable it is not to waste the mandatory compiler
course with the unnecessary half of the `Dragon book'.
And when infix goes wild, a LOT of dollars go down the drain (the one
with a bug-free C++ frontend please raise your hand!).
James McCartney
<Klaus.S...@home.ivm.de> wrote:
>Prefix rocks, infix is crap.
No, you mean:
Rocks prefix? Is infix crap?
James McCartney asynth <at> io <dot> com
Stig Hemmer
(think I (meant you (and (rocks prefix) (is-crap infix))))
Stig Hemmer,
Jack of a Few Trades.
William Tanksley
>> Prefix rocks, infix is crap.
>(think I (meant you (and (rocks prefix) (is-crap infix))))
prefix rocks infix crap is and false =
...as long as we're fighting... :-)
>Stig Hemmer,
>Jack of a Few Trades.
(I like all the languages I know, except Fortran. I even like C++,
although I wish they could break backwards compatibility.)
--
-William "Billy" Tanksley
Utinam logica falsa tuam philosophiam totam suffodiant!
:-: May faulty logic undermine your entire philosophy!
Maxwell Sayles
Robin Becker wrote:
> postfix, prefix, infix etc etc are isosemantic
for myself and the others who might not know... can we get an example of
each?
and i remember someone mentioned parenthesized vs non-parenthesized...
Maxwell Sayles
William Tanksley
Infix (ML and Prolog):
3 + (4 minus 10) == 1
(parenthesis are not optional)
Prefix (C, Lisp, Scheme):
function(that(x(1)))
or:
(do-this (do-that (x 1)))
(Parenthesis are not optional)
Postfix (Forth, Postscript):
3 4 + SWAP MOD do-that
rinse on agitate 10 seconds rinse off
(Parenthesis are not optional)
As a common thread, note that in none of the languages are parenthesis
optional. In Postfix parenthesis are not optional because they have nno
meaning; in the other languages they're assigned arbitrary meaning.
I suspect that the person who mentioned "parenthesised" languages to you
was actually commparing a language which used only parenthesis for
grouping, such as classical Scheme, with a language like C which uses lots
of other punctuation marks as well.
My preference? I use C at my job. I prefer postfix (Forth) for its lack
of punctuation. I like ML and Prolog because they let me create my own
punctuation (but then I don't use them much).
Heck, just learn them all. There's time -- there's always time to do the
stuff you enjoy.
>Maxwell Sayles
Fernando Mato Mira
Chris Ebenezer wrote:
> Fernando Mato Mira <mato...@iname.com> writes:
> : of folks end up using one or another GNU tool. As a side effect, some
> : newcomers to Tk that would have normally used tcl could end up going
> : the STk way (unfortunately, STk is not publicized enough). Things like
> : Kawa also increase the feel of security regarding code reusability.
> : And some of those people will end up wanting to write full-fledged
>
> 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.
I don't now. Some people might just `want to do Tk'.
Fernando Mato Mira
William Tanksley wrote:
> My preference? I use C at my job. I prefer postfix (Forth) for its lack
> of punctuation. I like ML and Prolog because they let me create my own
> punctuation (but then I don't use them much).
BTW, you can do infix stuff in Common Lisp
http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/0.html
eg.
(defun bar (x y)
(whatever))
(defun foo (u v x y z)
(typical-lisp-code)
(lets-just-copy-a-formula-from-a-book-and-use-it-here #I( u + v * bar(x,y)
^^ z))
(blah-blah))
Fernando Mato Mira
William Tanksley wrote:
> (I like all the languages I know, except Fortran. I even like C++,
> although I wish they could break backwards compatibility.)
Quiz: What do Scheme, Common Lisp, HPF and Java have in common?
Ian Wild
And when's Java*, the massively parallel version, coming out?
Fernando Mato Mira
Ian Wild wrote:
I seem to have forgotten C, too..
Julian Einwag
> 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.
Do you know where you can get the Qt bindings? Im quite interested in
it.
Johan Kullstam
> I seem to have forgotten C, too..
you lucky bastard!
--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
Don't Fear the Penguin!
Harvey J. Stein
> On Tue, 15 Jun 1999 01:54:53 GMT, Maxwell Sayles wrote:
> >Robin Becker wrote:
>
> >> postfix, prefix, infix etc etc are isosemantic
>
> >for myself and the others who might not know... can we get an example of
> >each?
> >and i remember someone mentioned parenthesized vs non-parenthesized...
>
> Infix (ML and Prolog):
>
> 3 + (4 minus 10) == 1
> (parenthesis are not optional)
>
> Prefix (C, Lisp, Scheme):
>
> function(that(x(1)))
> or:
> (do-this (do-that (x 1)))
> (Parenthesis are not optional)
>
> Postfix (Forth, Postscript):
>
> 3 4 + SWAP MOD do-that
> rinse on agitate 10 seconds rinse off
> (Parenthesis are not optional)
>
> As a common thread, note that in none of the languages are parenthesis
> optional. In Postfix parenthesis are not optional because they have nno
> meaning; in the other languages they're assigned arbitrary meaning.
This isn't a completely fair example. Postfix can get away without
parentheses only when a) everything that's not a number is a function
and b) the arity (# of arguments) of each function is known and fixed.
Given such restrictions one can also drop the parentheses in prefix
notation.
Infix still requires parentheses even given the above restrictions.
--
Harvey J. Stein
Bloomberg LP
hjs...@bfr.co.il
William Tanksley
>wtan...@dolphin.openprojects.net (William Tanksley) writes:
> > On Tue, 15 Jun 1999 01:54:53 GMT, Maxwell Sayles wrote:
> > >Robin Becker wrote:
> > >> postfix, prefix, infix etc etc are isosemantic
> > >for myself and the others who might not know... can we get an example of
> > >each?
> > >and i remember someone mentioned parenthesized vs non-parenthesized...
> > Prefix (C, Lisp, Scheme):
> > function(that(x(1)))
> > or:
> > (do-this (do-that (x 1)))
> > (Parenthesis are not optional)
> > Postfix (Forth, Postscript):
> > 3 4 + SWAP MOD do-that
> > rinse on agitate 10 seconds rinse off
> > (Parenthesis are not optional)
> > As a common thread, note that in none of the languages are parenthesis
> > optional. In Postfix parenthesis are not optional because they have nno
> > meaning; in the other languages they're assigned arbitrary meaning.
>This isn't a completely fair example. Postfix can get away without
>parentheses only when a) everything that's not a number is a function
>and b) the arity (# of arguments) of each function is known and fixed.
Not true -- in Forth part (a) holds, but part (b) doesn't. The number of
arguments and number of returns can vary arbitrarily; they're put onto and
taken off of a stack.
And I don't see the relevance of restriction (a). It seems that with or
without it we would get the same result -- postfix doesn't need
parenthesis.
Oh, for example, Forth "immediate" words. These aren't the same as other
functions, since they execute at compile time (in all other respects they
are functions, though).
Also, HP RPN uses syntactic elements which are neither numbers nor
functions.
So therefore, neither of your conditions are necessary.
>Given such restrictions one can also drop the parentheses in prefix
>notation.
You're right here, though.
>Infix still requires parentheses even given the above restrictions.
Yes.
We see that postfix never requires parenthesis, and prefix can skip its
parenthesis under certain conditions. Are there any conditions under
which infix can ignore parenthesis?
>Harvey J. Stein
Tom Cloney
> 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.
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.
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
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
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.
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.
* Baby with the baboon heart sold separately.
-Tom
David Thornley
>: newcomers to Tk that would have normally used tcl could end up going
>: the STk way (unfortunately, STk is not publicized enough). Things like
>: Kawa also increase the feel of security regarding code reusability.
>: And some of those people will end up wanting to write full-fledged
>
>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.
>
graphics environment that will run on Unix with X-Windows, the
Macintosh, and Microsoft Windows. CLIM is commercial, Garnet last
I looked didn't run on Microsoft Windows, and it looks to me like
I should be able to get Macintosh Common Lisp communicating with
Tk through Tcl without *that* much work.
I know little of this Qt animal. Is it free? Is it open source?
Does it run on the Macintosh? Is it easy to set up an interface with?
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Cameron Laird
Julian Einwag <jul...@brightstar.swin.de> wrote:
.
.
.
>Do you know where you can get the Qt bindings? Im quite interested in
>it.
<URL:http://
starbase.neosoft.com/~claird/comp.lang.python/python_GUI.html#PythonQt>
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 281 996 8546 FAX
Cameron Laird
David Thornley <thor...@visi.com> wrote:
.
.
.
>I know little of this Qt animal. Is it free? Is it open source?
>Does it run on the Macintosh? Is it easy to set up an interface with?
.
.
Qt comes in a handful of flavors. Some are free of charge.
There's an open-sourced work-alike. None of these run under
MacOS, to the best of my knowledge. I'm collecting information
about them at <URL:
http://starbase.neosoft.com/~claird/comp.windows.misc/Qt.html>
Tom Cloney
> >
>
Yes, I've often thought of Alpha as a sort of Tcl-based Emacs. Alpha felt a
bit snappier and less burdened with history, though. Emacs Lisp is very
powerful when you get into it. I used to hack it quite a bit on my DOS
laptop, and way before that in ZetaLisp. But when I use Emacs I feel like
I'm definitely going to another planet and leaving the normal OS and apps
behind. A lot of stuff in there was developed long before GUIs were common.
Tcl embedded in a more modern application can give similar extensibility
while preserving a modern look and feel for those times when you don't need
the whole Emacs cultural heritage. Indeed, I think Tcl is ideal for
extending a text processor, since most people never _deeply_ hack that sort
of thing. It's an example of where Tcl's easy-reading "brainless" syntax is
very appropriate. The learning curve is very shallow. A great customizing
language.
I still use Emacs from time to time, though. Its source code formatting
hacks and foreign compiler integration are very good and it has hooks for
languages that haven't even been invented yet. Also, if you reverse your
power cord and turn your monitor upside down Emacs prints out "TECO is
dead".
-Tom
Marco Antoniotti
"Tom Cloney" <mu...@viadoc.com> writes:
...
>
> It's super when embedded in a text editor. Alpha is a great example.
>
Emacs is a great example :)
Cheers
Marco
--
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
Greg Ewing
>
> I wanted to find out whether the disgust for tcl I've seen many people
> express had some basis on some generally accepted principles.
I think I can give some reasonably objective reasons why
I find that I enjoy using Python in a way that I don't
enjoy using Tcl. (I have used both, and in one case have
written versions of the same program in both languages.)
1. Syntax
Tcl's syntax is based on the principle that an unadorned
sequence of alphanumeric characters represents a literal.
Anything else (such as referring to a variable) requires
extra syntax.
Ousterhout's justification is that this is optimal
for entering commands interactively, which is probably true.
However, this seems to me the wrong thing to optimise for,
given that tcl is meant to be a *programming* language.
The case being optimised for -- typing in a command which
is to be used once and thrown away -- simply doesn't occur.
Programs, even tiny ones, get used more than once!
In my opinion, the small amount of extra syntax needed
to quote literals and express function calls in a language
like Python is well worth the benefits you get further
down the track. An example of these is that, where in
Tcl you find yourself writing
set a [expr $b + $c]
in Python you get to write
a = b + c
Since the vast majority of words in my programs refer
to variables, and string literals are relatively rare,
I much prefer the Python way of writing things to
the Tcl way.
2. Data structures
Briefly, Python has them, Tcl doesn't. Tcl has character
strings, which are sometimes interpreted according to a
certain set of rules as lists of other character strings.
The rules are pedantic and can trip you up sometimes.
Tcl also has associative arrays, which is a powerful
feature compared to what some languages give you, but
they're not first-class objects and all you can put
in them are character strings.
Python has a rich set of first-class data types, including
lists, dictionaries (associative arrays) and classes/instances,
from which you can build real data structures and manipulate
them in easy and intuitive ways.
Tcl proponents will tell you that you can emulate all of
that using tcl lists and arrays, which is true, but misses
the point. Why bother with emulation when you can have the
real thing at no extra cost?
Summary
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.
Greg
Klaus Schilling
> "Tom Cloney" <mu...@viadoc.com> writes:
>
> ...
> >
> > It's super when embedded in a text editor. Alpha is a great example.
> >
>
> Emacs is a great example :)
Exactly! And it will be a greater example once it will use guile,
the ultimate scripting language.
Klaus Schilling
Jason Stokes
>I know little of this Qt animal. Is it free? Is it open source?
>Does it run on the Macintosh? Is it easy to set up an interface with?
See www.troll.no, but here's the synopsis:
Qt is a cross-platform GUI toolkit for Unix and Windows. Qt releases a
special "free edition" for Unix only which does match the open source
definition, but with some licensing issues.
The problem is that linking with the Qt free edition libraries is only
allowed if you write open source software yourself. If you want to write a
commercial application for Qt, you have to buy a license from Troll Tech.
--
Jason Stokes: js...@bluedog.apana.org.au
Donn Cave
...
| 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.
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.
Donn Cave, University Computing Services, University of Washington
do...@u.washington.edu
Juhani Rantanen
>I know little of this Qt animal. Is it free? Is it open source?
>Does it run on the Macintosh? Is it easy to set up an interface with?
Qt will be soon licensed with an open-source license, though it will
be practically very restrictive (all changes must be distributed as
patches). Current version of Qt is not free software, and I am
surprised to find one who doesn't know about the flamewars... Try "qt
gtk free" in Altavista or Dejanews to find out:)
I also suggest looking at Gtk+ <http://www.gtk.org/> that is used in
GIMP (free Photoshop clone for Unix/Linux http://www.gimp.org/), Gnome
(a free desktop environment for GNU project http://www.gnome.org/) .
Gnome folks have made a version of Guile with Gtk and Gnome bindings,
but this is not very widely tested AFAIK, and some higher-level
interface would be preferable (though now we have C-level API mapped
to scheme, the higher-level interface could be written in scheme).
Gtk+ is available on Unix and Win32. Win32 support is not in the official
sources, but I even occasionally use a version of GIMP on Windows NT
and it is quite robust compared to some commercial programs on the
same operating system (though both Gtk+ and Gimp on that machine are
developer's versions from CVS).
--
Juhani Rantanen
Lähderanta 20 G 55 Espoo
This message is best read on a 80x24 tty with 2 colors and a
non-proportional font
Klaus Schilling
> > > It's super when embedded in a text editor. Alpha is a great example.
> > >
> >
> > Emacs is a great example :)
>
> Yes, I've often thought of Alpha as a sort of Tcl-based Emacs.
Does Alpha require pixel-graphics or can it be run on a text-only
console, which is possible for the GNU Emacs?
Klaus Schilling
Fernando D. Mato Mira
> > Exactly! And it will be a greater example once it will use guile,
> > the ultimate scripting language.
>
> And it will be an even greater example once it will be based on CL,
> the ultimate programming language. ;-)
Tell me how to `put the big on the small' and the magic will follow..
--
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
Fernando D. Mato Mira
> Tell me how to `put the big on the small' and the magic will follow..
Oh, yes. RMS took care of `that'. Who said he was anti-CL? ;->
Tom Cloney
Klaus Schilling <Klaus.S...@home.ivm.de> wrote in message
news:87r9nbj...@home.ivm.de...
> "Tom Cloney" <mu...@viadoc.com> writes:
> Does Alpha require pixel-graphics or can it be run on a text-only
> console, which is possible for the GNU Emacs?
Alpha requires a GUI, and actually had some simple GUI functionality built
in before Tk became available on the Mac, such as list pickers, simple
button dialogs, and so on.
My point is that the text-only capabilities of Emacs (which are part of what
make Emacs so transportable) also impose some lowest-common-denominator
baggage on it. I'm certainly not trying to warm up that tired old flame war
about "which editor is best". Emacs and Alpha are both very good in
different, but partially overlapping ways. There are plenty of other good
editors out there, each with its own specialized advantages. What I was
getting at is that Tcl (like Emacs Lisp) is a nice language for embedding in
an editor to provide customization. Perl would also be a cool choice. Like
Emacs Lisp, it might be seen as a bit more powerful than Tcl, but would
probably be a little harder for occasional users to learn and maintain.
-Tom
Marco Antoniotti
Clemens Heitzinger <chei...@rainbow.studorg.tuwien.ac.at> writes:
> Klaus Schilling <Klaus.S...@home.ivm.de> writes:
>
> > Marco Antoniotti <mar...@copernico.parades.rm.cnr.it> writes:
> > =
>
> > > "Tom Cloney" <mu...@viadoc.com> writes:
> > > > =
>
> > > > It's super when embedded in a text editor. Alpha is a great example.
> > > =
>
> > > Emacs is a great example :)
> > =
>
> > Exactly! And it will be a greater example once it will use guile,
> > the ultimate scripting language.
>
> And it will be an even greater example once it will be based on CL,
> the ultimate programming language. ;-)
>
How true!
Klaus Schilling
> Clemens Heitzinger <chei...@rainbow.studorg.tuwien.ac.at> writes:
>
> > Klaus Schilling <Klaus.S...@home.ivm.de> writes:
> >
> > > Marco Antoniotti <mar...@copernico.parades.rm.cnr.it> writes:
> > > =
> >
> > > > "Tom Cloney" <mu...@viadoc.com> writes:
> > > > > =
> >
> > > > > It's super when embedded in a text editor. Alpha is a great example.
> > > > =
> >
> > > > Emacs is a great example :)
> > > =
> >
> > > Exactly! And it will be a greater example once it will use guile,
> > > the ultimate scripting language.
> >
> > And it will be an even greater example once it will be based on CL,
> > the ultimate programming language. ;-)
> >
Common Lisp lacks support for termcap and the termios routines.
It can't be used as a base language for the emacs.
Klaus Schilling
Marco Antoniotti
Klaus Schilling <Klaus.S...@home.ivm.de> writes:
> Marco Antoniotti <mar...@copernico.parades.rm.cnr.it> writes:
>
> > Clemens Heitzinger <chei...@rainbow.studorg.tuwien.ac.at> writes:
> >
> > > Klaus Schilling <Klaus.S...@home.ivm.de> writes:
> > >
> > > > Marco Antoniotti <mar...@copernico.parades.rm.cnr.it> writes:
> > > > =
> > >
> > > > > "Tom Cloney" <mu...@viadoc.com> writes:
> > > > > > =
> > >
> > > > > > It's super when embedded in a text editor. Alpha is a great example.
> > > > > =
> > >
> > > > > Emacs is a great example :)
> > > > =
> > >
> > > > Exactly! And it will be a greater example once it will use guile,
> > > > the ultimate scripting language.
> > >
> > > And it will be an even greater example once it will be based on CL,
> > > the ultimate programming language. ;-)
> > >
>
> Common Lisp lacks support for termcap and the termios routines.
> It can't be used as a base language for the emacs.
>
Ok. Let's see.
(DEFPACKAGE "CL.TERMIO" (:use "COMMON-LISP")
(:export "...."))
Shall I go on? :)
Cheers
sam...@panix.com
[...]
> Common Lisp lacks support for termcap and the termios routines.
> It can't be used as a base language for the emacs.
The editor Hemlock runs just fine within a plain old TTY.
Soren Dayton
> Fernando Mato Mira wrote:
> >
> > I wanted to find out whether the disgust for tcl I've seen many people
> > express had some basis on some generally accepted principles.
>
> I think I can give some reasonably objective reasons why
> I find that I enjoy using Python in a way that I don't
> enjoy using Tcl. (I have used both, and in one case have
> written versions of the same program in both languages.)
>
> 1. Syntax
>
> Tcl's syntax is based on the principle that an unadorned
> sequence of alphanumeric characters represents a literal.
> Anything else (such as referring to a variable) requires
> extra syntax.
>
> Ousterhout's justification is that this is optimal
> for entering commands interactively, which is probably true.
> However, this seems to me the wrong thing to optimise for,
> given that tcl is meant to be a *programming* language.
> The case being optimised for -- typing in a command which
> is to be used once and thrown away -- simply doesn't occur.
> Programs, even tiny ones, get used more than once!
but it occurs to me that this is a GOOD argument for the best uses of
tcl, that is as an interactive style shell or scriptable configuration
file language.
tcl _IS_ too annoying to do real programming in, but it is not clear
that it is not _by far_ the best tool for this kind of niche use. (Yes,
I've heard about guile, but frankly, tcl looks like my ipfilter
configuration files and we are _NOT_ after expressibility here but a
sort of clarity)
Soren
Tim Bradshaw
> Common Lisp lacks support for termcap and the termios routines.
> It can't be used as a base language for the emacs.
emacs lisp lacks support for for termcap and the termios routines. It
can't be used as a base language for the emacs.
--tim
Greg Ewing
>
> But I think
> Tcl is syntactically more adaptable, where Python kind of makes
> a virtue of its fixed ways.
Yes, someone who likes languages with highly reconfigurable
syntax would perhaps like Tcl for that reason. Personally
I find that Python provides as much flexibility as I need
or want almost all the time.
Python's keyword arguments are quite useful for designing
little sub-languages for certain contexts. Tk's option
settings for widgets map naturally onto keyword arguments,
for example.
Greg
Christopher R. Barry
> Klaus Schilling <Klaus.S...@home.ivm.de> writes:
>
> [...]
>
> > Common Lisp lacks support for termcap and the termios routines.
> > It can't be used as a base language for the emacs.
>
> The editor Hemlock runs just fine within a plain old TTY.
Actually Hemlock's TTY support has been broken for quite some time
now. Not that I particularly give a damn about TTY support in
it. Emacs has abandoned its heritage of painstakingly coded redisplay
algorithms that once allowed the editor to be usable over 300 baud
terminals. (Witness MULE.)
Ultimately TTY support will vanish in likewise fashion. Look at all
the stuff supported in X operation of GNU Emacs that is not supported
in TTY operation. It's obvious which mode of operation the developers
prefer. Zmacs, the editor of the Symbolics Lisp Machine, does not
support TTY operation, and it's been around since the early 80s. I
think when the one true successor or next-generation of Emacs based on
CL appears in 200x, TTY support will not be present at all.
I suspect some form of incomplete TTY support will be around for GNU
Emacs as long as Linux and HURD are around, only because of their tie
to the way of Unix and non-mandatory graphics capabilities that every
PC since 1986 has had.
Christopher
Klaus Schilling
> * Klaus Schilling wrote:
>
> > Common Lisp lacks support for termcap and the termios routines.
> > It can't be used as a base language for the emacs.
>
> emacs lisp lacks support for for termcap and the termios routines. It
> can't be used as a base language for the emacs.
Irrelevant. Emacs Lisp is just an extension language, the base language
for the GNU Emacs is of course C.
Klaus Schilling
Klaus Schilling
> sam...@panix.com writes:
>
> > Klaus Schilling <Klaus.S...@home.ivm.de> writes:
> >
> > [...]
> >
> > > Common Lisp lacks support for termcap and the termios routines.
> > > It can't be used as a base language for the emacs.
> >
> > The editor Hemlock runs just fine within a plain old TTY.
>
> Ultimately TTY support will vanish in likewise fashion. Look at all
> the stuff supported in X operation of GNU Emacs that is not supported
> in TTY operation.
> It's obvious which mode of operation the developers
> prefer.
Only fools prefer GUI mode which is obsolete junk.
> Zmacs, the editor of the Symbolics Lisp Machine, does not
> support TTY operation, and it's been around since the early 80s. I
> think when the one true successor or next-generation of Emacs based on
> CL appears in 200x, TTY support will not be present at all.
Then I'll have to start my own editor, which supports tty.
Klaus Schilling
Stig Hemmer
> > > Common Lisp lacks support for termcap and the termios routines.
> > > It can't be used as a base language for the emacs.
> >
> > can't be used as a base language for the emacs.
>
> for the GNU Emacs is of course C.
C lacks support for termcap and the termios routines. It can't be used
as a base language for emacs.
Stig Hemmer,
Jack of a Few Trades.
Mike McDonald
And since TCL uses the C versions, it can't either.
Mike McDonald
mik...@mikemac.com
Tim Bradshaw
> sam...@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.
--tim
Tim Bradshaw
>> > It can't be used as a base language for the emacs.
>>
>> emacs lisp lacks support for for termcap and the termios routines. It
>> can't be used as a base language for the emacs.
> Irrelevant. Emacs Lisp is just an extension language, the base language
> for the GNU Emacs is of course C.
C lacks support for termcap and termios routines. It can't be used as
a base language for the emacs.
Unless you write a library, cretin.
--tim
Christopher R. Barry
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]
Christopher
1. :Show Documentation Zwei Internals
Tim Bradshaw
> 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.
--tim
Marco Antoniotti
Klaus Schilling <Klaus.S...@home.ivm.de> writes:
> Tim Bradshaw <t...@tfeb.org> writes:
>
> > * Klaus Schilling wrote:
> >
> > > Common Lisp lacks support for termcap and the termios routines.
> > > It can't be used as a base language for the emacs.
> >
> > emacs lisp lacks support for for termcap and the termios routines. It
> > can't be used as a base language for the emacs.
>
> Irrelevant. Emacs Lisp is just an extension language, the base language
> for the GNU Emacs is of course C.
>
Irrelevant. C is just an extension language, the base language for any
C application is the underlying assembly. :)
Fernando Mato Mira
Marco Antoniotti wrote:
> Irrelevant. C is just an extension language, the base language for any
> C application is the underlying assembly. :)
Which makes C an extension for both Lisp and Occam.
Fernando Mato Mira
Fernando Mato Mira wrote:
So Lisp is an extension of Lisp. QED (duh)
David Thornley
Chris Ebenezer <chr...@nortelnetworks.com> wrote:
>
>thor...@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.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Fernando Mato Mira
David Thornley wrote:
> besides Tk that meets the requirements I've specified: free, open source,
> on MacOS, Microsoft Windows and X Windows.
wxWindows.
DrScheme (MzScheme) uses that.
Christopher C Stacy
However, the system input editor (which all applications normally use) provides
a subset of emacs commands, and that mostly works on everything.
Russell Nelson
> 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!
Paul Duffin
>
> > 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: pdu...@hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880 International: +44 1962-816880
Paul Duffin
>
> > I'm trying to collect a list of all the _current_ issues making tcl
> > a bad language choice...
>
> 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.
>
> 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
>
> Greg Ewing <greg....@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.
Marco Antoniotti
Paul Duffin <pdu...@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 :)
Klaus Schilling
> Paul Duffin <pdu...@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.
Klaus Schilling
Greg Ewing
> Russell Nelson wrote:
> > Because it necessarily parses strings.
> What do you mean by "necessarily parses strings" ?
It's better than unnecessarily parsing
strings, I suppose! :-)
Greg
Greg Ewing
>
> 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.
Greg
Paul Duffin
Both Tcl and Scheme can do it, "best" is subjective.
Marco Antoniotti
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.
Cameron Laird
Marco Antoniotti <mar...@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].
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 281 996 8546 FAX
Marco Antoniotti
> Delivery-Date: Tue, 29 Jun 1999 17:28:08 +0200
> Date: Tue, 29 Jun 1999 10:30:14 -0500 (CDT)
> From: Cameron Laird <cla...@Starbase.NeoSoft.COM>
> Newsgroups: comp.lang.python,comp.lang.lisp,comp.lang.scheme
> Organization: NeoSoft, Inc. +1 713 968 5800
> content-length: 645
>
> In article <lw67471...@copernico.parades.rm.cnr.it>,
> Marco Antoniotti <mar...@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. :)
==============================================================================
* (defmacro zut (a) `(list ,a))
ZUT
* (defun zot (x) (zut x))
ZOT
* (compile 'zot)
ZOT
* (disassemble 'zot)
071B5790: .ENTRY ZOT(x) ; (FUNCTION (T) LIST)
7A8: ADD -18, %CODE
7AC: ADD %CFP, 32, %CSP
7B0: CMP %NARGS, 4 ; %NARGS = #:G0
7B4: BNE L0
7B8: NOP
7BC: MOVE %A0, %A4 ; %A0 = #:G1
7C0: MOVE %A4, %A0 ; No-arg-parsing entry point
7C4: ADD 4, %ALLOC
7C8: ANDN %ALLOC, 7, %A3
7CC: OR 3, %A3
7D0: MOVE %A3, %A1
7D4: ST %A0, [%A1-3]
7D8: ST %NULL, [%A1+1]
7DC: TADDCCTV 4, %ALLOC
7E0: MOVE %A3, %A0
7E4: MOVE %CFP, %CSP
7E8: MOVE %OCFP, %CFP
7EC: J %LRA+5
7F0: MOVE %LRA, %CODE
7F4: UNIMP 0
7F8: L0: UNIMP 10 ; Error trap
7FC: BYTE #x04
7FD: BYTE #x19 ; INVALID-ARGUMENT-COUNT-ERROR
7FE: BYTE #xFE, #xED, #x01 ; NARGS
801: .ALIGN 4
*
==============================================================================
Of course I could have defined a much more intricated macro.
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?
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.
Marco Antoniotti
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 :) )
Lars Marius Garshol
* 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.
--Lars M.
[1] <URL: http://www.sunworld.com/swol-03-1999/swol-03-regex.html >
Pierre R. Mai
> 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):
(do-query ((name) [select [ename] :from [emp]])
(print name))
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."
...)
(defmacro in-tcl (&body expressions)
(let ((compiled-code (mapcar #'compile-tcl-to-lisp expressions)))
`(progn ,@compiled-code)))
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 <pm...@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]
Erik Naggum
| 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