This comment (https://news.ycombinator.com/item?id=6119221) fascinates me; previously, I've had the same reaction to APL previously.

I've heard this idea before: have a language that separates the chrome of the top-level syntax from the underlying code.^1 That is, you can have the same language use different syntaxes ^2. This would allow robomartin to have his "notation as a tool for thought", while still having another syntax that's easier to understand, for those that want it.

But, of course, this would be difficult, especially if you want to allow mixing of multiple syntaxes in the same line of code.

For this specific example, you could have aliases for APL tokens to (possibly) multiple J tokens. The reader of the code could decide how to view it.^3 The writer could write whatever he or she prefers. But this doesn't even seem to be enough here; I don't think J and APL have all the same operators; unless you can make APL operators easily by combining J ones, this won't work. Of course, that doesn't mean a newly-designed language won't work.

Also, it's hard enough to get one language adopted by people; trying to get a language with variable syntax must be significantly harder. The toolchain will be an extremely important part of language evangelism; if there's no good way for people who don't use, say, either Emacs or Vim to use this language, no one will.

Perhaps start with an even simpler J version; instead of

  avg=: +/ % #

  avg=: fold(+) divide list-len

[1] Heck, even Lisp started that way, with M-expressions: https://en.wikipedia.org/wiki/M-expression . That no one used them is possibly an indication this is a bad idea.

[2] It's a fool's argument, but not technically wrong, to say we have that with different languages that compile to assembly, or to C, or scheme, or whatever. That's missing the point.

[3] This sounds like a nice Emacs mode.

[4] Yes; I'm suggesting a "simple" version include the terminology "fold". It's an implementation detail; perhaps this is better:

  avg=: +-list divide list-len

Relevant here is also http://worrydream.com/LearnableProgramming, and the Boxer paper (http://www.soe.berkeley.edu/boxer/20reasons.pdf; I could swear I'd submitted it here before.)

At least Arc does the default properly:

  arc> (def f (n (o tbl (obj))) (= tbl.n (* n 2)) tbl)
  #<procedure:zz>
  arc> (f 1)
  #hash((1 . 2))
  arc> (f 2)
  #hash((2 . 4))

If you looked at it closely, I made many changes in the spirit of getting something running that PG (and you!) would likely not agree with.

I know nothing of PG's plans for future releases, and I'd not be the one doing them.

But also, recursive macros are hard. You need to know whether you'll recurse without looking at the values of variables, because macroexpansion time is before runtime.

---

A project like this should probably use an "arclanguage.github.io" repo rather than some other repo's gh-pages branch.[1]

The arcfn static site generator may lead to some hassle. The generated website artifacts need to be pushed to the master branch, so they'll be the first thing someone sees when they delve into the repo to make a wiki edit. GitHub goes out of its way to make it easy to edit a repo as though it's a wiki[2], but that method of update won't trigger a very expressive build language[3], let alone anything that supports an Arc-based generator. Unless we have another server that does builds in response to a GitHub post-receive hook[4], in which case why not host the website there instead?

To use a custom generator, or to use Jekyll directly... both of these choices seem to have problems.

Another option would be to do keep Arc code inside <script> tags and run it with something like Rainbow.js, but search engines probably wouldn't index any content generated this way.

Hopefully someone here will be more optimistic about these ideas than I am. ^_^

[1] https://help.github.com/articles/creating-pages-with-the-aut...

[2] https://github.com/blog/844-forking-with-the-edit-button

[3] http://jekyllbootstrap.com/lessons/jekyll-introduction.html#...

Some quick thoughts:

Can we split arcfn docs into two parts: tutorial and reference.

The tutorial part can integrate with current Google Site wiki contents, and can be renderred by Jekyll so it can be more like a wiki.

And the reference part need to be generate locally and then push the static html to the repo.

All those two part can reside on "arclanguage.github.io" repo.

The repo structure may be like this:

  arclanguage.github.io/
  |-- index.html
  |-- tutorial/ ; or move all stuffs to the top dir?
  |-- docs/     ; static html. (reference instead of docs?)
  |-- _docs/    ; source of docs
  |-- anarki/
  |-- jarc/
  |-- ...

Please create a new repo named arclanguage.github.io, then I'll do some initial work.

  arc> (= (s 0) #\m)
  Error: "string-set!: expects type <mutable string> as 1st argument, given: \"foo\"; other arguments were: 0 #\\m"

http://comments.gmane.org/gmane.lisp.scheme.plt/14787

In ac.scm, in the arc compiler ac, arc strings are translated using ac-string. I've tried instrumenting the output of ac-string, and it seems mutable when it's encountered. And yet it's immutable by the time I return to the prompt:

  arc> ($.immutable? "abc")
  #f  # printed inside *ac-string*
  #t  # return value

---

I tried bisecting the git history, and the stable branch, which still requires mzscheme, has mutable strings. But sometime in 2011 when the master branch switched to using racket and stopped working with mzscheme, strings went immutable again. Still investigating..

---

Back in Feb 2011, waterhouse provided a bugfix for arc's mutable pairs. http://arclanguage.org/item?id=13616. https://github.com/arclanguage/anarki/commit/cea8a4c5e9. This change requires a racket-only lib, and so arc stopped working with the old mzscheme versions. Prior to it, modifying strings worked in mzscheme but not in racket. So it seems to be something about the move from mzscheme 372 to racket.

---

Update 34 minutes later: It seems eval in racket emits immutable strings even when given mutable strings. Since everything passes through racket's eval it doesn't matter how much arc twists and turns to avoid immutability.

  $ racket
  > (immutable? "abc")
  #t
  > (immutable? (string-copy "abc"))
  #f
  > (immutable? (eval (string-copy "abc")))
  #t

Here is a quick and dirty patch for arc3.1, it postpones string-copy and let it run by eval.

Not sure if it will cause some other problem.

  50,51c50,51
  <           (unescape-ats s))
  <       (string-copy s)))          ; avoid immutable strings
  ---
  >           `(string-copy ,(unescape-ats s)))
  >       `(string-copy ,s)))          ; avoid immutable strings

