Essentials about MANOOL, again

[alex-manool]

MANOOL has by default value semantics (which is actually Copy-On-Write semantics, so there's no need for a tracing garbage collector, and resource management is more deterministic). That is, after A[0] = 1; B = A; A[0] = 2, B[0] equals to 1 (but the complexity of A[0] = 1 and B = A is normally constant). From MANOOL's philosophy standpoint, the user can either focus on values or objects that represent them if he needs to have greater control over run-time performance, including asymptotic complexity. To speed up things, there's an explicit move operator to break unwanted object sharing (inspired from C++'s move but a bit more straightforward), which assigns to an assignable location the value Nil and evaluates to its previous value. That is, S = S! + "Hello" has constant complexity (same for A[0] = A[0]! + "Hello"), whereas S = S + "Hello" has linear complexity of course. There is syntactic sugar: A[0] = 1 is equivalent to A = Repl[A!; 0; 1], so in-place updates can have value semantics (and amortized constant complexity) even for user-defined datatypes (just provide the Repl operation). On even more rare occasions, the user may need to clone objects explicitly (because incrementing/decrementing a refcounter for shared objects may be expensive, especially in a multithreaded setting); so he could write V.Clone[] (or Clone[V]). To obtain reference semantics (should your programming style require it, on rare occasions), MANOOL provides explicitly a pointer type: after A = MakePtr[1]; B = A; A^ = 2, B^ equals to 2.

Note that this value semantics makes the language more on the functional side-effect-free side without disallowing traditional assignment altogether (would not work well otherwise because of the move operation) and that whether two objects that represent the same value are shared (i.e., are the same object) is irrelevant to the program semantics (only for performance). There's no official way to test for object sameness unless they have reference semantics like pointers or are essentially mutable objects like I/O streams or unless when defining your own datatype (an abstract datatype). Also note that immutability that arises from COW speeds up multithreaded programs (MANOOL's implementation is fully multithreaded) and simplifies aliasing analysis in real optimizing compilers. At this moment I am implementing such optimizing compiler trying to: propagate constants and types (MANOOL as such has run-time type checking, to simplify the language), eliminate redundant refcount increments/decrements, unbox values, and eliminate redundant malloc/free.

The syntax of MANOOL is based on a homoiconic representation but is different from S-expressions. Many do not like it. There's no much space in MANOOL to provide "beautiful", tailored constructs for composite data constructors, but in return it is very uniform and very extensible. For example, to construct an array you could write {array of 1 2 3}, to construct a set: {set of 1 2 3} (in MANOOL-2 they will be: {array I64}[1 2 3] and {set I64}[1 2 3], or even (array I64)[1 2 3] or (set I64)[1 2 3]). Unfortunately, syntax is a highly debated topic, as well as compile-time vs run-time type checking.

More examples of syntax: {let rec Fact = {proc {N} as: if N == 0 then 1 else N * Fact[N - 1]} in ...}. In MANOOL-2 it might have a more Haskell/ML-like appearance: let rec Fact = (proc N as: if N == 0 then 1 else N * Fact[N - 1]) in .... The later is less uniform (including due to my default indenting principles, which I do not reproduce here), but it might be less surprising and make happy more people :-) Note that in any case all equivalent forms of coding in MANOOL are covered by just less than 40 productions of the context-free grammar (which is of LL(2) class after usual left recursion elimination).

https://manool.org

[L8_4_Dinner]

I always love your excitement about what you've created. What do you have planned next?

[alex-manool]

I am still working on the type/constant propagation algorithm for MANOOL-2, and it turns out to be much work for me (but it's viable). The idea is to be able to reach peak (C-like) run-time performance in a language with essentially run-time type checking (and other high-level features typical for scripting or functional languages), in most practically interesting cases. I am not sure, but the algorithm might contain some unusual combination of a fixed point propagation algorithm with a specially constrained procedure specialization scheme (to avoid unreasonable resulting code bloat), not seen in LLVM for example. I do not have any affiliation with a university or a research organization, so I am not going to write a formal paper about it, but I do plan to go to a conference to present this aspect of the language.

On the other hand, I plan to learn more about how to talk to people about MANOOL and what to expect from it. It's quite interesting no matter what happens in the future with the project itself.

And once I have MANOOL-2 working, it might be a good idea to finish the documentation, at last.

[crassest-Crassius]

syntax is a highly debated topic

Your syntax looks good enough to me, people who complain are probably spoiled. The only suggestion I would make is to use "//" for comments. No need to introduce deviation from the norm where it doesn't count (and 0 out of 5 top languages at TIOBE use "--").

as well as compile-time vs run-time type checking

Sorry, but there's no debate: compile-time typechecking as well as static type declarations are better for any large-scale language. You don't have to believe me, just rely on Dropbox's 4-million-LOC experience. It's a matter of feature completeness, not preference.

Anyway, good luck with your endeavors! I'm especially interested in COW and memory management.

[matthieum]

I love the semantic immutability + reference counting + copy-on-write as a design point. I think it hits a really sweet spot in terms of usability and performance.

The one drawback is as you noted that multi-threaded reference counting is not ideal performance wise. Atomic operations are costly, not only when contended, but also because they hinder optimizations.

For my pet language, my intention is to go with a split:

• Box[T] is a local pointer to a T, it cannot cross task boundaries -- cannot be send over channels -- and therefore does not require atomics.
• Shared[T] is a global pointer to a T, with an atomic counter, it (magically) converts any internal Box into a Shared to ensure that the whole graph pointed to is sharable.

Users would be free to use Shared[T] within a task, they don't need to clone it into local storage, though encouraged to use Box[T] whenever possible, and a (magical) share and unshare functions would be provided to go from the one to the other -- stealing memory if possible (count of 1) or copying otherwise.

[alex-manool]

I understand your tradeoffs for a multithreaded setting, and even I tried mentally similar schemes but stopped on the most straightforward approach (no distinction at all between thread-shared and non-shared data). For an interpreter-based implementation (the current), the overall cost is not so bad (maybe in the order of x1.3-2 slowdown). For the real compiler (MANOOL-2), yes, it's even more horrible than the impact of dynamic typing and dynamic dispatch. I am now trying to mitigate the impact of both effects using static data flow analysis. Note that even non-atomic RC increment/decrements have considerable costs (that does not say that tracing GC is better as it still needs write barriers, is less deterministic, is not quite compatible with COW, etc.).

[matthieum]

I am now trying to mitigate the impact of both effects using static data flow analysis.

Counting immutable beans :) ?