I agree 100% about different group requiring different landing pages. Both of the ones you mentioned are good targets, I think. I'll do more keyword research to help dissect the audiences.

The beginning programmers' page is easiest, because pg's tutorial already targets them:

"This is a brief tutorial on Arc. It's intended for readers with little programming experience and no Lisp experience. It is thus also an introduction to Lisp."

All we have to do is put the tutorial in an iFrame next to the REPL, as thaddeus suggested. [1] I can take care of this one. (Eventually it would be cool to have an interactive tutorial though, as you suggested.)

Can I get your input on a page that targets a Lisper who's new to Arc? They can be coming from the Lisp dialect of your choice.

And what other audiences would you consider? Maybe people new to Lisp but coming from other programming experience, such as Ruby or JavaScript?

--

  screen-x: "Narrowest" 700 
            "Narrower" 800 
            "Narrow" 900 *default*
            "Wide" 1200  
            "Wider" 1400 
            "Widest" 1600
 
  screen-y: "Shortest" 400 
            "Shorter" 500 
            "Short" 600 *default*
            "Tall" 750 
            "Taller" 900 
            "Tallest" 1200 

If you would like you can create an account on PetroEnergyNews then go to the user preferences to select the various combinations to get a feel for these sizes.

The "Widest" by "Tallest" setting is perfect for my 27 inch iMac screen :)

Anyways hopefully this info is helpful/useful.

