Comment by taeric | Hacker News Reader

Comment by taeric | Hacker News Reader

Parent Full thread

Hmm, you seem to be indicating that people use macros to create new syntax all of the time. I have not actually found that to be the case that often. In particular, there are only two macros I know I use somewhat regularly that do this. LOOP and FORMAT. And even those always follow the same general syntax of lisp. Unless you get crazy, it is not usual to actually use things that drastically change the full syntax of lisp.

But again, in lisp, you probably make use of more metaprogramming than you'd realize, precisely because it is indistinguishable from normal programming.

(I'm tempted to contrast this with some of the DSLs I've seen in the likes of scala and ruby... I have a hypothesis that all of the hoops you have to jump through to make a macro like construct cause people to go all in when they do so.)

Now, I'm also not claiming lisp gives superpowers. Again, I'd almost go the other route. Most lisp is typically quite simple, because you can accomplish quite a lot that way.

Which does bring it back to aesthetics some. The parens just flat out don't bother me. They are a bemusing joke, that never actually made sense. Too often, the difference is minimal compared to most C programs. Foo(bar) becomes (Foo bar). Which isn't that big of a deal. The basic math changes from infix to prefix is a bit to get used to. However, I find it is much more pleasant to deal with generics (+ matrix1 matrix2) as opposed to matrix1.plus(matrix2) of java and the like. Of course, I was also a huge fan of my HP calculator in college. RPN for the win! :)

So, yes, I do think it comes down to preference. I don't think you're preference is wrong/bad. I do think your view of lisp sounds colored more by bemusing jokes than actual problems in lisp code. But, I fully grant my experience with ruby may be colored by an overly ambitious project written in it.

In ANSI CL, the macro related to formatting is called formatter; format is just a function.

The format function can take a function as an argument in place of the format string.

The formatter macro can compile a format string into such a function.

    (format nil (formatter "(~a-~a)") x y)

formatter spits out a lambda that is passed to format; format then passes it the stream, and the remaining arguments.

Indeed, apologies for messing that up. :) My point was more on the rarity of "syntax breaking" macros. And, even that one doesn't really change the syntax much. It is just a very complicated function, for all intents and purposes.

> My point was more on the rarity of "syntax breaking" macros.

Why don't you consider macros like DEFUN, DEFCLASS, COND, etc to be "syntax breaking"?

I was taking "syntax" to be "ubiquitous syntax". To that end, those don't really pose a big surprise.

Cond might. But really, if I said to prepare a list of test to action pairs, it has the somewhat obvious syntax to execute the first one with a true test.

Pcond is a bit crazier. But you can go a long way without ever touching that one.

Defclass is powerful, though again, you can go a long way without it. And if you are in a codebase using it, it is probably a touch on the ubiquitous side.

Loop is just famous for having a ridiculously powerful language inside it. Much more so than the others, which, quite frankly look like normal function calls most of the time.

Not speaking for grandparent, I would say that cond isn't syntax-breaking because it doesn't have to employ grammar -driven parsing to recognize and delimit the clauses and their constituent forms. The nested list structure of cond that you see is the real syntax.

defun could be like this, though its ANSI CL specification is quite screwed up.

The sytax is given as:

   defun function-name lambda-list [[declaration* | documentation]] form*

where the double square brackets are described in "1.4.1.2.1 Splicing in Modified BNF Syntax" which denotes that a list of elements is to be spliced into a larger structure, and the elements may appear in any order. The description of this idiotic bullshit is convoluted, but an example section gives the gist of just how idiotic:

"For example, the expression

  (x [[A | B* | C]] y)

means that at most one A, any number of B's, and at most one C can occur in any order. It is a description of any of these:

  (x y)
  (x B A C y)
  (x A B B B B B C y)
  (x C B A B B B y)

but not any of these:

  (x B B A A C C y)
  (x C B C y)

