I made a couple of tweaks to the menus. I think we should make anarki the default; 3.1 has some bugs and gotchas. Even if the docs will only support arc 3.1 for starters, there's still value in combining them with anarki, I think.

I love the favicon :)

I pointed at external resources where they're still useful. No reason to copy the default tutorial, for example, and everyone should know about http://tryarc.org.

Does anybody use anarki's arc.sh script? I just tried it from a different directory and it failed on me. If others can confirm the problem I'll try to fix it.

I'm not a designer, so currently I just use bootstrap. I wish there are some experts here, so that our site can have a shiny and unique look and feel.

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

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/
  |-- ...

---

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#...

There may be some compatibility issues.

If anarki is mostly compatible with the vanilla one, I think we can just put docs under http://arclanguage.github.io/doc, and add notes if some functions differently between them.

This is about stuff that overlapped by this two. For extensions and new libraries in anarki, we can make a dedicated page for them. e.g. http://arclanguage.github.io/anarki.

Also, it's time that I leave the Arc Forum. You all are free to follow my projects on GitHub (https://github.com/Pauan) and can e-mail me at pcxunlimited@gmail.com

"Because I can't tell if `Pauan` is human or not, I'd like to define exactly how `Pauan` arrived at this answer in the community-managed fork of Arc. Is this possible? (yes no)."

If I understand you correctly, you're asking if we could please open-source Pauan (or a subsystem thereof) for the sake of future development and discussion. No. Please don't undermine the voices of people on this forum.

- You're asking an in-depth question about someone in the third person, when they're right here to explain.

- It seems to me you're discriminating on the basis of someone's involuntary implementation details, without any obvious and respectable reason.

- You're suggesting to "define exactly" something which may be an essential secret ingredient in someone's appearance of individuality. As far as I'm concerned, you might as well suggest we zap someone's brain or hound them with paparazzi.

http://docs.racket-lang.org/reference/reader.html?q=string%2...

  arc> (prn "abc\"")
  abc"

Are you talking about making a guide about guides, or a guide specifically to help people to understand Lisp? I'm sure either one is possible, but this particular community should have a much easier time with the Lisp guide than the general guide.

That actually sounds like a pretty good idea: a single consolidated guide to help people understand the Lisp way of doing things. Of course we've written plenty of stuff already (as have people not on the Arc forum), but it's scattered everywhere and isn't really coherent. Something like the "learn you a Haskell for great good" but for Lisp sounds nice. Is that what you're talking about?

---

"you can decide immediately(or within ~10min) if someone's cool."

Even if that's true, that isn't necessarily useful. "Coolness" is arbitrary and cultural. It shifts over time. It isn't necessarily tied to quality. And I think that people who seek coolness tend to produce lower quality stuff. After all, any time and energy spent being cool is time and energy spent not improving in non-cool (but useful) ways. Though I myself am guilty of sometimes doing things for the sake of reputation, I try not to do that.

---

"How exactly did you parse it into such a coherent roadmap so quickly?"

I'm just that kinda person: somebody who's quick to read into things. Unless it's rocketnia doing the talking, then I have a much harder time. :P

---

"Must I fork my own version of Arc to do it? Is there a simpler way?"

Most of the Arc terminology is borrowed from other Lisps, so it's not really a problem with Arc; instead, it's simply that the Lisp culture is very old and has its own way of thinking and doing things. You get used to it.

If you have any questions, please do ask and we'll do our best to answer. Some of us here (including myself) started Arc with almost no Lisp experience, yet over time became quite good.

---

"What are some reusable trail maps that other people have experienced?"

Considering that I'm still learning new things all the time, and that the new things I discover have a tendency to demolish decades-old ways of thinking, I'm not sure there is a nice reusable "just read this and you'll be okay" kind of thing. I do know of at least one good resource for explaining what macros are and why they're awesome, but that's about it. The rest you either have to dig up, ask about, or learn on your own.

---

"How can I learn more about you folk?"

Well, it depends on how much you want to know us. If all you care about is the programming aspect, you can just hang around here and watch what we say and do. You can also ask.

---

"Why is the help button so small to get me to http://arclanguage.org/formatdoc? "

I don't know, that bugs me too. I didn't even know about that link until somebody pointed it out.

---

"Why can't I hover over the language and have it tell me how to refactor my thinking?"

Because good AIs don't exist yet. So it's up to us lowly meat-bags to do the thinking.

---

"How do I ask better questions?"

Everything happens with practice, which takes time and effort. If you really want something and you keep working at it, you'll see improvement. If you don't see improvement, then perhaps your methods are incorrect and you should seek better methods. But keep in mind that some things takes years of hard work, and there may not always be a way to speed it up.

Just focus on improving things bit by bit and after a long period of time, when you look back, you'll see amazing accomplishments. Every journey starts with a single step and all that jazz.

