For me, the BDFL model has worked quite well for Ruby, Python, etc. I expect I'm very biased since I'm a Ruby programmer currently, but I think it's fair to say the model works well to avoid dividing and conquering itself.

There are many things to like about Arc, but I think the fact that it could potentially unify a large community around a single implementation is very powerful.

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 funny thing is that perhaps unbeknownst to you all the Lisp establishment is ragging on pg for Arc being too much like Lisp, you (and I a little) are hosed that he diverged from Lisp, so him being smart I would guess he is now ignoring everyone. :)

  (define (ac-call fn args env)
   (let ((macfn (ac-macro? fn)))
    (cond (macfn
           (ac-mac-call macfn args env))
          ((and (pair? fn) (eqv? (car fn) 'fn))
           `(,(ac fn env) ,@(map (lambda (x) (ac x env)) args)))
          ((= (length args) 0)
           `(ar-funcall0 ,(ac fn env) ,@(map (lambda (x) (ac x env)) args)))
          ((= (length args) 1)
           `(ar-funcall1 ,(ac fn env) ,@(map (lambda (x) (ac x env)) args)))
          ((= (length args) 2)
           `(ar-funcall2 ,(ac fn env) ,@(map (lambda (x) (ac x env)) args)))
          ((= (length args) 3)
           `(ar-funcall3 ,(ac fn env) ,@(map (lambda (x) (ac x env)) args)))
          ((= (length args) 4)
           `(ar-funcall4 ,(ac fn env) ,@(map (lambda (x) (ac x env)) args)))
          (#t
           `(ar-apply ,(ac fn env)
                      (list ,@(map (lambda (x) (ac x env)) args)))))))

  (define (ac-call fn args env)
  (let ((macfn (ac-macro? fn)))
    (if macfn
      (ac-mac-call macfn args env)
      (let ((afn (ac fn env))
            (aargs (map (lambda (x) (ac x env)) args))
            (nargs (length args)))
        (cond
          ((eqv? (xcar fn) 'fn)
           `(,afn ,@aargs))
          ((and (>= nargs 0) (<= nargs 4))
           `(,(string->symbol (string-append "ar-funcall" (number->string nargs)))
              ,afn ,@aargs))
          (#t
           `(ar-apply ,afn (list ,@aargs))))))))

  (define (ac-fn args body env)
   (if (ac-complex-args? args)
      (ac-complex-fn args body env)
      `(lambda ,(let ((a (ac-denil args))) (if (eqv? a 'nil) '() a))
         'nil
         ,@(ac-body body (append (ac-arglist args) env)))))

  (define (ac-fn args body env)
   (if (ac-complex-args? args)
      (ac-complex-fn args body env)
      `(lambda ,(let ((a (ac-denil args))) (if (eqv? a 'nil) '() a))
         ,@(ac-body* body (append (ac-arglist args) env)))))

  (define (ac-fn args body env)
   (if (ac-complex-args? args)
      (ac-complex-fn args body env)
      `(lambda ,(let ((a (ac-denil args))) (if (eqv? a 'nil) '() a))
         'nil
         ,@(ac-body body (append (ac-arglist args) env)))))

  (define (ac-fn args body env)
   (if (ac-complex-args? args)
      (ac-complex-fn args body env)
      `(lambda ,(let ((a (ac-denil args))) (if (eqv? a 'nil) '() a))
         ,@(ac-body* body (append (ac-arglist args) env)))))

arc.arc:

  templates*, bar*, hooks*

  arcdir*, logdir*, quitsrv*, breaksrv*, srv-noisy*, srvthreads*, threadlimit*, threadlife*, ...

So then, to sum it all up, I'd have to say that this "program" to meet pg's requirements requires no server-side code (and thus a server-side parse tree of size 0) since it's just being served up as a static page. If you want to count the DOM parse tree length of my HTML/CSS, then you must also count that generated by every other submission here, which essentially adds some constant factor to all the metrics in this forum and thus becomes essentially a non-useful piece of information in comparing the entries.

pg claimed that you don't need to include your template libraries or other magical exotic web framework code. You can just assume it's there, so most folks aren't showing their HTML, and of course, it wouldn't make sense to count it towards their program's parse trees on a tag-by-tag basis since it's likely just a bunch of strings in most of their systems. But hey, like I said, in the end they're all making webpages, and if that's the case then I still think I've got a bit of a headstart on a lot of folks.

Then again, maybe not. What do you folks think? Am I just a big fat cheater or what? prepares to dodge ballistic tomatoes

  ~Keep on hackin' in the Free world.

In most examples, HTML runs on client machines which may be roughly comparable to your example, but who cares, because the code (whether measured in lines or nodes) the author had to write to generate that HTML was presumably superior in some way compared to writing HTML manually. (Otherwise why not just code straight HTML, all the time?)

In your example, even though the server side code consisted of 0 lines/nodes, the code written by you consisted on an entire HTML page. So did you really save any time or effort in writing the HTML? Maybe, that's why we compare the code trees. But even in that case, the HTML itself will count toward the code tree.

Perhaps this means that HTML templates (not HTML generated by server-side scripts) used in other entries should also be included in their code tree count, if they had to be coded manually by the author. But even if this is the case, it doesn't just add a constant factor to all entries (I believe the arc entry did not require any HTML to be written by the author), and thus is still useful information, although perhaps the two should be considered separately.

The thing that strikes me as being kind of a funny metric here with code length is that if the author wrote the HTML and imported it into their code, you have to count it, but if some other author wrote the HTML and you import it, then you don't have to count it. Seems kind of weird to me, seeing as this opens the door to somebody else saying:

Alright, maybe gjohnson's code count includes all that silly HTML and CSS, but my program uses his HTML template file (which isn't much of a template in this case, of course, being kind of the whole shebang), and has a parse tree of length 1.

Here it is:

  <!--#include virtual="gjohnsons_magic.html" -->

Anyway, keep going everyone. Those submissions are rockin' on. I've got my mind wrapped around a pretty perversely heinous challenge response that I may get to in the next couple of days. Keep your eyes peeled!

So I removed arc.arcc from Anarki. Now, arc-exe generates it automatically if it cannot find it on startup. And the -cc flag doesn't write anymore on stdout but directly in file foo.arcc (if you called arc-exe -cc foo.arc).

I get the following errors when I try to start arc-exe:

  C:\User\Programming\Arc\arc-wiki>arc-exe
  reference to undefined identifier: _ref
  
   === context ===
  c:\User\Programming\Arc\arc-wiki\arc-exe.scm:1005:0: cload1
  c:\User\Programming\Arc\arc-wiki\arc-exe.scm:1032:0: cload
  #f::354: loop

  C:\User\Programming\Arc\arc-wiki>arc-exe
  reference to undefined identifier: _map
  
   === context ===
  c:\User\Programming\Arc\arc-wiki\arc-exe.scm:1005:0: cload1
  c:\User\Programming\Arc\arc-wiki\arc-exe.scm:1032:0: cload
  #f::354: loop

  C:\User\Programming\Arc\arc-wiki>arc-exe
  Use (quit) to quit, (tl) to return here after an interrupt.
  arc>

EDIT: Actually, arc-exe doesn't seem to be working properly. I can't access any of the predefined functions:

  C:\User\Programming\Arc\arc-wiki>arc-exe
  Use (quit) to quit, (tl) to return here after an interrupt.
  arc> prn
  Error: "reference to undefined identifier: _prn"
  arc> (prn "hello world")
  Error: "reference to undefined identifier: _prn"
  arc> quit
  Error: "reference to undefined identifier: _input-history-update"
  arc> (quit)

  (defsyntax insert-file-here ()) ; dunno, never figured out scheme macros

  (module arc-exe mzscheme
    (insert-file-here "ac.scm")
  )

  (progn
    (provide (all-defined))
    ...
    (define (ac s env)
    ...)
  )

The alternative is to have the macros generate the (module ...) code, and insert the code inside the modules of ac.scm and as.scm and what else arc needs.

I hacked together a short version of arc-exe.scm that worked just fine importing from ac.scm. The only problem with that version was that it wasn't a module, and thus couldn't be compiled by mzc. I couldn't make it a module because scheme complained when brackets.scm tried to override read and read-syntax. (Apparently overriding imported bindings only works outside modules.) And when I tried to modify or not include brackets.scm, it would complain that it couldn't find the module ac.

  cat arc.arc libs.arc >all.arc
  arc-exe -cc arc.arc > arc.arcc

    arc-exe -cc all.arc > arc.arcc

"Letting people rewrite your language is a good idea. You, as the language designer, can't possibly anticipate all the things programmers are going to want to do with it. To the extent they can rewrite the language, you don't have to."

"If you want to overload existing operators to do the right thing when given your new type, you don't need anything new in the core. As long as you have lexical scope, you can just wrap a new definition of the operator around the old one."

http://arclanguage.com/item?id=3356

See the parent of that link for other ways to patch. I just used one of the original patches and modified slightly for arc1. For arc2, I justed used ediff in emacs and copied the old date block over.

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.