--- In snobol@yahoogroups.com, Mike Radow <mikeradow@...> wrote:

> _Thanks_ for the incisive comments, Mr. Aksjghkajshd! ?Are you _actually_
Scott Walters? No surprise if "yes"... ,,,and,,,:

Yes, I'm Scott Walters. Or SWALTERS on CPAN. I have a strong typing (C++ or
Java style types) implementation for Perl, among other things.

Yahoo! was deleting my accounts left and right for a while, for reasons not
clear to me, so I became lazy in filling in details when creating new ones.

> When early specs came out for Perl 6, several of us looked into using a
SNOBOL4 program to scan Perl 5 _source_, at least to scan for conflicts. This,
we reasoned, would be useful _even_if_ a complete conversion was not possible.
In many cases, tho' admittedly not all, it did look like a large portion of
programs _could_ be fully "automatically" converted. Of course, there are likely
numerous (pathological) cases which we missed. (My Dad used to call these
abusive "corner cases" with a special name: ''Sharp corner cases''.)

Interesting. I'm sure you've heard the saying, "only perl can parse Perl"
(referring to the name of the interpreter and the name of the language
respectively).

There's PPI, which is a pretty good Perl 5 grammar implemented in Perl 5.
Creating that was quite a project. That's unable to deal with a lot of things
still though. The approach that would probably be taken would be a "from the
inside" one, where Perl 5 parsers a program and then runs code that inspects the
bytecode to generate the translation. Larry Wall's own work runs closer to this
direction, combined with fixing up the parser and bytecode to preserve even more
information than it already does. For illustration purposes, this already
works:

perl -MO=Deparse -e 'print "hi\n" for 1..10;'

# outputs:

print "hi\n" foreach (1 .. 10);

The B module makes this possible by providing an OO interface to inspecting the
bytecode of the compiled program:

http://search.cpan.org/~nwclark/perl-5.8.9/ext/B/B.pm

> Since Perl 6 will be implemented for Parrot (?is this the correct
terminology?), there will be a natural _reuse_ of CPAN modules which were
converted by "regular" Perl 6 users, who have not interest nor contact with the
Parrot implementation. This would speed the availability of CPAN modules to
Parrot users, through no effort of their own.

Yes, that terminology is correct. But this brings up another problem with
translation... XS. Most Perl modules are written entirely in Perl, but many,
including many of the most useful ones, are partially implemented in C. This
includes but isn't limited to bindings to system libraries. Those "XS" modules
rely on details of Perl 5 internals that need to change and cannot easily be
translated. The XS interface has held back core Perl 5 cleanups and prevented
Perl 5's growth. It's something of a paradox. Getting rid of it means breaking
half of CPAN but keeping it means no future growth for Perl. Breaking the XS
interface is perhaps more of a radical step for Perl going from 5 to 6 than
changing the language's syntax.

> BTW: The "pugs" implementation is extremely clever. I'd have expected that the
Haskell-based implementation would run very slowly, but this is not the case. So
much, I guess, for the common wisdom that "functional languages are always
slow".

ghc is getting very good at optimizing. I'm not sure if the Pugs page mentions
this, but the original plan was to make Pugs self hosting by rewriting the
Haskell in Perl 6. As it is though, the project has mostly run out of steam.
Perl 6's constant revisions to specification haven't helped matters there.

> For the curious, please see...:
> +
> http://en.wikipedia.org/wiki/Pugs

> Sorry to go on so long. In these (economic) days, I don't have much time for
more than infrequent reading of emails and postings, with almost no time to
write posts...

Understood. I had been meaning to make time to say "hello" here for some time.

>
> I hope that something above is of interest / use to S4LS members.
>
> Mike

Regards,
-scott