---

"Is there a periodic element of lisp-y things?"

Kinda. Lisps do share some things in common, like S-expressions, macros/vaus, code-is-data-is-code... but the Lisp culture also deeply values individuality and giving programmers more power. So despite some overlap, you tend to see a lot of variance between Lisps, as people try out different things.

---

"Why exactly can't we make improvements again? May I?"

We can't make improvements because pg has been too busy. However, there is a fork of Arc called Anarki, which anybody can change:

https://github.com/arclanguage/anarki

There are also various other forks of Arc, such as Rainbow, Rainbow.js, Jarc, and Arc/Nu:

https://github.com/conanite/rainbow

https://github.com/rocketnia/rainbow-js

http://jarc.sourceforge.net/

https://github.com/Pauan/ar

---

"I believe there needs to be a search engine to help me answer that."

If you want to search for something on the Arc Forum, I've found the best way is to go to google.com, and then do this:

  site:arclanguage.org foo

"Why can't JS just be a Wart?"

Oh man I can go on and on about JS. The answer to your question is pretty long and detailed. If your question is, "why isn't JS better?", well... that's a history lesson that people smarter than me have already gone into:

https://brendaneich.com/2008/04/popularity/

http://www.jwz.org/blog/2010/10/every-day-i-learn-something-...

http://www.jwz.org/blog/2010/10/every-day-i-learn-something-...

For the record, they are working hard on fixing some problems with JS:

https://brendaneich.com/2012/10/harmony-of-dreams-come-true/

But things take time. Especially because they have to worry a lot about backwards compatibility.

Also, even though JS is worse than say, Arc, it is possible to write a compiler that takes some dialect of Lisp and compiles it to JavaScript... for an example of that, see my language Nulan:

http://pauan.github.io/nulan/doc/tutorial.html

https://github.com/Pauan/nulan

I think what math people obsess about is always reality. The fact that they are obsessing about it at all is a real phenomenon, and we can think about tracing it back to its most immediate cause. That immediate cause is likely to be a very math-like problem in need of a solution. The not-so-math-like problem which inspired that math-like problem may be an awfully long way from where we started searching, but it's still connected.

Some mathematicians (the pure mathematicians) may pursue math-like curiosities without much regard for where they're going. Still, their own intuition and sense of elegance will constrain their discoveries to forms that can come in handy later on. In this case, mathematics acts as a bridge that starts from today's human intuition and elegance and connects to tomorrow's newfound human problems.

Clearly you're looking for an efficient connection, not just any connection. I suspect the only way to find that is to keep yourself in a state of perpetually looking, even as you continue with what you're doing. Be your own JIT compiler--and yet, don't let a JIT compiler be all that you are.

You seem to be focussed on questions of the form, "Why can't an A be a B?" I ask: Why should it? Different things enrich the world and provide opportunities for future cross-fertilization.

"Elm's interaction with JavaScript code seems like it could use some improvement, which matters because I care about using new Web standards as they come out. Fortunately, it's not so bad that it makes the language unusable for this purpose, and I have an idea for how to prototype a new FFI from within the existing one. I'll elaborate on that idea in a separate post."

Since Elm's evaluation semantics are typical of functional languages, my design in this post could be relevant for just about any language that has an FFI to JavaScript. However, it's focused around what Elm already strives to make available in its FFI.

I've found four ways an Elm program can currently interact with JS code:

- There's a top-level way to associate well-behaved DOM events with Elm signals, described here: http://elm-lang.org/learn/Syntax.elm#javascript-ffi

- Some built-in JavaScript, JavaScript.Experimental, and Json modules are available, as described here: http://elm-lang.org/Documentation.elm

- The built-in functions == and show can operate on JavaScript values. There may be more like these.

- If a variable isn't bound in any imported module, the compiler will translate it directly into a JavaScript variable reference. This makes it possible to call JavaScript's eval() and similar tools. Unfortunately, this process is unhygienic, making it possible to access and assign to(?) the compiler-generated local variables. This feature isn't documented, but I've found no other use values of type JSString, JSFloat, etc., so I conclude it's the trap door to JS that I'm looking for.

When integrating a language like Elm with JS, some semantic awkwardness is to be expected. I don't expect Elm's reactivity to have perfectly elegant integration with all the step-by-step structure of the HTML+JS operational semantics. I don't expect an Elm `Element` to behave well in all the dark corner cases of DOM+CSS layout.

If it were up to me to improve Elm, I would stop relying on this unbound variable feature, since it's probably one of the oddest features as far as the type system is concerned. In place of this, I'd introduce an explicit eval mechanism, and I'd slightly redesign the other basic utilities to be more inclusive of heterogeneous Arrays, and generally to wrap JavaScript's idiosyncrasies more snugly.

