Re: MAIN conflict in S06?
On Thu, Nov 13, 2008 at 07:19:31PM -0600, Patrick R. Michaud wrote: : S06:2362 says: : : You can get the current routine name by calling C?ROUTINE.name. : (The outermost routine at a file-scoped compilation unit is always : named CMAIN in the file's package.) : : Is this the same MAIN that is described later in : Declaring a MAIN subroutine? It seems like that : section describes MAIN subroutines that are lexically : nested within the mainline code of the outermost : file-scoped compilation unit, and it seems a little : confusing if both are called MAIN. : : I'm guessing that the statement at S06:2362 is an artifact of : an earlier draft that didn't have the section on MAIN subroutines, : but I'm wanting to verify that this is the case (or seek further : clarification if it isn't). That's correct. We could fix it two ways. Either the mainline code gets a consistent new name, or the outermost scope is redefined to an INIT if there is a user-defined MAIN. I can argue it both ways. Larry
Re: MAIN conflict in S06?
On 2008 Nov 14, at 12:14, Larry Wall wrote: On Thu, Nov 13, 2008 at 07:19:31PM -0600, Patrick R. Michaud wrote: : S06:2362 says: : : You can get the current routine name by calling C? ROUTINE.name. : (The outermost routine at a file-scoped compilation unit is always : named CMAIN in the file's package.) : : Is this the same MAIN that is described later in : Declaring a MAIN subroutine? It seems like that : section describes MAIN subroutines that are lexically : nested within the mainline code of the outermost : file-scoped compilation unit, and it seems a little : confusing if both are called MAIN. : : I'm guessing that the statement at S06:2362 is an artifact of : an earlier draft that didn't have the section on MAIN subroutines, : but I'm wanting to verify that this is the case (or seek further : clarification if it isn't). That's correct. We could fix it two ways. Either the mainline code gets a consistent new name, or the outermost scope is redefined to an INIT if there is a user-defined MAIN. I can argue it both ways. WHat *is* the outermost scope in that case? When is code in that scope executed? I could see this as being a hack to allow a module to be used either directly as a main, or used; the former ignoring top level scope code, the latter ignoring MAIN. I think Python has something similar. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: MAIN conflict in S06?
On Fri, Nov 14, 2008 at 01:50:59PM -0500, Brandon S. Allbery KF8NH wrote: WHat *is* the outermost scope in that case? When is code in that scope executed? I could see this as being a hack to allow a module to be used either directly as a main, or used; the former ignoring top level scope code, the latter ignoring MAIN. I think Python has something similar. Python names the outermost scope __MAIN__ if the file is directly interpreted, but it gets a name related to the filename if it is used. That outermost code is always executed, but the standard idiom to have code that is only executed when the file is executed directly is to wrap it in an if test that compares the name against __MAIN__.
