Sender: pop-forum-request@computer-science.birmingham.ac.uk
In article <1994Jan17.095242.18410@aifh.ed.ac.uk> dcu@aifh.ed.ac.uk () writes:
> Hullo POP people,
> One of those Friday afternoon confusions I would really appreciate a
> clear answer to. Consider the following:
> constant a1;
> [1 2 3]->a1;
> define binki(lst);
> lvars lst;
> 10->hd(lst);
> enddefine;
> When I run binki() it changes the value of the constant a1. I'm sure this is
> what everyone apart from me would expect (even on a Friday).
> So WHY does this happen and HOW do I stop it?
A reasonable question! Access is not an orthogonal aspect of POP
data-structures. That is to say, there is no apparatus which allows one to
specify that a particular member of a given data-structure class can or
cannot be updated. To do so would require either (a) extra apparatus,
such as a "read-only" bit somewhere in the data-structure, or (b) putting
the structure in an area of memory which is made read-only by the operating
system.
(a) would impose extra time overhead on all updates and extra space
overhead as well. Of course, in a persistent language, which POP is not,
orthogonal access control is likely to be a desirable design feature,
and would include various aspects normally associated with -files-.
(b) is not possible for the POP syntax as shown, since the semantics of
[1 2 3]->a1;
are "evaluate [1 2 3]" and then bind the resulting value to "a1". So there
is no way that [1 2 3] could be created in a special area of store, and it
would really not be good design to make the evaluation depend on the
destination. If the preferred form
constant a1 = [1 2 3];
were used, one could change the evaluation-context so that the list was
constructed in read-only memory. However, given that POP is incrementally
compiled (usually) this is not so easy as would be the case for a
conventional compile-load-link kind of language, where the data-structure
can be thrown into the code-segment. It depends on facilities that are even
now rather non-portable between operating system versions. The POP system
would have to ask the operating system "make this constant page writable",
it would then build the data-structure [1 2 3], and then ask "make this
constant page non-writable".
And why lvars? Well - the answer is that we, in common with the LISP
community, went for dynamic binding of local variables rather than lexical
binding. Our reasoning was "all languages (except CPL) treat variable
bindings incorrectly (most still do). Ours is wronger than most, but it can
be remedied by creating explicit closures using partial application.
And it has some pragmatic advantages". Subsequently we devloped correct
ways of handling variables (lvars in POP). So they -should- be the default
(they are e.g. in Common Lisp) but are not because of compatibility
problems. My POP-11 type-checker -insists- that non-lexicals be declared
dlocal. Frankly, I think the POP community should bite the bullet and
make lvars the default.
Robin Popplestone.
|