As it turns out, I think this can be implemented as a library in Elm.

  module Js where
  
  -- We label something here as "unsafe" iff it makes it possible to
  -- break Elm's usual semantics even when using *safe* JavaScript
  -- techniques. This is meant to indicate that the JavaScript-related
  -- code needs to be extra careful to avoid breaking the Elm program.
  --
  -- For this definition to be meaningful, there has to be some notion
  -- of "safe" JavaScript code. We consider JavaScript code to be
  -- "unsafe" iff it defies JavaScript conventions in such a way that
  -- even an everyday JavaScript program would break. For instance, it's
  -- unsafe to modify basic platform features like Object.prototype and
  -- window.setTimeout. Ultimately, this is subjective; I'm relying on
  -- my own assessment of what an "everyday" JavaScript program is like.
  
  
  -- If a JavaScript Array or string has around 2^53 elements (and if we
  -- can somehow hold it in memory), the indexing functions may not work
  -- very well. Perhaps this issue will be more realistic if Elm ever
  -- supports infinite lists. Either way, I'm using the FixList and
  -- FixString types to make it clear that a list's length must be a
  -- representable integer.
  takeFix : Int -> [a] -> FixList a
  prependFix : FixList a -> [a] -> [a]
  type FixString = FixList Char
  
  
  -- These utilities are actually so safe that their behavior should be
  -- possible even if unsafe JavaScript code has utterly sabotaged
  -- everything else. If only the internal workings of the compiled Elm
  -- code were just as airtight! (Are they?)
  toFloat : JsValue -> Maybe Float
  fromFloat : Float -> JsValue
  toFiniteString : JsValue -> Maybe FixString
  fromFiniteString : FixString -> JsValue
  eq : JsValue -> JsValue -> Bool
  true : JsValue
  false : JsValue
  null : JsValue
  undefined : JsValue
  typeof : JsValue -> FixString
  
  
  -- I'm not sure there's any safe way to detect whether something is an
  -- Array and enumerate its contents. Some objects intentionally
  -- imitate Arrays, so this is a semantic battlefield.
  --
  -- Let's say fromArray checks for a "length" field and then enumerates
  -- numeric properties up to that length. This way it can handle
  -- arguments objects, strings, NodeLists, TouchLists, Uint32Arrays,
  -- jQuery objects, etc. Let's also say that any object that causes
  -- side effects during this operation is so unsafe for JavaScript that
  -- it's not extraordinarily unsafe for Elm.
  --
  fromArray : JsValue -> Maybe (FixList JsValue)
  toArray : FixList JsValue -> JsValue
  
  
  -- Execute arbitrary code as though by using Function( "..." )( x ).
  -- Naturally, the observed value of free variables, primitive-related
  -- prototypes, etc. may vary depending on the frame or Web worker used
  -- for executing the Elm code. If this JavaScript code has side
  -- effects or accesses internal details of Elm-managed objects, it may
  -- interfere with Elm's usual semantics.
  --
  -- Elm's design is oriented around pure manipulation of time-varying
  -- Signals, so significant JavaScript side effects should probably be
  -- reserved for responding to DOM events and Elm Signal updates,
  -- rather than acting at arbitrary moments during Elm's expression
  -- evaluation.
  --
  unsafeEvalFunctionBody : FiniteString -> JsValue -> JsValue
  
  
  -- I'm not sure there's a better alternative to "x instanceof Node" or
  -- "x instanceof Element" for detecting DOM nodes or DOM elements
  -- created in the JS code's frame. I'm not sure which of these Elm
  -- cares about, but let's say JavaScript code is unsafe for Elm if it
  -- causes these checks to fail or perform side effects, or if it gives
  -- a DOM node unusual behavior such as custom property getters.
  domNodeFromElement : Element -> JsValue
  unsafeDomNodeToElement : Int -> Int -> JsValue -> Maybe Element
  
  
  -- These take the place of the entire JavaScript.Experimental module
  -- and the Json module's utilities for JSObjects. I think there's no
  -- safe way to detect whether an object's "own" properties are all
  -- safe to dereference, so the JS-to-Elm conversions are unsafe.
  --
  -- Similarly, I'm not sure object and Array initialization are
  -- necessarily pure if Object.prototype or Array.prototype has been
  -- modified. In my testing, object and Array literals seem to be able
  -- to initialize fields without calling their setters, but it's not
  -- possible to use this technique with programmatic lengths/keys
  -- without resorting to some kind of eval. However, this case is
  -- unsafe for JavaScript code in general, so it isn't extraordinarily
  -- unsafe for Elm.
  --
  fromJson : JsonValue -> Maybe JsValue
  unsafeToJson : JsValue -> Maybe JsonValue
  fromNestedStructure : a -> Maybe JsValue
  unsafeToNestedStructure : JsValue -> Maybe a