about summary refs log tree commit diff stats
path: root/factorial.mu
Commit message (Collapse)AuthorAgeFilesLines
* 578 - switch to non-polymorphic 'print' functionsKartik K. Agaram2015-01-171-1/+1
| | | | | Also clean up various prints from last few commits. As a convention, for debugging we always print directly to host.
* 574 - printing string literals is a hack; hard-code it in for nowKartik K. Agaram2015-01-161-2/+2
|
* 571 - screen primitives take an explicit terminalKartik K. Agaram2015-01-151-3/+3
| | | | | | | | | | | | | | | | | This will let me swap in a fake in tests. Still hacky, though. I'm sure I'm not managing the parameter right in the chessboard app. And then there's the question of whether it should also appear as an output operand. But it's a start. And using nil to mean 'real' is a reasonable convention. If I ever need to handle multiple screens perhaps we'll have to switch to 1:literal/terminal and 2:literal/terminal, etc. But those are equally easy to guard on.
* 497 - strengthen the concept of 'space'Kartik K. Agaram2015-01-021-1/+1
| | | | | | | | | | | | | | | | | | | | 'default-scope' is now 'default-space' 'closure-generator' is now 'next-space-generator' The connection to high-level syntax for closures is now tenuous, so we'll call the 'outer scope' the 'next space'. So, let's try to create a few sentences with all these related ideas: Names map to addresses offset from a default-space when it's provided. Spaces can be strung together. The zeroth variable points to the next space, the one that is accessed when a variable has /space:1. To map a name to an address in the next space, you need to know what function generated that space. A corollary is that the space passed in to a function should always be generated by a single function. Spaces can be used to construct lexical scopes and objects.
* 428 - cleanup odds and endsKartik K. Agaram2014-12-141-13/+13
|
* 403 - 'function' is more clear than 'def'Kartik K. Agaram2014-12-121-2/+2
|
* 401 - stop abbreviating opsKartik K. Agaram2014-12-121-4/+4
| | | | | We expect users to come across mu from arbitrary bits of code, so try to make each line as self-contained as possible.
* 314 - better syntax for functionsKartik K. Agaram2014-11-241-4/+6
|
* 307Kartik K. Agaram2014-11-231-1/+4
|
* 269Kartik K. Agaram2014-11-181-0/+2
| | | | | | Minor cleanup and code comments. I'm starting to feel the need for formatting primitives, so I don't use comments just to provide section headings.
* 268 - recursive function: factorialKartik K. Agaram2014-11-171-0/+15
Is this really harder to reason about by being somehow 'operational' and 'abstraction free'? http://cacm.acm.org/magazines/2010/8/96632-an-interview-with-edsger-w-dijkstra/fulltext