Attumi (email Batch B) - A Java-like Language with default immutability

This is the third in a series of 5 posts:

1. Why?
2. Attumi (email Batch A) - A Java-like Language with default immutability
3. Attumi (email Batch B) - A Java-like Language with default immutability (this article)
4. Attumi (email Batch C) - A Java-like Language with default immutability
5. Attumi (email Batch D) - A Java-like Language with default immutability

---

My last post, ...(email Batch A), explained the creative brainstorm started in 2010/November regarding my designing a "What's next?" language to follow Java. And I shared the first email covering my first batch of self-directed notes for exploring the things I would want to consider incorporating into a design.

Here is the second batch (of four) notes, mostly unedited:

<BATCH_B>

1. consider use of transactional memory model to handle concurrency (as opposed to lock based model), push distributed (Erlang-like) model into separate/library/framework
2. Source occurs as a named resource (name spaces are merely dot separated identifiers) and stored as ASTs (expressed both in platform independent binary as well as well formed Schema defined XML file) as opposed to the currently more common text file - enables ability to have text representation be human language independent (i.e can be represented in English, Chinese, etc.), allows personalized layout and indentation (avoiding entirely issues around syntax formatting flame-wars) and enables source to reside in a file, set of folders/files, different kinds of DB, over network streamed from undefined data source conforming to API (ex: Web-dav)
3. when defining reference, possible states {once-at-definition, *once-post-definition*, many} X {*no-null*, nullable} where * is default
4. when defining class, possible states {*immutable*, mutable} X {*not-derivable*, derivable} where * is default
5. enforce immutable by requiring all references be to immutables, i.e. if class is immutable, the semantics are guaranteed to be immutable all the way down through any references chains (will enforce acyclic graph, i.e. child cannot contain reference to parent or parent's parent, etc.) - must use external supplemental data structure to facilitate traversing child to parent relationships
6. execution start-up will pass "main()" a map of key/value pairs - which will be able to be represented as a simple property file/stream, XML file/stream, etc. will be completely generified to make code not care how the execution started and obtained the initial values
7. design ability for an immutable data structure to lazily fill in state without requiring all state to be completed in definition by the time the constructor terminates (may be challenging to prove from a code path perspective, if not careful)

</BATCH_B>

As I said with batch A, Depending upon interest, I will consider diving into some/all of these and exploring my thoughts and reasoning.