....

While working on BEGINFILE/ENDFILE/nextfile extension, I've
got I/O logic that makes nested loops possible. In a simplest
case it can be used as follows (if you trust the input :)

$ cat test1.txt
A
include test2.txt
B

$ cat test2.txt
c
d

$ xgawk  '/include/ {with $2; next} {print}' test1.txt
A
c
d
B

patch is at http://xgawk.radlinux.org/Articles/patch-fileworks/show

Peter V. Saveliev wrote:
> ...
> 
> While working on BEGINFILE/ENDFILE/nextfile extension, I've
> got I/O logic that makes nested loops possible. In a simplest
> case it can be used as follows (if you trust the input :)
> 
> $ cat test1.txt
> A
> include test2.txt
> B
> 
> $ cat test2.txt
> c
> d
> 
> $ xgawk  '/include/ {with $2; next} {print}' test1.txt
> A
> c
> d
> B
> 
> patch is at http://xgawk.radlinux.org/Articles/patch-fileworks/show
> 

Why "with" instead of "include" for the keyword? What happens if a file 
named $2 doesn't exist or isn't readable? Does it print the value of $2, 
or print nothing but succeeed, or abort the program, or....? What if the 
file test2.txt contains:

    include test1.txt

Is that infinitely recursive or do you detect trying to open a file 
that's already open?

	Ed.

<skip />
> Why "with" instead of "include" for the keyword?

@include is used to include awk code (as -f in the command line). I
used "with" as it is so in some object-oriented languages to specify
variables scope. Anyway, the name for keyword is not of fundamental
importance, I think: if most of developers will prefer "include", I (or
anyone
else) can change it.

> What happens if a file
> named $2 doesn't exist or isn't readable?

As usual, fatal(). For now, exceptions aren't handled in awk. Statement
like "try {} catch // {} else {}" is in my todo but it is not realized
yet.

> Does it print the value of $2,
> or print nothing but succeeed, or abort the program, or....? What if the
> file test2.txt contains:
>
>     include test1.txt
>
> Is that infinitely recursive or do you detect trying to open a file
> that's already open?

There will be an infinite loop. Now it is up to developer to detect
such
situations, example from standard gawk:

$ cat 1.txt
1
2

$ strace -e trace=file gawk '{print; getline <"1.txt"; print}' 1.txt
....
open("1.txt", O_RDONLY)                 = 3
1
open("1.txt", O_RDONLY)                 = 4
1
2
2

The behaviour can be changed but we must decide in which way.

Peter V. Saveliev wrote:
> <skip />
> 
>>Why "with" instead of "include" for the keyword?
> 
> 
> @include is used to include awk code (as -f in the command line). I
> used "with" as it is so in some object-oriented languages to specify
> variables scope. Anyway, the name for keyword is not of fundamental
> importance, I think: if most of developers will prefer "include", I (or
> anyone
> else) can change it.

"include" just seems the most natural, obvious word. "with" doesn't have 
any obvious connotations for file inclusion, and I don't see the 
relationship between variable scope and including a file.

> 
>>What happens if a file
>>named $2 doesn't exist or isn't readable?
> 
> 
> As usual, fatal().

I'm not sure what that means. In gawk it wouldn't be a fatal error to 
call getline on a file that isn't readable unless gawk was invoked in 
POSIX compliance mode. Are you just saying that those same "getline" 
rules apply here or that it's always a fatal error for "with"?

  For now, exceptions aren't handled in awk. Statement
> like "try {} catch // {} else {}" is in my todo but it is not realized
> yet.
> 
> 
>>Does it print the value of $2,
>>or print nothing but succeeed, or abort the program, or....? What if the
>>file test2.txt contains:
>>
>>    include test1.txt
>>
>>Is that infinitely recursive or do you detect trying to open a file
>>that's already open?
> 
> 
> There will be an infinite loop. Now it is up to developer to detect
> such
> situations, example from standard gawk:
> 
> $ cat 1.txt
> 1
> 2
> 
> $ strace -e trace=file gawk '{print; getline <"1.txt"; print}' 1.txt
> ...
> open("1.txt", O_RDONLY)                 = 3
> 1
> open("1.txt", O_RDONLY)                 = 4
> 1
> 2
> 2
> 
> The behaviour can be changed but we must decide in which way.
> 

