Re: lex - how to get current file position of parser file

Gene Wirchenko <genew@telus.net>
Thu, 03 Sep 2015 18:19:01 -0700

          From comp.compilers

Related articles
lex - how to get current file position of parser file jkallup@web.de (Jens Kallup) (2015-09-01)
Re: lex - how to get current file position of parser file kaz@kylheku.com (Kaz Kylheku) (2015-09-01)
Re: lex - how to get current file position of parser file federation2005@netzero.com (2015-09-03)
Re: lex - how to get current file position of parser file genew@telus.net (Gene Wirchenko) (2015-09-03)
Re: lex - how to get current file position of parser file jkallup@web.de (Jens Kallup) (2015-09-06)
Re: lex - how to get current file position of parser file kaz@kylheku.com (Kaz Kylheku) (2015-09-07)
Re: lex - how to get current file position of parser file jkallup@web.de (Jens Kallup) (2015-09-07)
| List of all articles for this month |
From: Gene Wirchenko <genew@telus.net>
Newsgroups: comp.compilers
Date: Thu, 03 Sep 2015 18:19:01 -0700
Organization: A noiseless patient Spider
References: 15-08-019 15-09-001
Keywords: parse, yacc
Posted-Date: 03 Sep 2015 23:50:43 EDT

On Tue, 1 Sep 2015 14:19:33 +0000 (UTC), Kaz Kylheku <kaz@kylheku.com>
wrote:


>On 2015-09-01, Jens Kallup <jkallup@web.de> wrote:
>> Hello,
>>
>> I used flex, and bison under Linux. But how can I handle multiple
>> input files? When I follow the examples of the documentation, I fail
>> to handle tokens after include file.
>>
>> Example:
>>
>> PRINT "Before"
>> SET PROCEDURE TO testproc
>> PRINT "After"
>
>> this is a abstract language, which does (should) open a file called
>> "testproc".
>
>I think that in a dBase-type language, SET PROCEDURE doesn't necessarily have
>to open the file at parse time. According to current documentation that


          It does not have to, but if compiling a project, it will be
compiled as well.


>I'm able to find, it's actually become a complex module-loading command, and
>not parse-time textual inclusion. It can load compiled files, not only text,


          Yes.


>and cause non-persistent files to be unloaded. Loaded files have a refcount so
>that if you invoke SET PROCEDURE on some file N times, you have to CLOSE
>PROCEDURE that many times before it is unloaded.


          No. At least, this is not the case in Microsoft Visual FoxPro
9.0. You can not add a procedure file more than once. If you do, it
is just ignored. I tried using just the filename and then with the
path. The two were recognised as being the same. And, yes, I was
using the ADDITIVE keyword. CLOSE PROCEDURE releases *all* of the
procedure files.




          SET PROCEDURE's exact meaning is determined by file contents at
run-time.


[snip]


Sincerely,


Gene Wirchenko


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.