[edit:

1. oops, that's only the map inset window, so it doesn't include the top and bottom bars, but still they should be easy to guesstimate at about 24px each.

http://rocketnia.kodingen.com/af/try-lava-script/

It shows you the compiled JavaScript for your input expression as well as the evaluated result. For example:

  ; Defining a function
  > (= add1 (fn(x­) (+ 1 x)))        
  add1=(function(x){return 1+x;})   
  => function (x){return 1+x;}      

  ; Calling the function
  > (add1 2)
  add1(2)
  => 3

--

It's a bittersweet situation as we rejoice pg adding a search bar to Hacker News [1] while mourning the sudden loss of SearchYC [2].

One service SearchYC provided that remains a need unfulfilled even with the new feature is search for Arc Forum, pg’s other news.arc forum [3]. This had been an extremely valuable resource to the Arc language community as SearchYC had been to the Hacker News community. It kept the old gem posts and comments which tend to get buried in the forum accessible to new readers.

How can we address the problem of lost search to Arc Forum and the other Hacker News sister forums in the wake of SearchYC’s shutdown?

[1] http://news.ycombinator.com/item?id=2619736

[2] http://news.ycombinator.com/item?id=2605959

They are interesting questions. I think that to be a lisp, a language must homoiconic and applicative. A cons-based system is non-essential, and I am coming to agree with the OP that it's not the best way.

Update: Hmm... my mind is playing tricks on me now. What would you use besides conses to represent s-expressions? Maybe that is a good role for cons.

What are s-expressions? I thought their main aspect was the way they used lists to represent user-extensible syntax forms (macro forms, function applications, fexpr applications). I'm not a fan, but even if we assume s-expressions, they could always use some other implementation of lists.

--

"I wonder if there's a way to merge quote and lambda into a single operator."

Do you mean like in PicoLisp, where all user-defined functions are lists containing their code, and applying a list causes it to be interpreted as a function?

Arrays, objects, pretty much anything that can represent nested sequences. In fact, in PyArc, conses are a class, because Python has an infatuation with classes.

I don't see conses as an "ultimate abstraction". They're a low-level primitive that can be used to create lists, among other things. To put it bluntly, they're a simple way to implement linked lists. The only difference between an array and a linked list is performance, but they have the same semantics.

Most popular languages choose arrays as their default sequence type, but Lisp chose linked lists. I could represent conses as Python lists (which are like arrays), and then define car so it returns list[0] and cdr so it returns list[1:].

As far as Arc programs would be concerned, everything would look exactly the same. The only difference is that certain operations (like prepending) would be slower with arrays than with a linked list. Specifically, (cons 'a some-list) would be O(n) rather than O(1).

Of course, an easier fix would be to change `cons` so it throws an error if the second argument isn't a cons or nil. Honestly, are improper lists useful often enough to warrant overloading the meaning of cons? We could have a separate data-type for B-trees.

That's one area that I can actually agree with the article, but that has nothing to do with conses in general (when used to create proper lists), only with improper lists. And contrary to what he says, it's not an "unfixable problem", instead it would probably take only 2 lines of Python code to fix it.

One thing though... function argument lists:

  (fn (a b . c))

If so... then you may end up with the odd situation that it's possible to create improper lists, using the (a . b) syntax, but not possible to create improper lists using `cons`

---

---

"how about this: proper lists would have a type of 'list and improper lists would have a type of 'cons."

I don't think I like the idea of something's type changing when it's modified. But then that's mostly because I don't think the 'type function is useful on a high level; it generally seems more flexible to do (if afoo.x ...) rather than (case type.x foo ..), 'cause that way something can have more than one "type." Because of this approach, I end up using the 'type type just to identify the kind of concrete implementation a value has, and the way I think about it, the concrete implementation is whatever invariants are preserved under mutation.

"we see the actual example of Arc running in the actual environement, not some different or pretend environment that might be the same as the cell phone or might not."

And from https://eval.to/, after clicking the "start new repl" button:

"Note the connector allows this website to execute arbitrary code on the computer running the connector. If you'd rather not do this on your own personal computer, you may wish to use a virtual machine or an Amazon EC2 instance, etc."

Presuming that most people concerned about security would opt to run the connector through a virtual machine or something other than their personal computer, wouldn't we be effectively running the Arc examples through just the kind of different or pretend environments that we're trying to avoid?

And... naturally there will be other people who don't want to run the connector, and so the site will be less useful to them.

Since this is a new and different kind of system, I wanted to be clear about what's going on -- so no one is surprised, and can make their own informed decision about if and where they want to run the connector.

  (def cons (x y) (fn (f) (f x y)))
  (def car (x) (x (fn (a b) a)))
  (def cdr (x) (x (fn (a b) b)))

  (car (cons 'a nil)) -> a

  ; arc3.1                     ; arc4.0 ?
  
  (def foo (a b (o c) (o d))   (def foo (a b . (c d))
    ...)                         ...)

  > (def bar (a b . (c . args))
      (list a b c args))
  #<procedure:bar>
  > (bar 1 2)
  (1 2 nil nil)
  > (bar 1 2 3)
  (1 2 3 nil)
  > (bar 1 2 3 4)
  (1 2 3 (4))
  > (bar 1 2 3 4 5)
  (1 2 3 (4 5))

---

  arc> (read "(a . (b c))")
  (a b c)

  * (+ 1 . (2 3)) ;SBCL
  6

  (def print (x)
    (if (acons x)
        (do (disp "(")
            (print (car x))
            (disp " . ")
            (print (cdr x))
            (disp ")"))
        <handle remaining cases: x is a symbol, number, string...>))

  Welcome to Racket v5.1.
  > (define abc (read-syntax #f (open-input-string "(a b c)")))
  > (define a.bc (read-syntax #f (open-input-string "(a . (b c))")))
  > (define abc.null (read-syntax #f (open-input-string
                                       "(a b c . ())")))
  > abc
  #<syntax::1 (a b c)>
  > a.bc
  #<syntax::1 (a b c)>
  > abc.null
  #<syntax::1 (a b c)>
  > (syntax-e abc)
  '(#<syntax::2 a> #<syntax::4 b> #<syntax::6 c>)
  > (syntax-e a.bc)
  '(#<syntax::2 a> . #<syntax::6 (b c)>)
  > (syntax-e abc.null)
  '(#<syntax::2 a> #<syntax::4 b> #<syntax::6 c> . #<syntax::10 ()>)

  (def foo (a b ? (c d . e)))

  (def foo (a b ? c d . e))

True, the first version is more explicit, and the parens make it clearly distinct from the required arguments, but then again, it does add an extra level of (arguably useless) parens. I still think it looks nicer than Arc's current version, though:

  (def foo (a b (o c) (o d) . e))

On the other hand, even if you made all arguments default to nil, you could still have some error checking:

  (def foo (a b c))
  
  (foo)          ; (a b c) are (nil nil nil)
  (foo 1 2)      ; (a b c) are (1 2 nil)
  (foo 1 2 3)    ; (a b c) are (1 2 3)
  (foo 1 2 3 4)  ; error: expected 0 to 3 arguments (4 given)
  

I'm pretty okay with that tradeoff, actually. It gives up a bit of safety and control, but in exchange it avoids the whole icky mess with "what syntax do we use for optional arguments?" I might try that approach with my interpreter.

In fact, we could reverse the question. Rather than asking, "how do we define optional arguments?" we can instead ask "how do we define required arguments?"

In other words, all arguments default to nil, but it's possible to specify certain arguments as required, or to change what the default is. That may be a better approach than specifying what arguments are optional.

There is one problem with that approach, though. You'll likely want a way to specify what the default for an argument is, which would require some sort of construct. But then if you want to specify a required parameter, you'll need a second (different) construct.

If you have required arguments by default, then you can use a single construct to specify both optional arguments and what their defaults are. But if you have optional arguments by default, you need two constructs.

Unless you're suggesting to not have required arguments at all, and require the programmer to manually write an (if (no a)) check and manually throw an error? That could work, assuming most people don't need required arguments most of the time.

You could even wrap it up in a macro or something, like this:

  (def foo (a b c)
    (require a))

  (def foo (a b c)
    (require a 'sym))

  (mac require (n t)
    `(if (no ,n)         (err (string "parameter " ',n " is required"))
         (no:isa ,n ,t)  (err (string "parameter " ',n " must be of type " ,t))))

  (mac require (n (o typ))
    `(if (and ,typ ,n (no:isa ,n ,typ))
           (err:string "parameter "
                       ',n
                       " must be of type "
                       ,typ)
         (no ,n)
           (err:string "parameter " ',n " is required")))

  ((fn (t) t) 10)         -> 10
  ((fn (quote) quote) 10) -> 10
  ((fn (nil) nil) 10)     -> nil

That's because ((fn (nil) nil) 10) is supposed to be the same as ((fn (()) nil) 10), which destructures the first 0 elements from 10, treating it as a degenerate cons list.

I actually use this behavior in practice, 'cause it's useful to have at least some parameter syntax that doesn't bind any variables, rather than just using a conventional name like "ignored" or "_". Most of the time I use it in a much-too-big 'withs block, where I abuse one of the bindings for sanity-checking or other side effects. ^^ I wouldn't worry about it too much, though.

On the other hand, nil's behavior makes it more verbose to determine whether something's usable as a local variable; you have to check (and x (isa x 'sym) (~ssyntax x)). In Lathe, I define 'anormalsym to do just that. (It might be more accurate to change it to (and (isa x 'sym) (~in x nil t 'o) (~ssyntax x)).)

Speaking of (~ssyntax x), ssyntax is usable for local variable names, but naturally, you can only get the values from the Racket side:

  arc> (let a.b 4 a.b)
  Error: "reference to undefined identifier: _a"
  arc> (let a.b 4 ($ a.b))
  4

nil is such a weird value... it's false, a symbol, and an empty list all at once. I actually had to do some hacky stuff to get () and '() and nil to behave properly.

"Speaking of (~ssyntax x), ssyntax is usable for local variable names, but naturally, you can only get the values from the Racket side:"

  (is 'nil nil) -> nil

On the other hand, (listp nil) should be true. In fact, its precise definition should probably be (and is, or is equivalent to) this:

  (def listp (x)
    (or (is x nil)
        (and (acons x)
             (listp (cdr x)))))

Actually, I could represent nil as an actual 'cons cell, so that assigning to the car or cdr would work. Crazy? Probably. Especially since nil is a singleton and you can't create more nil's, so it would be a global change.

That's a bit crazy. :)

PicoLisp does something reminiscent. Every one of its data structures (numbers, symbols, nil and conses) is implemented using the low-level cons cell structure (i.e. a pair of machine words). [1] They talk about nil's representation fulfilling its dual nature as both a symbol whose value is nil and a list whose car and cdr are nil; both the symbol predicate and the list predicate return true when applied to nil:

  : (sym? NIL)
  -> T
  : (lst? NIL)   
  -> T

--

[1] http://software-lab.de/doc/ref.html#vm

[2] http://software-lab.de/doc/ref.html#nilSym

--

Not sure about empty tables, though... maybe it would be fine to treat those as nil. We already treat an empty list as nil, after all.

Actually, what you're suggesting is very similar to how languages like JavaScript and Python do it, with 0 null undefined NaN "" etc. being falsy. So in JS, you can do this:

  var foo = 0;
  if (foo) {} // will not be evaluated

  foo = "";
  if (foo) {} // will not be evaluated

  foo = NaN;
  if (foo) {} // will not be evaluated

Also, if = doesn't work, assign probably would:

  (assign nil '())

  (assign nil 'foo) -> foo
  nil               -> foo
  'nil              -> nil
  ()                -> ()
  '()               -> nil
  (assign nil '())  -> nil
  (is nil ())       -> t
  

I too have sometimes wished for that in JavaScript, but let me tell you a little story. I was writing a syntax highlighter, and got it working fine in Chrome and Firefox 3.5, but there was a bug in Firefox 3.0.

You see, I was using this bit of code here:

  output.push(text.slice(curr.index[1], next && next.index[0]));

But in Firefox 3.0, the slice method behaves differently depending on whether you pass it `undefined`, or don't pass it any arguments. So, I had to use this instead:

  if (!next) {
      output.push(text.slice(curr.index[1]));
  } else {
      output.push(text.slice(curr.index[1], next.index[0]));
  }

Consider this hypothetical example in Arc:

  (your-func 5 (and x y z))

By behaving differently when nil is passed in vs. not passing in an argument, you might cause the above example to break. Or perhaps it would work, but the behavior would be subtly different... introducing bugs.

By having different behavior depending on whether an argument is passed or not, you force callers to do this, instead:

  (iflet val (and x y z)
    (your-func 5 val)
    (your-func 5))

I share this sentiment. One thing we could do is have a space of hidden-from-the-programmer variables which tell you whether other variables have been bound. They can be accessed using a macro:

  (= given-prefix* (string (uniq) "-given-"))
  (mac given (var)
    ; NOTE: I don't think this will work properly for nil, but nil is
    ; never a local variable name anyway.
    (sym:+ given-prefix* var))

---

"Maybe doing destructuring on rest args would help solve that problem in most cases?"

  (def test args
    (if (assoc 'c args)
          (pr "c was passed")
        (pr "c was not passed")))

  ; Current options:
  
  (def test args
    (let ((o c)) args
      (pr:if (len> args 0)
        "c was passed"
        "c was not passed")))
  
  (let missing list.nil  ; This is just something unique.
    (def test ((o c missing))
      (pr:if (is c missing)
        "c was not passed"
        "c was passed")))
  
  
  ; Some hypothetical options and non-options:
  
  (def test (& (c))
    (pr "no way to tell if c was passed"))
  
  (let missing list.nil
    (def test (& (c))
      (pr "still no way to tell if c was passed")))
  
  (def test (& args)
    (let ((o c)) args
      (pr:if (len> args 0)
        "c was passed"
        "c was not passed")))
  
  (def test (& (&both args (c)))  ; Destructure twice.
    (pr:if (len> args 0)
      "c was passed"
      "c was not passed"))
  
  (def test ((o c nil c-passed))
    (pr:if c-passed
      "c was passed"
      "c was not passed"))
  
  (def test ((o c))
    (pr:if given.c
      "c was passed"
      "c was not passed"))
  
  (def test (c)  ; Parameter lists are just destructuring.
    (pr:if given.c
      "c was passed"
      "c was not passed"))
  
  (def test (&both args (c))
    (pr:if (len> args 0)
      "c was passed"
      "c was not passed"))

  (mac defreq (name args . body)
    `(w/uniq gen
       (def ,name ,(map (fn (x) `(o ,x gen)) args)
         ,@(map (fn (x) `(if (is ,x gen) (err:string "parameter " ',x " is required"))) args)
         ,@body)))

  (defreq foo (x y) (+ x y))
  (foo)     -> x is required
  (foo 1)   -> y is required
  (foo 1 2) -> 3

  (mac defreq (name vars . body)
    (if (isa vars 'cons)
          (let exp (len vars)
            `(def ,name args
               (let giv (len args)
                 (if (< giv ,exp)
                       (err:string "expected " ,exp " arguments (" giv " given)")
                     (apply (fn ,vars ,@body) args)))))
        `(def ,name ,vars ,@body)))


  (defreq foo (x y) (+ x y))
  (foo)     -> error: expected 2 arguments (0 given)
  (foo 1)   -> error: expected 2 arguments (1 given)
  (foo 1 2) -> 3
  
  (defreq foo args args)
  (foo)     -> ()
  (foo 1)   -> (1)
  (foo 1 2) -> (1 2)
  

  (defreq foo (x y . args) (list x y args)) -> error

  (mac require (n (o t))
    `(if (no ,n)                  (err:string "parameter " ',n " is required")
         (and ,t (no:isa ,n ,t))  (err:string "parameter " ',n " must be of type " ,t)))

  (def foo (a b (o c) (o d) . e))  ; works
  (def foo (a b . (c d . e)))      ; works
  

  (def foo (a b ? o d . e))
  
  

  def foo(a, b, c=None, d=None, *e):
      pass
      

  (def foo (a b c=nil d=nil . e))
  

  (def foo (a b (= c nil) (= d nil) . e))

Make all arguments optional, as per evanrmurphy's suggestion. I'll still support the (o foo) form for backwards compatibility, but I think it has so many problems that it really should be avoided.

This isn't final, but I figure the simplicity of not supporting required parameters will be a net gain most of the time. If you really need required parameters, it's possible to write macros that do the checks at run-time. I might even provide such a macro in arc.arc so you don't have to write it yourself.

Also, for telling Arc what the default is (it's normally nil), you use the (= foo 'bar) form, like so:

  (def foo ((o a 1) (o b 2))) ; pgArc
  (def foo ((= a 1) (= b 2))) ; PyArc

  (def foo (a=1 b=2))

  (def baz ((o a) (o b))
    ...)               

  (def baz (& a b)
    ..)

---

+ Technically, it would be:

  (defn baz [& [a b]]
    ..)