Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!apple!claris!ames!amdcad!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!strath-cs!glasgow!orr
From: orr@cs.glasgow.ac.uk (Fraser Orr)
Newsgroups: comp.lang.forth
Subject: Re: Infix/Postfix notation
Keywords: infix, postfix, stacks
Message-ID: <1583@crete.cs.glasgow.ac.uk>
Date: 25 Aug 88 14:53:47 GMT
References: <2768@pt.cs.cmu.edu>
Reply-To: orr@cs.glasgow.ac.uk (Fraser Orr)
Organization: Comp Sci, Glasgow Univ, Scotland
Lines: 100

In article <2768@pt.cs.cmu.edu> koopman@a.gp.cs.cmu.edu (Philip Koopman) writes:
>Several recent postings have debated the merits of infix versus
>postfix notation in Forth.  I'd like to present a different
>viewpoint for discussion.  Postfix notation is just a side-effect
>of a much more important issue: parameter passing for subroutines.

A think a more historically accurate point of view would be
that implicit parameter passing is a side effect of postfix :-]

>One of the most useful aspects of Forth is implicit parameter
>passing.  That eliminates the tedious lists of parameters in
>parenthesis found in other languages.  This makes the code much
>cleaner and more flexible than other languages.  It also makes
>defining words and immediate words handy. 

I don't agree that it makes the code either cleaner or more flexible
than other languages, because the parameters are very hard to see
(they are mixed up with all sorts of junk on the stack)
I agree though that in theory "implicit parameter passing is good....

All you need to do is define a syntax that makes it clean, and
explicit. For example consider a procedure that takes (x0,y0)
and (x1,y1) as coordinates, and a string and a colour, and an operation
(XOR, AND or OR) and draws a box on the screen. It uses two
procedures hline and vline, (which draw horizontal and vertical lines)
taking colour and operation as their last parameters. It then prints
a string in the box, with a procedure called showat, that does not
take operation or colour as parameter.
We could define it as follows.

procedure Box (String,x0,y0,x1,y1) (colour,operation)
begin
  hline (x0,x1,y0)...
  hline (x0,x1,y1)...
  vline (x0,y0,y1)...
  vline (x1,y0,y1)...
  showat(x0,y0,String)
end

The first line specifies two parameter lists (the later is
optional). The second specifies which of the parameters are 
to be passed on implicitly.
Now we mark every procedure call that requires the implicit params
with an elipsis (...) and thus you have all the power of
implicit parameter passing, without hiding anything (the
elipsis makes it clear that there is more information that
has been omited, and the second param list show exactly what it is).

Since you might want to do this on a scope less than a whole
procedure, you might also introduce an implicit keyword viz.

procedure Box (String,x0,y0,x1,y1,colour,operation)
begin
  implicit (colour, operation)
    hline (x0,x1,y0)...
    hline (x0,x1,y1)...
    vline (x0,y0,y1)...
    vline (x1,y0,y1)...
    showat(x0,y0,String)
  end
end

This would allow you to vary the parameter list within
the procedure, so that different implicit params could be given.
Can anyone really, honestly deny that this syntax is MUCH
nicer, MUCH clearer, MUCH more flexible than what we currently
have in forth? I was going to write a similar routine in forth
to contrast, but the thought of dealing with a six deep stack
was too much for me!:->
I would though be interested to see your offerings.

>The arithmetic operators are treated as subroutines just like
>any other word.  This allows a blurring of the distinction between
>hardware supported primitives and high level routines, improving
>transportability and making optimization of inner loops in
>assembly language or microcode quite easy.

This is true of most of the newer programming langauguages,
that is '+' is treated as a function taking two arguments,
just that it has a different function call syntax.

>So, to me, the RPN notation is just an inconvenient side-effect
>of the implicit parameter passing mechanism used by the language,
>and is not really an important feature itself.
>
>As an aside, real infix notation parsers are relatively simple
>to write (for example, the one Chuck Moore wrote for his tiny
>BASIC interpretter.)  I think that most people don't bother with
>them because most expressions that are evaluated are very simple.
>
Both these comments lead me to ask again, why don't you
accept the idea of programming in a language that deals with
important issues (syntax, type checking etc) that compiles
quickly into forth? And to say that most expressions are simple
thus making them clearer is not necessary is a terrible argument.
I try to keep my expressions as simple as possible for the sole
reason of making them clearer!

Regards,
===Fraser (orr%cs.glasgow.ac.uk@nss.ucl.ac.uk)