Hm. I didn't realize my name was Gabriel Scherer and I had already made a comment.

  (def my-len (lst)
    
    ; Introduce a local variable `n'.
    (let n 0
      
      (each element lst
        
        ; Modify that variable.
        (= n (+ 1 n)))
      
      n))

---

"Is there a deeper reason for these irregularities, or is it just convenience?"

The syntax of languages like Arc, Lisp and Scheme is actually a bit more irregular than it looks: The code (a b c) usually means to do a function call, but this isn't true if "a" is the name of a special form or a macro. Special forms are how the language provides structured syntaxes other than function calls. Macros are user-defined special-form-like syntaxes that specify a way to translate ("macroexpand") their syntax into some already-supported code.

In Arc, both '= and 'def are macros provided with the language. They act as shorthand for using Arc's 'assign special form.

Kernel is a different kind of language. It goes back to lisp's roots a little, and lets users define syntaxes based on a way to interpret them at run time. Since the user can write their interpretation code however they want to, it's challenging to predict what these programs will do until they execute, which is why nobody (I think) has managed to write a good optimizing compiler for Kernel.

---

"Why are lists compared via `iso' but strings are compared via `is'?"

This is a very irregular part of Arc. You can compare lists using either operator, but 'iso does a deep comparison and 'is compares by reference. However, 'is actually special-cases strings and compares them by their contents, just like 'iso.

I think this choice was made because strings aren't usually modified. Arc lets you mutate a string if you really want to, but it's not a very commonly used feature.

---

"Is it because strings are a symbol but lists aren't?"

Technically, string and symbol are separate data types.

Technically, the empty list (nil) is a symbol. :)

Even if you choose to quote names in definers, you still need some irregularity in evaluation policies to build short-circuiting or/and.

(2) Arc is built on racket, and strings in racket (and other schemes?) are interned and so fast to compare just by their address. Lisp choose not to intern strings.

I tend to avoid these complexities and just use 'iso' everywhere. (My language has only an equivalent of iso: https://github.com/akkartik/wart/blob/955497c1ca/045check.wa...)

I'm honored! (And I didn't even have to sign up for GitHub!) How'd you find your way over to this forum?

You're absolutely right in that I've glossed over quite a few details, and clearly I've screwed up in some ways that were immediately obvious to you :P

If it seems like I found it immediately obvious, it's only because I took a long time writing & discovering these thoughts before committing them to one big post. :)

yes, this is exactly the point. The idea is that if you're giving it a name, that actually means something pretty significant, much more than just a way to access some specific bit of RAM with a bunch of ascii characters as reference.

