The problem is, I think, that ac-qq1 doesn't expect to encounter an improper list. So, with arc1 you can't use a dot in a quasiquote to denote an improper list.

However, as vsingh pointed out, an unescaped cons operation will get you an improper list in a quasiquote where a dot doesn't.

This seems like a bug indeed, and it is easy to fix, simply replace this in ac-qq1:

  ((pair? x)
   (map (lambda (x) (ac-qq1 level x env)) x)))

  ((pair? x)
   (cons (ac-qq1 level (car x) env) (ac-qq1 level (cdr x) env)))

  (define (read-square-brackets ch port src line col pos)
    `(fn (_ . __)
       ,(read/recursive port #\[ #f)))

  Scheme:   Arc:
  pair?     acons
  number?   number
  set!      set
  set-car!  scar

So if the function/macro has side-effects, def/mac could e.g. also assign it to a second symbol with "!" appended.

'?' could also be done similarly, but would be more difficult. Here is a start:

def/mac should also assign its function/macro to a second symbol with "?" appended if:

1) The function/macro has no side-effects (no "!")

2) The function/macro has a least one argument

list? ?

sort? ?

first? ?

It's not doing it for me.

Leaving aside the issues of detecting a query, I think it's a really bad idea to have the compiler force (badly guessed) semantic knowledge on me.

It's my code, I wrote it, and I don't want any compiler telling me that a query that caches previous results must be imperative! and not end in a ? .

bear with me here, but '!' means the function isn't pure, right? if so, who cares? it seems like an ivory tower thing. ? is fine, though maybe prefix notation can be considered

  isPair
  isNumber
  dangerSet
  dangerSet-car

  arc> (= x (range 1 5))
  (1 2 3 4 5)
  arc> (map [do (= (cdr x) (cddr x)) _] x)
  (1 3 4 5)
  arc> x
  (1)

If you then additionally make the editor display the opening parenthesis as a colon then, voila, you have the visually pleasing colon syntax.

PG commented "The single biggest compromise I had to make because of MzScheme was not being able to put objects like functions and hashtables into macroexpansions." Not exactly sure what he meant by that, or if it had anything to do with the evaling functions directly.

  [Note: Like functions, hash tables can't be printed out in a way
  that can be read back in.  We hope to fix that though.]

First, disallowing arithmetic operators in symbol names, so that (a+b/c) is interpreted like (a + b / c). All the replies to that, up till now, can be summed up like this:

  eds: *I don't really think it is worth it*
  kennytilton: *impoverishing the Arc naming syntax*
  cadaver: *seems not such a good idea after all*

One good point of having support is brevity for math-infix users. The only bad point that I see is that we use up the valuable number-in-functional-position real estate, which could have been used for something else.

Supporting infix may not only be good for math. Consider the following:

  (sort (fn (sm gr) (sm < gr)) somelist)

Consider: (sort < somelist)

And if (sort (fn (x y) (< x y)) somelist) looks awkward then maybe the issue is prefix altogether? I think anyone trying Arc who is new to Lisp might try Just Lisping (in Arc, of course) for a few weeks before even thinking about changing the language. These things take time and until one has done enough coding to get fluent (or throw up ones hands and say it has been three weeks and I still hate this!) one cannot even form an opinion about the whatever that thing might be. It is like an editor or IDE -- I hated the IDE I love now but made myself wait a month before ripping the vendor a new one. Now people accuse me of being on their sales team.

Case in point: Arc. It is hard judging the brevity/parens stuff because I am in pain anyway without a decent IDE, without a debugger, without a standard library... but I slogged my way thru a port of Cells from Lisp to Arc and some of the brevity is growing on me (I deliberately stopped doing a transliteration and reinvented over the keyboard so I could feel the language better) and at this point I think I can say I would not kick Arc out of bed. Something like that.

  (sort (fn (sm gr) (sm < gr)) somelist)

What are those plans for numbers in the functional position? pg's comments in the arc1 source are completely compatible with eds's system:

Comment 1 is about literal numbers as functions: (1) evaluates to 1

But that is not incompatible with comment two, which is about swapping first and second positions: (1 + 1) evaluates to 2

This seems a little like Perl's AUTLOAD.

If an unbound symbol is evaluated, a global AUTLOAD function is called with that symbol as an argument. AUTOLOAD could then parse this symbol and add, at runtime, the necessary functions/variables to the global environment. Invoking AUTOLOAD only on a page-fault basis may not be too inefficient. I have very often seen this done in Perl.

  (1 + x/y        ;expanded: x / y
   + (w/bar func) ;not expanded, function call

For this to work you'd need truly first-class macros, since it is not possible to definitely detect infix-context at compile-time:

  (1 + x/y)           ;infix, but may be subject to macro expansion
  ((sqrt 16)*4 + x/y) ;need to decide at runtime

As for precedence analysis, you need some evaluation to happen in order to know that the object in the functional position is a number, after which all your symbols representing functions have been evaluated too.

But even if you did manage to get a hold of the symbols, you would have to make arbitrary decisions about what is an operator and what is a function. (Unless you start evaluating stuff, which gets us back to where we started.) For example, even though expt isn't defined as an operator in the current version, this expression still works:

  (2 expt 3)

True, (a+b) has no infix context, havn't thought about that; seems not such a good idea after all.

--

Regarding symbol precedence

Getting hold of the symbols: it's the same with macros, you need some evaluation to happen to know that the object in the functional position is a macro. That's why I said truly first-class macros; the functional position is evaluated first and only then a decision is made to either evaluate the already compiled form in the case of a function call, or to macro-expand the uncompiled form in case of a macro expansion.

Arbitrary decisions about operator/function: macros have all the power, you can handle precedence exactly like in your current system, but get the precedence information by looking up a table with the symbols as keys. This will work exactly the same for functions and yield more predictable precedence for operators.

On the other hand, I'd prefer that functions with undefined precedence were forbidden wherever precedence matters, because it's very easy to unwittingly redefine a function that has precedence defined for it. By itself, (2 expt 3) is fine; no precedence handling necessary.

Think of it as: infix-functions make precedence invisible (masked through the binding, you see the symbol not the function); infix-symbols make precedence obvious.

EDIT: Actually, you wouldn't need first-class macros, if you could redefine "fn" and "set" to handle specially all functions that get bound/assigned to symbols that have some precedence defined for them.

There seems to be some difficulty doing this in arc1; "fn" and "set" are kind of special:

  arc> set
  Error: "reference to undefined identifier: _set"
  arc> fn
  Error: "reference to undefined identifier: _fn"

    (def func ()
      (if cond
          true
          false))
  -><- editor's suggested level of indentation

    :def func ()
      :if cond
          true
          false
  -><- forceful break of suggested indentation through backspace

If you have indentation based syntax, the sorting out by hand is replaced by matching the indentation level to the s-expression you want to modify; much easier, especially if you have programmed in non-lisp languages and are new to lisp, like me.

Here, for what it's worth, comes my insight: practically the same functionality that is gained by your proposed system could be gained by making the editor interpret a forceful break of indentation as a command to add/remove closing parenthesis of the last s-expression, e.g.:

    (if cond
      (do (one)
          (two)))
  -><- ;we start here and want to add another expression to (do ...
    -><-) ;we break the editor's suggested indentation once and the editor
          ;places if's ')' after the cursor
        -><-)) ;we break indentation twice and the editor
               ;places do's ')' after the cursor
          (three)-><-))

The beauty of parentheses is precisely being able to edit code in meaningful chunks because the parentheses naturally organize our code that way, which is part of why I think Arc's philosophy of "First, we kill all the parentheses" is away from goodness.

When I do edit code as if it were just so many lines and characters (about half the time -- after a dozen years I still have not mastered more than a few keychords) a simple "reformat" keychord automatically puts everything where it should be. And I am rarely disappointed by mistakes because the editor is still giving me cues by auto-indenting when I hit TAB and by blinking matching parens as I type.