Perl grammar for Perl5 -> Perl6

[Peter Schwenn]

Dear Perl6 Language,

I am Perl user from near year 0.  For me the easiest way to learn (,
track, and get to the point of contributing to) Perl6 would be a Perl
grammar (a regex rule set in, preferably, Perl6) that transforms any
Perl5 script into a Perl6.  Of couse, besides learning Perl6 for a
regex'r or Perl5'r such as myself, and tracking, and documenting 6, it
would have huge use for Perl5 users making or considering the
transition.


For example one can infer the structure and some of the rules from
   http://svn.openfoundry.org/pugs/docs/other/porting_howto   which is
however written out in informal (not regex) rules such as $array[idx] ->
@array[idx]



Is there such a Perl5->Perl6 translator underway?


Sincerely,
Peter Schwenn

www.schwenn.com

p.s. I'm not yet up to originating a good one, but believe I could make
contributions in extending and checking it.

p.s. A Perl5 starting point might be better since running it on itself
would provide and initiate at least 2 major test modes.

p.s. The developing form of such a grammar could likely lead to
a grammar package which facilitates rule sets for languages in
other domains, in terms of illuminating means of choosing among modes
for rule ordering, collecting, scoping, re-application, recursion, 
exclusion and so forth.

Re: Perl grammar for Perl5 -> Perl6

[Yuval Kogman]

On Wed, Dec 07, 2005 at 16:48:11 -0500, Peter Schwenn wrote:
> Dear Perl6 Language,
> 
> I am Perl user from near year 0.  For me the easiest way to learn (,
> track, and get to the point of contributing to) Perl6 would be a Perl
> grammar (a regex rule set in, preferably, Perl6) that transforms any
> Perl5 script into a Perl6.  Of couse, besides learning Perl6 for a
> regex'r or Perl5'r such as myself, and tracking, and documenting 6, it
> would have huge use for Perl5 users making or considering the
> transition.

IMHO machine translation is not that good a way to start learning -
the real benefit of Perl 6 is in the features which have no perl 5
equivalents and solve problems much more elegantly.

The best thing to do is to hang out on #perl6 and get involved with
the test suite, as well as reading the synopses.

Perhaps writing a toy program or something like that could also
help.

> For example one can infer the structure and some of the rules from
> http://svn.openfoundry.org/pugs/docs/other/porting_howto   which is
> however written out in informal (not regex) rules such as $array[idx] ->
> @array[idx]

These are rules for humans with lots and lots of context info...
Furthermore, they are more of a perl 6 gotcha list, for perl 5
programmers than a translation guide.

> Is there such a Perl5->Perl6 translator underway?

Larry Wall is working on using the perl (5) interpreter to create
compiled output (as opposed to just something that executes in
memory) that can then be read by a translator without actually
parsing perl 5.

Before this happens this will be very very hard - the high level
language has vast amounts of implications on execution etc, but the
opcode tree is much more simpler to predict (for a computer).

> p.s. The developing form of such a grammar could likely lead to
> a grammar package which facilitates rule sets for languages in
> other domains, in terms of illuminating means of choosing among modes
> for rule ordering, collecting, scoping, re-application, recursion, exclusion 
> and so forth.

Since perl 5's actual parser and tokenizer will be used for this it
won't be very extensible, but this is important because perl is
reallly hard to parse.

-- 
 ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
 /\  kung foo master: /me supports the ASCII Ribbon Campaign: neeyah!!!



pgpnA5re5zZw2.pgp
Description: PGP signature

Re: Perl grammar for Perl5 -> Perl6

[Ruud H.G. van Tol]

Peter Schwenn schreef:

> Is there such a Perl5->Perl6 translator underway?

http://dev.perl.org/perl6/ 
>> Perl6 FAQ <<

-- 
Grtz, Ruud

Re: Perl grammar for Perl5 -> Perl6

[Christian Renz]

Is there such a Perl5->Perl6 translator underway?


I started toying with one, but didn't get very far yet. PPI (on CPAN)
would be a good way to start, but it needs to be extended to be used
as a Perl5->Perl 6 translator.

Greetings,
   Christian

--
[EMAIL PROTECTED] - http://christian.web42.com - http://www.web42.com/crenz/ 


"If the Creator really did write himself into his own story, that's
what we ought to expect to see. Creative solutions. And this
creativity is intended to be transitive. We are expected to be
creative. And we're expected to help others be creative."  -- Larry Wall

