LLL stack questions

Chris Harris chharris@u.washington.edu
Mon, 19 Dec 1994 18:03:19 -0800 (PST)


    There seems to be a general agreement that the LLL should have 
something to do with stacks.  However, this still leaves a lot to be 
decided.  Here's some of my questions:

    Do we support a fixed number of stacks (as in Forth), or as many 
as the programmer wishes?
    I'd tend to go with as many stacks as are necesary.  This raises the 
question of how they are identified (number and/or name?), but this isn't 
too difficult of a question.

    What data types should we support on our stacks?
    This is currently being given enough attention, imho, and I'm yet to 
formulate an opinion.

    Are all elements in a stack the same size, or do the instructions 
specify what size their operands are?
    The latter would be harder to impliment and possibly to program for, 
but it might be more powerful.  (keyword: might)

    Do we allow access to a stack only by pushing and popping, or do we
permit accessing them at any point needed?
    For the most flexibility, there should be support for accessing them 
as linear memory, but this might make our CG system more complicated.  
(Any of you GC experts care to comment?)

    Do the primitive operations (add, subtract, swap, etc.) require their 
operands to be on or near the top of a stack (like Forth), or can they
access anywhere inside the stack?

    Should we allow recursive stacks?  (Should we allow stacks to enclose 
stacks to enclose stacks to enclose stacks, etc.?)
    While this might be more difficult to support than single-level 
stacks, it might make things easier and/or more efficient in the long 
run.  Recursive stacks would allow us to break a problem down in a 
fairly logical way, without having quite as much overhead on the next 
level up.  (If I have a data structure that is represented as an enclosed 
stack, the enclosing stack can look at it as one unit, rather than a 
number of seperate elements.)

    Should our primitive language provide VM for stacks?  (For example, 
if a stack is larger than physical memory, the items near the bottom 
could be paged to disk until required.)

    Is code just a special type of stack, and thus agents can play with 
the code they're able to execute?

    I'm also not clear as to how an agent/toolbox/program can communicate 
with the outside world.  Is there a language primitive to communicate 
with external objects, or is this accomplished only through shared stacks?

    Stradegies to map toolboxes/whatever to a higher-level object 
construct are also welcome.  I'm formulating a concept of my own, but it 
seems a bit weird, and I'd like to hear what others have to say first.

    Any thoughts are welcome and appriciated....

-Chris

"If patterns of 1s and 0s were 'like' patterns of human lives and death,
if everything about an individual could be represented in a computer by a
long string of 1s and 0s, then what kind of creature would be represented
by a long string of lives and deaths?"  --Thomas Pynchon