Re: I'm a lurker too ...

At 12:48 PM 8/7/00 -0700, Gary Richardson wrote:
>On Mon, 07 Aug 2000, you wrote:
> > 1. A Perl to C or Perl to machine code compiler. Perl is fast, but
> > compiled C is an order of magnitude faster. (And I vote for data types,
> > i.e. my int $num, so that a compiler do its job that much better.)
>
>Compiling perl will only cut down on initial loading (I am guessing).

Incorrectly, actually. It's quite possible that a perl2C or perl2something 
backend (likely one that connected to a real compiler's optimizing backend, 
like gcc or DEC's GEM backend) would get you faster code in spots, though 
whether it was overall fast enough to be worth it's an open question.

Not likely to be done to start just for portability reasons. Building a 
portable interpreter's enough fun--building backends for all the 
architecture/OS combos perl runs on would be a major pain.

> > 3. Visual Perl. Just like Visual Basic and Delphi, but its Perl and runs
> > almost everywhere, not just windows.(I know ActiveState is working on a
> > product called Visual Perl, but I'm note sure this will be just like VB
> > or if it will run on non-windows platforms.)
>
>See Perl/TK and/or GTK.
>
>Perl runs just about everywhere, as does TK, there for Perl/TK runs just 
>about everywhere..

Incorrect assumptions. Many Unices, yes. Windows, mostly. VMS, sort of. 
That leaves out a lot of perl's platforms. (Mac, anyone?)

This is more an add-on, though it wouldn't hurt to do simultaneous 
development to get the appropriate hooks from perl to make it easier.

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[email protected]                         have teddy bears and even
                                      teddy bears get drunk