Multi Stack Environment in Awelon

Last post, I took things to an extreme. Which is a good thing. Extremism tells us where the limits are. After we know the limits, we can seek balance.

There is a simple problem with the tree-zipper environment: It is not obvious how to use it effectively. There are too many possibilities, too many ways to ‘do it’. A typeful tree zipper is not zen. Developers will seek guidance on how to use it effectively, will receive a dozen conflicting opinions, and will ultimately hang themselves in their well typed tree.

For Awelon, I’ve decided on something much simpler:

  • the environment is a non-empty list of stacks
  • developers can stepLeft or stepRight through this list
  • developers can create and destroy stacks (always to their right)
  • all the normal stack-based programming still works, on current stack
  • developers have two hands modeled in the type system
  • with their right hand, developers take, put, copy, and paste objects
  • with their left hand, developers carry ad-hoc environment extensions

A developer who wants a strongly typed understanding of the environment might think in terms of:

(sLeft * (sCurr * sRight)) * (hLeft * (objHeld * hRight))

However, a static multi-stack environment should be easy to visualize, to such an extent that an IDE could help developers do so. I imagine a small area of the screen rendering the whole multi-stack environment: a series of colorful stacks (colors relating to types), current stack highlighted or magnified, objects held displayed in the upper left and right corners. The rendering could be associated with keyboard cursor or mouse position.

The utility of a multi-stack environment and the right hand becomes quickly obvious: different stacks for different tasks for easy access to intermediate values, stacks for scratch space when surgically picking apart or restructuring complex values in ad-hoc ways, etc.

The use of the left hand for ‘environment extensions’ is perhaps less obvious, but it’s very powerful. Awelon supports compile-time metaprogramming based on inspection of static values and types. Thus, developers are able to create ad-hoc extensions such as:

  • keyword-based inventories, e.g. `"lighter" getItemByName` could remove an item from inventory into hand
  • static counters or pseudo-random number generators
  • aspect-oriented extensions – `"foo" signal` could look up code and inject it

Awelon makes very, very heavy use of its type system: the world and one’s place in it, the hand and what it carries, language extensions, all are modeled with the type system. Almost every operation will change the computed type of the environment or hand.

This entry was posted in Concurrency, Language Design, Modularity, Types, UserInterface. Bookmark the permalink.

3 Responses to Multi Stack Environment in Awelon

  1. Pingback: Imperative Metaprogramming of a Declarative Program | Awelon Blue

  2. dmbarbour says:

    Bootstrapping this multi-stack environment has been an interesting challenge. The issue is that the literals are added deep within the structure, but that the primitives (like ‘first’) operate on shallow structures. Consequently, I must extract values from deep in the environment before operating on them – without adding more literals to the stack while I’m in the middle of an operation.

    To do this, I’ve had to add a few primitives. Trivially, I suppose I could just add exactly the primitives I need, shifting the burden to the compiler. This wouldn’t be too bad. But I’m interested in using simple primitives – rot2, rot3, assocr, and the like.

  3. Pingback: Multi-Stack Environment part 2 | Awelon Blue

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s