Macros are not used to create unrecognizable languages. They are used when an API has grown to the point where writing the code to use it can be automated. That is probably hard to parse if you fear macros, because you can only fear macros if you do not know how they are used. But the idea is simple.

This little call tends to require this little call before it and this little call after it, or something like that. And this pattern appears often enough, or the Lisp developer recognizes it as the sort of thing that will appear again and again, and they just say, macro time!

They then give the macro a totally comprehensible name derived from the bits of the API being hit and, golly, no confusion.

The other time you see macros is in things like aif. There will only be so many of these, and they will confuse people not at all.

The two ways to get changes into Arc, as far as I can see, are to find a bug or write some real-world code that proves your suggestion is a good one. With so little real-world code around, that means very few changes will make it.

That reduces the burden of code review/merging/demerging on the person you'd like to pull the changes (PG).

e.g. have a bugfix branch containing only "obvious" fixes.

  (= setters (table))

  (with (var1 1 var2 2 var3 3 var4 4)
    (= foo (fn (v) (case v
                     var1 var1
                     var2 var2
                     var3 var3
                     var4 var4)))
    (= (setters foo) (fn (v val) (case v 
                                   var1 (= var1 val)
                                   var2 (= var2 val)
                                   var3 (= var3 val)
                                   var4 (= var4 val)))))


  (setters.foo 'var1 5)

  foo!var1
  => 5

  (= settersym (uniq))
  
  (= foo
    (with (var1 1 var2 2 var3 3 var4 4)
      (fn (v)
        (if (is v settersym) (fn (v val) (blah blah setter code)
            (case v
              var1 var1
              var2 var2
              var3 var3
              var4 var4)))))

  (mac set-value (f v val) `((,f ,settersym) ,v ,val))

  (set-value foo 'val1 5)

  (= matrix
    (let matdata '((1 0)
                   (0 1))
      (fn (v (o j nil)) ; ugly hack
          (if (is v settersym) (fn (val i j) (= ((matdata j) i) val))
              ((matdata j) v)))))

  (let m (matrix '((1 0) (0 1)))
     (= (m 0 1) 42))

Although I suppose you could actually use --warning-blatant-self-proclamation-- my p-m: macro:

  (p-m:def matrix
    (,(s (is s settersym)))
      writerfunction
    (i j)
      (readerfunction i j)
    x (err "argument error"))

I'll edit the above to use it.

  (find [< (len _) 3] '((1 2 3 4) (5 6 7 8)))
  => nil

  (find [< (len _) 3] '(nil (1 2 3 4) (5 6 7 8))
  => nil

Consider again the very similar case of Arc tables being unable to differentiate "key not found" from "key associated with nil". I was halfway thru a brilliant retort to pg on this with an example from my own real live working code (where I used CL's ability to differentiate the cases) when I realized Doh! I totally did not need the capability (and man was I happy I realized that before trying to school pg <g>).

Besides the kludginess of mem, consider how easy it is to screw up with find. How do you verify that a list doesn't contain any nils? Without a type system to enforce such invariants you get the worst kind of bugs: those that are manifest only once in a blue moon and present no obvious diagnosis.

That similar problems arise with other uses of nil suggests to me that we're missing an abstraction.

   (all idfn lst)

Meanwhile, are you sure (member nil lst) is a kluge? It sure looks readable, and it sure does work. What exactly bothers you about that?

Meanwhile, a use case means your are not just running code samples you typed in at the repl, it means you are trying to solve a problem using a computer and something came up. So here we are after iterating over the members of the library and we built up a list of overdue books per member -- no, that would not have nils, that would have an assoc entry (bob . nil). Hmmm... can you help me here, I cannot think of one.

You have not responded to the very similar example of tables. Correct, one cannot distinguish the absence of a key from a key added with the value nil. A use case is not a couple of lines of code proving that, a use case is a lookup on drivers license number during a traffic stop and...?

My point you may have missed is that without a use case not perfectly well expressed with either of the two solutions I offered above, the fundamental weakness is in offering a theoretical functional gap in a language as if it were a gap in a language.

Recall that pg is already on record as wanting things that are problems in practice, that this is a hacker's language, not a strait jacket language like C++ or Java with all sorts of theoretical angst over untyped variables.

   (= (cdr prior-kill-me) (cdr kill-me))

   (= (car kill-me) nil)

I'm trying to let the user specify what is/isn't infix, which is why I detect operators rather than numbers. I want the macro to have uses beyond infix arithmetic e.g. parsers expressed in BNF.

Also, mine is written entirely in Arc, so it's a good demonstration of what Arc can do, not to mention good practice for me.