Author Message

> But of course, you have to keep changing the definition of the
> structure Env for different purposes, which can makes reuse of code
> difficult.

This of course is missing the point of functional abstraction - POP in some
sense has no data-structures, only functions. So you can just extend
environments by introducing new selector functions. The trouble with this
approach is of course the *constructor functions* which have an arity that
is specific to a particular application.

A useful approach to dealing with this problem is to introduce constructive
ways of changing individual components of a data-structure (I usually call
them with_X - eg  L with_hd 2  is the list L with its head constructively
replaced by 2). I think that something similar is talked of for ML.

Alternatively, you can make environments be properties which map names to

>Also when the environment changes you either have to use
> dlocal anyway, to ensure that it is automatically reset whenever
> procedure exit occurs, or else you have to copy the structure on
> entry to any procedure that can change it.

Well...there is profit for many applications in using POP as a
functional-language-toolkit, in a style in which you write you topmost
layer (the user interface) and your bottom layer (*your* primitive
functions) in a non-functional way, but write the rest in a pure functional
form. This means in particular that you obtain log times for
the incremental computations of tree-to-tree functions via memoisation.
All problems of algebraic simplification and compilation are much eased by
such an approach (algebraic simplification is usually conducted in some
kind of environment - e.g. what order to sort the variables, whether to
apply distributivity, trig. identities...). In particular, one would be
able to perform log time incremental compilation of context-sensitive
languages like ADA, instead of the linear time compilation characteristic
of conventional compilers. (...for changes that didn't involve a change to
a global declaration that is...).

Generally, I think the world made a big mistake when it went for the likes
of C as a systems language, and regarded a system like Multipop as the
muddling along of amateurs. I believe that decent functional abstraction
could (e.g.) provide flavours of X that are efficiently local or
distributed as required by an application, and that the uniform checking
mechanisms of POP avoid inefficiencies arising from non-uniform checking
mechanisms that C programmers are forced to hack up. But some of the things
you can get with NJML (and that they are actively exploiting in CMU) do
require that variables be lexical.


Sat, 15 Jul 1995 02:08:52 GMT  
 [ 1 post ] 

 Relevant Pages 

1. puzzle about dlocal and input locals

2. conditional version of dlocal

3. dlocals etc.


Powered by phpBB® Forum Software