Re: [perl #40002] TGE Refactor / Compiler Tools Object

[Christoph Otto]

Will Coleda wrote:

On Sun, Jul 19, 2009 at 10:50 PM, Christoph Otto via
RT wrote:

On Sun Jul 19 16:18:01 2009, jk...@verizon.net wrote:

Would any of the participants in this thread be able to post an update?

Was the TGE refactor ever done?

If not, is it still needed in light of subsequent work on the Parrot
Compiler Tools?

Thank you very much.
kid51

I'm marking this as rejected because (as far as I can tell) TGE has been
superseded by PCT.  It's only around because Lua and possibly other HLLs
depend on it.  It's certainly not going to be refactored.
___
http://lists.parrot.org/mailman/listinfo/parrot-dev



You really need to get allison's feedback before rejecting this ticket.

Regards.




In retrospect, I completely agree.  I've sent her a msg via purl.  Hopefully 
she'll see either this thread or the purl msg and say which direction these 
TGE tickets should go.  I'll either reopen this ticket or close the others 
once I hear from her.


Christoph

Re: [perl #40002] TGE Refactor / Compiler Tools Object

[Will Coleda]

On Sun, Jul 19, 2009 at 10:50 PM, Christoph Otto via
RT wrote:
> On Sun Jul 19 16:18:01 2009, jk...@verizon.net wrote:
>> Would any of the participants in this thread be able to post an update?
>>
>> Was the TGE refactor ever done?
>>
>> If not, is it still needed in light of subsequent work on the Parrot
>> Compiler Tools?
>>
>> Thank you very much.
>> kid51
>
> I'm marking this as rejected because (as far as I can tell) TGE has been
> superseded by PCT.  It's only around because Lua and possibly other HLLs
> depend on it.  It's certainly not going to be refactored.
> ___
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

You really need to get allison's feedback before rejecting this ticket.

Regards.


-- 
Will "Coke" Coleda

Re: [perl #40002] TGE Refactor / Compiler Tools Object

[jerry gay]

On 8/3/06, Allison Randal <[EMAIL PROTECTED]> wrote:

Kevin Tew wrote:
> Patrick R. Michaud via RT wrote:
>> So, if we're going to allow other languages in the transform
>> bodies, we may want a "hereis" or podly {{...}}, {{{...}}} syntax to
>> delimit the transform bodies.  At the moment I'm leaning towards the
>> {{...}} form, if only because PGE is already using it.

I'm comfortable with multiplying curly brackets. We may also ultimately
offer a "shorthand" form something like:

  t///

And allow all the perlish alternate delimiters.

> How about here doc style?
> This was mentioned on IRC by either Coke or Particle, I had the the same
> idea.

We talked about that at OSCON. The problem is that it encourages people
to think of the body of transform rules as strings. They aren't strings,
they're code blocks.


that may be a perl5 way of looking at it, but having written countless
pir tests with heredoc syntax, i for one am used to thinking of them
as more than just strings. but as long as there's a syntax that works,
i don't really care what it looks like

 pir_output_is( <<'CODE', <<'OUTPUT', 'description' );
 .sub 'main' :main
   say 'ok 1'
 .end
 CODE
 ok 1
 OUTPUT

~jerry

Re: [perl #40002] TGE Refactor / Compiler Tools Object

[Patrick R. Michaud]

On Thu, Aug 03, 2006 at 11:21:57AM -0600, Kevin Tew wrote:
> Patrick R. Michaud via RT wrote:
> >
> >In discussions with Allison at OSCON, I noted that we needed to reconsider
> >the syntax slightly.  We don't want TGE to have to know how to parse every
> >language, and it may not be reasonable to expect every compiler to expose
> >a parser.  So, if we're going to allow other languages in the transform
> >bodies, we may want a "hereis" or podly {{...}}, {{{...}}} syntax to
> >delimit the transform bodies.  At the moment I'm leaning towards the 
> >{{...}}
> >form, if only because PGE is already using it.
> >
> >Pm
> >
> >  
> How about here doc style?
> This was mentioned on IRC by either Coke or Particle, I had the the same 
> idea.

Sorry, "heredoc" is what I meant by "hereis" above.  But yes, I'm thinking we'll
allow some form of heredoc.

Actually, {{, {{{,   may end up simply being shortcuts that say "heredoc 
with }}, }}}, 
as the end marker...".

Pm

Re: [perl #40002] TGE Refactor / Compiler Tools Object

[Allison Randal]

Kevin Tew wrote:
> Patrick R. Michaud via RT wrote:
>> So, if we're going to allow other languages in the transform
>> bodies, we may want a "hereis" or podly {{...}}, {{{...}}} syntax to
>> delimit the transform bodies.  At the moment I'm leaning towards the
>> {{...}} form, if only because PGE is already using it.

I'm comfortable with multiplying curly brackets. We may also ultimately
offer a "shorthand" form something like:

  t///

And allow all the perlish alternate delimiters.

> How about here doc style?
> This was mentioned on IRC by either Coke or Particle, I had the the same
> idea.

We talked about that at OSCON. The problem is that it encourages people
to think of the body of transform rules as strings. They aren't strings,
they're code blocks.

Allison

Re: [perl #40002] TGE Refactor / Compiler Tools Object

[Kevin Tew]

Patrick R. Michaud via RT wrote:


In discussions with Allison at OSCON, I noted that we needed to reconsider
the syntax slightly.  We don't want TGE to have to know how to parse every
language, and it may not be reasonable to expect every compiler to expose
a parser.  So, if we're going to allow other languages in the transform
bodies, we may want a "hereis" or podly {{...}}, {{{...}}} syntax to
delimit the transform bodies.  At the moment I'm leaning towards the {{...}}
form, if only because PGE is already using it.

Pm

  

How about here doc style?
This was mentioned on IRC by either Coke or Particle, I had the the same 
idea.

Re: [perl #40002] TGE Refactor / Compiler Tools Object

[Patrick R. Michaud]

On Fri, Jul 28, 2006 at 08:43:27AM -0700, Kevin Tew wrote:
> 
> What bullet items will the TGE refactor consist of?

Keeping in mind that the "TGE refactor" really also includes refactoring
PAST and POST, we have...

> * better command-line arg processor, like getopts, but returning a capture

Yes.

> * optimization levels based on level, group related optimizations which 
> may occur during different transform steps

Eventually this will happen, but I don't know if it'll be in the first
round of refactoring.

> * support for languages other than PIR
> * generic PAST/POST nodes for short-circut ands and ors
> * basic conditional and case constructs, there exists a common semantic 
> for if/else, it should be represented in a common way in PAST
> * for and while loop generation

Yes, yes, yes, and yes.

> * label management.
> * scope management.

Scope management definitely in this first refactor; label management may
wait slightly (or I'll just invite someone else to do it :-).

> *38761 * *[TODO] 
> TGE, precompile more *

I'll wait and see on this one.

>   [EMAIL PROTECTED]
> *39831 * *TGE - 
> Needs more diagnostics on failure. 
> *

Definitely.

>   [EMAIL PROTECTED]
> *39854 * 
> *[PATCH] 
> adds preamble section to tge grammar to allow for includes and global 
> defines *

I'm working this one out.  There *will* be a way to set pragmas (e.g.,
so that the :language(...) modifier isn't specified on every transform).

>   [EMAIL PROTECTED]
> *39897 * 
> *[PATCH] 
> TGE - add basic syntax error 
> *
>   [EMAIL PROTECTED]
> *39905 * *[TODO] 
> TGE - line number reporting. 
> *

We'll definitely add better line number reporting.

>   [EMAIL PROTECTED]
> *39913 * *[BUG] 
> TGE - Can't use } in the transform definitions. 
> *

In discussions with Allison at OSCON, I noted that we needed to reconsider
the syntax slightly.  We don't want TGE to have to know how to parse every
language, and it may not be reasonable to expect every compiler to expose
a parser.  So, if we're going to allow other languages in the transform
bodies, we may want a "hereis" or podly {{...}}, {{{...}}} syntax to
delimit the transform bodies.  At the moment I'm leaning towards the {{...}}
form, if only because PGE is already using it.

Pm

[perl #40002] TGE Refactor / Compiler Tools Object

[via RT]

# New Ticket Created by  Kevin Tew 
# Please include the string:  [perl #40002]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=40002 >


What bullet items will the TGE refactor consist of?

* better command-line arg processor, like getopts, but returning a capture
* optimization levels based on level, group related optimizations which 
may occur during different transform steps
* support for languages other than PIR
* generic PAST/POST nodes for short-circut ands and ors
* basic conditional and case constructs, there exists a common semantic 
for if/else, it should be represented in a common way in PAST
* for and while loop generation
* label management.
* scope management.
 
*38761 *   *[TODO] 
TGE, precompile more *

[EMAIL PROTECTED]
*39831 *   *TGE - 
Needs more diagnostics on failure. 
*

[EMAIL PROTECTED]
*39854 *   *[PATCH] 
adds preamble section to tge grammar to allow for includes and global 
defines *

[EMAIL PROTECTED]
*39897 *   *[PATCH] 
TGE - add basic syntax error 
*

[EMAIL PROTECTED]
*39905 *   *[TODO] 
TGE - line number reporting. 
*

[EMAIL PROTECTED]
*39913 *   *[BUG] 
TGE - Can't use } in the transform definitions. 
*

[EMAIL PROTECTED]