scripting language newbie - compatibility

[Martijn Faassen]

Paul Duffin <pduffin at hursley.ibm.com> wrote:
> Martijn Faassen wrote:
>> 
>> Paul Duffin <pduffin at hursley.ibm.com> wrote:
>> [snip]
>> > Actually you can generate byte compiled versions of Tcl which you can
>> > distribute but you need to use a commercial package called TclPro to
>> > do that. It is certainly not as easy as Python but pre byte compiling Tcl
>> > code is not as useful as pre compiled Python code because of Tcl's dynamic
>> > nature.
>> 
>> How would Tcl be more dynamic than Python? (you seem to be
>> implying this) 

> AFAIK it is. Tcl does not have any special flow control statements, instead 
> it provides flow control commands. These commands are the same as any other
> command and therefore can be redefined. AFAIK Python does not allow "if" to
> be redefined whereas Tcl does.

Okay, so it's more dynamic on the statement level; or another way to
express it, it's more flexible on the statement level. Similar to
Smalltalk, perhaps. Still..

>> And how does a language's dynamic nature stop it from
>> being (usefully) byte-compiled?

> Byte compilation is done on the fly when data is executed as code and 
> depends on the command not having been redefined. The byte compiled code
> is invalid as soon as any of the commands that it uses and which can be 
> byte compiled are redefined. Actually Tcl invalidates all byte compiled
> code as soon as a command which can be byte compiled is redefined.

> In order for byte compiled code which has been saved into a file to behave
> properly it would need the complete source code so that it could be 
> recompiled if a byte compiled command had been redefined. 

As others said, doesn't the same problem occur with objects? Python doesn't
have to know what 'foo' points to during byte compiling for an operation
on 'foo' to succeed (or fail) during the running of the program, after
all. 'foo' may be defined to be whatever is desired.

Does the redefining of a command in Tcl influence the *parsing* stage,
then? I can imagine a problem in this imaginary language:

# we state command 'alpha' takes two arguments
arguments alpha 2
alpha 1 2 # we call alpha with arguments 1 and 2
alpha 1 2 alpha 17 18 # we call alpha twice
# we say alpha takes *one* argument
arguments alpha 1
alpha 1 2 alpha 17 18 # we do something which now fails

This language would need to know how many arguments alpha takes to make
sense of the code, and it may not always be able to keep track of things.

> Tcl does not actually invalidate byte compiled code which has been loaded
> from a file as that would eliminate most of the benefits of providing
> pre byte compiled code in the first place, namely speed and code hiding.

>> Perhaps you mean Tcl is more dynamic on the syntactic level somehow?

> It depends what you view as the syntax. 

> If you use syntax in the sense of Python, C, Pascal, ..., i.e. including 
> flow control statements, reserved words etc. then Tcl's syntax is very 
> dynamic as you can create new flow control statements and redefine others.

> If you use syntax in the Tcl/Lisp sense then its syntax is very rigid and 
> very simple.

Right, that makes sense; for it to be dynamic it has to be simple, just like
in Smalltalk and Lisp. So, is my conclusion correct that Tcl's parser cannot
figure out Tcl code because Tcl code can influence the way parsing works?
Or is something else the problem?

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?