Re: [MacPerl] Byte Compiler for MacPerl

[online@mactech.com (Jeff at MacTech)]

In article <mac-perl.v04003a00b1fbca6957af@[194.2.9.12]>, Vincent
Nonnenmacher <dpi@pobox.oleane.com> wrote:

>>In article <mac-perl.199808121257.OAA28691@gwaihir.ee.ethz.ch>, Matthias
>>Ulrich Neeracher <neeri@iis.ee.ethz.ch> wrote:
>>
>>>I still think the C/C++ backend option is overrated. What is missing in
>>>this debate is that the C/C++ backend still needs at least 80% of the
>>>Perl runtime,if not 100%, to run.
>>
>>Is most of this there to support "eval $string" and the like (things
>>which sill require an full interpreter)? Would it be possible to cut
>>this down significantly by just outlawing a few of Perl's features?
>
>WHAT ??????
>
>eval is one of the most unique and powerfull feature of Perl it couldn't
>be conceivable tgo remove that and still prented this is perl.

I didn't say to remove it from the language. I asked if programs that
didn't use features such as this, which overtly requires a complete perl
interpreter, could compile down to maybe 10K rather than 1 or 2MB. By
"outlaw", I mean that this version of the compiler would only allow (ie,
compile) programs which didn't use these language features. Since there
are already 2 or 3 backends to the compiler, adding this would not prevent
the others from existing.

There are already language features which will probably never be supported
in compiled-to-C Perl. As mentioned in the Camel, "goto LABEL" will
probably work, but "goto function($state)", where function returns the
label of a block, probably won't. So, my question is, could I obtain
compact binary versions of short scripts which don't actually use these
interpreter-dependent language features? Or will even the smallest script
ultimately require a megabyte-sized download for the end user?

>>>Byte code should be a massive improvement in speed vs. source code
>>
>>I presume that this will allow distribution of executables without
>>human-readable source code? If so, will they be (unfortunately) trivial
>>to decompile?
>
>This would be the same kind of debate we've seen 4 years ago when java
>starting to make noise, ask your'self what is the current situation about
>decompiling class file.

I don't know what the current situation is with Java class files. I wasn't
starting a debate, just asking a question.

>The point is not to make an opaque wayt o make money about selling perl 
>scripts or module it is to enhance the compile stage problem and provide 
>much more speed when executing over and over cgi or mod-like plugs.

The goals are not incompatible, and their relative importance will vary
from person to person. Some people want faster execution, some would like
to be able to distribute smaller stand-alone binaries, and some are
legally prohibited from distributing proprietary source code but can
distribute binaries which use it. Different people have different goals,
concerns, and restrictions.
-- 
__________________________________________________________________________

Jeff Clites                Online Editor           http://www.MacTech.com/
online@MacTech.com         MacTech Magazine
__________________________________________________________________________

***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch