#!/usr/bin/env escript
  
  -import(lists, [seq/2, reverse/1]).
  
  main([]) ->
     lists:foreach(fun(L) ->
                         io:format("[ ~s ]~n",
                                   [string:join(
                                      [ integer_to_list(I)
                                        || I <- L ], ", ")])
                   end, queens([], 0)).
                         
  
  threatens(Q, _, [Q|_], _) -> true;
  threatens(_, _, [], 0) -> false;
  threatens(Q, I, [Q2|Queens], I2) ->
     if
        abs(I - I2) =:= abs(Q2 - Q) -> true;
        true -> threatens(Q, I, Queens, I2 - 1)
     end.
  
  is_valid([Q|Queens]) ->
     TL = length(Queens),
     not threatens(Q, TL + 1, Queens, TL).
  
  queens([], _) -> queens([ [X] || X <- seq(1, 8) ], 8);
  queens(Tree, 1) -> Tree;
  queens(Tree, Place) ->
     queens([ [N|Node] || N <- seq(1, 8),
                          Node <- Tree,
                          is_valid([N|Node]) ],
            Place - 1).

I prefer the word encourage :) I know it's nitpicky, but the idea was to not simply use a native print. Of course, had I required the 'pp' Ruby lib, I could have just said:

  pp stack   # => [ 1, 2, 3, ... , 8 ]

Your point is my point. I wanted to see how well Arc handles formatting something that didn't fit neatly into an expected pattern.

Ruby has several formatting techniques that are quite nice:

1) String interpolation. You can insert an expression into a spring by using #{expression}

2) String formatting. You can use sprintf style patterns in strings via format or the % operator. For example:

  puts "%4.1f hours" % hours
  puts "%4.1f hours and %4.1f minutes" % [hours, minutes]

But in my experience on large projects that kind of documentation becomes:

   # do_my_foo() is a function accepts a float and
   # returns a float, performing necessary calculations.
   double do_my_foo(double inarg) {
   .
   .
   .

annotate is a general mechanism

ellipsize is supposed to display at most 80 characters of the input

median of an even-length list is supposed to return the lower of the middle two

cdar is supposed to be missing

(type 3.0) is supposed to be an int (for now)

support for complex numbers is supposed to be in Arc

client-ip is supposed to be there (for now)

afn stands for "anaphoric function"

> yes

Wasn't the point keeping the names car and cdr so you can compose them? (I remember reading such in one of pg's essays.) Then it seems to me to take full advantage of that you need to provide those names for use.

I don't think it is unreasonable to do the following, but it is currently not provided in Arc:

arc> (cdar '((1 2 3) (4 5 6))) Error: "reference to undefined identifier: _cdar"

On the one hand, it does feel like all the c....r s should be there.

  car  --> hd
  cdr  --> tl
  caar --> inner
  cddr --> skip2
  cadr --> second

Lisp itself is an example of this phenomenon. JMC didn't expect to use s-expressions in the real language, but they turned out to be way more useful than he envisioned.

If you're delivering a final product, users don't care if some design is deliberate or not; they care it is good or bad. If you're deriving mathematic proof, others don't care if some choice is deliberate or not; they care if it is correct, beautiful, or useful to prove other theorems. That's because changing your choice afterwards won't break existing products or proofs that relied on the previous choices.

Some Scheme implementation evaluates arguments left to right. You can see that by reading the source. In future, it may switch it right to left, maybe for better optimization. The spec in natural language, or more formal and abstract form like in Appendix A of R6RS, can explicitly say the order of evaluation is unspecified. How you tell your users that they should not rely on the evaluation order purely by the source code, given the state of most programming languages?

Ideally I like to think the source only describes the spec and the compiler and runtime figure out the details, so maybe spec-by-source and spec-by-other-notation will converge in future. Is that what you are talking?

If the goal of a language is to be readable there's nothing wrong in the implementation being the spec. Consider it a form of self-hosting, or of eating your own dogfood.

---

An implementation in a reasonably high-level declarative language is a more reasonable 'spec' than one in C. More features are amenable to checking just by reading rather than by execution.

When something is obviously a bug it doesn't matter if it's a bug in the spec or the implementation.

Regarding the difficulty in identifying a bug in the expression, I tend to agree. That's why I have a lot of unit test cases for each meaningful regular expression.

2) Eh, unit tests can catch the mistakes you anticipated making. Lots of other mistakes are possible. Why write a complex regular expression and page full of unit testing code for it when you could write more straightforward logic.