I would like to have the short forms from my examples in ObjC though.. writing "x:x y:y width:width height:height" is actually something that happens quite a bit ^_-

  arc> 'the-basic-purpose-of-quote-is-to-prevent-a-symbol-from-being-evaluated
  the-basic-purpose-of-quote-is-to-prevent-a-symbol-from-being-evaluated
  arc> '(quote can be used on any expression --- including a list)
  (quote can be used on any expression --- including a list)
  arc> (list 'you 'can 'think 'of ''(a b c) 'as 'shorthand 'for '(list 'a 'b 'c))
  (you can think of (quote (a b c)) as shorthand for (list (quote a) (quote b) (quote c)))
  arc> `quasiquote-is-pretty-much-just-like-quote
  quasiquote-is-pretty-much-just-like-quote
  arc> (list 'so '`(a b c) 'is 'like '(list 'a 'b 'c))
  (so (quasiquote (a b c)) is like (list (quote a) (quote b) (quote c)))
  arc> `(but suppose you want to write (list 'a 'b c) --- where the last element has no quote)
  (but suppose you want to write (list (quote a) (quote b) c) --- where the last element has no quote)
  arc> `(then quasiquote gives you a shorthand by using "unquote")
  (then quasiquote gives you a shorthand by using "unquote")
  arc> `(so `(a b ,c) is like (list 'a 'b c) and `(a ,b c) is like (list 'a b 'c) etc)
  (so (quasiquote (a b (unquote c))) is like (list (quote a) (quote b) c) and (quasiquote (a (unquote b) c)) is like (list (quote a) b (quote c)) etc)
  arc> `(thus this list will have 4 instead of (+ 2 2) right here: ,(+ 2 2))
  (thus this list will have 4 instead of (+ 2 2) right here: 4)
  arc> `(because `(a b ,(+ 2 2)) is like (list 'a 'b (+ 2 2)))
  (because (quasiquote (a b (unquote (+ 2 2)))) is like (list (quote a) (quote b) (+ 2 2)))
  arc> (list 'see? 'a 'b (+ 2 2))
  (see? a b 4)
  arc> 'voila
  voila

  arc> (each x '(1 2 3)
         (prn "\"each\" is used for side-effects on the variable x = " x)
         (prn "but ultimately, it will return nil")
         (prn "we can call pure functions on x")
         (+ x 1)
         (prn "but we won't see anything they return")
         x
         (* x 12)
         (when (is x 3)
           (prn "witness: the next line is the return value of \"each\"!")))
  "each" is used for side-effects on the variable x = 1
  but ultimately, it will return nil
  we can call pure functions on x
  but we won't see anything they return
  "each" is used for side-effects on the variable x = 2
  but ultimately, it will return nil
  we can call pure functions on x
  but we won't see anything they return
  "each" is used for side-effects on the variable x = 3
  but ultimately, it will return nil
  we can call pure functions on x
  but we won't see anything they return
  witness: the next line is the return value of "each"!
  nil

  (each x xs
    (do-something x)
    (do-something-else x))

  ((rfn loop-around (elements)
     (when (acons elements)
       (let x (car elements)
         (do-something x)
         (do-something-else x))
       (loop-around (cdr elements))))
   xs)

Thus,

  arc> `(if I "unquote" (each x '(1 2 3) x) into this list I just get ,(each x '(1 2 3) x))
  (if I "unquote" (each x (quote (1 2 3)) x) into this list I just get nil)

  arc> (map (fn (x) (+ x 1)) '(1 2 3))
  (2 3 4)
  arc> `(if I "unquote" (map [* _ 12] '(1 2 3)) into this list I get ,(map [* _ 12] '(1 2 3)))
  (if I "unquote" (map (fn (_) (* _ 12)) (quote (1 2 3))) into this list I get (12 24 36))

  (mac css (sel props . nest)
    `(do ,(pr (string sel "{"))
      ,(gen-css-properties props)
      ,(map [gen-nested-css _ sel props] nest)))

  arc> (let macro-expansion (macex1 '(css "#foo" (id 5) (".bar" (z-index 2))))
         (prn)
         (ppr macro-expansion)
         (prn))
  #foo{
  (do "#foo{"
      (do (if 5 (pr "id:" 5 ";"))
          (pr "}"))
      ((css "#foo .bar"
            (id 5 z-index 2)
            nil)))
  nil

  arc> ((+ 2 2))
  Error: "Function call on inappropriate object 4 ()"

  arc> (+ 2 2)
  4

  arc> `(symbols wrapped in parens because of unquote: ,'(a b c))
  (symbols wrapped in parens because of unquote: (a b c))
  arc> `(symbols without parens because of unquote-splicing: ,@'(a b c))
  (symbols without parens because of unquote-splicing: a b c)

  (mac css (sel props . nest)
    `(do ,(pr (string sel "{"))
      ,(gen-css-properties props)
      ,@(map [gen-nested-css _ sel props] nest)))

  arc> (let macro-expansion (macex1 '(css "#foo" (id 5) (".bar" (z-index 2))))
         (prn)
         (ppr macro-expansion)
         (prn))
  #foo{
  (do "#foo{"
      (do (if 5 (pr "id:" 5 ";"))
          (pr "}"))
      (css "#foo .bar"
           (id 5 z-index 2)
           nil))
  nil

Recommendation: with these points (I hope) cleared up, look closer at html.arc. If you had modeled your code after it more precisely, you probably wouldn't have had these issues. But hey, that's how we learn.

"functions will not be called unless the calls within do not fail, so"

  if y < (x | 5) then write("y=", y)

  write("y=", (x | 5) > y)

I'd also somehow missed that it had the infix-chaining idea long before wart:

"the < operator returns its second argument if it succeeds, allowing things like a < b < c" https://en.wikipedia.org/wiki/Icon_%28programming_language%2...

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.

About the nil problem, maybe we should nil terminate list this way: (1 2 nil), instead of (1 2 . nil). just a joke. :)

Thanks for the analysis!

You're absolutely right in that I've glossed over quite a few details, and clearly I've screwed up in some ways that were immediately obvious to you :P

I guess the first thing I'd have to introduce for the whole issue of basic operations destroying the entire system is to introduce something like:

    def _foo:+(_foo:n, _foo:m):
        ...

Then we have:

  hello = "hi, "
  world = "planet"

  hello_world = hello + world     # error, since join(hello, world) = top

  # and yet...

  hello_world = "hi, " + "planet" # not an error: join(bottom, bottom) = bottom

I don't know how it'd scale but I imagine that many users of such a theoretical system would find it really annoying to write in the beginning without good tooling (kind of like Java with all those getters and setters :P). I do believe though that this is also the case in Objective-C and that in ObjC this tradeoff is appreciated later when maintaining big code bases. Maybe my rather draconian idea is unfeasible because of this reason alone!

Yeah, I agree with this. I weakly think (without evidence) that arc's destructive ops are more functional, and it encourages a better style to not constantly make assumptions about precisely which cons cells go where.

On the other hand, a set of 'alias-friendly' functions could coexist with the existing primitives.

  arc> (= y (= x '(1 3 5)))
  (1 3 5)
  arc> (insort < 2 x)
  (1 2 3 5)
  arc> x
  (1 2 3 5)
  arc> y
  (1 2 3 5)
  arc> (insort < 0 x)
  (0 1 2 3 5)
  arc> x
  (0 1 2 3 5)
  arc> y
  (0 1 2 3 5)
  arc> (insort < 6 x)
  (0 1 2 3 5 6)
  arc> x
  (0 1 2 3 5 6)
  arc> y
  (0 1 2 3 5 6)
  arc> (= y (= x nil))
  nil
  arc> (insort < 1 x)
  nil
  arc> x
  nil
  arc> y
  nil

  (def destructive-cons (elt seq)
    ; Note: (push elt seq) won't work, because push is a macro on the "place",
    ; and seq isn't the proper "place" to mutate (push will just mutate the local
    ; binding of seq).  This function will actually mutate the cons cell being
    ; pointed at by seq.
    (let (first . rest) seq
      (scar seq elt)
      (scdr seq (cons first rest)))
    seq)

  (def insorter (test elt seq)
    (if (no seq)
         (list elt)
        (test elt (car seq))
         (destructive-cons elt seq)
        (do1 seq
             ((afn (prev cell)
                (if (or (no cell) (test elt (car cell)))
                    (scdr prev (cons elt cell))
                    (self cell (cdr cell))))
              seq (cdr seq)))))

  (mac insorted (test elt seq)
    `(zap [insorter ,test ,elt _] ,seq))

  arc> (= y (= x '(1 3 5)))
  (1 3 5)
  arc> (insorted < 2 x)
  (1 2 3 5)
  arc> x
  (1 2 3 5)
  arc> y
  (1 2 3 5)
  arc> (insorted < 0 x)
  (0 1 2 3 5)
  arc> x
  (0 1 2 3 5)
  arc> y
  (0 1 2 3 5)
  arc> (insorted < 6 x)
  (0 1 2 3 5 6)
  arc> x
  (0 1 2 3 5 6)
  arc> y
  (0 1 2 3 5 6)
  arc> (= y (= x nil))
  nil
  arc> (insorted < 1 x)
  (1)
  arc> x
  (1)
  arc> y
  nil

  arc> (= x nil)
  nil
  arc> (scar x 1)
  Error: "set-car!: expected argument of type <pair>; given nil"
  arc> (scdr x '(2))
  Error: "set-cdr!: expected argument of type <pair>; given nil"

  arc> (= y (= x '(a b c)))
  (a b c)
  arc> (= z (= w '(1 2 3)))
  (1 2 3)
  arc> (swap x w)
  (a b c)
  arc> x
  (1 2 3)
  arc> y
  (a b c)
  arc> z
  (1 2 3)
  arc> w
  (a b c)

But your code only make first cell of x to be destructive.

  (let insorted (insert-sorted < 2 x)
         (scar x (car insorted))
         (scdr x (cdr insorted)))

I think insort should modify the list, not merely assign a new list.

Some demo code:

  (def insort1 (test elt seq)
    (if (no seq)
         (list elt)
        (test elt (car seq))
         (with (first (car seq) rest (cdr seq))
          (scar seq elt)
          (scdr seq (cons first rest)))
        (no (cdr seq))
          (scdr seq (list elt))
        (insort1 test elt (cdr seq))))
  
  (mac insort (test elt seq)
    `(do (insort1 ,test ,elt ,seq) ,seq))

You're right in thinking that x and y share the same reference, like

  y -.
      \
  x ---+--> [ * | * ]
              |   |
              1   `--> [ * | * ]
                         |   |
                         3   `--> [ * | * ]
                                    |   |
                                    5   `--> nil

  arc> (= y (= x '(1 3 5)))
  (1 3 5)
  arc> x
  (1 3 5)
  arc> y
  (1 3 5)
  arc> (macex '(= (car x) 2)) ; '= expands into a form that uses 'scar
  ((fn () (atwith (gs1731 x gs1732 2) ((fn (val) (scar gs1731 val)) gs1732))))
  arc> (= (car x) 2)
  2
  arc> x
  (2 3 5)
  arc> y
  (2 3 5)

  arc> (= y (= x '(1 3 5)))
  (1 3 5)
  arc> (macex '(insort < 2 x))
  (atomic-invoke
    (fn ()
      (withs (gs1736 x
              gs1735 [insert-sorted < 2 _])
        ((fn (gs1737) (assign x gs1737))
         (gs1735 gs1736)))))

  (def insert-sorted (test elt seq)
    (if (no seq)
         (list elt) 
        (test elt (car seq)) 
         (cons elt seq)
        (cons (car seq) (insert-sorted test elt (cdr seq)))))

  y -.
      \
  x    `--> [ * | * ]
  |           |   |
  |           1   `--> [ * | * ]
  |                      |   |
  |                      3   `--> [ * | * ]
  |                                 |   |
  |                                 5   `--> nil
  `-------> [ * | * ]
              |   |
              1   `--> [ * | * ]
                         |   |
                         2   `--> [ * | * ]
                                    |   |
                                    3   `--> [ * | * ]
                                               |   |
                                               5   `--> nil

  arc> (= y (= x '(1 3 5)))
  (1 3 5)
  arc> (let insorted (insert-sorted < 2 x)
         (scar x (car insorted))
         (scdr x (cdr insorted)))
  (2 3 5)
  arc> x
  (1 2 3 5)
  arc> y
  (1 2 3 5)

  y -.        1
      \        
  x ---+--> [ * | * ]
             /     \
            /       \        [ * | * ]
           /         \         |   |
          /           \        3   `--> [ * | * ]
         /             \                  |   |
        /               |                 5   `--> nil
        |   [ * | * ]   |
        |     |   |     |
        `---> 1   `-----+---> [ * | * ]
                                |   |
                                2   `--> [ * | * ]
                                           |   |
                                           3   `--> [ * | * ]
                                                      |   |
                                                      5   `--> nil

On line 5, he mentions that hours_to_minutes has its return value named minutes. And I can see how time.minutes would be "named" minutes. But he's really baking a lot of tacit semantics into the + operator that aren't actually obvious...

In a Python-like language, there's a distinction between the built-in "plus" statement and a "plus" function. Since + isn't a function, I'm assuming the "return value" doesn't need its own name. However, he's clearly under the impression that the expression "inherits" the names of its arguments somehow. But exactly how is unclear.

Variables obviously have names (name(var) = var). But what are the names of literals? Presumably it's kind of just "no name" (the _ wildcard he mentions?), so no errors arise from something like

  any_way_you_want_it = "that's the way" + " " + "you need it"

What about mixing literals with named values in expressions? The result of an expression seems to take on the name of the named operands, as in his example where minutes needs the <- annotation:

  minutes<-hours = hours * 60

  join(bottom, bottom) = bottom
  join(name, bottom)   = name
  join(bottom, name)   = name
  join(name, name)     = name
  join(name1, name2)   = top     (where name1 != name2)
  join(top, _)         = top
  join(_, top)         = top

  hello = "hi, "
  world = "planet"

  hello_world = hello + world     # error, since join(hello, world) = top

  # and yet...

  hello_world = "hi, " + "planet" # not an error: join(bottom, bottom) = bottom

Could we coerce the name of hello_world to allow the mixing of hello and world? The <- notation seems unsuitable, because it only allows the renaming of a single name, as in the minutes<-hours example. Unless maybe you use a wildcard to switch off...well, really the whole strong-naming system, I guess:

  hello_world<-_ = hello + world

At any rate, traditional copy propagation certainly becomes a nightmare. Of course, this is probably deemed a worthwhile trade-off in such a strong-naming system.

On another note, I think there's an error of omission. While he addresses the input parameters whose names you don't care about, what about functions that have no meaningful name for their return values? I think it would be appropriate to have something like

  def _:reciprocal(_:n):
      return 1.0 / n

It's weird though, because it further increases the distance between syntactic expressions and user-defined functions. If + were a function, it'd be one of those declared with a _ return name, because there's no meaningful way to predict the names of what you'll be adding. You'd have something like

  def _:+(_:n, _:m):
      while n > 0:
          n = n - 1
          m = succ(m) # primitive "plus one" function...again, a _ return name
      return m

  minutes = hours_to_minutes(time.hours) + time.minutes

  ha_the_return_value_is_unnamed = +(time.hours * 60, time.minutes)

I dunno. I'm thinking the strong-naming system happens to work well for his example just because his example has variables named after units. I'm skeptical about how well the system would scale to other code bases. Good names are important, yes, but building a type system around them? Plus, it kind of puts names on a pedestal, which I think encourages mutation, which is runs somewhat counter to my normal mode of thinking.

  arc> (insort < 2 x)
  (1 2 3 5)
  arc> x
  (1 2 3 5)

The real confusion is that y and x are not aliases. They just happen to be bound to the same value (cons cell) at the start. A destructive change to one doesn't affect the other.

Or, put another way, 'destructive' doesn't mean the original list is guaranteed to be destroyed. Just that it _can_ be modified. It would be destroyed if nothing else was using it and it got garbage-collected. The GC is the only entity actually doing destruction.