__END__ in PIR

kjstol parrotcode at gmail.com
Wed Dec 2 17:25:18 UTC 2009


On Wed, Dec 2, 2009 at 1:54 PM, jerry gay <jerry.gay at gmail.com> wrote:
> On Wed, Dec 2, 2009 at 05:03, Andrew Whitworth <wknight8111 at gmail.com> wrote:
>> I'm inclined to say "yes", but really it's part of a larger set of PIR
>> language features we might want to look into:
>>
>> 1) The ability to say where the PIR code starts, so we can provide a
>> separate stub header ("perl -x")
>> 2) The ability to say where the PIR code ends, so we can include other
>> information in the file thereafter ("__END__")
>> 3) The ability to get access to the information in the file after the
>> __END__ ("<DATA>" and "__DATA__" In perl5)
>>
>> Any of these features alone would be nice but not necessary. Together
>> I think they open up a lot of flexibility. I would, however, prefer to
>> use something more PIR-ish than "__END__", maybe ".endfile" instead.
>>
> these constructs do not work well with the '.include <file>'
> directive, which inserts the text of the file passed to the directive
> in place in the current file.  in particular, they leave me with
> several questions:
>
> ~ when using '.include <file>', are separate stub headers always
> ignored if the '.include <file>'?
> ~ what if the include statement is above all other pir in the including file?
> ~ are they processed only on the first (recursive) '.include <file>'
> in the pir stream?
> ~ disallowed in files passed in via '.include <file>'?
>
> the same questions apply to '__END__' blocks:
> ~ are they always ignored with '.include <file>'?
> ~ what if the include statement is below all other pir in the including file?
> ~ are they processed only on the last (recursive) '.include <file>' in
> the pir stream?
> ~ disallowed in files passed in via '.include <file>'?
>
> similar questions apply to '__DATA__' blocks:
> ~ and what of multiple '__DATA__' blocks, how are these handled?
>
> for example, with the following file structure:
>
> ==========
> TOP.pir:
> .include 'MIDDLE.pir'
>
> .sub 'main' :main
>    say 'TOP'
>
> .include 'LAST.pir'
> __END__
> =pod
> =cut
>
> __DATA__
> 1
> 2
> 3
>
>
> MIDDLE.pir:
> .include 'FIRST.pir'
>
> .sub 'init' :anon :load
>    say 'MIDDLE'
> .end
>
> __DATA__
> a
> b
> c
>
>
> FIRST.pir:
> .sub 'init' :anon :load
>    say 'FIRST'
> .end
>
> __END__
>
>
> LAST.pir:
>    say 'LAST'
> .end
>
> __END__
> foo
> bar
> ==========
>
> what is the behavior of the pir compiler?
> does this compile? why or why not?
> what is the __END__ block contents?
> what is the __DATA__ block contents?
>
> ~jerry
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

I agree that it needs careful thought, but I think technically it
would not be impossible, but it depends a bit on the implementation of
the PIR macro preprocessor. __END__ and __DATA__ blocks could just end
at the end of the file. the end of file of an included file can be
distinguished from the end of a file from the "main" file.

However, I would agree with Pm that it causes more issues than it
solves. If there are some good use cases for using this kind of
construct, we could always come up with a PIR-like directive (.data
/.enddata -- geez, that starts to look like a REAL assembly language
:-)


kjs


More information about the parrot-dev mailing list