inferno programmer's notebook

NAME lab 48 - symbol NOTES I'm clearing out the backlog and found this lab's code, which is really a continuation of earlier labs on the lispy-shell (26, 27, 28). I felt that where I was going with lab 28 wasn't working out, or was just going to end up looking like scsh (if I was lucky, and as smart as Olin Shivers). This attempt is more a mathematica-like-shell, and for a while was looking better, in that it fit in better with the existing sh, but now I've decided against it too. I'm posting it here just to record what I've done. I'll try and explain at the end why I don't like this approach anymore. In Mathematica everthing is an expression of the form f[x,y] which translates quite easily into the shell expression f x y Because of Inferno sh's command blocks, we can directly support the nesting in expressions: % Head {f x y} f % Head {f;x;y} List # a sequence of commands {f;x;y} is # represented as {List f x y} in "FullForm" And...

NAME lab 28 - side effects DESCRIPTION I was planning on just implementing side effects, but it turned out to be a little more complicated than I thought, and then I got sidetracked into changing the evaluator to handle more of the shell semantics. The file lisp7.b implements setq but it is limited in that in cannot change the type of the value referenced by the symbol. % eval {setq a `{b c d}} (b c d) % eval {setq a `b} error at type mismatch (b c d) Fixing this requires me re-implementing the sepxrs library to remove pick from the ADT. I'll follow up on this later. Mixing shell and lisp syntax The final parser in the Sussman and Steele paper The Art of the Interpreter puts dynamic scoped variables back into the evaluator. It maintains two environments, one for lexical and one for dynamic binding. Instead of havi...

NAME lab 27 - sh sexpr DESCRIPTION The implementation of the lisp dialect in lab 26 had some problems. For each car or cdr operator I recursively descended the syntax tree rather than holding the lists in memory in a more convenient fomat and simply taking the head or tail of the list. I did not want to build further on this implementation. Instead I wanted to rewrite eval to use the sexprs (2) module and convert the sh's syntax tree to an s-expression. Converting from the syntax tree to an s-expression is pretty easy to do, though it took me a while to remember the method. The first file lisp1.b is a brute force implementation, which of course once I got working I remembered the method I should of used. % load ./lisp1 % eval {a {b} c} (a (b) c) % unload ./lisp1 The second file lisp2.b maintains a global stack of lists of sexp...

NAME lab 26 - greenspun's rule DESCRIPTION Let me state up front, I do not know much about lisp. I've always been aware of it but never saw it's benefits so never used it. However, recently I've begun to read more about it, particularly the essays by Paul Graham, and his book On Lisp (which I'm still reading, on and off). I went a bit further and read Steele and Sussman's paper The Art of the Interpreter. Also, as a symptom of my Mathematica envy I became curious about symbolic programming languages, computer algebra systems, and how these are based on lisp dialects. I started playing with Maxima and yacas and also Mockmma And so I think I finally got what lisp was about. (I still have much more reading to do. It's funny how a large and rich subculture within computer science suddenly opens up to you when you read about its core language. I hav...

NAME lab 25 - Accumulator Generator DESCRIPTION The problem by Paul Graham is stated here and I quote Write a function foo that takes a number n and returns a function that takes a number i , and returns n incremented by i . I thought I'd attempt it in sh (I'm already assuming it's not possible in limbo). Here's my first attempt, which is wrong. % subfn foo { n=$1 result={i:=$1; n=`{fc $n $i +}; echo $n} } % n := 0 % x=${foo 3} % $x 1 4 The problem is we can't create another accumulator generator in the same scope, since it will overwrite the variable n. Sh uses dynamic variable binding instead of lexical binding, as used by lisp. The shell paper /doc/sh.ms:/lexical.binding/ mentions the issue and proposes a workaround but it doesn't really solve the stated problem. Here's a solution that incor...