https://github.com/Pauan/ar/commit/a2c1939936846b665eccf06d0...

BTW, I think `(unescape-ats s)` also needs to be treated as the same.

I'd like to run some tests to make sure it does not cause much problem.

I found this one:

https://github.com/conanite/rainbow/tree/master/src/arc/lib/...

But it failed with following error when using arc3.1.

  arc> (load "unit-test.arc")
  nil
  arc> (rat)
  Error: "_dfn: undefined;\n cannot reference undefined identifier"

I've added a few piecemeal tests over the years (all the .t files in the repo), and there's also some tests in my curated repo (http://github.com/akkartik/arc). All those seem ok..

---

Looks like dfn is a rainbow innovation: http://arclanguage.org/item?id=10539

---

I've also added/plagiarized rainbow's tests to the repo: https://github.com/arclanguage/anarki/commit/68be3c0f4d. Joys of the perl artistic license.

There's still a couple of syntax tests that are failing, likely because of test harness issues. And I'd like to unify all the different tests into a single framework. For future work..

---

If you want to go with base Arc, you can pass a dictionary in, something like this:

  (def greet ((o arg-dict (obj)))
       (prn "Hello there, "
            (or arg-dict!person "friend")
            "! Would you like "
            (or arg-dict!thing-to-offer "some ice cream")
            "?"))
  
  arc> (greet)
  Hello there, friend! Would you like some ice cream?
  "Hello there, "
  arc> (greet (obj person "Darth Vader" thing-to-offer "a lightsaber"))
  Hello there, Darth Vader! Would you like a lightsaber?
  "Hello there, "
  arc> (greet (obj thing-to-offer "two lightsabers"))
  Hello there, friend! Would you like two lightsabers?
  "Hello there, "
  arc> 

  (def greet2 arg-list
       (let args (pair arg-list)
            (prn "Hello there, "
                 (or (alref args 'person) "friend")
                 "! Would you like "
                 (or (alref args 'thing-to-offer) "some ice cream")
                 "?")))
  
  arc> (greet2)
  Hello there, friend! Would you like some ice cream?
  "Hello there, "
  arc> (greet2 'person "Darth Vader" 'thing-to-offer "a lightsaber")
  Hello there, Darth Vader! Would you like a lightsaber?
  "Hello there, "
  arc> (greet2 'thing-to-offer "two lightsabers")
  Hello there, friend! Would you like two lightsabers?
  "Hello there, "
  arc> 

  arc> (greet2 'person)
  Hello there, friend! Would you like some ice cream?
  "Hello there, "
  arc> 

  (def greet3 (emotion . arg-list)
       (let args (pair arg-list)
            (prn "Hello there, "
                 (or (alref args 'person) "friend")
                 "! I'm " 
                 emotion
                 " to see you. Would you like "
                 (or (alref args 'thing-to-offer) "some ice cream")
                 "?")))
  arc> (greet3 'happy)
  Hello there, friend! I'm happy to see you. Would you like some ice cream?
  "Hello there, "
  arc> (greet3 'enraged 'thing-to-offer "to be murdered")
  Hello there, friend! I'm enraged to see you. Would you like to be murdered?
  "Hello there, "
  arc> 

Downsides include not having a good way to set defaults -- you have to supply the default each time in the code you use it. Alternately, you can put the body in a function that requires each argument, then in the "regular" function, supply the default as an argument to the helper:

  (def greet4 (emotion . arg-list)
       (let args (pair arg-list)
            (greet4-helper emotion
                           (or (alref args 'person)
                               "friend")
                           (or (alref args 'thing-to-offer)
                               "some ice cream"))))
  
  (def greet4-helper (emotion person thing-to-offer)
       (prn "Hello there, "
            person
            "! I'm " 
            emotion
            " to see you. Would you like "
            thing-to-offer
            "?"))
  
  arc> (greet4 'bored)
  Hello there, friend! I'm bored to see you. Would you like some ice cream?
  "Hello there, "
  arc> (greet4 'bored 'thing-to-offer "to go away")
  Hello there, friend! I'm bored to see you. Would you like to go away?
  "Hello there, "
  arc> 

  arc> (greet4 'bored 'thing-to-offer nil)
  Hello there, friend! I'm bored to see you. Would you like some ice cream?
  "Hello there, "
  arc>