* Luc <no@no.no>
| On Fri, 4 Nov 2022 16:48:50 -0000 (UTC), Rich wrote:
>
| > It is not. As defining a proc, inside another proc, is only rarely
| > done, and even then, generally for very advanced "dynamic code
| > generation" reasons. None of which your example, nor initial question,
| > implied was happening.
>
| Are you saying I should remove everything from its all-enveloping proc
| and provide the entire idea as a plain page (though still with procs)
| and let people just [source] it instead of running it as a proc?

Basically: yes, eventually using a namespace so your code is less likely
to collide with other code, using procs with the same name.

The usual way, if your code is not a standalone program but rather a
library which other programs use, is to build a *package*:

#------------
# yourpackage.tcl
package provide yourpackage 1.0
namespace eval yourpackage {
proc proc1 {} {
puts "this is proc1"
}
proc proc2 {} {
puts "this is proc2, now calling proc1"
proc1
}
proc proc3 {} {
puts "this is proc3, now calling proc2"
proc2
}
}
#------------

#------------
# pkgIndex.tcl
package ifneeded yourpackage 1.0 [list source [file join $dir yourpackage.tcl]]
#------------

Then the program using that library does

% lappend auto_path /path/to/yourpackage
% package require yourpackage
1.0
% yourpackage::proc3
this is proc3, now calling proc2
this is proc2, now calling proc1
this is proc1

etc.

| I believe everything I'm doing is pretty regular except that I wrapped
| the whole package in an all-encompassing proc.

And that exception is not usual. In fact, it would not pass any code
review by me :-)

| That one statement is not accurate. As it turns out, EVERYTHING I'm doing
| has its own namespace so nothing in it will clash with anything else in
| whatever application that may come to adopt it. It's one big proc inside
| one single namespace. ALL procs and variables reside in that namespace.

You did not show that namespace in the code you posted.
Such things are essential to show.

By defining a proc2 inside another proc1, you are *not* defining that
proc2 inside a somehow magically appearing namespace, you define it at
the same level as proc1 itself.

R'

On Fri, 04 Nov 2022 17:35:27 +0000, Robert Heller wrote:

> No. Wish (or package require Tk), does not "exit" upon EOF on the .tcl
> file. It does not exit until either the exit command is invoked or the
> main toplevel (.) is destroyed. So, what you really want bound to your
> "exit" button is:
>
> proc exitButton {} {
> # print the answer
> puts "This is the answer"
> # then exit
> exit
> }
>
> Or with a pure GUI environment (with no console screen or shell window):
>
> proc exitButton {} {
> # put up a message dialog box.
> tk_messageBox -icon info -message "This is the answer" -type ok
> # when the user clicks OK, exit the program.
> exit
> }
>

I can't use exit. It's a proc. It's meant to be used inside a parent
application. Calling [exit] will kill the parent application.

--
Luc
>>

* Luc <no@no.no>
| proc outside {} {
|
| proc inside {} {
| return "deep thoughts"
| }
| inside
| return "shallow thoughts"
| }
>
| puts [outside]
| --------------------
>
| How do I get the outside proc to return "deep thoughts"?

The simple answer of course is

proc outside {} {
return [inside]
}
proc inside {} {
return "deep thoughts"
}
outside
=> deep thoughts

But I suspect this is not what you're after...

R'

At Fri, 4 Nov 2022 14:17:39 -0300 Luc <no@no.no> wrote:

>
> On Fri, 4 Nov 2022 16:48:50 -0000 (UTC), Rich wrote:
>
> > It is not. As defining a proc, inside another proc, is only rarely
> > done, and even then, generally for very advanced "dynamic code
> > generation" reasons. None of which your example, nor initial question,
> > implied was happening.
>
> Are you saying I should remove everything from its all-enveloping proc
> and provide the entire idea as a plain page (though still with procs)
> and let people just [source] it instead of running it as a proc?

Sure. Or put something like "#!/usr/bin/tclsh" at the version top of the file,
call your main proc at the bottm, "chmod +x " it, and then people can just
./file.tcl.

> I admit I have thought about that.
>
>
> > By defining a proc, inside another proc, you are repeating the
> > creation of that 'inner' proc every time you execute the outer proc
> > (which if the outer proc is executed multiple times can result in a
> > rather significant performance loss).
>
> Yes, that's intended. All those procs are necessary every time the big proc
> is run. The big proc won't work without them.

It makes no difference if you have:

proc p1 {} {
}

proc p2 {} {
}
proc p3 {} {
}
proc p4 {} {
}
proc main {} {
p1
p2
p3
p4
}

