[MacPerl] Whither MacPerl?

[Matthias Ulrich Neeracher <neeri@iis.ee.ethz.ch>]

Chris has already summarized my statistics regarding the sources in the MacPerl
distribution. Another relevant article in this debate is, I think, my position
statement for the Perl Developer's Workshop, which I have attached to this
mail.

Now, regarding some more specific points:

David Turley <dturley@pobox.com> writes:
>I would love to see standard perl build out of the box for Mac,

Why?

> Perhaps, there could be an additional "make" to run that
>would add in the Mac specifics.

This is a misunderstanding. Merely to *run* on a Mac takes a lot of extra
code. *All* of GUSI is just support to make MacPerl run "plain" Perl scripts.

>It is somewhat disheartening, given the
>usual one-up that the Mac usually has over wintel, that it lags when it
>comes to perl.

Sorry, but this is a criticism that I cannot accept in this form. Until quite
recently, AFAIK, you had the pick between a WinPerl which did OLE and one which
did sockets, but you couldn't have both.

>That on my laptop, I can install (most) CPAN modules simply
>by running 'dmake', the win version of make. The modules build just like
>they do under *nix.

Now this, I consider a valid point, although it primarily has to do with the
fact that no Macintosh make runs standalone. It might be possible to do a
install-only MakeMaker variant that doesn't produce Makefiles, though.

>Having to install MPW to run perl like it was meant to
>run just doesn't do it for this user.

I don't understand this. You want to be able to build Perl from the sources,
but you are not willing to install a development environment for this. What do
you want me to do? Ship the distribution with a packet of fairy dust that, when
sprinkled over the source, compiles & installs it? :-)

> But I don't want to see the mac left
>out of standard perl, strictly for the sake of the "toolbox." This would
>also, I believe, relieve some of the burden from Matthias.

The Toolbox modules are not really the problem here. However, there is another
valid point in here: The Mac specific parts of the MacPerl distribution should
be packageable as a separate distribution, so you should be able to simply
drop in a new core release & recompile.

Matthias

-----
Matthias Neeracher   <neeri@iis.ee.ethz.ch>   http://www.iis.ee.ethz.ch/~neeri
   "These days, though, you have to be pretty technical before you can 
    even aspire to crudeness." -- William Gibson, _Johnny Mnemonic_

Perspectives for MacPerl:
First class Perl implementation, first class MacOS programming language

Matthias Neeracher, 01Jul98

For obvious reasons, my interest in Perl core development is mostly about the
future development of the ports of Perl to MacOS and potentially to future
Apple operating systems. I see this development progressing along two main
lines:

 - Strengthening MacPerl's ambition of being a first class Perl implementation,
   i.e., supporting all major components associated with Perl on other
   platforms.
 - Strengthening MacPerl's ambition of being a first class MacOS programming
   language, i.e., allowing any Macintosh program to be writable in MacPerl.

To some extent, these two goals coincide, such as in the implementation of
threading support currently in progress, and in support for the Perl compiler.

Moving toward a first class implementation
------------------------------------------

Major components currently missing in MacPerl are:

 - Support for Perl threading (multiple threads per interpreter). In progress.
 - Support for the Perl compiler. Planned.
 - Support for PerlTk. Under consideration.
 - Support for a GUI debugger. Under consideration.

Some of these efforts will require substantial amounts of work, especially
threading support, but especially the first two efforts are essential.

Moving toward a first class MacOS programming language
------------------------------------------------------

Currently, MacPerl supports about 30 MacOS toolbox managers, covering basic GUI
functionality like Window and Menu management, interprocess communication
through AppleEvents and OSA, but also advanced Multimedia functionality such as
Speech synthesis and recognition, QuickTime movie reproduction, and QuickTime
VR support.

Future plans include on one hand to cover more toolbox modules such as
QuickDraw 3D, on the other hand to make the writing of substantial MacOS
programs (for rapid development or prototyping) more practical by supporting
threading (multiple threads per interpreter and multiple interpreters running
in their own threads) and using the Perl compiler to decrease program startup
time (of which probably a substantial part can be attributed to module
loading).

General trends, including the availability of faster processors, more RAM, and
improved virtual memory support in MacOS, tend to work towards decreasing the
main drawbacks of MacPerl over conventional languages (speed and memory
demands), so MacPerl and other VHLLs can be expected to play an increasing role
in MacOS development in the future.

Keeping up with Apple's plans
-----------------------------

It is not clear to me at this point how exactly Apple's operating system
strategy will look like in the future. However, general trends (moving towards
a more POSIX compatible core, improved memory and process management) all point
towards an even brighter future for Perl on Apple operating systems, even if
the current MacPerl core may not be overly relevant in some of the OS
scenarios, e.g., Rhapsody.





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