Thanks for the questions! > How do you express recursion? E.g. the standard factorial example. factorial := { val | val = 0. True? [1] False

Thanks for the questions! > How do you express recursion? E.g. the standard factorial example. factorial := { val | val = 0. True? [1] False? [val * (self! (val - 1)).]. } factorial! 5. Print. The self reference does not imply a cycle. The reasoning for this is a little subtle. object := { Foo[3] Bar[self Foo] } object Bar. under the hood desugars to something like the following object := { method Foo(self) {return 3} method Bar(self) {return self.Foo()} } object.Bar(object) self is nothing more than a sort of syntax sugar for a parameter whose value happens to be the same as the enclosing prototype. In general, it is impossible for an object to refer to itself because an object doesn't have access to itself until after it is created. Yes, methods within an object have a self parameter, but the method itself doesn't have a reference to the enclosing object captured - it is passed in every time the method is called. I'm not sure that was the best explanation, and I would be happy to field any clarifying questions. As a side note, the documentation is a little bit unclear. Yes, qdbp has no cycles and can potentially be reference counted, but at the moment it is garbage collected and reference counting is TBD(probably in the next month or so). > If there is no "purely functional IO", what IO is there, and what prevents programs from using it to build a mutable local variable? There is no purely functional IO, there is just "regular" IO. There is nothing in theory that, for example, stops a program from building mutable state in an external file or something like that. I am just assuming that programmers will do things like that sparingly, which I think is a fair assumption to make. Printing is not a primitive. It is a method within a string object. I guess, though, the boolean example is missing the FFI primitive that the Print method uses under the hood. > "Phantom fields" look very like the name in nominative typing. Interesting that structs can be given more than one empty field as an equivalent to multiple names. Yea upon discovering the idea I thought it was pretty cool and is a way to recover many of the drawbacks of structural typing.