OR

proc main {} {
proc p1 {} {
}
proc p2 {} {
}
proc p3 {} {
}
proc p4 {} {
}
p1
p2
p3
p4
}

except in the second case p1, p2, p3, and p4 probably won't get byte compiled.

>
> The big proc will not be executed multiple times. Well, it will, but not
> in rapid sequence. It's a tool that people will launch occasionally.
>
> I don't believe any of those procs is CPU or memory intensive.
>
> I believe everything I'm doing is pretty regular except that I wrapped
> the whole package in an all-encompassing proc.
>
> For example, take /usr/share/tcltk/tk8.6/bgerror.tcl. It has seven procs.
> Now put that entire page inside one parent proc. That's what I did.
> Sort of. That's all.
>
>
> > That is also not how the procs are organized once defined. Without any
> > namespace qualifiers, they are all created, at the same level, in the
> > current namespace.
>
> That one statement is not accurate. As it turns out, EVERYTHING I'm doing
> has its own namespace so nothing in it will clash with anything else in
> whatever application that may come to adopt it. It's one big proc inside
> one single namespace. ALL procs and variables reside in that namespace.
>

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

Luc <no@no.no> wrote:
> **************************
> On 4 Nov 2022 17:00:34 GMT, ted@loft.tnolan.com (Ted Nolan ) wrote:
>
>> I think he means this:
>>
>> Create a file like:
>>
>> ============
>> #!/usr/local/bin/tclsh8.6
>>
>> proc a {} {
>> puts "Hello from a!"
>>
>> proc b {} {
>> puts "hello from b!"
>> }
>>
>> }
>> a
>> b
>> ============
>>
>> and run it. The output will be:
>>
>> Hello from a!
>> hello from b!
>
>
> Yes, because [puts] has a way of piercing through armour.

Puts outputs the string to a file descriptor (stdout by default). That
results in output being sent to the destination of that file
descriptor. Strings given to puts simply get sent to the file
descriptor specified, no matter where they occur.

> Now, if only I could do that with [return]...

Return provides the value that the invocation of the proc produces at
the call site. This allows the proc to be used in many ways like a
Pascal function:

set returned_result_value [proc_xyz $parm1 $parm2]

And the value "returned" from invoking "proc_xyz" with those two
parameters is stored into the returned_result_value variable.

On 11/4/2022 2:36 AM, Luc wrote:
> Gentlemen, please:
>
> --------------------
> #!/usr/bin/env tclsh
>
> proc outside {} {
>
> proc inside {} {
> return "deep thoughts"
> }
> inside
> return "shallow thoughts"
> }
>
> puts [outside]
> --------------------
>
> How do I get the outside proc to return "deep thoughts"?
>
>

First of all, it is important to realize that nesting of proc's, in this
particular case, as well as generally in Tcl, is *not* relevant here.

You may need to define that proc inside of another for whatever reasons.
That is beside the point.

So, once you realize this, the question becomes:

I need to call a proc in my program flow. And then stop right there
before moving on to the next statement.

Once you read it like this, the solution is simple. use an "if"
statement and see if you wish to stop/return or continue on.

If it doesn't already have it, you need to equip your inner proc's with
some flag so that it can communicate to you how you need to proceed
after calling it.

Luc <no@no.no> wrote:
> **************************
> On Fri, 4 Nov 2022 17:16:53 -0000 (UTC), Rich wrote:
>
>> Something is broken in your Tcl interpreter (or you did not actually
>> run the same code you posted):
>>
>> $ rlwrap tclsh
>> proc out {} {
>> proc in {} {
>> return "deep thoughts"
>> }
>> return "shallow thoughts"
>> }
>> % puts [out]
>> shallow thoughts
>> % puts [in]
>> deep thoughts
>> %
>
>
> True.
>
> I think I ran it the other way around:
>
> puts [in]
> puts [out]

Yes, that would generate the error you saw. And not because "in" is
'hidden' inside out.

The "in" proc simply does not exist until after "out" has been executed
once, afterwhich the execution of out will have defined "in" and "in"
can be called as many times, from anywhere, as you like.

And, as well, for each subsequent time "out" is executed, the existing
"in" will be destroyed and a new "in" recreated in its place.

At Fri, 4 Nov 2022 14:48:26 -0300 Luc <no@no.no> wrote:

>
> On Fri, 04 Nov 2022 17:35:27 +0000, Robert Heller wrote:
>
> > No. Wish (or package require Tk), does not "exit" upon EOF on the .tcl
> > file. It does not exit until either the exit command is invoked or the
> > main toplevel (.) is destroyed. So, what you really want bound to your
> > "exit" button is:
> >
> > proc exitButton {} {
> > # print the answer
> > puts "This is the answer"
> > # then exit
> > exit
> > }
> >
> > Or with a pure GUI environment (with no console screen or shell window):
> >
> > proc exitButton {} {
> > # put up a message dialog box.
> > tk_messageBox -icon info -message "This is the answer" -type ok
> > # when the user clicks OK, exit the program.
> > exit
> > }
> >
>
> I can't use exit. It's a proc. It's meant to be used inside a parent
> application. Calling [exit] will kill the parent application.

OK, then you probably want tkwait:

proc main {} {
global theanswer
# build widgets, etc.
# wait for an answer
set theanswer {}
tkwait variable theanswer
return $theanswer
}

and on the Exit button -command option:

proc exitButton {} {
global theanswer
set theanswer "this is the answer"
}

[It would really be easier to help you if we could see the code. There is
probably something obvious going on that could be solved with a trivial bit of
code. It is easy and free to create an account on Github.]

--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller@deepsoft.com -- Webhosting Services

On 11/4/2022 1:56 PM, Ralf Fassel wrote:

> The simple answer of course is
>
> proc outside {} {
> return [inside]
> }
> proc inside {} {
> return "deep thoughts"
> }
> outside
> => deep thoughts
>
> But I suspect this is not what you're after...
>
> R'

I think he's looking for a simple if-statement there. However, [inside]
does not seem to have any way of letting [outside] know of its decision,
thus the OP's confusion. OP will need to modify the input/output of its
[inside] proc and without any context, no one can help him do this.

Luc <no@no.no> wrote:
> On Fri, 4 Nov 2022 16:48:50 -0000 (UTC), Rich wrote:
>
>> It is not. As defining a proc, inside another proc, is only rarely
>> done, and even then, generally for very advanced "dynamic code
>> generation" reasons. None of which your example, nor initial question,
>> implied was happening.
>
> Are you saying I should remove everything from its all-enveloping proc
> and provide the entire idea as a plain page (though still with procs)
> and let people just [source] it instead of running it as a proc?
> I admit I have thought about that.

Yes, unless you really are trying to do LISP like macro dynamic code
generation (which it does not sound like you are doing, and even if you
were, there are already packages [sugar] to do just that).

>> By defining a proc, inside another proc, you are repeating the
>> creation of that 'inner' proc every time you execute the outer proc
>> (which if the outer proc is executed multiple times can result in a
>> rather significant performance loss).
>
> Yes, that's intended. All those procs are necessary every time the big proc
> is run. The big proc won't work without them.
>
> The big proc will not be executed multiple times. Well, it will, but not
> in rapid sequence. It's a tool that people will launch occasionally.
>
> I don't believe any of those procs is CPU or memory intensive.
>
> I believe everything I'm doing is pretty regular except that I wrapped
> the whole package in an all-encompassing proc.

That is the part that is 'irregular'. Wrapping proc definitions inside
another "proc" is *very irregular* except in specific circumstances
(that being LISP macro like dynamic code generation).

> For example, take /usr/share/tcltk/tk8.6/bgerror.tcl. It has seven procs.
> Now put that entire page inside one parent proc. That's what I did.
> Sort of. That's all.

Which sounds like you might be looking for namespaces or objects, not
"procs in procs".

>> That is also not how the procs are organized once defined. Without
>> any namespace qualifiers, they are all created, at the same level,
>> in the current namespace.
>
> That one statement is not accurate. As it turns out, EVERYTHING I'm doing
> has its own namespace so nothing in it will clash with anything else in
> whatever application that may come to adopt it. It's one big proc inside
> one single namespace. ALL procs and variables reside in that namespace.

I do not believe that I have seen you say anywhere in this thread so
far that you were doing all this inside a namespace.

My statement was perfectly accurate when not in a namespace, which is
what the "without any namespace qualifiers" was getting at.

If you are looking to isolate this set of "sub-procs" from the rest of
your "application" then create them inside a unique namespace (it can
even be a sub namespace of this "one single namespace").

I.e.:

namespace eval ::luc {

# stuff in your existing "one single namespace"

}

later in the same source file, or in a separate file that is itself
sourced:

namespace eval ::luc::sub-module {

# the "inner procs" which you wrapped in an outer proc go here

}

All those 'procs' will be inside the sub-module namespace, which is
itself inside the luc namespace. If you don't want them there, you can
also put them into ::sub-module1 if you like.

