>Jonathan (another late bird) wrote:
>
>> FWIW, I think the ease-if-use v. efficiency trade-off has gone too
>> far in the direction of efficiency. Certainly it should be *possible*
>> to make things more efficient, bt flexibility and ease-of-use are
>> the primary advantages (IMNSHO) of Poplog, so Dave should never haeve
>> had this error in the first place.
>
>I don't think lexical scoping is a matter of efficiency. It's a matter
>of clarity.
I agree - lexical scoping was not the problem, nor was I commenting on it.
The default should be lexical scoping, and it should not have caused
an error in the example.
>But I agree that in principle the compiler should have been able to
>guess his intention (just as you and I did). That could be done if it
>were a two pass compiler, which on the first pass collected all the
>local declarations and on the second pass used them. However, I am not
It's sufficiently complex that I wouldn't call it a single pass
compiler anyway; the added complexity (in the compiler) would be
negligible, I think.
>sure that this is possible in general in a language as flexible as
>pop-11 which can have arbitrarily complex macros and syntax words that
>can do anything, so that they may have a different semantics on the
>second pass.
Yes, if anything about it is single pass, one might say that the syntactic
analysis is done in a single pass. Although with macros, I'm not sure
I'd even assent to that much.
But your point, while correct, that a piece of code may have arbitrary
semantics is not *entirely* a good thing, e.g.
: 1 + 1 =>
** 57
would (to many people) be surprising behaviour, even though it is easily
achieved by redefining any or all of
the itemiser (see incharitem)
the + operator
the => syntax operator
etc.
and that's excluding things like modifying the code generator!
>So I wonder if a modification to the one pass compiler could do it: i.e.
I don't agree that it is a one pass compiler.
>plant virtual machine code in which undeclared identifiers are noted
>and perhaps represented by a reference which could be on a list of
>undeclared identifiers. Then if a declaration is found later on in the
>same procedure body the contents of the reference can be updated.
This would be done in sysENDPROCUDURE, probably, which has available
a lot of information being built up in the "single" pass, i.e. subsequent
"passes" are done on this data.
(If one tokenised a text file, using pdtolist(incharitem(discin(...))),
then the file would be read in a "single pass", even if you iterated
over and manipulated the resulting list a thousand times.)
But the real point I'm making is that the whole notion of "pass" probably
doesn't make a lot of sense any more: we are not running paper tape
through a tape reader (or card decks, or magnetic tape, etc.) so it is
possible to have interactions between the "passes" -- even macros can (and
do) do this: they put stuff back into the item stream.
I wonder to what extend a cleaner separation between compilation stages
would be of benefit v. loss of (useful) power?
(snip)
>Sometimes lexical nesting is useful, because you want the nested
>procedure to access a non-local variable, possibly to make a closure.
Which may, or may not, be the case here: D.J.Gurnell's example was
simplified.
>But in general it is easier to use file-local lexicals (lvars and
>lconstant).
I'm still wondering if we should have namespaces in pop11. This was
the intent of sections, but I don't know how clever the editor/compiler
combination is in working with them (e.g. compiling one procedure in
a ved buffer). In any case, we need to abstract out the editor
interface from core poplog, and defining how *any* editor should
interact with a namespace mechanism (which might be sections) may not
be simple.
Nor are file-local lexicals nice, with the current editor interface
(unless I'm misremembering).
(snip)
>There's a section on this in HELP LEXICAL
>(Are file-local lexicals available in common lisp? Maybe the package
>mechanism provides an equivalent.)
They are available in C, C++, Java etc. but not, IIRC, in Common Lisp,
where global variables are always "special" (i.e. accessed with
dynamic scope).
The package mechanism is what sections are for, and you are correct in
that it could/would be used for such a purpose.
>[AS]
>> >Very few languages have the kind of flexiblity and power that require
>> >all the subtlety described in the documentation.
>>
[JLC]
>> I'm not sure that sublety is a Good Thing(tm) in a programming language;
>> perhaps you meant Power and Convenience? :-)
>
>I am ambivalent about this. Certainly some of the things that can be
>done with lexically scoped identifiers (e.g. returning closures, or
>passing lexical closures to other procedures -- such as applist) are
>often very convenient.
Is that a subtle feature of the language, or a powerful one? :-).
As for your comments about GC, *one* possible way forward might be to
treat entire files as the minimal compilation unit (no more "load
current procedure" in the editor). Or sets of files. Given modern
amounts of RAM, the text of many files could be held in memory, and
compilation is fast enough that it would not be unreasonable to
recompile a whole "compilation unit" consisting of several small
files.
It would be interesting to know what compilation delay people would
tolerate: 1 second? 10 seconds? I can imagine the scene, a programmer
spends two days writing a program, and then storms out in fury because
compilation takes more than 3 seconds.
OTOH, people who write code with bugs in probably want fast recompilation
during debugging :-).
Jonathan
|