Note how the B elements generated by B* can be interspersed! So in the case of defun it means that we can have variations like:

  (defun name (args ...) decl doc decl decl decl body...)

  (defun name (args ...) doc decl decl decl decl body...)

  (defun name (args ...) decl decl decl decl doc body...)

There can be at most one docstring, and an arbitrary number of declarations, and they can be mixed in any order.

Note that if we interpret A|B*|C as a simple regex notation, it wants all the B's clumped together; someone really had to work hard to concoct this counterintuitive BNF extension.

That all said, I can't imagine that most folks are surprised by the general shape of most defun statements. The complexities that go into how it is implemented is crazy, but it is not at all like the first time you see a LOOP invocation, is it?

> I can't imagine that most folks are surprised by the general shape of most defun statements.

The general shape of a LOOP expression is just a list of symbols and lists. A complicated LOOP expression that uses many features at once doesn't end up looking very Lispy, but a shorter one like (loop :repeat 10 :do (print 'hello)) shouldn't look at all foreign, especially if you write the keywords as keywords, which many people do.

I guess when people talk about the regularity of Lisp syntax, I think they usually mean that (op ...args) applies the operator OP to the list ARGS. LOOP obeys this very well: the only LOOP syntax I can think of that breaks it is `using (hash-key k)` or with HASH-VALUE. Universally accepted macros break this rule all the time, though. By shoving everything into lists, they totally abandon trying to keep with the (op ...args) form. If you see that regularity as a great advantage of Lisp's, then it seems like you should be much more bothered by the more "mundane" macros than you should be by LOOP.

    (loop :for i :below 10 :do (print i))

Is less "syntax-breaking" than:

    (dotimes (i 10) (print i))

Commonly used loop syntax is replete with syntax that breaks "op args ...":

  when <condition> do
  for <var> in <list>
  for <var0> = <init0> then <step0> and
    for <var1> = <init1> then <step1>
  collecting <expr> into <var>

The normal macros that don't have a flat argument structure, but shove everything into lists are keeping with the idea of leveraging the nesting so that the construct is "parsed on arrival" (POA?) into the macro. All that remains is to access its structure.

Syntactically, those are things that could have been implemented as operators, but aren't, they're just LOOP keywords; lots of functions take keyword arguments (edit: even if LOOP's are a little different from &key parameters). LOOP avoids using unquoted lists for things other than calling operators.

edit: Oh, right, destructuring, too! I guess that also counts.

Out of curiosity, how would you feel about a macro like this (ignoring that it doesn't enforce any keyword order)?

    (defmacro for (var &key = (then =) while do)
      `(do ((,var ,= ,then))
           ((not ,while))
         ,do))

> (I'm tempted to contrast this with some of the DSLs I've seen in the likes of scala and ruby... I have a hypothesis that all of the hoops you have to jump through to make a macro like construct cause people to go all in when they do so.)

I don't think we have any points of contention left to argue over, but I will say that many Rubyists just aren't familiar enough with Ruby's object model and scoping to be able to do DSLs cleanly. It's certainly possible, but there's a learning curve.

Actually I can articulate how to do DSLs in a paragraph. Create a DSL class where all instance methods are DSL calls that set instance variables. The instantiator takes a block, the DSL input, and simply runs instance_exec on the block so it's executed in instance scope. Hand the DSL object with all the ivars to something else to actually do things with. Nothing in DSL behavior should do anything other than set ivars. The only metaprogramming is instance_exec.

Apologies if you took my posts as trying to argue you out of a position. I think the developer happiness is a fairly important point. And aesthetics being what they are, different strokes for different folks. So, I was just chiming in that I have an amusingly contrasted experience.

To that end, thanks for keeping the discussion going! This is a social site, so it is fun to flat out be social. :)

Oh I certainly don't see you doing that, that was why I said "I don't think we have any points of contention left to argue over." It's rather unfortunate that in a textual medium, tone must be inferred from prose. I just wanted to add a bit of extra color.

Reply on news.ycombinator.com