[perl #34258] [TODO] Here documents for PIR
Bernhard Schmalhofer
# Please include the string: [perl #34258]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34258 >
Hi,
in the near, or far, future there will be test scripts and compiler input in
PIR.
For that it would be nice, if long text doesn't have to be crammed into a
single line.
So some kind of HERE document syntax is needed for PIR. Suggestions for
syntax elements
are welcome. '<<' is already taken for the left shift operator.
CU, Bernhard
--
/* Bernhard.S...@biomax.de */
DSL Komplett von GMX +++ Superg�nstig und stressfrei einsteigen!
AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl
MrJoltCola
-----
I haven't ranted in a couple of years, so I'm due. Ranting is
nothing more than broadcasting my emotions from a soapbox
but it is so fun, I love to do it.
Let me respectfully give my opinion. In no way am I criticizing your
suggestion of here documents, nor am I ranting at the
originator of the suggestion.
I feel that this feature is for higher level languages. I did not
even want macros, but there was a lot of griping
when I removed them, so I relented and Leo reversed the patch.
What really is the problem here is the lack of a decent alternative.
It is not PIR that is lacking features. PIR, by definition should lack
features. It stands for "Pick-your-P-word Intermediate Representation."
What is missing is a good implementation language that compiles to
PIR. PIR is for compilers, not people, and I don't want to see PIR turn
into "PIRL".
What I always wanted to do was implement a C subset for Parrot, and
write all "low-level" things in that language. C is very good for close
translation to underlying "hardware" and it doesn't take a full-time think-tank
to implement a compiler for it. I'd like to see thin drivers written for
things (ala JDBC Thin SQL drivers), with VERY limited use of native
interfaces. I actually have a pretty nice compiler sitting in my archives,
but got too busy with life to finish it. The little "Cola" language that is
in languages
right now is a hack job that was a quick prototype to see if people would
actually write C like code for Parrot. Cola got very little interest, so I
shelved
my work on it and IMCC2.
Years after I dumped much work into Parrot, I've seen no progress or support
from other language camps (Python, Scheme) and Perl 6 seems to be such a
daunting goal to implement, I'm afraid we won't a full, commercial-free
implementation
for years. (I've written a couple of fully featured compilers in a matter
of weeks, and I
won't even begin to tackle Perl6 unless someone offered to fund me full-time).
Heck, what happened to the Pony project? Is there anybody out there? Or did we
all find that we were happier with Perl 5 than we realized. Or were we so
slow with Perl 6
that everyone had time to swallow the .NET pill?
I feel better now,
-Melvin
At 04:53 PM 2/24/2005, via RT wrote:
># New Ticket Created by Bernhard Schmalhofer
># Please include the string: [perl #34258]
># in the subject line of all future correspondence about this issue.
># <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=34258 >
>
>
>Hi,
>
>in the near, or far, future there will be test scripts and compiler input in
>PIR.
>For that it would be nice, if long text doesn't have to be crammed into a
>single line.
>
>So some kind of HERE document syntax is needed for PIR. Suggestions for
>syntax elements
>are welcome. '<<' is already taken for the left shift operator.
>
>CU, Bernhard
>
>
>--
>/* Bernhard.S...@biomax.de */
>
>DSL Komplett von GMX +++ Superg�nstig und stressfrei einsteigen!
Leopold Toetsch
> Hi,
> in the near, or far, future there will be test scripts and compiler
> input in PIR. For that it would be nice, if long text doesn't have to
> be crammed into a single line.
> So some kind of HERE document syntax is needed for PIR. Suggestions
> for syntax elements are welcome. '<<' is already taken for the left
> shift operator.
Yeah. I came to the same conclusion, while hacking the Z translator.
While the syntax extension isn't really necessary, it can produce much
more readable code.
WRT syntax:
$S0 = <<_EOT_
...
_EOT_
will work, because the token "<<_EOT_" is longer then the token "<<". The
only thing that will stop working is:
.local int _EOT_
$I0 = $I1 <<_EOT_ # space needed then
Not much of a problem. We don't need and don't support nested HERE docs,
so one fix-defined "<<_EOT_" or some such will do it.
> CU, Bernhard
leo
Leopold Toetsch
> I feel that this feature is for higher level languages.
[ snip ]
> ... PIR is for compilers, not people,
PIR is foremost Parrot's primary assembly language. If it were for
compiles only, it wouldn't have needed "a = b + c" in the first place,
the "add" opcode is doing the same.
PIR has nice constructs for function and method calls. I don't see any
reason, why people shouldn't write PIR code directly. A HERE document
syntax allows to write more readable code.
leo
Roger Browne
> This should actually be titled "Where are all the compilers?"
The compilers will come! Loads of people, myself included, are quietly
working away on compilers that target IMC.
It takes time for people to discover and adopt new platforms -
especially when you are so modest about Parrot. The FAQ says:
"Parrot is in the early phases of its implementation. The primary
way to use Parrot is to write Parrot assembly code"
when it could say something like:
"Although parrot is not yet complete, and indeed the design is
still being refined, it already offers an elegant, powerful,
feature-rich, solidly-designed (though poorly documented)
environment that makes it amazingly easy to implement
a wide range of scripting languages. The primary way to use
parrot is to generate code for its intermediate language
compiler (IMC) which handles all of the following things (and
more) for you: numbers, bignums, objects, multiple inheritance,
closures, garbage collection, strings, polymorphic feature
dispatch, regular expressions, exception handling, and more!"
> ... here documents ...
I don't care strongly either way about here-documents, and they're not
going to make-or-break parrot. Lots of folks like to use here-documents,
and lots of folks get by just fine using languages that don't support
anything like here-documents.
(Would I would like, though, is for the ".include" macro to
find .../runtime/parrot/include like it says it does in the
documentation :-)
But these things are mere details, minor bumps along the road.
> Years after I dumped much work into Parrot, I've seen no progress or support
> from other language camps (Python, Scheme) and Perl 6 seems to be such a
> daunting goal to implement, I'm afraid we won't a full, commercial-free
> implementation for years...
It would be ironic indeed if the standard Perl 6 implementation ended up
being written in Haskell! But Melvin's work on IMC is one of the core
things that will ensure Parrot's success. Many people wouldn't want to
manually generate code that satisfies the parrot assembly language
calling conventions, but they can cope with generating $P1."foo"($P2).
> . Or were we so slow with Perl 6 that everyone had time to swallow the .NET pill?
Naaah! Parrot is the scripting platform for the next few decades, so it
doesn't matter if it takes a few years for it to catch on.
Sorry that I can't help out more myself - I'm not fluent in either C or
Perl (I'm getting pretty good at IMC though!). But I'll at least help
out bringing the compilers that Melvin craves.
Regards,
Roger
--
Roger Browne <ro...@eiffel.demon.co.uk>
MrJoltCola
>MrJoltCola <mrjol...@mindspring.com> wrote:
>
> > I feel that this feature is for higher level languages.
>
>[ snip ]
>
> > ... PIR is for compilers, not people,
>
>PIR is foremost Parrot's primary assembly language. If it were for
>compiles only, it wouldn't have needed "a = b + c" in the first place,
>the "add" opcode is doing the same.
It filled a need at the time I wrote it, because there was pretty much
nothing else to write code in except PASM and Jako. It was supposed
to be a thin layer (register allocation and instruction choosing and subs)
over PASM.
Nowadays we have a hoard of little toy compilers.
>PIR has nice constructs for function and method calls. I don't see any
>reason, why people shouldn't write PIR code directly. A HERE document
>syntax allows to write more readable code.
...and adds another straw to the Camel's back of IMCC maintainability
...and encourages people to stay complacent and keep writing PIR code by hand,
which was the main point of my note.
-Melvin
Bernhard Schmalhofer
> At 03:21 AM 2/25/2005, Leopold Toetsch wrote:
>
>> MrJoltCola <mrjol...@mindspring.com> wrote:
>>
>> > I feel that this feature is for higher level languages.
>>
>> [ snip ]
>>
>> > ... PIR is for compilers, not people,
>>
non-existent abstract syntax tree. Though I'm somewhat confused about
the distinction between parse trees and AST.
PIR and PAST could be considered as being just some languages. Why don't
they take the some route, and generate an AST that gets compiled into PBC?
However most compilers I have seen so far are generating PIR and go from
there.
>> PIR is foremost Parrot's primary assembly language. If it were for
>> compiles only, it wouldn't have needed "a = b + c" in the first place,
>> the "add" opcode is doing the same.
>
>
> It filled a need at the time I wrote it, because there was pretty much
> nothing else to write code in except PASM and Jako. It was supposed
> to be a thin layer (register allocation and instruction choosing and
> subs) over PASM.
It is certainly possible to write code in PIR. But it is even more
certain that this is no fun. Adding HERE documents remedies an immediate
need, especially for playing with compilers and test scripts.
> Nowadays we have a hoard of little toy compilers.
Which language of that hoard should be promoted to become THE standard
language for writing test scripts and the Parrot standard library?
PIR is too hard on people, and a scripting language like Ruby, Perl or
Python is propably to hard on Parrot.
It propably shouldn't a newly invented language either, because all
language designers are having fun with designing Perl6.
How about ECMAScript? It has an specification, it has objects and no
pointers.
CU, Bernhard
--
**************************************************
Dipl.-Physiker Bernhard Schmalhofer
Senior Developer
Biomax Informatics AG
Lochhamer Str. 11
82152 Martinsried, Germany
Tel: +49 89 895574-839
Fax: +49 89 895574-825
eMail: Bernhard.S...@biomax.com
Website: www.biomax.com
**************************************************
MrJoltCola
>MrJoltCola wrote:
>>At 03:21 AM 2/25/2005, Leopold Toetsch wrote:
>>
>>>MrJoltCola <mrjol...@mindspring.com> wrote:
>>>
>>> > I feel that this feature is for higher level languages.
>>>
>>>[ snip ]
>>>
>>> > ... PIR is for compilers, not people,
>My impression was that the target for compilers should be a yet
>non-existent abstract syntax tree. Though I'm somewhat confused about the
>distinction between parse trees and AST.
>
>PIR and PAST could be considered as being just some languages. Why don't
>they take the some route, and generate an AST that gets compiled into PBC?
>
>However most compilers I have seen so far are generating PIR and go from
>there.
Text mode IR is easier to debug with the naked eye than an AST.
ASTs are great if you have supporting tools to browse the tree, dump things
out and
translate things back to IR. Virtually all compilers start with an IR and
mature
into AST usage, but many successful compilers are built with completely
separate layers. See Muchnicks's work at Sun Microsystems. He has been
the main influence on me as a compiler writer.
>>>PIR is foremost Parrot's primary assembly language. If it were for
>>>compiles only, it wouldn't have needed "a = b + c" in the first place,
>>>the "add" opcode is doing the same.
>>
>>It filled a need at the time I wrote it, because there was pretty much
>>nothing else to write code in except PASM and Jako. It was supposed
>>to be a thin layer (register allocation and instruction choosing and
>>subs) over PASM.
>
>It is certainly possible to write code in PIR. But it is even more certain
>that this is no fun. Adding HERE documents remedies an immediate need,
>especially for playing with compilers and test scripts.
I agree. Why not write a pre-processor that will handles things like this
and then
merge them forwards towards a front-end compiler rather than backwards into the
mess of IMCC? Trust me, I know the IMCC code, and it is BAD BAD BAD. And
I fully share the blame with Leo and Angel, bless their hearts. :)
> > Nowadays we have a hoard of little toy compilers.
>Which language of that hoard should be promoted to become THE standard
>language for writing test scripts and the Parrot standard library?
>PIR is too hard on people, and a scripting language like Ruby, Perl or
>Python is propably to hard on Parrot.
>It propably shouldn't a newly invented language either, because all
>language designers are having fun with designing Perl6.
You echo my feelings, PIR is too hard on people, and I feel that Parrot's
growth suffers
for it, not because of PIR, but because that is all we use. I'm appalled
that 3 years after I submitted IMCC
to the project, everyone is still writing in PIR. Parrot need's its own
version of "C" or "C#" to empower
more people to contribute. If every new feature for Parrot is thought of in
terms of PIR & IMCC, then IMCC
will just become more of a tangled mess that nobody wants to touch, and
high-level development will continue
to drag as it has for years.
>How about ECMAScript? It has an specification, it has objects and no pointers.
No complaints from me, I don't vote much anyway, but I have strong feelings
regarding this project.
The mixing of the VM team and the compiler team is a mistake. It is a
problem for commercial
development, much less open-source. One pumpking making decisions for such
a wide scope doesn't
leave much room for alternate points of view and unimpeded movement. This
is why I urged Dan
long ago to form a parrot-compilers list and split the project into
separate decision making teams.
Speaking of Dan, where is he?
-Melvin
Garrett Goebel
>
> Parrot need's its own version of "C" or "C#" to empower more people
> to contribute. If every new feature for Parrot is thought of in
> terms of PIR & IMCC, then IMCC will just become more of a tangled
> mess that nobody wants to touch, and high-level development will
> continue to drag as it has for years.
C scripting language implementations
S-lang: http://www.s-lang.org/index.html
seeR: http://przemekp.prv.pl/seer/
EiC: http://eic.sourceforge.net/
CSL: http://csl.sourceforge.net/
CINT: http://root.cern.ch/root/Cint.html
CH: http://www.softintegration.com/
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com garrett at scriptpro dot com
Will Coleda via RT
> [leo - Fri Feb 25 01:34:24 2005]:
Jonathan Worthington via RT
After a show of demand for here docs on IRC (and leo's approval), I've
now modified to lexer to support them. The syntax for introducing a
heredoc is <<"XXX", and it ends on the line containing (only) XXX. For
example:-
$ cat example.pir
.sub _main
$S0 = <<"quotage"
Blah blah
Oh happy days...
I love my pink highlighter pen...
quotage
print $S0
.end
$ parrot example.pir
Blah blah
Oh happy days...
I love my pink highlighter pen...
$
Have fun,
Jonathan
Will Coleda
advantage.
One problem I've discovered:
operators["<<"] = OPERATOR_SHL
This is probably because:
<*>"<<"{STRINGCONSTANT} {
Is too permissive. Can we perhaps just allow {ID}s ?
Thanks again! This is great! Woo!
Will Coleda
Thanks again!
Bernhard Schmalhofer via RT
>
> After a show of demand for here docs on IRC (and leo's approval), I've
> now modified to lexer to support them. The syntax for introducing a
> heredoc is <<"XXX", and it ends on the line containing (only) XXX. For
> example:-
>
Thanks a lot Jonathan. Here docs are alive and kicking.
The ticket is resolved.