Clarification for External Regex Variables?

[Brad Bowman]

Hello,

I'd like to get clarification on the scoping of variables
bound in a regex.  It's described in S05 as follows:

  External aliasing

* Instead of using internal aliases like:

 m/ mv  @:=+  $:= /

  the name of an ordinary variable can be used as an "external
  alias", like so:

 m/ mv  @files:=+  $dir:= /

* In this case, the behaviour of each alias is exactly as describe
  in the previous sections, except that the resulting capture(s) are
  bound directly (but still hypothetically) to the variables of the
  specified name that exist in the scope in which the rule declared.

S05 and A05 both seems to say that @files and $dir must be already declared
in the scope containing the declaration.  Is that correct?

Is there any way to introduce a new variable to the containing scope
with a regex?  Either the declaration scope or execution scope?

A05 says no, unless MY:: fiddling is allowed.  I can see that variables
popping into existence goes against lexical scoping hygiene, but
it may be acceptable with a "my" in the regex or limiting the
additions to declaring scope.

(I think I've used the word "scope" too much there)

My motivation for this is to use rules as an alternative parameter
list sublanguage.  That idea is still in the oven though.

Brad

--
  To ask when you already know is politeness. To ask when you don't know
  is the rule.  -- Hagakure http://bereft.net/hagakure/

Re: Clarification for External Regex Variables?

[Larry Wall]

On Thu, Dec 08, 2005 at 11:14:16PM +0100, Brad Bowman wrote:
: Hello,
: 
: I'd like to get clarification on the scoping of variables
: bound in a regex.  It's described in S05 as follows:
: 
:   External aliasing
: 
: * Instead of using internal aliases like:
: 
:  m/ mv  @:=+  $:= /
: 
:   the name of an ordinary variable can be used as an "external
:   alias", like so:
: 
:  m/ mv  @files:=+  $dir:= /
: 
: * In this case, the behaviour of each alias is exactly as describe
:   in the previous sections, except that the resulting capture(s) are
:   bound directly (but still hypothetically) to the variables of the
:   specified name that exist in the scope in which the rule declared.
: 
: S05 and A05 both seems to say that @files and $dir must be already declared
: in the scope containing the declaration.  Is that correct?

Yes, that's the current intent.

: Is there any way to introduce a new variable to the containing scope
: with a regex?  Either the declaration scope or execution scope?

Not currently.

: A05 says no, unless MY:: fiddling is allowed.

MY:: fiddling is disallowed on an already compiled scope, and maybe even
on a compiling scope if COMPILING<$foo> becomes the normative way to
refer to the lexical scope being created.

: I can see that variables
: popping into existence goes against lexical scoping hygiene, but
: it may be acceptable with a "my" in the regex or limiting the
: additions to declaring scope.

I've gone around about that in my head lots of time, but there isn't
a good way to sneak a "my" into rule syntax, and besides, we're trying
to encourage people to think of rules as lexical scopes in their own
right, so even if you did sneak a "my" in there somehow, it would
most naturally limit itself to the scope of the rule.

And, of course, part of our reason for the $ shortcut notation
is to take some of the pressure off the desire for lexical leakage,
but it's also a nice visual pun on , so self-documenting in a
"pillish" kind of way.

: My motivation for this is to use rules as an alternative parameter
: list sublanguage.  That idea is still in the oven though.

Maybe some variant of "is parsed" and macros is where you're headed.

Or maybe we can do something better with named parameter binding:

my ($foo,$bar,*rest) := @/{};

Anyway, @Larry is also trying to come at it from the other direction
by allowing signatures as part of rule syntax, but that's motivated
by wanting to do pattern matching on trees, where a list of child
nodes is construed to look like an argument list.  In theory a
declarative nested parameter syntax can be reversed and used to write
the constructors to rebuild the tree that would also be parseable by
the syntax.  (Or at least one of those trees.)

Larry

Re: Perl grammar for Perl5 -> Perl6

[Larry Wall]

On Thu, Dec 08, 2005 at 11:51:52AM +0200, Yuval Kogman wrote:
: On Wed, Dec 07, 2005 at 16:48:11 -0500, Peter Schwenn wrote:
: > Dear Perl6 Language,
: > 
: > I am Perl user from near year 0.  For me the easiest way to learn (,
: > track, and get to the point of contributing to) Perl6 would be a Perl
: > grammar (a regex rule set in, preferably, Perl6) that transforms any
: > Perl5 script into a Perl6.  Of couse, besides learning Perl6 for a
: > regex'r or Perl5'r such as myself, and tracking, and documenting 6, it
: > would have huge use for Perl5 users making or considering the
: > transition.
: 
: IMHO machine translation is not that good a way to start learning -
: the real benefit of Perl 6 is in the features which have no perl 5
: equivalents and solve problems much more elegantly.

Except it would be lovely to have a smart enough refactoring translator
that it could recognize where those elegant solutions are possible and
at least give the option of attempting them.  Or at least a hint that
there might be a better way.

: The best thing to do is to hang out on #perl6 and get involved with
: the test suite, as well as reading the synopses.
: 
: Perhaps writing a toy program or something like that could also
: help.

Sure, but some of our toys are bigger than others.  :-)

