multiple stacks per type

parameters (current)

borne out of concern for memory conservation

borne out of mathematical & textual-only notation

all parameters pushed onto one stack (heterogeneous)

compiler must do work to determine type safety

compiler must do work to determine alignment

a stack is any array which is just a degenerate (aka optimized) collection

stack per type

Assertion: if it’s on the stack, then it is of that type

type check done at push time

nil? Nothingness? Empty slot only meaningful for list (collections)

one stack per parameter (what if some parameters have the same type?)

A.T.M

operations

input stack

maybe this should be called the “work” stack?

NewScope

push empty slot onto self.input

CoerceFrom

s

move s.output.TOS to self.input.TOS ; pop s

AppendFrom

s

append s.output.TOS to self.input.TOS ; pop s.output

SetFieldFrom

f

s

self.input.TOS.f := s.output.TOS ; pop s.output

output stack

return a value, leave a value

Output

push self.input.TOS onto self.output.TOS ; pop self.input

operations

standard operations for input stack

standard operations for output stack

external operations that are application (domain) specific (can operate with either stack or both) ; written in base language ; declared but not specified in Architecture (no need for detailed operation syntax in Architectural language) ; the base language is like an assembler for the Architectural Language (architects don’t need to worry about implementation details (in fact, implementation details and implementation rigour adversely affect Architectural thought)

concept

a component receives multiple parameters on a set of stacks and leaves results on (another?) set of stack

generalization: inputs arrive on input stacks, immediately transferred to work stack (in the above, I fold “input” and “work” stacks together “for efficiency”