Newbie question

After sniffing around the edges of Tcl/Tk for years I am ready to take
the plunge. I come from the modular programming tradition. So here is
my question:

I want to break up the source of a largish application into separate
files, and bring in those pieces of script at execution time. What is
the simplest way to do this (equivalent to an include function in
other languages or an \input function in TeX.)

I'll have more questions later.


John Culleton

John Culleton wrote:
> After sniffing around the edges of Tcl/Tk for years I am ready to take
> the plunge. I come from the modular programming tradition. So here is
> my question:
>
> I want to break up the source of a largish application into separate
> files, and bring in those pieces of script at execution time. What is
> the simplest way to do this (equivalent to an include function in
> other languages or an \input function in TeX.)
>
> I'll have more questions later.
>
either source or for many things better the package mechanism of tcl.

See:
http://wiki.tcl.tk/source
http://wiki.tcl.tk/package

Michael

Michael Schlenker <schlenk@uni-oldenburg.de> wrote in message news:<2mi6kpFn85piU1@uni-berl
in.de>...
> John Culleton wrote: 
> either source or for many things better the package mechanism of tcl.
>
> See:
> http://wiki.tcl.tk/source
> http://wiki.tcl.tk/package
>
I looked at both of these, but they  didn't fill the bill exactly. I
am looking of a command that will allow me to break up the source code
in separate files.

The "source" command brings in the code and immediately attempts to
evaluate it, like a called function.  The package command is a bit
closer, in that you can package up one or a series of procs for later
execution. But it is a bit elaborate.

Consider TeX for example. If I say "\input foo.tex" then the foo.tex
file is incorporated in the program source as if it had been written
inline. Or to go back to my misspent youth, the COBOL command "copy"
brings in a chunk of code from a side file.


It appears that there is no exact analogue. I will study up some more
on the package facility.

John Culleton

John Culleton wrote:
> The "source" command brings in the code and immediately attempts to
> evaluate it, like a called function.

[...]

> Consider TeX for example. If I say "\input foo.tex" then the foo.tex
> file is incorporated in the program source as if it had been written
> inline.

[...]

I'm perhaps missing the difference.

What you may be missing is the ability to "souce" a file that contains
nothing but calls to [proc]. That is, indeed it evaluates the file, but
the only result of evaluating the file is compiling a bunch of commands.

Maybe that makes more sense?

John Culleton wrote:

> The "source" command brings in the code and immediately attempts to
> evaluate it....
>
> Consider TeX for example. If I say "\input foo.tex" then the foo.tex
> file is incorporated in the program source as if it had been written
> inline.

That is exactly what the source command does. Why do you think they are
different? Source treats the data exactly as if you had typed the code
inline.

john@wexfordpress.com (John Culleton) writes:

> The "source" command brings in the code and immediately attempts to
> evaluate it, like a called function.

It is no different from
\input mymacros
in plain TeX (for an example dear to your heart).

Donald Arseneau                          asnd@triumf.ca

Hi John,

The package mechanism is probably the most elegant and flexible way to do
what you're after.  Ultimately, though, you're forced to use [source] one
way or the other, since the package mechanism uses [source] internally.
Creating a package seems a bit intimidating the first time around, but it's
really pretty simple.  The steps to create a package are as follows:

1. Create a directory for your package.
2. Put the script that implements your package into that directory.  Make
sure your script includes a "package provide <package name> <package
version>" somewhere in the global scope of the script -- the first line is a
good place for this, in my opinion.
3. Create a pkgIndex.tcl.  You can use pkg_mkIndex to do this.  More info on
this in a moment.

To use your package, either put your package directory under one of the
directories in the $auto_path variable (/tcl/lib is a good one), or else add
your directory to auto_path like so:

lappend auto_path </my/directory>

Then do a package require mypackage, and there are your procs.

Here's an example to get you started.  Not very useful, but it'll give you
an idea of how to proceed.

1. For simplicity, create the directory hellopkg in your /tcl/lib directory.
2. Inside the hellopkg directory, create the following file, hellopkg.tcl:

# start of hellopkg.tcl
package provide hello 1.0

proc hello {string} {
puts "Hello, $string !"
}
# end of hellopkg.tcl

3. Fire up your Tcl interpreter.  Type "pkg_mkIndex <directory name>" where
<directory name> is the hellopkg directory, i.e. /tcl/lib/hellopkg or
c:/tcl/lib/hellopkg or whatever.  This will generate (in the same directory
as hellopkg.tcl) the file pkgIndex.tcl, which contains the instructions Tcl
needs to load your package (in this case, basically just a source command --
go ahead and open the file up to see what's inside).

Now you can do "package require hello" and use the hello command.

Hopefully this can help you get started.  Best of luck with Tcl!

Regards,
Aric

:> See:
:> http://wiki.tcl.tk/source
:> http://wiki.tcl.tk/package
:>
:I looked at both of these, but they  didn't fill the bill exactly. I
:am looking of a command that will allow me to break up the source code
:in separate files.
:
:The "source" command brings in the code and immediately attempts to
:evaluate it, like a called function.

Well, actually, the source command reads a file and treats the lines in it
as if they were coded right in place.

So, if the code being source'd is a series of proc statements, they
will be treated as if they were coded in place of the source.  And,
as you state, if they are outside of a proc, then they will be executed -
just as they would have been if you had written them in place of the source.

No difference.

For example:

$ cat pgm1.tcl
#! /usr/local/bin/tclsh
set a "123"
set b "xyz"
source pgm2.tcl
set e $d
puts $e
exit 0
$ cat pgm2.tcl
proc do_this {arg1 arg2} {
return "$arg1$arg2"
}
set d [do_this $a $b]

$ tclsh pgm1.tcl
123xyz

$ cat pgm3.tcl
#! /usr/local/bin/tclsh
set a "123"
set b "xyz"
proc do_this {arg1 arg2} {
return "$arg1$arg2"
}
set d [do_this $a $b]
set e $d
puts $e
exit 0
$ tclsh pgm3.tcl
123xyz


See - identical behavior.

:The package command is a bit
:closer, in that you can package up one or a series of procs for later
:execution. But it is a bit elaborate.

The primary differences that package provides is the ability to
indicate to tcl that you want it to search for a group of code files
that are stored by with a name associated to them somewhere in the
environment at the time of the invocation.  Tcl will search based on
the name, and possibly a version number, find some group of files that match
 as
closely as they can, and then loads the files.


--
<URL: http://wiki.tcl.tk/ > In God we trust.
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvirden@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >