Steve, thanks for your comments.
> The recent change to Pop11, that of making input/output locals be
> implicitly declared as "lvars" goes part of the way towards this.
> And because I believe that this is a highly desirable change, I
> am pleased to see it. Aaron's complaints about the change are, I
> think, not so much about the merit of the change but about the
> migration policy that was adopted
Yes. A (final) summary:
(a) some very old books and teach files will be made out of date, but I
am not so worried about that as I am not sure they are used much -- but
those in the poplog system should have been updated. Fortunately making
input and output variables default to lvars will hardly affect
documentation and libraries I've produced over the last five or six
years as I've been using lvars explicitly anyway;
(b) disallowing a combined dlocal and permanent declaration has no
justification. (I am not convinced by any of the arguments so far
adduced). (Maybe the real justification has something to do with POPC,
though I'll be very surprised if anyone outside Sussex and ISL ever
wraps their brain around POPC.)
(c) allowing a global compile_mode switch rather than introducing new
syntax for the new defaults seems to me to be a recipe for long term
problems as there will be code fragments that people will develop under
different assumptions, and then the attempts to combine them will not
work. (I am not talking about professional software engineers, but
students, harrassed and overworked teachers, non-serious users, etc. But
it could afflict some professionals too: not all of them will remember
to put the appropriate compile_mode declaration in every file, if they
have been using the "global" option.)
I assume the developers could not face replacing all occurrences of
"define... enddefine" with "defun ... enddefun", and replacing
"procedure .... endprocedure" with "lamda ... endlambda", or whatever.
That would have made it easy to write an appendix to the primer on the
new syntax for pop95.
Your idea of a new file suffix for a new subsystem is better than using
the compile_mode declaration, but I still think people will transfer
bits of code and get into unnecessary muddles. If the procedure header
syntax were new, the muddles would not arise. I think that once define
and procedure had new (optional) replacements then "for" and other
things would not need a new syntax: the new semantics could go with the
procedure header, which would normally be visible as a clear reminder.
Anyhow, that's water under the bridge now.
> ....
> The missing category of contant-lexical
> variables is sorely missed in Pop11. (N.B. lconstant is
> an entirely different concept, despite the name.)
yes. Something like "lprotect" ?
Also I seem to recall, from discussions with Rob Duncan about 6 or seven
years ago that we decided there was a need for a type 4 lexical, for
optimising things like ML. But I can't now remember what that was.
Perhaps he does. Maybe something between type 2 and type 3.
> ...
> All these suggestions need justifying and I don't propose to
> do that here since the arguments are extensive. However, all these
> ideas are present in Pepper and this is a demonstration of how
> they all play together marvellously to create a simpler language
> that is (in my view) easier, safer and more natural to program
> with.
Maybe that's where the future of Pop-11 lies, not in Poplog perhaps, but
as a stand-alone, single language system. When will others have access
to it? I assume HP would not wish to turn it into a product?
Aaron
|