Why is tcl broken?

[Paul Duffin]

Marco Antoniotti wrote:
> 
> Paul Duffin <pduffin at mailserver.hursley.ibm.com> writes:
> 
> > Marco Antoniotti wrote:
> > >
> > > 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
> >
> > I am surprised at this because Tcl's [upvar] is simply an explicit form
> > of dynamic binding which I seem to remember is what Lisp uses. (That

Mistake, I think I meant dynamic scoping.

> > is how the 'let' function can be (is) implemented as a lambda
> > function).
> 
> Ahem!  LET is essentially a macro built on top of LAMBDA application.

I know that.

> Dynamic binding is another beast altogether, which Common Lisp and
> Scheme (statically scoped languages) allow in through a back door.

If they are statically scoped how does the following work.

Look at the following code.

	(let ((a 2))
	  (let ((b 3))
	    (+ a b)))

When you expand the macro let you get something like.

	((lambda (a)
	   ((lambda (b) 
	      (+ a b)) 3)) 2)

Which is equivalent (apart from side effects) of.

	(defun inner (b)
	  (+ a b))

	(defun outer (a)
	  (inner 3))

	(outer 2)

So what is the process which associates the use of "a" inside inner
with the formal argument of outer. I 

The Tcl equivalent is

	proc inner {b} {
	    upvar 1 a a;
	    expr {$a + $b}
	}

	proc outer {a} {
	    inner 3
	}

	outer 2

> The notion of [upvar] and [uplevel] (with the optional numeric argument which allows
> you to inspect N levels of stack is truly hackish.  The utility of

As I have said before it is simply an explicit form of the Lisp mechanism which allows
the let macro to be implemented using lambda. It is very rare that N is more than 1.

> this construct is not in question.  But its use as a
> 'macro-approximating' device is questionable.
> 
> BTW. Is TCL statically or dynamically scoped?
> 

Tcl is statically scoped but you can use upvar to get access to variables
in enclosing stack frames.

> > > 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.
> > >
> >
> > I find that Lisp macros (while a very powerful and necessary mechanism)
> > are sooo confusing. They are in essence another language inside Lisp,
> > and as such introduce inconsistencies.
> 
> You are very mistaken.  Common Lisp macros are definitively not
> another language.  They manipulate S-expressions, which are what Lisp

Lisp macros manipulate S-expressions but the macro definitions themselves
are interpreted differently to Lisp expressions.

A simple macro version of setq would convert from
	(setq symbol '(list))
to
	(set 'symbol '(list))

A macro setq is not interpreted the same way as set is because if it
was an error would occur when the Lisp interpreter tried to get the
value of the variable symbol before symbol was created.

This is where the inconsistencies come from.

> is made of.  They generate inconsistencies insofar as you are careless
> when dealing with possible name capture problems. GENSYM and GENTEMP
> are there to help you.
> 
> > Tcl on the other hand doesn't
> > need a macro language and as such is much more consistent than Lisp.
> 
> You severely underestimate the power of Common Lisp (Scheme and Dylan)
> macro systems and ascribe to them inconsistencies which are not

I don't underestimate the power of Lisp macros I am just saying that I
find the way they warp the otherwise simple Lisp syntax / semantics.

Lisp does not really need macros, they are really just a way of
creating short cuts.

> there.  It is true that Tcl does not need a macro system. But mostly
> because, since you have Common Lisp, you do not need Tcl altogether :)

Not a particularly effective argument.

> Apart from some good ole flaming, why doesn't Tcl need a Lisp style
> macro system? Just because you have [eval]?  Not a very good
> argument. Especially when brought up in front of a Lisp audience.
> 

Tcl does not need a macro system because it has a simple consistent
syntax / semantics and all commands are treated equally and it is
possible to change the behaviour of existing commands.

> >
> > If I needed a macro language in Tcl I can just write one.
> 
> I just recieved an email from Cameron Laird, citing a 'procm' form in
> Tcl, which is supposed to do 'scan time' macros - probably something
> in line with the real thing. However, the manual pages for 8.1 at Scriptics
> does not mention it.  Yet, I suppose that it is still an experimental
> feature that maybe will appear in Tcl in a later edition - a few
> lustres after Lisp had them :)
> 

I would say that that is probably something Cameron has created. Despite
what you think Tcl is not crying out for a Lisp like macro system. What
it is crying out is for more data types and it will soon be getting them.
Including a 'proper' [lambda] implementation.

I would say that Tcl (without macro system) can do anything that Lisp
(with macro system) can do.

> > Lisp and Tcl have a lot more in common than Lispers seem to want to
> > acknowledge.
> 
> Ahem!  Do you remember the "revised" Tcl paper by Ousterhout (sorry
> for the spelling mistakes :) ), where the essential
> addition/correction was the mention of the L-word? :)
> 

No I don't.

-- 
Paul Duffin
DT/6000 Development	Email: pduffin at hursley.ibm.com
IBM UK Laboratories Ltd., Hursley Park nr. Winchester
Internal: 7-246880	International: +44 1962-816880