Newsgroups: comp.lang.apl
From: bernecky@eecg.toronto.edu (Robert Bernecky)
Subject: Re: Structured APL requires abandoning dynamic scope?
Message-ID: <1994Sep12.002048.7641@jarvis.cs.toronto.edu>
Keywords: Object oriented
Nntp-Posting-Host: algonquin.eecg.toronto.edu
Organization: University of Toronto, Computer Engineering
References: <350j9d$pms@overload.lbl.gov>
Date: 12 Sep 94 04:20:49 GMT
Lines: 88

In article <350j9d$pms@overload.lbl.gov> wchang@cshl.org (William Chang) writes:
>In article <1994Sep11.114534.5151@jarvis.cs.toronto.edu> bernecky@eecg.toronto.edu (Robert Bernecky) writes:
>>In article <34ual4$ji4@overload.lbl.gov> wchang@cshl.org (William Chang) writes:
>>Dynamic scoping's main effect is to make function call Very Slow, compared
>>to other approaches.
>
>Can you provide a rigorous comparison?  Shallow binding for dynamic scope is
>pretty fast.  (I know what you mean, statically scoped variables can be
>pre-compiled.  I never said dynamic scope is faster; someone else did.)

Aside from dynamic scoping's main feature: Making programs VERY hard to
debug or maintain, it IS slow. A rigorous comparison? Against what?
Let's assume that comparison against a compiled language with static
scoping is OK:
  compiled: Function call pushes a stack pointer.
  APL:      Function call pushes EACH localized name onto a
            stack, with its previous class and value. This is fixed
            time per element, but the more locals you have, the
            longer it takes.
            It then [same time, actually] initalizes the appropriate
            symbol table entry as "value error" for the local.

  Compiled: Function exit pops a stack pointer.
            Names which are allocated from the heap must be
             expunged.

  APL:      Function exit pops each localized name from the stack,
            marking garbage the local value. Each shadowed local
            is then reattached to the symbol table.

Thus, both call and exit are fairly expensive.
I don't know if this is rigorous enough for you.

>>>structured, and efficient.  Types/structures are inherently inflexible
>>>(of course not necessarily a bad thing) and possibly inefficient for an
>>>interpreter (APL has no pointers; structs have to be copied).

>You are confusing implementation hacks with semantics.

Not me, boy. YOU are the one talking about "copying" [a serious
implementation and non-semantic issue].

>I and most others in this discussion know about reference counts in APL
>implementations.  We have also read Girardot's APL90 paper on "box" as
>"reference": box is NOT merely a pointer.  When one copy is modified
>internally, even a little bit, it will have to be made into a new object.
>Do you pass an object by reference or by value?  Your type/struct system will

In a functional language, everything is passed by value, to minimize
cost. By that, I mean you pass a pointer to the value's descriptor,
rather than copying it. If the language has a non-functional aspect,
such as indexed assignment in APL, AND you try to alter the sucker, you
must copy it IF there is more than one reference to it. If there's only
one reference [Very common in indexed assign], you do it in place anyway.
So, you copy when you have to, and don't otherwise.  No worse than
other languages.

>you think f.p. can replace the rest of CS?  You of course know even SISAL is
>not "functional"--array elements can be modified in place, i.e. side-effect.

I don't think I ever made the claim that f.p. can replace anything.
It IS, however, much easier to write Maintainable, Debuggable, Readable
code if you stick to f.p., than if you're a side effect fan.

Your comment about SISAL and side effects is sort of correct but not quite.
Array elements are treated as in APL: If you tinker an array, you DO NOT
make a copy if reference count information says the tinkering is SAFE.

>>>I don't know about types, but structures are commonly simulated in APL, i.e.
>>>nothing really new.  They fall apart when things get really big or complex;
>>>it's not clear to me that built-in types and struct would change that.
>>
>>Yes, it would. It would formalize things, so that you have a hope in hell
>>of writing Large Maintainable Systems.
>
>Maintaining types in a "large system" is nontrivial even in a (slow) compiled
>setting.  As far I know nobody has real experience doing so with an interpreter.
We [Well, I] was talking about structs as a programmer tool. Given the choice
between buckets-full of globals, structs whose structure is implicit[
"Everyone KNOWS the second element of this thingy is the cv"], etc.,
and REAL structs, where I could reorder the struct, insert a new element, etc.,
and have the code still work, AND the existing situation, I'll take
the structs, please. AND I am willing to take some performance hit on it,
since I'll bet the performance of the system overall will improve
given structs, over the mess we have nowadays.
Bob