The getline behavior could, arguably, be useful and it's at least not 
clearly detsructive. For "with", there doesn't seem to be any possible 
benefit to allowing it to go into an infinite loop, so I'd vote for 
changing it to an error like trying to open an unreadable file.

By the way, does "with" have a retun code that could be tested? Does it 
set ERRNO?

	Ed.

Ed Morton wrote:

> Peter V. Saveliev wrote:
> 
>> <skip />
>>
>>> Why "with" instead of "include" for the keyword?
>>
>>
>>
>> @include is used to include awk code (as -f in the command line). I
>> used "with" as it is so in some object-oriented languages to specify
>> variables scope. Anyway, the name for keyword is not of fundamental
>> importance, I think: if most of developers will prefer "include", I (or
>> anyone
>> else) can change it.
> 
> 
> "include" just seems the most natural, obvious word. "with" doesn't have 
> any obvious connotations for file inclusion, and I don't see the 
> relationship between variable scope and including a file.

Maybe I'm misunderstanding what "with" does. Having read your posted 
example and the reference page, 
http://xgawk.radlinux.org/Articles/patch-fileworks/show, I've been 
thinking it just lets you print an included file, like you'd get with this:

     awk 'function with(file) {
            while ( (getline < file) > 0)
                if ($1 == "include") with($2)
                else print
            close(file)
        }
        BEGIN{ with(ARGV[1]) }' file1

but that doesn't seem to really warrant a new language construct and 
rereading the reference I see something at the end about a nextfile that 
doesn't seem to fit with my assumption. Is the above it, or does it do 
something more?

	Ed.

<skip />
> Maybe I'm misunderstanding what "with" does. Having read your posted
> example and the reference page,
> http://xgawk.radlinux.org/Articles/patch-fileworks/show, I've been
> thinking it just lets you print an included file, like you'd get with this:
>
>      awk 'function with(file) {
>             while ( (getline < file) > 0)
>                 if ($1 == "include") with($2)
>                 else print
>             close(file)
>         }
>         BEGIN{ with(ARGV[1]) }' file1
>
> but that doesn't seem to really warrant a new language construct and
> rereading the reference I see something at the end about a nextfile that
> doesn't seem to fit with my assumption. Is the above it, or does it do
> something more?
<skip />

Call of "with" does not print a file. It allows to apply record
statements to
a file. Current input I/O loop (let's call it 1) is suspended,
FNR/NR/FILENAME
are to be saved, and a nested input loop (2) is started. In two words,
"with"
applies io.c:do_input() on a file. When (2) hits EOF, nested loop
exits,
restores FNR, NR, FILENAME and a record $0 itself (this lets a record
that
spawns (2) to be consistent)

At the next iteration increments restored FNR and increments NR from
the
highest value got in a nested loop.

That's because I used "with". As in an object-oriented environment, if
you
call a method or refer a variable, it can be acquired from an object
that
makes current scope. After you call "with object2" the same code will
operate with methods and objects with the same names but owned by
object2.

So, here if you define records:

/pat1/ {statement1}
/pat2/ {statement2}
/pat3/ {with "file2"}

then "with" will start I/O loop that applies statement1, statement2 and
so
on to the file2. After there is no input records left in file2, I/O
returns the
control to the parent I/O loop from where it was called.

Peter V. Saveliev wrote:

> <skip />
> 
>>Maybe I'm misunderstanding what "with" does. Having read your posted
>>example and the reference page,
>>http://xgawk.radlinux.org/Articles/patch-fileworks/show, I've been
>>thinking it just lets you print an included file, like you'd get with this:
>>
>>     awk 'function with(file) {
>>            while ( (getline < file) > 0)
>>                if ($1 == "include") with($2)
>>                else print
>>            close(file)
>>        }
>>        BEGIN{ with(ARGV[1]) }' file1
>>
>>but that doesn't seem to really warrant a new language construct and
>>rereading the reference I see something at the end about a nextfile that
>>doesn't seem to fit with my assumption. Is the above it, or does it do
>>something more?
> 
> <skip />
> 
> Call of "with" does not print a file. It allows to apply record
> statements to
> a file. Current input I/O loop (let's call it 1) is suspended,
> FNR/NR/FILENAME
> are to be saved, and a nested input loop (2) is started. In two words,
> "with"
> applies io.c:do_input() on a file. When (2) hits EOF, nested loop
> exits,
> restores FNR, NR, FILENAME and a record $0 itself (this lets a record
> that
> spawns (2) to be consistent)
> 
> At the next iteration increments restored FNR and increments NR from
> the
> highest value got in a nested loop.
> 
> That's because I used "with". As in an object-oriented environment, if
> you
> call a method or refer a variable, it can be acquired from an object
> that
> makes current scope. After you call "with object2" the same code will
> operate with methods and objects with the same names but owned by
> object2.
> 
> So, here if you define records:
> 
> /pat1/ {statement1}
> /pat2/ {statement2}
> /pat3/ {with "file2"}
> 
> then "with" will start I/O loop that applies statement1, statement2 and
> so
> on to the file2. After there is no input records left in file2, I/O
> returns the
> control to the parent I/O loop from where it was called.
> 

Got it. Makes sense. Still hate "with" ;-). "include" doesn't quite 
capture it either though. Since we have a "nextfile" keyword, could we 
come up with something more consistent with that but which really 
captures the fact that we're temporarily jumping into a new file and 
will come back when we're done, e.g. "stackfile"? I know, any word will 
do, but when adding a new keyword to a language it's well worth taking 
the time to consider the best possible choice of word since once you 
make that choice, it's going to be around for a very long time....

	Ed.

