ljdickey@water.waterloo.edu (Lee Dickey) (04/24/89)
I do not have anything helpful to say to Paul Maclauchlan, when he writes: >When trying to clean up a heavily used workspace on the system >1. )CLEAR, to make a fresh space for the new ws >2. )SYMB 3000, to match the symbol table size in the old ws >3. )COPY OLDWS >4. Assign QuadLX and QuadELX >5. )WSID OLDWS >6. )SAVE and so on, except to say, that I have done that too. But I just want to complain about the necessity of any user ever having to use the )SYMBOL command. APL is a language that allows dynamic storage allocation. All APL users are accustomed to making statements like A <- A, MORE and having more storage for "a" set aside. Why should not this same thinking have permeated into the thinking of the implementors? Why should someone have to know, in advance, how many variables they might need. Why isn't the symbol table empty and small in a clear ws, and why doesn't it grow as needed, dynamically, just as the variables do in a ws? To me, a SYMBOLS command is like a DIMENSION statement. It sets aside, in advance, space for pointers where names and values are kept. Why isn't this just another table, just like all other arrays in APL? There, I said it. Any response? -- L. J. Dickey, Faculty of Mathematics, University of Waterloo. ljdickey@water.UWaterloo.ca ljdickey@water.BITNET ljdickey@water.UUCP ..!uunet!watmath!water!ljdickey ljdickey@water.waterloo.edu
hafer@infbs.UUCP (Udo Hafermann) (04/25/89)
I find it understandable that implementors want to have the symbol map at a fixed location, as this saves at least one indirect reference per symbol access. But nevertheless it should be possible to increase this size dynamically, even if this means moving the rest of the WS and shuffling around a lot of pointers. Less work than a typical )COPY must perform. This seems to be one the few non-dynamic features of APL left from the past, like the traditional bracket notation for indexing, which fixes the rank of an object at programming time.
mrys@ethz.UUCP (Michael Rys) (04/26/89)
In article <2270@water.waterloo.edu> ljdickey@water.waterloo.edu (Lee Dickey) writes: [stuff deleted] > >But I just want to complain about the necessity of any user ever having >to use the )SYMBOL command. APL is a language that allows dynamic storage >allocation. All APL users are accustomed to making statements like > > A <- A, MORE > >and having more storage for "a" set aside. Why should not this >same thinking have permeated into the thinking of the implementors? >Why should someone have to know, in advance, how many variables they >might need. Why isn't the symbol table empty and small in a clear >ws, and why doesn't it grow as needed, dynamically, just as the >variables do in a ws? To me, a SYMBOLS command is like a DIMENSION >statement. It sets aside, in advance, space for pointers where >names and values are kept. Why isn't this just another table, just >like all other arrays in APL? > >There, I said it. > >Any response? > Symbol tables are normally implemented at a fixed start address (like the stack) in the workspace memory. Therefore it is not treated the same as an APL array (at least not in all implementation). This still does not justify why a symbol table cannot grow dynamically. Remembering the old days of VS APL I always wondered why IBM did not implement the symbol table using an automatic allocation scheme. How happy I was when I started using Sharp APL and realized that the symbol table actually increased its size automatically when needed (however shrinking does not happen automatically). So I forgot )symbol till the day I received these news article ;^)... >-- > L. J. Dickey, Faculty of Mathematics, University of Waterloo. Michael Rys UUCP: mrys@ethz.UUCP or mrys@bernina.UUCP EAN: mrys@ifi.ethz.ch IPSANet: mrys@ipsaint Voice: +41 1 242 35 87 Letter: V. Conzett Str. 34; CH-8004 Zuerich; Switzerland --- Wovon man nicht sprechen kann, darueber muss man schweigen --- Ludwig Wittgenstein, Tractatus logico-philosophicus