Or, look into 'objects', which also allow you to "put procs inside
containers" (the 'procs' inside objects are called 'methods'). One
advantage of objects is you can then create more than one 'object' in
your outer code, and each 'object' will have its own set of inner
'procs' (methods), isolated from the 'procs' of the other objects of
the same type.

On 11/4/22 11:00, Robert Heller wrote:
> At Fri, 4 Nov 2022 10:17:17 -0500 Gerald Lester <Gerald.Lester@KnG-Consulting.net> wrote:
>
>>
>> On 11/4/22 09:34, Luc wrote:
>>> **************************
>>> On Fri, 4 Nov 2022 13:36:14 -0000 (UTC), Rich wrote:
>>>
>>>> Ralf Fassel <ralfixx@gmx.de> wrote:
>>>>> Why is proc2 *inside* proc1?
>>>
>>>> Indeed, an answer to this question is important.
>>>
>>> ************************
>>>
>>> I believe the answer is pretty obvious.
>>>
>>> It's a large proc. I need to organize everything in sub functions
>>> inside the function.
>>
>> Ah, you do realize that all procs are globally addressable -- there is
>> no such thing as a sub function in Tcl.
>
> You can sort of get that with OOP with member functions (eg SNIT, incrTcl,
> BWidget). You can also use namespaces to "protect" things and avoid problems
> with name clashes.

I know.

Procs in namespaces still can be called from anywhere -- you can even
call "private" OO methods if you know what you are doing.

>>
>> A Tcl proc, can have another proc declared inside of it -- but that just
>> causes it to be defined/redefined at runtime and it can be called by anyone.
>>
>> Now a Tcl proc can *call* another function, but that does not make it
>> "inside" nor does it make it a aub function.
>
> It sounds like that OP wants to create a class with "private" members (or
> something like that). Tcl has OOP extensions, but I don't think any implement
> strickly private (or protected) members or methods (AFAIK). (SNIT doesn't.)

I think he was local procedures like some of the Algol languages give
you -- the "inside" procedure is only visible in the scope of the
procedure it is declared in -- but it really could be anything due to
his very imprecise language.

>
>>
>>> ...
>>> The return -code return "deep thoughts" idea doesn't work either.
>>> The "deep thoughts" example I posted previously is too simple to reflect
>>> what I have here. I basically need a command that says
>>> STOP EVERYTHING RIGHT NOW, RETURN THIS STRING AND DISAPPEAR
>>
>> You need to combine [info level] with [return] -- please read both
>> man/help pages in detail and pay close attention to the level option on
>> the return.
>
> I suspect that this won't help either. He wants to exit a proc on a button
> click. The button -command is running at level 0 and the proc is somewhere
> else (or maybe already exited).

Oh, that was not my read -- so either the proc would have to be a a
vwait/update or it would have to be an a different interp.

>
> I suspect he really wants tkwait:
>
> proc main {} {
> global theanswer
> ## build widgets and start processing
> set theanswer {}
> tkwait variable theanswer
> return $theanswer
> }
>
> And somewhere there is a button with a -command bound to a proc like:
>
> proc buttonpress {} {
> global theanswer
> set theanswer "This is the answer"
> }
>
>
>>
>>
>

--
+----------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald.Lester@kng-consulting.net |
+----------------------------------------------------------------------+

On 11/4/22 11:54, Luc wrote:
> On Fri, 4 Nov 2022 10:17:17 -0500, Gerald Lester wrote:
>
>> Ah, you do realize that all procs are globally addressable -- there is
>> no such thing as a sub function in Tcl.
>
> I don't understand what you mean.
>
> proc out {} {
> proc in {} {
> return "deep thoughts"
> }
> return "shallow thoughts"
> }
>
> % puts [out]
> shallow thoughts
>
> % puts [in]
> invalid command name "in"
> while executing
> "in"
> invoked from within
> "puts [in]"
> (file "procproc.tcl" line 9)
> Compilation failed.

Ok, you must not be using Tcl but Tcl inside of something else that is
doing magic!

Here is what happens in Tcl:
gerald@gerald-laptop:~$ cat temp.tcl

proc out {} {
proc in {} {
return "deep thoughts"
}
return "shallow thoughts"
}

puts [out]
puts [in]

gerald@gerald-laptop:~$ tclsh temp.tcl
shallow thoughts
deep thoughts

--
+----------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC |
| Email: Gerald.Lester@kng-consulting.net |
+----------------------------------------------------------------------+