🚀 go-pugleaf

In article <KERS.92Nov12085629@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
>In article ... veit@du9ds3.uni-duisburg.de (Holger Veit) writes:

			......................

>But Herman might not think of those things as ``operators''. Consider the Pop11
>definition:

>    define 5 ++( x, y ); lvars x, y; x + y + 1 enddefine;

>The ``5'' is the precedence (it happens to be the same as ``+'') and makes
>``++'' a (nominally infix) operator, so expressions such as

>    x ++ y, f(x) ++ g(h(y), z)

>work. But (in Pop) an operator is *just* a procedure with a pleasant calling
>syntax; writing ``x ++ y'' just means ``push x, push y, call ++'' (Pop is an
>open-stack language), ``x * y'' means ``push x, push y, call -'', and ``f(x)''
>means ``push x, call f''. *Some* procedure calls are coded in-line, but this is
>not a property of being (syntactically) operators; it is a property of being a
>particular procedure, such as fast_front, or fi_+.

If you could write 

define	(x ++ y) x+y+1

I would accept that as the insertion of the ++ operator.  I would definitely
allow far more complicated versions, as defining the power operator differently
depending on the types of the arguments.  But I would object to any language
which insists that we use a strictly stack machine.  Pushing, popping, and
calling are to be avoided unless necessary.  Otherwise things just run too
slowly to be of more than theoretical use.

But there are operators I would not want to consider defining in terms of the
usual language primitives, because they essentially cannot be sensibly done 
that way.  SOME of these may get into libraries where the user cannot use
them himself, like add with carry, or simultaneous results of an operation.
One should strive for semiportability, but not full portability, and in many
cases the use of them would be portable, but the code would be machine.

Getting any speed out of machines requires that we think of speed in coding,
rather than the fact that it is possible in principle to operate with a 
stack machine with no registers.  This also ignores hardware, such as vector
machines, where the use of a control register or control stream introduces
basic bit operations which did not exist before, and which are utterly stupid
as a means of efficient computation on a stack machine.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@snap.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!snap.stat!hrubin(UUCP)