🚀 go-pugleaf

In response to the comments about ``inline'' procedures in M2 (and other
procedure languages.  I do not see why the programmer should provide hints
to the compiler or linker as to the ``correct'' way to optimize a particular
program.  Given that most linkers nowadays are static, I see no reason why
a linker couldn't decide to in-line a particular procedure given enough
information by the compiler (like the size of the procedure).  After 
programming in C a few years, it was particularly annoying to me to have
to figure out which variables were supposed to go in a register
and which were not.  I also always wondered why I couldn't make global 
variables register variables, but that is besides the point.

Clearly, I am making a common argument: let the compiler do it, it is smarter
than you are.  The Volition's M2 compiler for the P-system provides
a method for doing in-line code in the definition module.  It always seemed
silly to me to provide such an interface.  The argument was that it was a
cheap way towards improving the speed of M2 code.  I say that it is
a good way to decrease the maintainability of a program or library.  The
same goes for in-line procedures which are not in the definition module.
Specifically, some machines have expensive procedure calling mechanisms
and others have cheap ones (VAX vs. RISC).  It is certainly reasonable
that if you in-line something on a VAX it may go faster while the same
``optimization'' may reduce the speed of the same code running on a RISC.
The reasons for this are complicated, but it boils down to how much is
in the Cache and how fast is a procedure call.

M2 has plenty of silly programmer directed optimization techniques
and some of them yield incorrect results when used without special checks
(e.g. the CAP function).  We should work on getting a good optimizing
compiler for the language that exists instead of trying to add features that
make the language even more complicated.

Rob Nagler
Olsen & Associates
seismo!mcvax!cernvax!unizh!olsen!nagler