Ed Morton wrote:
> Peter V. Saveliev wrote:
> 

>>
>> So, here if you define records:
>>
>> /pat1/ {statement1}
>> /pat2/ {statement2}
>> /pat3/ {with "file2"}
>>
>> then "with" will start I/O loop that applies statement1, statement2 and
>> so
>> on to the file2. After there is no input records left in file2, I/O
>> returns the
>> control to the parent I/O loop from where it was called.
>>
> 
> Got it. Makes sense. Still hate "with" ;-). "include" doesn't quite 
> capture it either though. Since we have a "nextfile" keyword, could we 
> come up with something more consistent with that but which really 
> captures the fact that we're temporarily jumping into a new file and 
> will come back when we're done, e.g. "stackfile"? I know, any word will 
> do, but when adding a new keyword to a language it's well worth taking 
> the time to consider the best possible choice of word since once you 
> make that choice, it's going to be around for a very long time....
> 

Sounds like 'source' in shell or troff.
Of course 'include' from C pre-processor is quite close too,
even resetting line numbers etc.

Ed Morton escribi�:
> ...
> Got it. Makes sense. Still hate "with" ;-). "include" doesn't quite 
> capture it either though. Since we have a "nextfile" keyword, could we 
> come up with something more consistent with that but which really 
> captures the fact that we're temporarily jumping into a new file and 
> will come back when we're done, e.g. "stackfile"? I know, any word will 
> do, but when adding a new keyword to a language it's well worth taking 
> the time to consider the best possible choice of word since once you 
> make that choice, it's going to be around for a very long time....

Possible alternatives:
- getfile
- takefile
- processfile
- insertfile
- inputfile
- getinput
- getinputfrom
- readfrom
- readfromfile
- inputfrom
- ... etc.

-- 
Mauel Collado - http://lml.ls.fi.upm.es/~mcollado

Le Mon, 30 Oct 2006 11:48:28 -0600, Ed Morton a �crit�:

> Peter V. Saveliev wrote:
> 
>> <skip />
>> 
>>>Maybe...
>> 
>> then "with" will start I/O loop that applies statement1, statement2 and
>> so
>> on to the file2. After there is no input records left in file2, I/O
>> returns the
>> control to the parent I/O loop from where it was called.
>> 
> 
> Got it. Makes sense. Still hate "with" ;-). "include" doesn't quite 
> capture it either though. Since we have a "nextfile" keyword, could we 
> come up with something more consistent with that but which really 
> captures the fact that we're temporarily jumping into a new file and 
> will come back when we're done, e.g. "stackfile"? I know, any word will 
> do, but when adding a new keyword to a language it's well worth taking 
> the time to consider the best possible choice of word since once you 
> make that choice, it's going to be around for a very long time....
> 
> 	Ed.

  I'll second this opinion, I kind of like the functionality you're
adding (though it's not within my regular use of awk I sometimes had to
simulate this function), anyway the idea of 'naming' it <<WITH>>
is desastrous to my ears, eyes, brains, whatever :-)

  Maybe it'd be easier to submit a vote from any possible awk group ?
  Any (not fully unknown) participant would be able to give his idea
on the naming of the shrew ?

  For instance, the previous question was, possibly  :

 Q1	would you use this awk extension ?
 A1	not right now but next time I'll need it it'll save me
	of a few hours to try and decide the way I have to chop
	and store data, this may seem a laugh but dealing with
	*huge* datafile on living bodies is not that `simple' ;-)

 Q2	Preference on names for the extension, score from 0 (never) to
	5 (hunky dory) append your proposal if any:
 A2
    - "whith"		1
    - "stackfile"	3
    - "slack"		5


  Ah, in case this'd arise over-reactions from fast readers: I was half
joking and half serious, although I like the idea ;D)

Three words that popped into my head as replacements for "with" (well,
one is not a real word):

reading
subread
readdown or downread

The "sub" or "down" might connote "nestedness"?

I don't have any particular preference for these but merely offer them
as possibilities.

Galen

"Manuel Collado" <m.collado@fi.upm.es> wrote in message
news:45467ce0@news.upm.es...
>
> Possible alternatives:
> - getfile
> - takefile
> - processfile
> - insertfile
> - inputfile
> - getinput
> - getinputfrom
> - readfrom
> - readfromfile
> - inputfrom
> - ... etc.

Perhaps "insertfrom"? As in:

$1 ~ /includepat/ { insertfrom $2 }

Or maybe  "includefrom":

$1 ~ /includepat/ { includefrom $2 }

"Include" is so associated with the idea of "insert the entire contents of
another file at this point in the current file" that it seems a shame not to
use that connotation somehow.

- Anton Treuenfels

Anton Treuenfels wrote:

> Perhaps "insertfrom"? As in:
> 
> $1 ~ /includepat/ { insertfrom $2 }
> 
> Or maybe  "includefrom":
> 
> $1 ~ /includepat/ { includefrom $2 }
> 
> "Include" is so associated with the idea of "insert the entire contents of
> another file at this point in the current file" that it seems a shame not to
> use that connotation somehow.

Yes, "insertfile" or "insertfrom" really points
the user into the right direction.

I'm afraid that any usage of "include" can be interpreted in the
sense of C #include or xgawk @include: in the sense of source
inclusion. This ability have nothing to do with source inclusion,
it is just temporary input stream switching; or stacking.

<skip />
> Yes, "insertfile" or "insertfrom" really points
> the user into the right direction.

So, I'd prefer "stackfile" or "insertfile" or just "stack". About
"insertfrom", it is clear, from where something will be inserted.
It isn't clear, what exactly will be inserted -- a record (I know,
there is getline, but a newbie may not (I know, rtfm and so on,
but who follows this way before reading a code? a few from
many)), whole file or something else.

OT: as a joke: what about "stick" or "stickfile" or ever "stumble"? :)))

Peter V. Saveliev wrote:

> /pat1/ {statement1}
> /pat2/ {statement2}
> /pat3/ {with "file2"}
> 
> then "with" will start I/O loop that applies statement1, statement2 and
> so
> on to the file2. After there is no input records left in file2, I/O
> returns the
> control to the parent I/O loop from where it was called.
> 

Now I understand why you call it "with" and why
Manuel suggested "processfile".

Do you have any realistic application for this ?
This looks like a powerful feature, but (as always
with powerful new features) it is hard to imagine
when we will apply this feature in daily work.

<skip />
> Now I understand why you call it "with" and why
> Manuel suggested "processfile".
>
> Do you have any realistic application for this ?
> This looks like a powerful feature, but (as always
> with powerful new features) it is hard to imagine
> when we will apply this feature in daily work.

As an example:
http://groups.google.com/group/comp.lang.awk/browse_thread/thread/fe26bf9fdebf9458#c9301bef6e599789


Another example:

$ cat doc.xml
<document>
        <head source="head.xml" />
        <body source="body.xml" />
<document>

$ cat head.xml
<header>
        <title>title</title>
</header>

$ cat body.xml
<chapter>
        <para>
                bala
        </para>
</chapter>

$ cat process.awk
@load xml

BEGIN {
        print "<html>"
        tB["header"]  = "head"
        tB["title"]   = "title"
        tB["chapter"] = "body"
        tB["para"]    = "p"
}

END {
        print "</html>"
}

$0 ~ /source/ {
        file = XMLATTR["source"]
        with file
}

XMLSTARTELEM {
        if (tB[XMLSTARTELEM]) print "<"tB[XMLSTARTELEM]">"
}

XMLENDELEM {
        if (tB[XMLENDELEM]) print "</"tB[XMLENDELEM]">"
}

XMLCHARDATA {
        if ($0 && !($0 ~ /^[[:blank:]\n]+$/)) print $0


$ xgawk -f process.awk doc.xml
<html>
<head>
<title>
title
</title>
</head>
<body>
<p>

                bala

</p>
</body>
</html>

"J�rgen Kahrs" <Juergen.KahrsDELETETHIS@vr-web.de> wrote in message > Do you
have any realistic application for this ?

> This looks like a powerful feature, but (as always
> with powerful new features) it is hard to imagine
> when we will apply this feature in daily work.

I use it for text transformations, of course. One application is an
assembler where the "includes" are assembler source code files. Another is a
simple text-to-html converter where the "includes" are various documents I
want "automagically" cross-referenced to each other (and sometimes to merge
several input documents into one HTML document while leaving others
separate).

- Anton Treuenfels

Anton Treuenfels wrote:

> I use it for text transformations, of course. One application is an
> assembler where the "includes" are assembler source code files. Another is a
> simple text-to-html converter where the "includes" are various documents I
> want "automagically" cross-referenced to each other (and sometimes to merge
> several input documents into one HTML document while leaving others
> separate).

This is interesting. If new features are motivated
by such practical needs, it is much more likely that
users will really adopt them. Sounds like Peter's
new "with" feature makes sense (whatever keyword
will be used instead of "with").

"Peter V. Saveliev" <peet@peet.spb.ru> wrote in message
news:1162374911.861640.200920@e3g2000cwe.googlegroups.com...
>
> I'm afraid that any usage of "include" can be interpreted in the
> sense of C #include or xgawk @include: in the sense of source
> inclusion. This ability have nothing to do with source inclusion,
> it is just temporary input stream switching; or stacking.
>
> <skip />
> > Yes, "insertfile" or "insertfrom" really points
> > the user into the right direction.
>
> So, I'd prefer "stackfile" or "insertfile" or just "stack". About
> "insertfrom", it is clear, from where something will be inserted.
> It isn't clear, what exactly will be inserted -- a record (I know,
> there is getline, but a newbie may not (I know, rtfm and so on,
> but who follows this way before reading a code? a few from
> many)), whole file or something else.

Well, I kind of like:

$1 ~ /includepat/ {
    pushfile( FILENAME )
    FILENAME = $2
}

but it's not at all clear where or when the corresponding

{ FILENAME = popfile() }

should take place. I mean, I know where and when and how and why I do these
things in my own implementation of these concepts, but it's not entirely
clear to me how to do them automatically in an intuitive manner.

Eg, if there was an explicit pushfile() should there be an explicit
popfile()? If there was an explicit popfile() and I didn't use it, would it
then happen implicitly as the last operation of an ENDFILE block? And if it
did, what if there wasn't an ENDFILE block?

In my own use the main loop goes something like this:

- pushfile( ARGV[1] )
- while ( popfile() ) {
- while ( !EOF(FILENAME) ) {
- $0 = getline
- dostuff
- }
- }

Then "include" goes like this:

- pushfile( FILENAME )
- pushfile( includefile )
- popfile()

And "popfile" goes like this:

- while( stkptr ) {
- FILENAME = filestack[ stkptr-- ]
- if ( fopen(FILENAME) )
- return TRUE
- }
- return FALSE

So basically every file can be interrupted by an include that will be read
to completion before it is resumed (or if the include file can't be opened
the interrupted file will be popped right away.

But in this case I've kind of built the concept of include files right into
the "automatic input loop" (even if it is really a manual input loop) to
start with. And I don't really handle the idea of more than one file named
on the command line. Maybe that would look like this:

- do BEGIN
- while ( ARGI < ARGC ) {
- do BEGINFILE( ARGV[ARGI] )
- pushfile( ARGV[ARGI] )
- while ( popfile() ) {
- while ( !EOF(FILENAME) ) {
- $0 = getline
- do rules
- }
- }
- do ENDFILE( ARGV[ARGI++] )
- }
- do END

where, yes, I'm using ARGI which doesn't exist in gawk :(. But you get the
idea.

- Anton Treuenfels

PS. How about "slurpfile"?

$1 ~ /includepat/ { slurpfile $2 }

<skip />
> Well, I kind of like:
>
> $1 ~ /includepat/ {
>     pushfile( FILENAME )
>     FILENAME = $2
> }
>
> but it's not at all clear where or when the corresponding
>
> { FILENAME = popfile() }


pushfile. Ok, it's a good keyword.

About popfile: a nested I/O loop is terminated either with EOF
(implicilty), or with nextfile (explicitly). I can introduce popfile
as an alias for nextfile, but I think it is overkill.


<skip />
> If there was an explicit popfile() and I didn't use it, would it

there is an explicit nextfie

> then happen implicitly as the last operation of an ENDFILE
> block? And if it

strictly speaking, interpret(endfile_block) is called from
iop_close() called from nextfile(). But, roughly speaking,
you're right.

> did, what if there wasn't an ENDFILE block?

if there is no endfile_block, no endfile_block is to be interpreted
at the end of input :) But there will be end of input anyway, and
file will be closed.

<skip />

The exact way the nesting is working you can see in the code,
take a look at:
  run_io_thread()
  do_input()
  do_with()
  do_nextfile()
  nextfile()
in io.c

Peter V. Saveliev wrote:

> ...
> 
> While working on BEGINFILE/ENDFILE/nextfile extension, I've
> got I/O logic that makes nested loops possible. In a simplest
> case it can be used as follows (if you trust the input :)
> 
> $ cat test1.txt
> A
> include test2.txt
> B
> 
> $ cat test2.txt
> c
> d
> 
> $ xgawk  '/include/ {with $2; next} {print}' test1.txt
> A
> c
> d
> B
> 
> patch is at http://xgawk.radlinux.org/Articles/patch-fileworks/show
> 

Did you ever reach a conclusion on a keyword? I saw the following 
suggestions (and I added a couple, subfile, scopefile and childfile, 
that just occurred to me since you don't have enough to consider :-) ):

    childfile
    downread
    getfile
    getinput
    getinputfrom
    include
    includefrom
    inputfile
    inputfrom
    insertfile
    insertfrom
    processfile
    pushfile
    readdown
    readfrom
    readfromfile
    reading
    scopefile
    slurpfile
    source
    stack
    stackfile
    subfile
    subread
    takefile
    with

FWIW, I'd like the keyword to end in "file" since it is a file operation 
and it can be terminated by "nextfile" (it's all about symmetry and the 
QWAN!).

I like the association with a stack since the way you're processing this 
file has a lot in common with the way a function gets a stack when it's 
called and releases it when done or the way in which a variable in a C 
program can be declared and used within a given scope, ending when the 
end of the scope/function is reached (like reaching the end of an input 
file) or when it explicitly "return"s or "goto"s (like using "nextfile").

I also see a similarity between this and the way a foreground child 
process is explicitly spawned in UNIX and then can either die when it's 
done (like reaching the end of an input file) or it explicitly "exist"s 
(like using "nextfile").

So, all things considered, my vote would still be for "stackfile" since 
I think it's got the clearest "stack" connotation, but I could also see 
"scopefile", "childfile", and "subfile" (intended to be like "gosub" in 
BASIC for calling subroutines). That those were my suggestions is, of 
course, pure co-incidence....

	Ed.

Ed Morton wrote:
> Peter V. Saveliev wrote:
> 
>> ...
>>
>> While working on BEGINFILE/ENDFILE/nextfile extension, I've
>> got I/O logic that makes nested loops possible. In a simplest
>> case it can be used as follows (if you trust the input :)
>>
>> $ cat test1.txt
>> A
>> include test2.txt
>> B
>>
>> $ cat test2.txt
>> c
>> d
>>
>> $ xgawk  '/include/ {with $2; next} {print}' test1.txt
>> A
>> c
>> d
>> B
>>
>> patch is at http://xgawk.radlinux.org/Articles/patch-fileworks/show
>>
> 
> Did you ever reach a conclusion on a keyword? I saw the following 
> suggestions (and I added a couple, subfile, scopefile and childfile, 
> that just occurred to me since you don't have enough to consider :-) ):
> 
>    childfile
>    downread
>    getfile
>    getinput
>    getinputfrom
>    include
>    includefrom
>    inputfile
>    inputfrom
>    insertfile
>    insertfrom
>    processfile
>    pushfile
>    readdown
>    readfrom
>    readfromfile
>    reading
>    scopefile
>    slurpfile
>    source
>    stack
>    stackfile
>    subfile
>    subread
>    takefile
>    with
> 
> FWIW, I'd like the keyword to end in "file" since it is a file operation 
> and it can be terminated by "nextfile" (it's all about symmetry and the 
> QWAN!).

Seconded.

> I like the association with a stack since the way you're processing this 
> file has a lot in common with the way a function gets a stack when it's 
> called and releases it when done or the way in which a variable in a C 
> program can be declared and used within a given scope, ending when the 
> end of the scope/function is reached (like reaching the end of an input 
> file) or when it explicitly "return"s or "goto"s (like using "nextfile").

(Though, there is a possible generalization of stack logic; see below.)

> I also see a similarity between this and the way a foreground child 
> process is explicitly spawned in UNIX and then can either die when it's 
> done (like reaching the end of an input file) or it explicitly "exist"s 
> (like using "nextfile").
> 
> So, all things considered, my vote would still be for "stackfile" since 
> I think it's got the clearest "stack" connotation, but I could also see 
> "scopefile", "childfile", and "subfile" (intended to be like "gosub" in 
> BASIC for calling subroutines). That those were my suggestions is, of 
> course, pure co-incidence....
> 
>     Ed.

Let me throw in another two cents...

   'resumefile'
   'callfile'  [1]

would allow extensions for non-sequential processing (quasi-parallel
read) comparable to the coprocess call structure in Simula[2]. (Then
there would be an additional 'detachfile' to complete that logic[2].)
Possible applications might be "union-find" and data driven types of
problems. (I'll post an example if I can make one up; not quite sure
whether such a generalization of the stack concept could be helpful.)

Janis

[1] Equivalent to the 'subfile' suggestion but naming schema consistent
with Simula namenclature.

[2] For details about the concepts see (e.g.)...
http://tinyurl.com/y5s5qf (PDF file, ACM org)
http://staff.um.edu.mt/jskl1/talk.html (Ch."SIMULA QUASIPARALLEL SYSTEMS")

Janis Papanagnou wrote:
<snip>
> Let me throw in another two cents...
> 
>   'resumefile'
>   'callfile'  [1]

While I can see the functional relationship between Simula's "call" and 
what we're doing, IMHO "callfile" sounds like you're calling a script in 
a separate file so it'd be misleading to anyone who didn't understand 
the history of the term.

	Ed.

Le Sat, 11 Nov 2006 13:38:20 -0600, Ed Morton a �crit�:

> Janis Papanagnou wrote:
> <snip>
>> Let me throw in another two cents...
>> 
>>   'resumefile'
>>   'callfile'  [1]
> 
> While I can see the functional relationship between Simula's "call" and 
> what we're doing, IMHO "callfile" sounds like you're calling a script in 
> a separate file so it'd be misleading to anyone who didn't understand 
> the history of the term.
> 

  I also get this feeling, though I sort of liked the idea of
calling "operator operator" thus it could as well be named
'menphistenesseefile'

  OK, I still believe 'stackfile' is a good short clean and effective
name for what we're looking at :-)