[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jul 19 11:14:56 1993 
Subject:Re:quickie test 
From:Robin Popplestone 
Volume-ID:930719.03 

> However, I was trying to write an infix operator & which has the following
> behaviour:

>     (f & g)(...)
>     means:
>        g gets its arguments, f gets its arguments, f runs, g runs

There is a literature about the combination of functions, which goes back to a
paper by Schonfinkel [1922], in which he showed that three combinators, S,K
and I were all that is required for "gluing" functions together in arbitrary
combinations. If we don't want to appear before the world as country bumpkins,
it would be useful to show that we know that literature.  I don't have
the reference to Shonfinkel just to hand here in Glasgow, but a throrough
discussion is to be found in "the Implementation of Functional Programming
Languages" [1987] by Simon Peyton Jones, published by Prentice Hall.

Once we have established basic levels of scholarship, it is appropriate to
compare what you are trying to do with what is standard knowledge in
functional programming. Are there a complete set of combinators for POP-11
for example, which conveniently exploit the stack?


> I'd like to know what is gained by making these yield errors, apart from a
> sense of cleanliness? Does the "clean" stack treatment buy you anything?
> Since it is a restriction, I assume it would prevent you doing things that
> are very nasty. What?

There are infinitely many ways in which a program can run, so it is hard to
test a program systematically. However many errors can be caught by
type-checking in a sufficiently constrained language, i.e. for NONE of the
possible patterns of execution can one of these errors occur. Now giving the
wrong arguments to a function is possibly the commonest error in POP-11. In
many cases the error is rapidly caught during debugging, but systematic type
checking is a much better road to quality assurance. The open stack combined
with a lack of type info. makes these errors very easy to commit in POP-11.

In the old days, type-checking was a straitjacket, which meant for example
that you could not write general structure traversing functions in e.g.
Pascal, except by exploiting some dirty loophole which invalidated the type
safety (e.g.  non-policed variant records). Nowadays parametric polymorphism
avoids many of the old problems.

POP-1 arose  from the observation that since a reverse-polish form
operating on a stack was an appropriate target language for a functional
programming system, the low-overhead way of providing funcitonal programming
was to provide what was in effect an assembly language for a stack machine.
We left the open stack in POP-2 partly from inertia, but justified it from the
observation that arrays in particular, and memo-functions in general, would
need to be the closures of variadic functions. There are still, I believe,
good reasons for preserving an open stack (e.g. the cheap associative
combination of the results of functions).

However if we want to provide modern standards of assurance that our programs
are correct then we have to find some way of constraining stack use. My idea
of stack-grammars seems the only one presented in this group (to my
knowledge) that has a chance of preserving a useful body of open-stack usage
with the possiblity of a feasible implementation.

Robin.