Hacker News Reader

Comment by drcode | Hacker News Reader

Author of LOL here, if there are any questions!

Hey Dr Barski. I'm actually reading your book right now. I do have a question. How do you write Lisp effectively? And by that I mean, Lisp seems to be written from the inside out due to the nested lists. Is there something that makes it more natural to write: (trim-string (get-string '(some data))) Or do you need to know that you're going to call trim before you get the string? Hope that makes sense.

Does Common Lisp have something similar to Clojure's threading macros?

  (trim-string (get-string '(some data)))

  (-> '(some data)
      get-string
      trim-string

https://clojure.org/guides/threading_macros

Yes, of course there is... Lisp always has the thing you find :-) https://github.com/hipeta/arrow-macros

Thanks guys, that macro makes it easier to see the flow :)

how do you write it in other languages?

   sin(cos(10.4));

   v = 10.4;
   c = cos(v);
   s = sin(c);

in Lisp one might write:

   (let* ((v 10.4)
          (c (cos v)))
     (sin c))

really old style:

   (prog (v c s)
     (setq v 10.4)
     (setq c (cos v))
     (setq s (sin c))
     s)

Why not write it as in lisp as:

    (sin (cos 10.4))

The question was for alternatives to code that reads inside->out. I personally don't have a problem with it, but I can see that many languages have a more procedural/imperative top->down control flow by default. A Java programmer might prefer that, where a Lisp programmer will be trained to alternate while reading between inside->out and outside-in in code.

Still using those long expression is unfair

A(b(c)) are 2 function calls.

Hence

(A (b c))

is the fair abd equal expression. And you inside out whilst valid and in fact easier to read (as more normal) would need precedence rule in other scenario.

But those examples just not right.

Thanks for the reply! I'd go the first route unless method chaining was available.

  SomeData.ToString().Trim()

I would like to write idiomatic Lisp code and it's getting easier to read the nested expressions but it breaks the flow to leave the expression and wrap it. Another user mentioned using a command with Emacs to escape the expression and auto wrap it. That might be what I'm looking for.

That's the same as:

    (chain somedata (tostring) (trim))

It's a macro away in Lisp. But I would not use it much, since it kind of defeats the advantage of using nested expressions -> they are actually nested.

  This is the TXR Lisp interactive listener of TXR 215.
  Quit with :quit or Ctrl-D on empty line. Ctrl-X ? for 
  cheatsheet.
  1> [chain tostring trim-str]
  #<intrinsic fun: 0 param + variadic>
  2> [*1 3.4]
  "3.4"
  3> [[chain tostring trim-str] 3.4]
  "3.4"

No ready example of a datatype that requires trimming after a string conversion! We'd have to write one:

  4> (defstruct foo nil
       (:method print (me stream pretty-p)
         (put-string "foo " stream)))
  #<struct-type foo>
  5> (tostring (new foo))
  "foo "

Okay we are in business:

  6> [[chain tostring trim-str] (new foo)]
  "foo"

Method chaining syntax is possible, but with actual methods only. Most library functions aren't methods; you have to roll your own:

  1> (defstruct accum nil
       (val 0)
       (:method inc (me : (delta 1))
         (inc me.val delta)
         me)
       (:method mul (me : (factor 2))
         (upd me.val (* factor))
         me))
  #<struct-type accum>
  2> (new accum).(inc).(inc).(mul 3)
  #S(accum val 6)
  3> (new accum).(inc).(inc).(mul 3).val
  6

Support for idiom isn't the result of a conscious design decision; it just arises naturally when you have this sort of postfix syntax.

TXR's dot syntax is a very straightforward sugar for Lisp structure. Basically x.y.z == (qref x y z). Whitespace is not allowed around the dot. Numbers are also not allowed: 3.4 is a floating-point constant and a.3 or 3.a are invalid. If the leading element is missing, then it's the uref (unbound ref) operator: .y.z == (uref y z). This compiles to a function resembling (lambda (obj) obj.y.z).

The way I do it, is that in my editor, I can type:

'(some data|)

Where | is my cursor.

And then I have a keybinding that moves my cursor to the front and wraps around like so:

(| '(some data))

So I can type the next thing:

(get-string| '(some data))

Press it again:

(| (get-string '(some-data)))

And so on.

That way, even though the code is visually nested, I can write it in logical order from what eval first to what eval last. A good editor for editing lisp code makes that possible, as I showed, and many other operations.

Basically, get yourself accustomed to a good Lisp editor such as Emacs and I'm sure you'll find that problem will disappear. For me, it's even more productive now typing wise, because I can make more structural edits to my code, which is way faster.

I don't think he's talking about how to type the characters... He's probably asking: you're inverting, visually, the order of operations. When does start becoming natural?

This is just what I've been looking for!

I've been searching for this and see there are commands for navigating s expressions but I haven't found this example. Is this a built-in command? Is there name for this action?

There are some built-in commands in Emacs for navigating, cutting and transposing s-exps, but what you want is probably a step further - a package like Paredit[0], that gives you much more sexp-specific actions, and automatically keeps parens balanced for you. See animated examples at [1] and a cheat sheet at [2].

There isn't, as far as I know, a default keybinding for what GP did - navigate up the SEXP, wrap in parens and place point before the inner SEXP. You can get very close to it with two steps: paredit-backward-up [C-M-u] and paredit-wrap-round [M-(], though it gets confused by the hanging quote a bit. To demonstrate on GP's example:

  '(some data|)
  '|(some data)    ; after C-M-u
  '(|(some data))  ; after M-(

So the quote is in a wrong place. You could probably whip a command doing OP's thing that calls paredit-backward-up and paredit-wrap-round, with a conditional that backs up a few chars if it detects a piece of syntactic sugar attached to the SEXP (quote, quasiquote, comma, reader macro invocation). Somebody has likely already done it, or maybe there is a less known Paredit command for that - I don't know. If anyone does, please chime in.

Myself, I mostly use wrapping, barfing and slurping.

[0] - Available in Emacs' package manager on MELPA, or here: https://github.com/emacsmirror/paredit.

[1] - http://danmidwood.com/content/2014/11/21/animated-paredit.ht...

[2] - https://github.com/joelittlejohn/paredit-cheatsheet

For anyone stubborn enough to want to do this with Vim, I've come up with this.

  function NestExpression()
      " Get end paren pos
      " Returns [0, 0] if not in parens.
      let save_cursor = getpos('.')

      " If line not set to zero, append
      let end_paren_pos = searchpairpos('(', '', ')')
      if end_paren_pos[0] > 0
          execute "normal! a)"
      else
          " We're not in a set of parentheses
          return
      endif

      " Return to the inside of the parentheses
      call setpos('.', save_cursor)

      " If line not set to zero, start insert
      " mode, prepend and move cursor left
      let end_paren_pos = searchpairpos('(', '', ')', 'b')
      if end_paren_pos[0] > 0
          call feedkeys("i( \<LEFT>")
      endif
  endfunction

  nmap fj :call NestExpression()<cr>

Did you draw the pictures yourself? I really like the long final comic story, and several times thought about making some roguelike ascii game with this background (choosing a guild with specific skills, killings various kinds of bugs, etc.), but I am too lazy for having actually written it... Thank you for that!

Yes, drew everything myself, took years of my free time given the size of the book :)

Let Over Lambda is LOL too :)

Enjoyed your book, currently teaching my nephew some lisp with it!

Thanks for the book! It was the reason I finally started to really learn LISP apart from just dabbling with it. It did serve as a great way to get over the "scary-ness" of learning LISP. :)

Are you plan to write any new Lisp books? Or any book for that matter?

Would be interested in reading anything you write :)

I also co-wrote "Bitcoin for the Befuddled" and participated in "Realm of Racket". I am sort of enamoured by other media now (video, animation, interactive web stuff) and if I do anything else it will be in that vein in the future (though I have struggled with akrasia on that front)

What do you think about making a second edition?

I would say "Realm of Racket" is really the second edition to "Land of Lisp"- The fact is that most lisp developers now use either Racket Scheme or Clojure, so those are really the only markets that could support a rework of LOL in 2019. I've tried a couple of times in the past to work with someone on a Clojure port, but just haven't been able to make the coauthor+publisher work out right to get it launched.

If you ever manage to get that off the ground and onto shelves, that would make me a very happy kiddo.

Thanks for writing one of the most enjoyable programming books out there.

Flick me a message if you're interested in chatting to Manning at any stage

I'll have to check it out. I'm surprised about your impression of where most lisp developers are in 2019 vs 2010 -- from my (admittedly still rather outsider) perspective the CL ecosystem looks significantly healthier in 2019 than in 2010. Clojure[Script] remains dominant but has lost a lot of steam, Racket took some high-profile Lispers but still doesn't have the production success stories that both CL and Clojure have and language progress is likely to be stalled a while as the transition to a Chez core continues, and CL usage and useful libraries have despite it all grown. The main IRC channel is active, there's a C++ integration story (Clasp), more frequent CL-related HN submissions, the European Lisp Symposium this year had a lot of new first-time attendees, and new books with an emphasis on helping production programmers (e.g. Common Lisp Recipes) were published.

absolutely loved it, basically learned coding with it.

extended the games a lot and even ported them later on to other languages.

thanks a lot :)

Reply on news.ycombinator.com