: > Is there such a Perl5->Perl6 translator underway?
: 
: Larry Wall is working on using the perl (5) interpreter to create
: compiled output (as opposed to just something that executes in
: memory) that can then be read by a translator without actually
: parsing perl 5.

Yes, I have a version of 5.9.2 that dumps out some *very* strange
XML that represents, as closely as possible, the exact meaning of
the code to Perl 5, along with all the syntactic bits.  I then filter
that strange XML back into something approximating an AST.  I am in
the process of proving to myself that I'm getting enough information
out of this to recreate the original Perl 5, so I jokingly call this
my Perl5-to-Perl5 translator.  As of today, I'm able to translate
76.57% of the t/*/*.t files that come with the Perl distribution.
Considering that last week this number was down at about 5%, it would
seem that I've been making a lot of progress.  But most of the work
went into that first 5%, and a lot of work will likely go into the
last 5% as well.  To get that first 5% I basically had to completely
refactor the lexer and the grammar without changing anything, which
is of course impossible.  The Perl 5 parser forgets or misplaces an
astounding variety of information that the translator needs, and
you can't just go and tell it to turn off the optimizations, because
in fact most of those optimizations are deeply interwingled with
semantic analysis and transformations as well.

Basically, every skipspace() in toke.c and every op_free() in op.c
and every rule reduction in perly.y loses necessary information.
To attempt to do what I'm currently doing you would have to be
completely insane like me.  It's a total nightmare.  If I were
Catholic I'd be hoping this all counts as pennance for my past sins,
and gets me out of 100 million years of Purgatory or so.  But being
a Protestant, I'm merely repenting of my past sins, and thinking
about maybe repenting my future ones.

And if I were Jewish I'd've said "Oy vey" many times over.  :-)

Anyway, once I get to 100% of the t/ files, I'll make it translate
all of CPAN back to itself.  And at some point I'll take a first
whack at the Perl5-to-Perl6 translator, then open it up for community
participation.  It's still just a bit too early for that, though,
because there's such a delicate interplay between refactoring bits
of perl without changing anything vs trying to guess whether we are
getting enough type and structural information out to recreate the
original in the backend.  There are already more than 1 lines of
code in the backend just to undo the damage done by the Perl 5 engine.

: Before this happens this will be very very hard - the high level
: language has vast amounts of implications on execution etc, but the
: opcode tree is much more simpler to predict (for a computer).

Right.  But my intent is to write a really good translator, and that
implies that it has to be a multi-level translation.  That involves
keeping track of all the subtle semantic and pragmatic information
as well as the basic syntactic information.  Otherwise we might as
well just feed Perl 5 to babblefish and see if Perl 6 comes out...

: > p.s. The developing form of such a grammar could likely lead to
: > a grammar package which facilitates rule sets for languages in
: > other domains, in terms of illuminating means of choosing among modes
: > for rule ordering, collecting, scoping, re-application, recursion, 
exclusion and so forth.
: 
: Since perl 5's actual parser and tokenizer will be used for this it
: won't be very extensible, but this is important because perl is
: reallly hard to parse.

And it's oh about 2

Re: the $! too global

[Larry Wall]

On Wed, Dec 07, 2005 at 09:43:31AM +0100, TSa wrote:
: HaloO,
: 
: Larry Wall wrote:
: >My gut-level feeling on this is that $! is going to end up being an
: >"env" variable like $_.
: 
: I just re-read about exceptions. Well, I undestand now that $! is
: intented as a variable with a spectrum of meanings ranging from
: 
:   1) the return value of a sub, through
:   2) an error return value, up to
:   3) a non-return value.
: 
: Of these only the last is what I know as exceptions. I'm for now
: undecided to regard these three purposes of $! as very clever or
: as big potential for subtle problems. From the viewpoint of the
: execution model this environment approach is very clear, though.
: It nicely unifies return values with in-band errors and out-band
: exceptions. Which leaves just one wish from my side: make CATCH
: blocks dispatched. That is they get a signature what kind of
: exception they handle. The optimizer will make good use of this
: information.

I think that's basically the direction that Parrot is headed.

: >Then the problem reduces
: >to what you do with an unhandled $! at the end of a lexical scope,
: 
: I don't understand this. The end of scope is either the closing
: brace or an explicit statement like next, leave, return, yield,
: fail or die. In the above spectrum of $! these are resultizer
: just as given, for and friends are topicalizer for $_. But I think
: simple assignment to $! is not foreseen, or is it?

I don't entirely understand it all yet myself.  It's possible that we're
trying to unify too many ideas into $! all at once.  It may be impossible
to simultaneously do all of:

* emulate Perl 5's $!, $@, $? and $^E
* represent only the "last" exception status
* never lose exception information

Indeed, the faults with Perl 5's $! mechanism are the major reason
for CATCH blocks.  So maybe we should just make $! as close to Perl 5
semantics as possible and then steer people away from it if they
want to write robust code.

Even the first of those items above is something we really haven't
thought through.  In Perl 5 $! has errno semantics that mean you
shouldn't rely on its value unless something went "bang" and you know
it some other way.  Whereas $@ and $? rely respectively on evalish
and systemish calls to clear the variables on success.  Does unifying
$! with those mean that $! has to be cleared on every function call?
That seems rather ill-defined.  I think the solution is more along
the lines of $! clears its boolean/defined status on every function
call but remembers the last actual exception.  Or maybe we just say
that $! stays true if it contains any exception, and rely on eval
or system-like calls to clear $! if they want test-after semantics?
I can argue it both ways, which probably means that neither solution
is the right one.

: For an example let's assume that / returns 'undef but division by zero'
: in $! if its rhs is zero.

Well, NaN probably, but go on.

:   {  # begin of scope
: 
:  my $x = 3;
:  my $y = 4;
: 
:  say $x/$y;
: 
:  $x = foo; # foo could return 0
: 
:  my $z = $y/$x; # $! == 'undef but division by zero' if $x == 0
: # Is that assignable to $z?
: 
:  $z++;  # This is now a statement in a potential CATCH block?
:   }

Yes, the return value is assignable whether it is NaN or undef
(assuming the type of $z doesn't prevent assignment), but the return
value is not quite the same thing as $!, I suspect.  It's more like
$! contains a pointer to the latest error return value.  Another
way to look at it is that the returned exception value is immutable
(more or less) but $! is mutably bound to some error value.

Larry

Re: Perl grammar for Perl5 -> Perl6

[Uri Guttman]

> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:

  LW> And if I were Jewish I'd've said "Oy vey" many times over.  :-)

or if you were a lazy jewish perl6 hacker you would code:

say "Oy Vey!" for 1 .. ;

:)

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org

Re: Perl grammar for Perl5 -> Perl6

[Rob Kinyon]

> As for the original question, I think that the Perl 6 grammar will
> be a much better example for how to parse other languages than a
> Perl 5 grammar would be, since one of the underlying design currents
> from the beginning has been that Perl 6 had to be a language that
> was amenable to parsing by Perl 6 rules (with a little help from a
> bottom-up operator-precedence expression parser.)

Once Patrick is done with PGE, will it be able to parse Perl5? If so,
why aren't we focusing on that?

Rob

Re: Perl grammar for Perl5 -> Perl6

[Jonathan Scott Duff]

On Thu, Dec 08, 2005 at 01:46:51PM -0500, Rob Kinyon wrote:
> > As for the original question, I think that the Perl 6 grammar will
> > be a much better example for how to parse other languages than a
> > Perl 5 grammar would be, since one of the underlying design currents
> > from the beginning has been that Perl 6 had to be a language that
> > was amenable to parsing by Perl 6 rules (with a little help from a
> > bottom-up operator-precedence expression parser.)
> 
> Once Patrick is done with PGE, will it be able to parse Perl5? If so,
> why aren't we focusing on that?

PGE isn't much of a parser; it's more like a framework for bulding
parsers. So, once PGE is done, to parse perl5, you'll still have to
write a grammar-ish thing that includes all of the maze of twisty
executions that perl currently goes through to "parse perl".

The same holds for parsing perl6 only the twisty maze isn't there (or is
at least much much smaller)

-Scott
-- 
Jonathan Scott Duff
[EMAIL PROTECTED]

Re: Perl grammar for Perl5 -> Perl6

[Larry Wall]

On Thu, Dec 08, 2005 at 01:46:51PM -0500, Rob Kinyon wrote:
: > As for the original question, I think that the Perl 6 grammar will
: > be a much better example for how to parse other languages than a
: > Perl 5 grammar would be, since one of the underlying design currents
: > from the beginning has been that Perl 6 had to be a language that
: > was amenable to parsing by Perl 6 rules (with a little help from a
: > bottom-up operator-precedence expression parser.)
: 
: Once Patrick is done with PGE, will it be able to parse Perl5? If so,
: why aren't we focusing on that?

Sure, but if you want to parse it *correctly* and know what it actually
means, I estimate it'll take about 20 times as much effort as you're
thinking it will, because there are an incredible number of foibles
in the Perl 5 parser.  Otherwise you might as well just use perl5:PPI.

I'm not trying to malign the PPI approach here.  It works most of
the time, and when it works, it works fine.  I don't doubt that it
will produce better translations of certain programs, especially
source-filtered programs where the filtering can essentially be
ignored.  But with the "PPD" approach I'm aiming first for a correct
semantic translation and secondarily for a close syntactic translation,
so what you'll get out of my approach is a post-source-filtered
translation that is likelier to work but less likely to be readable.
For a known source filter we can perhaps then refactor that back to
a more readable form.

In the long run these different approaches will complement each other,
and help us better understand each approach's weaknesses and strengths.
It's just that I have to take the PPD approach because no one else
is simultaneously knowledgable enough and nutty enough to attempt
it and succeed.  (Whether I am myself knowledgable enough and nutty
enough to succeed is yet to be decided.  Recent signs are encouraging,
especially in the latter department.)

Larry

Re: Perl grammar for Perl5 -> Perl6

[Larry Wall]

On Thu, Dec 08, 2005 at 01:10:14PM -0600, Jonathan Scott Duff wrote:
: The same holds for parsing perl6 only the twisty maze isn't there (or is
: at least much much smaller)

Hmm.  Maybe...

Perl 5 is a twistly maze of passages all different.

Perl 6 is a twistly maze of passages all alike.

Larry

This week's summary

[The Perl 6 Summarizer]

The Perl 6 Summary for the week ending 2005-12-04
I heard a rumour on the London.pm mailing list week. Apparently the Perl
6 Summaries are no longer being published. As I'm sure you can imagine,
it came as something of a surprise to me.

This week has been all about Parrot, Leo's got the new lexical scheme,
calling conventions and exception handlers working and made Parrot
stricter about arguments. The end of the week saw the release of
'Luthor', version 0.4.0 of Parrot. Read on for more details...

This week in perl6-compiler
Um... one post in perl6-compiler this week. And that was crossposted to
perl6-language. And because it got posted at the end of the week, none
of the actual discussion occurred this week.

Moving swiftly on...

This week in perl6-internals
Much more going on here as everyone rushed towards the release of Parrot
0.4.0 "Luthor" at the end of the week.

  Exception handlers and calling conventions
As I predicted last week, Leo's brain dump about exception handling got
discussed this week. It was well liked, and after a small bit of sugar
was sprinkled on to make ParTCL's life a little easier (and possibly
unsprinkled later) all manner of things were well.



  Subs may not contain dynamic call info, ever
Chip posted a clarification of his comments on what data could and
couldn't be hung off a Sub object at runtime. Let's be reentrant people.



  PDD20 Tcl
Will Coleda announced that ParTCL is now working with the new lexically
lovely Parrot calling conventions. There was much rejoicing.



  Test::More and Tests in PIR
Leo showed the love for chromatic's shiny pure parrot implementation of
Test::More. So the patch was applied.



  Upcoming changes
Leo announced the scratchpad's impending doom and outlined the planned
change for comment. Nobody commented, and the changes went in.



  Parrot directory reorganization
Quick quiz: where would you expect to find tests in the parrot
distribution? How about generated source files?

Jerry Gay proposed a reorganization to make things a little more lovely.

The consensus seemed to be that a reorg along Jerry's lines wouldn't be
a bad idea, but Chip pointed out that, whatever gets done it should be
done 'cautiously so as to minimize unpleasantness'. So Jerry is
proceeding cautiously, starting with a host of new TODO tickets in RT.



  Solving "=" confusion: ':=' for aliasing
There are those of us who are wondering why this one took so long...

Chip proposed that people start to spell aliasing as ":=" and assignment
as "=". I think it's a really good idea, but then I don't have a large
amount of PIR code to maintain so what do I know. Some other folks
weren't so sure, but Chip is not to be denied. Discussion then span off
into what language to write the automagical translator in.

I believe this may involve writing it in PIR then converting it to PIL,
which would be converted to Perl 5 using pugs and then Larry's Perl 5 to
Perl 5 project could be used to convert it to XML, which could then be
modified using XSLT and converted back into PIR using some scary voodoo
magic.

Or they could just write it in Perl 5. Prosaic, but possible right now.



  PDD03 Revisions
Chip announced that he'd put up another revision of PDD03 on Parrot
calling conventions. Most of the changes are simple clarifications and
flag renaming, but he's also proposing a new "READONLY" flag for
"get_params" to make it easy to support the default Perl 6 argument
mode. Response was muted, but favourable.



  PDD03 and Overflow/Underflow
It's been mandated for ages that Parrot should throw an exception when
functions get called with the wrong number of arguments. It's always
been one of those things that will be implemented 'some day'. Well this
week had a someday in it as Leo made parrot do what it's supposed to do.
And broke PGE for a while...



  PDD20 questions
Jonathan Sillito is a class act. He didn't just ask a bunch of questions
about the new PDD20 on lexical variables, he promised to take the
answers he received and use them to patch PDD20 to make things clearer.
Spurred on by this promise, Chip was unstinting in his answers and
clarifications of them. Which is nice.



  PIR methods and local variables occupy the same 'namespace'
Allison Randal used Snarks, Boojums and Thingies to demonstrate a
possible problem with the way Parrots local variable and method
namespaces overlap. Leo pointed out that this can sometimes be useful.
So, for the time being, Parrot continues as is in this area. 

Re: Modular versions and APIs

[Larry Wall]

It's probably not entirely clear in the spec, but it is already the
intent that version numbers work as API designators as well as module
designators.  Certainly, as you speculate, if different authors want
to share an API, they can give it an "API" author that knows how to
delegate to one of the authors.

For the most part, however, I think people will use v1.2 as the API
and v1.2.3 as one particular module implementating the v1.2 API.
That was more or less why three part version numbers were invented,
after all.  You'll note that we've been careful to define our matching
so that v1.2 requires an *exact* match on the specified part, so v1.2
does not match v1.3.  It does, however, match any of v1.2.0, v1.2.1,
v1.2.3, up to v1.2.18446744073709551615 or so, plus any subversions
like v1.2.3.4.5.6.

Plus there's all the pattern matching, which lets you say (v1.2...)
if you really want that.  Plus the fact that a v1.3 module is allowed
to advertise that it knows how to pretend to be the v1.2 interface,
though admittedly the syntax for that part isn't specced yet.  In
any event, the module aliasing mechanism is expected to paper over
all those differences to the extent possible.  I can say

use Penguin-1.2;

and within the rest of the *lexical* scope it aliases the short
name Penguin to whatever full name we really used, and that might
be actually be cobol:Dinosaur::Factory-42.582.17.255.255.0-DARWIN
or some such...

That probably covers most of your concerns.  Improvements to the spec
always welcome...

Larry

Re: Perl grammar for Perl5 -> Perl6

[Scott Walters]

Hi Peter,

There are several source filters that make select changes and modules
that give select Perl 6 features to Perl 5. All in all, there's a 
lot there -- I've written Perl6::Contexts, for example, which diddles
the bytecode to give Perl 5 programs most of the new contexts from
Perl 6. In fact, I kind of even wrote a book on doing this stuff...
http://www.perl6now.com. If you download the code listings, you'll get
examples of a couple dozen of these modules. As far as your example
of $array[idx], see Perl6::Variables. I have non-release version on 
Perl6::Variables in my CPAN area, SWALTERS, that adds more of the
Perl 6 changes.

I know this isn't the approach you had in mind, but I thought I'd 
mention it, as there is actually stuff there to play with. Fundamentally,
regexen to transform a Perl program aren't a bad idea, but this
approach, of fixing up Perl 5, is less likely to introduce bugs 
into the code and keeps the production-ready environment that Perl 5 is.
Transforming the code isn't a bad idea where there are transformations,
but in many cases, there aren't. I suppose that could be a fatal error,
but people would still be trying to "convert" their Perl 5 programs,
much as when people where converting to C from B, and any failure
scenario would create a flood of help requests, bug reports, etc.

I hope this helps!

Best regards,
-scott

On  0, Peter Schwenn <[EMAIL PROTECTED]> wrote:
> Dear Perl6 Language,
> 
> I am Perl user from near year 0.  For me the easiest way to learn (,
> track, and get to the point of contributing to) Perl6 would be a Perl
> grammar (a regex rule set in, preferably, Perl6) that transforms any
> Perl5 script into a Perl6.  Of couse, besides learning Perl6 for a
> regex'r or Perl5'r such as myself, and tracking, and documenting 6, it
> would have huge use for Perl5 users making or considering the
> transition.
> 
> 
> For example one can infer the structure and some of the rules from
>http://svn.openfoundry.org/pugs/docs/other/porting_howto   which is
> however written out in informal (not regex) rules such as $array[idx] ->
> @array[idx]
> 
> 
> 
> Is there such a Perl5->Perl6 translator underway?
> 
> 
> Sincerely,
> Peter Schwenn
> 
> www.schwenn.com
> 
> p.s. I'm not yet up to originating a good one, but believe I could make
> contributions in extending and checking it.
> 
> p.s. A Perl5 starting point might be better since running it on itself
> would provide and initiate at least 2 major test modes.
> 
> p.s. The developing form of such a grammar could likely lead to
> a grammar package which facilitates rule sets for languages in
> other domains, in terms of illuminating means of choosing among modes
> for rule ordering, collecting, scoping, re-application, recursion, 
> exclusion and so forth.
> 

Some thoughts on threading

[Ron Blaschke]

Hi everyone,

I am not a regular to this list but I'd like to induce some thoughts on
threading. I'm not too much into the subject myself, but I've got some
pointers, which I hope are of some use.  Please ignore me if I am not
making any sense here.

Herb Sutter has an interesting article called " 
The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software."
[1] He starts with "The biggest sea change in software development since
the OO revolution is knocking at the door, and its name is Concurrency."

Herb Sutter and James Larus continue with another interesting article about
"Software and the Concurrency Revolution." [2] They talk about "The problem
of shared state, and why locks aren't the answer" and "What we need in
programming languages."

Microsoft provides "An Overview of the Singularity Project." [3] In
Singularity, processes are very lightweight, and communicate with each
other through channels. Objects are owned by a single process only.

The Java folks have revamped "The Java Memory Model." [4]  Can't say much
to that one, as I am not through with it yet.

Hans-J. Boehm argues that "Threads Cannot be Implemented as a Library." [5]

Ron

[1] http://www.gotw.ca/publications/concurrency-ddj.htm
[2]
http://acmqueue.com/modules.php?name=Content&pa=printer_friendly&pid=332&page=1
[3] ftp://ftp.research.microsoft.com/pub/tr/TR-2005-135.pdf
[4] http://www.cs.umd.edu/users/jmanson/java/journal.pdf
[5] http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html

Re: [Phoenix-pm] Perl grammar for Perl5 -> Perl6

[Scott Walters]

Oh, sorry... Larry Wall didn't actually to Phoenix-pm. At least not that
I know of. This was a forward from me. Thought ya'll might find this 
interesting... on a Perl 5 level, in a Perl 6 sort of way, and also on
the subject of software refactoring.

-scott

On  0, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 08, 2005 at 11:51:52AM +0200, Yuval Kogman wrote:
> : On Wed, Dec 07, 2005 at 16:48:11 -0500, Peter Schwenn wrote:
> : > Dear Perl6 Language,
> : > 
> : > I am Perl user from near year 0.  For me the easiest way to learn (,
> : > track, and get to the point of contributing to) Perl6 would be a Perl
> : > grammar (a regex rule set in, preferably, Perl6) that transforms any
> : > Perl5 script into a Perl6.  Of couse, besides learning Perl6 for a
> : > regex'r or Perl5'r such as myself, and tracking, and documenting 6, it
> : > would have huge use for Perl5 users making or considering the
> : > transition.
> : 
> : IMHO machine translation is not that good a way to start learning -
> : the real benefit of Perl 6 is in the features which have no perl 5
> : equivalents and solve problems much more elegantly.
> 
> Except it would be lovely to have a smart enough refactoring translator
> that it could recognize where those elegant solutions are possible and
> at least give the option of attempting them.  Or at least a hint that
> there might be a better way.
> 
> : The best thing to do is to hang out on #perl6 and get involved with
> : the test suite, as well as reading the synopses.
> : 
> : Perhaps writing a toy program or something like that could also
> : help.
> 
> Sure, but some of our toys are bigger than others.  :-)
> 
> : > Is there such a Perl5->Perl6 translator underway?
> : 
> : Larry Wall is working on using the perl (5) interpreter to create
> : compiled output (as opposed to just something that executes in
> : memory) that can then be read by a translator without actually
> : parsing perl 5.
> 
> Yes, I have a version of 5.9.2 that dumps out some *very* strange
> XML that represents, as closely as possible, the exact meaning of
> the code to Perl 5, along with all the syntactic bits.  I then filter
> that strange XML back into something approximating an AST.  I am in
> the process of proving to myself that I'm getting enough information
> out of this to recreate the original Perl 5, so I jokingly call this
> my Perl5-to-Perl5 translator.  As of today, I'm able to translate
> 76.57% of the t/*/*.t files that come with the Perl distribution.
> Considering that last week this number was down at about 5%, it would
> seem that I've been making a lot of progress.  But most of the work
> went into that first 5%, and a lot of work will likely go into the
> last 5% as well.  To get that first 5% I basically had to completely
> refactor the lexer and the grammar without changing anything, which
> is of course impossible.  The Perl 5 parser forgets or misplaces an
> astounding variety of information that the translator needs, and
> you can't just go and tell it to turn off the optimizations, because
> in fact most of those optimizations are deeply interwingled with
> semantic analysis and transformations as well.
> 
> Basically, every skipspace() in toke.c and every op_free() in op.c
> and every rule reduction in perly.y loses necessary information.
> To attempt to do what I'm currently doing you would have to be
> completely insane like me.  It's a total nightmare.  If I were
> Catholic I'd be hoping this all counts as pennance for my past sins,
> and gets me out of 100 million years of Purgatory or so.  But being
> a Protestant, I'm merely repenting of my past sins, and thinking
> about maybe repenting my future ones.
> 
> And if I were Jewish I'd've said "Oy vey" many times over.  :-)
> 
> Anyway, once I get to 100% of the t/ files, I'll make it translate
> all of CPAN back to itself.  And at some point I'll take a first
> whack at the Perl5-to-Perl6 translator, then open it up for community
> participation.  It's still just a bit too early for that, though,
> because there's such a delicate interplay between refactoring bits
> of perl without changing anything vs trying to guess whether we are
> getting enough type and structural information out to recreate the
> original in the backend.  There are already more than 1 lines of
> code in the backend just to undo the damage done by the Perl 5 engine.
> 
> : Before this happens this will be very very hard - the high level
> : language has vast amounts of implications on execution etc, but the
> : opcode tree is much more simpler to predict (for a computer).
> 
> Right.  But my intent is to write a really good translator, and that
> implies that it has to be a multi-level translation.  That involves
> keeping track of all the subtle semantic and pragmatic information
> as well as the basic syntactic information.  Otherwise we might as
> well just feed Perl 5 to babblefish and see if Perl 6 comes out...
> 
> : > p.s. The developing form of su

Re: Modular versions and APIs

[Rob Kinyon]

On 12/8/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> [snip]  Certainly, as you speculate, if different authors want
> to share an API, they can give it an "API" author that knows how to
> delegate to one of the authors.

Would you mind elaborating on this some more?

Thanks,
Rob