3) Like I said, it's not clear why you have the expressions you do.

I'm not saying regular expressions never ever have their place. In particular, they can be a convenient method to offer users to specify search and validation patterns and that kind of thing. But fixing program logic into them is a bad idea.

I think an example of what you're talking about would be great. If you have a better way to validate textual data than regular expressions, then naturally I would want to know about it.

Here's a few regular expressions I've collected. I realize they're not perfect (e.g. the email regex), but they're good enough for my purposes presently.

    REGEX_EMAIL     = /^([-\w+.]+)@(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})|(([-\w]+\.)+[a-zA-Z]{2,4}))$/
    REGEX_FLOAT     = /^([0-9]+|[0-9]{1,3}(,[0-9]{3})*)?(\.[0-9]*)?$/
    REGEX_INTEGER   = /^([0-9]+|[0-9]{1,3}(,[0-9]{3})*)$/
    REGEX_ISO_8601  = /^(\d{4})-(\d{2})-(\d{2})[Tt](\d{2})[-:](\d{2})[-:](\d{2})[Zz]$/
    REGEX_MONEY     = /^(\$[ ]*)?([0-9]+|[0-9]{1,3}(,[0-9]{3})*)?(\.[0-9]{0,2})?$/
    REGEX_PHONE     = /^(\((\d{3})\)|(\d{3}))[-. ]?(\d{3})[-.]?(\d{4})[ ]*([^\s\d].{0,9})?$/
    REGEX_SSN       = /^(\d{3})-?(\d{2})-?(\d{4})$/
    REGEX_ZIP_CODE  = /^(\d{5})[- ]?(\d{4})?$/

In response to your question, I don't accept your premise that replicating a particular regular expression is a real programming task. You say your email regular expression isn't perfect, but it's not clear to me why you chose those particular set of restrictions beyond what's defined in the RFC--so it's a little hard for me to replicate (for example, the local-part and domain of the address can have a more kinds of characters that what you have defined).

Instead, I'll offer this as a non-equivalent but interesting comparison. I've elided the module declarations (as have you), including the imports that allow some of these functions without their module qualifiers:

  email(S) ->
     [User, Domainp] = tokens(S, "@"),
     {User,
      case {address(Domainp), reverse(tokens(Domainp, "."))} of
         {{ok, Addr}, _} -> Addr;
         {_, RDomain = [Tld|_]} when length(Tld) >= 2,
                                     length(Tld) =< 4 ->
            join(reverse(RDomain), ".")
      end
     }.

The Erlang function above returns a tuple of the local-part and the domain part and throws an error if it can't match the address. If this were something I wanted to ship around to other functions or send to another machine or store in a database table or something, I would have email/1 return a fun (function object) instead.

If either one of us wanted something better than what we have (or even if we don't--it seems like coming up with The Right Thing To Do With Email Addresses is worth a bit of time to do only once) I would write a grammar. The applicable RFC 2822 more or less contains the correct one, which is only a few lines.

At the "low" end of text processing power, there are basic functional operations on strings and lists, and at the "high" end there are grammar specifiers and parser generators. In the band in between lives regular expressions, and I am not convinced that that band is very wide. I like regular expressions (and, indeed, I would like it very much if Erlang had better support for them) but for me they are a specialized tool, particularly useful (like wildcard globbing) for offering as an input method to users.

When I read the arc challenge at first it seemed like a trivial "win" for arc and a cheap shot. It upset me, to be frank, and that interested me, because usually if you read something upsetting it means there's something there you need to see.

After I got done grumbling (mostly to myself) about how much better in a general case was my favorite language (Erlang), I used the challenge as a jumping off point for thinking about what an Erlang web framework would be (freely admitting my status as a dabbler and dilettante here, where yariv maintains a mature Rails-like web framework for Erlang).

I wrote an (extremely rudimentary) framework to support the code in my Erlang answer to the arc challenge. I noticed that a number of the answers supposed hypothetical or imaginary frameworks, so I suspect that a lot of people only got what was on the surface of the arc challenge (this toy web app is so short!) without understanding what was underlying it (what would it take to extend your favorite language to express something so concisely? And does that concise form take the form of a Greenspunesque arcalike or is it possible to express the same intent in your language's idiom?).