(let (a b) (list 3 4)
    ..)

  # Single binding
  w/var foo = 5
    ...
  
  # Multiple bindings, like "withs" in Arc
  w/var foo = 5
        bar = 10
    ...
  
  # Look, ma, destructuring works
  w/var {foo bar} = {1 2}
    ...

  w/each x = {1 2 3}
    prn x

  $mac w/each -> {('=) x y} body
    w/uniq i len
      w/complex y
        'w/var len = y.length
           for (var i = 0) (i ~= len) (++ i)
             w/var x = y[i]
               body

  # Simulating a `for` loop using a `while` loop
  $mac for -> init test incr body
    '| init
     | while test
         | body
         | incr

  for (var i = 0) (i < 10) (++ i)
    prn i


  # Simulating a `do..while` loop using a `while` loop
  $mac do -> body {('while) test}
    'while %t
       | body
       | if ~ test
           &break;

  var i = 0
  do
    | prn i
    | ++ i
    while (i < 10)

That's a lot stronger claim than your original :) Aren't python, ruby, and haskell all high-power but easy to read?

There's the confounding effect of learnability; lisp gets more readable over time. There's also the confounding effect of density or difficulty. This quote captures both:

Incidentally, I've never written python, ruby, or haskell, except for a tiny amount of python.

Good quote. I've been reading a lot of computer science papers lately, and I tend to skip over the math formulas and focus on the text. This could be because I'm reading them for "fun" and not because I have to for a class, or something. But I have always found it hard to take in dense notation, and preferred a conceptual argument. Maybe it's just that I have a deficiency in that area. But I think prose has the potential to carry powerful insights that are out of the reach of formulas; I suspect the problem is that succinct, brilliant prose is just incredibly hard to write. It's probably easier to just list formulas than to get deep ideas into prose. The reverse is also true, of course. Some ideas can only be expressed properly with notation.

I didn't really mean to say that the book was directly applicable to the problem at hand; I was thinking of throwing in a disclaimer, but I guess I didn't. I don't have the book handy, but as I recall, some of the principles were things like grouping similar things together, and making things that are different look as different as possible. The author goes on to describe how these things determine where your eyes land and then move over the page, which consequently determines how easy or hard it is to make sense of; remarkably, it was true, as you can see from the examples. The insight was striking... I'm not sure how much of my current thinking was in the book and how much is extrapolation; but I think it's possible to bring the mindset of a graphic designer to something like code. I like how in PHP, variable references always have dollar signs attached. If you bring the mindset of a computer scientist only, you might say, well, the dollar signs are obviously to simplify the tokenization; if you can solve this engineering problem, you should get rid of them. But I think it probably makes a difference in helping your brain's "tokenizer." The connection to the design book might be tenuous, but it seems to me that you could connect it to the idea of making different things look different, or one of the other principles in the book. A minimalist implementation of lisp has practically no inherent structure, which is both a strength and a weakness. Before I knew anything about how to write lisp programs, I knew that lisp had lots and lots of parentheses. I think that if you ask programmers what they know about lisp, probably 10% have used it, and 90% know that it has lots of parentheses. This is the thing that stands out when you look at it.

PHP took sigils from Perl, where Larry Wall said "Things that are different should look different" and used different sigils for different types. However, sigils in PHP, Perl, and shell syntax all make string interpolation possible, which is more of a tokenization issue. So I think sigils probably exist in PHP for both reasons.

As a side note, Groovy uses $foo or ${foo} to mark string-interpolated expressions, but that $ isn't used in other circumstances. It uses the sigil only where the tokenization really demands it.

Personally, I consider "different things should look different" to be a good justification for lisp syntax. If macros are really going to give programmers the power to make the language syntax their own, then language-imposed irregularity is at cross purposes with that open-endedness. I think the parentheses help programmers realize that they should look only at the variable names to determine meaningful differences between things.

---

"The author goes on to describe how these things determine where your eyes land and then move over the page, which consequently determines how easy or hard it is to make sense of; remarkably, it was true, as you can see from the examples."

Does the author just describe and demonstrate these things qualitatively, or are there also references to quantitative studies?

This is Arc Forum, where the regulars already know how to read lisp syntax. We may try to look at our culture with fresh eyes, but it isn't easy. And as I hope you can see, I justify lisp syntax for qualitative reasons similar to the ones you use against it, without really disagreeing with you.

Hard numbers are the kind of thing that would clarify which of these arguments should win, so that's what I hope to find in a thread about "concrete, objective reasons." I'm not surprised or offended that this discussion hasn't focused on the numbers, but I am a bit disappointed.

The Wikipedia article on readability (http://en.wikipedia.org/wiki/Readability) does seem to be heavy with empirical justification. ^_^

From the article: "Bonnie Meyer and others tried to use organization as a measure of reading ease. While this did not result in a formula, they showed that people read faster and retain more when the text is organized in topics. She found that a visible plan for presenting content greatly helps readers in to assess a text. A hierarchical plan shows how the parts of the text are related. It also aids the reader in blending new information into existing knowledge structures."

That's the beauty of Nulan's syntax system: it is almost completely customizable, feels very "Lispish", and plays very well with macros. You can now have your short syntax and the benefits of "code is data is code".

Even wart's system works pretty damn well, despite being much less powerful, because it has very simple rules for how to handle things.

I didn't know that. Perl seems to me like a monstrosity. But I'm sure there are worthwhile aspects to it.

>> language-imposed irregularity is at cross purposes with that open-endedness

I agree. There seems to be a trade-off between flexibility and readability.

>> Does the author just describe and demonstrate these things qualitatively, or are there also references to quantitative studies?

It's not that kind of a book.

>> I justify lisp syntax for qualitative reasons similar to the ones you use against it

I'm not trying to argue against Lisp. I've proposed that there may be a trade-off between flexibility and readability, and Lisp sits at one end of that spectrum.

>> Bonnie Meyer and others tried to use organization as a measure of reading ease. While this did not result in a formula, they showed that people read faster and retain more when the text is organized in topics.

The kind of readability I'm talking about is at a much smaller scale, like being able to recognize a function call or a loop.

>> There's one point potentially in favor of object-oriented programming, where some of the inheritance and data-and-behavior bundling may be formally unhelpful, but (I feel) it does establish an informally organized structure over the code. On the other hand, it's almost never exactly the organization I feel is ideal for conveying my own program. Grr, subjectivity again. x_x

I agree. I think one of the problems with OOP is that it tries to organize everything into hierarchies. Most things in the real world don't fit into neat hierarchies.

In the beginning, Perl was a simple language. It generalized awk with user-defined functions[1], explicit file handles (STDIN, FILE) and array variables. With the idea that different things should look different, you got sigils to namespace arrays and scalars away from keywords and the standard library[2].

Over time, however, it got more line-noise. % for hashes. & and -> for references. Constants like $_ got added, positional arguments. When you consider all the primitives and capabilities in the language today, do array/scalar variables really deserve their sigils? It feels a little like hungarian notation now that the standard library includes so much more than just functions on strings and arrays.

It's all very well to say "different things should look different", but "different" isn't some absolute property. Programming languages are human things, and subject to human limitations. Our visual and frontal cortex gets swamped by too much "difference". So we need to pick carefully what to make salient. And, above all, not paint ourselves into a corner with our early decisions.

rocketnia: "I think the parentheses help programmers realize that they should look only at the variable names to determine meaningful differences between things."

nburns: "The kind of readability I'm talking about is at a much smaller scale, like being able to recognize a function call or a loop."

The advantage of lisp isn't necessarily that it forces you to do without syntax entirely. Perhaps it is that it allows syntax to be tuned by project/codebase, to make decisions in the small based on the characteristics of the whole.

For several months now I've been sporadically mulling this rambling paper: http://davewest.us/pdfs/ducks.pdf. I'm not sure what it's trying to say, but the lesson that sticks to my mind is that of the Tibetan Thangka, arranging a number of stories spatially for maximum memetic power. A program doesn't have to be just a list of functions, macros, symbols and calls. Or indeed a long list of user stories. I'm starting to believe that it matters how things are arranged in the small, because it can help grasp how things are arranged in the large, help the program to get into my head, ensure I understand how it is organized in the large, keep me from messing up the architecture with my changes, and thereby help preserve the program's coherence over longer periods of time.

[1] nawk -- the first version of awk with user-defined functions -- was released in 1988 (http://en.wikipedia.org/wiki/AWK). Larry Wall had already released Perl in 1987.

I assume you're looking at the toprow function? (http://github.com/nex3/arc/blob/f311b3879c/lib/news.arc#L618) If the url is at /about all you have to do is add:

  (link "about")

To create /about, use newsop. Here's a simple example to append to news.arc:

  (newsop about ()
    (shortpage user nil "about" "About" nil
      (pr "hihihi")))

---

If it works, you might notice that the "about" link on the top nav of the about page isn't highlighted like say the "new" link is for the corresponding page. To fix this, add "about" to toplabels, and change the call in toprow to this:

  (toplink "about" "about" label)

Do you know the paper "INTUITIVE EQUALS FAMILIAR"?

I'll plug my whitespace-sensitive toy lisp as well: http://github.com/akkartik/wart#readme

  $ git clone http://github.com/akkartik/wart
  $ cd wart
  $ ./wart   # ./wart test runs tons of unit tests

  (def testify (x)
    (if (isa x 'fn) x [is _ x]))

Of course! A quick Google search for [site:arclanguage.org testify iso] turns up a few places Arc Forumgoers have talked about this before:

http://arclanguage.org/item?id=9183 (aw)

http://arclanguage.org/item?id=13678 (me)

http://arclanguage.org/item?id=13267 (me and you)

These were just my first three search results. :)

---

"A caller of either shouldn't typically care whether they create new conses or not."

So there's two ways to fix this:

1) Change Arc to be like Arc/Nu, so that it doesn't need to do the conversion. I don't expect this to be too hard.

2) Write + in Arc, and have it call "join" when the first argument is a list. Then there's no discrepency between the two.

Also, if the language used immutable conses then every cons would indeed have to change, so there's some rationale for keeping it purely functional.

Let's say we call (+ '((1) (2))). I'll draw the list this way:

  ( , . , )                   
    |   `-------> ( , . nil)  
    |               |         
    |               |         
    |               |         
    v               v         
   (1 . nil)       (2 . nil)

  top-level  ( , . , )                   
    conses     |   `-------> ( , . nil)  
               |               |         
               |               |         
               |               |         
   element     v               v         
    conses    (1 . nil)       (2 . nil)

  these conses  ( , . , )
  can change      |   `-------> ( , . nil)
                  |               |
                  |               |
                  |               |
  these conses    v               v
  shouldn't      (1 . nil)       (2 . nil)

  (+ (list (obj 1 2)))

  arc> (def check-cars-obj (join-fun)
              (let x (list (obj 1 2))
                   (is (car (join-fun x))
                       (car x))))
  #<procedure: check-cars-obj>
  arc> (check-cars-obj +)
  t

  ( 1 . , )                   
        `-------> ( 2 . nil)

  arc> (+ '((1) (2)))
  ((1) (2))
  arc> (join '((1) (2)))
  ((1) (2))

  arc> (flat '((1) (2)))
  (1 2)

  arc> (+ '(1 2) '(3 4))
  (1 2 3 4)

Yes, but Arc/Nu manages to implement that Arc feature without conversion, so I don't consider it a problem with the feature, but a problem with the implementation.

---

akkartik: "+ and join on a single arg is just the identity function, right?"

Yes, but Arc does the conversion even if you pass in a single argument. So another possible solution to the problem is to change Arc to return the first argument unchanged when passed in a single argument.

---

zck: "If you call (+ '(((((((1))))))) '(((((((2)))))))) , you shouldn't have to change fifteen conses, just one or two."

Yes, you shouldn't have to. Arc uses ar-nil-terminate and ac-niltree to do the Arc->Racket->Arc conversion. ar-nil-terminate does a shallow copy, but ac-niltree does a deep copy. Simply changing ac-niltree wouldn't work, because I'm pretty sure other stuff depends on the deep copy.

However, the Arc compiler could be changed so that + uses a shallow version of ac-niltree."

That's the essence of the bug, as I see it. This fix is much shallower than the other fixes discussed, so this fix would make the most sense in a minimally updated variant of pg's Arc.

From what I can see, there are only three places in the pg-Arc code where 'ac-niltree traverses too far, and they're all in ac.scm. Two are the definitions of + and ar-+2, and one is a misleading comment:

  ; Arc primitives written in Scheme should look like:
  
  ; (xdef foo (lambda (lst)
  ;           (ac-niltree (scheme-foo (ar-nil-terminate lst)))))
  
  ; That is, Arc lists are NIL-terminated. When calling a Scheme
  ; function that treats an argument as a list, call ar-nil-terminate
  ; to change NIL to '(). When returning any data created by Scheme
  ; to Arc, call ac-niltree to turn all '() into NIL.
  ; (hash-table-get doesn't use its argument as a list, so it doesn't
  ; need ar-nil-terminate).

The other uses of 'ac-niltree are in 'ar-coerce (string to cons), 'dir, and 'timedate, where the lists are flat anyway.

I only looked for uses in pg-Arc, not any code that's been derived from it.

And the places in the Arc/Nu source that treat () as 'nil:

https://github.com/Pauan/ar/blob/c8dea3f2d3a4f343ec633c81437...

https://github.com/Pauan/ar/blob/c8dea3f2d3a4f343ec633c81437...

https://github.com/Pauan/ar/blob/c8dea3f2d3a4f343ec633c81437...

https://github.com/Pauan/ar/blob/c8dea3f2d3a4f343ec633c81437...

https://github.com/Pauan/ar/blob/c8dea3f2d3a4f343ec633c81437...

https://github.com/Pauan/ar/blob/c8dea3f2d3a4f343ec633c81437...

Insane. I'm bummed I haven't noticed this before :( Has it come up in the past?

---

a) The difference between + and join, which triggered this post (http://arclanguage.org/item?id=17074)

b) The idea of overloading * analogously to +. And of making avg variadic. zck, do you want to update anarki? I'm happy to do it otherwise.

c) Quotable quote: "I thought of no simple way to do this but functionally, using recursion. The second place winner, who wrote in Python, approached this imperatively, using mutable state. We actually had to explain our solutions to each other, as the minified versions were not easy to gather the algorithm from. Programming styles can be restrictive."

  import math,itertools as i
  def f(k,p):
  	while(len(p)>k):
  		m=()
  		for r in i.combinations(p,2):
  			d=math.sqrt(sum(map(lambda x,y:(x-y)**2,*r)))
  			if d<m:m=d;x,y=r
  		t=p.remove;t(x);t(y);p+=[map(lambda g,h:(g+h)/2,x,y)]
		print p

  (map(fn e avg.e)r t)
  (map avg:list r t)

Edit: Here's another opportunity:

  (cdr(mem _ s))
  (cdr:mem _ s)