I don't have much to add. Your explanation of the type system, such as it is, makes more sense now. Could sit here splitting hairs all day over whether to call it "weakly typed" or "untyped" or whatever other term, but it makes sense at the end of the day when you put it in terms of the (val 0xXX 0xXX) stuff.

Am I right in basically reading that like (val [value] [tag])? And then, the idea is that all operators (not just +) operate on the "value" part of these "value x tag" tuples? Destructive operators preserve the tag, because they're also just operating on the "value" part, but of the same structure. Whereas nondestructive operators need to create a separate (val ...) structure, and don't set the tag. So would

  {'b' 'a' +}

Sorry to ask all these questions that would probably be better answered by me playing with the language myself or looking at the docs. It's an easy---but surely annoying---way to make conversation. Feel free to "RTFM" me. :)

P.S.:

"cloud" computing (scare-quotes because cloud is a particularly obtuse buzzword, IMO).

    (define (tl2)
      (display "arc> ")
      (on-err (lambda (c) 
                (set! last-condition* c)
                (display "Error: ")
                (write (exn-message c))
                (newline)
                (tl2))
        ...))

On a more constructive note, is there some part of your code (or could there be, with some rewriting) where you could specifically catch the exception whose message you want to display nicely? Seems like you could probably work out some way to wrap something like:

    arc> (on-err (fn (c)
                    (pr "Error: ")
                    (prn (details c)))
                 (fn () (err "a \"b\" c")))
    Error: a "b" c

    (mac w/nice-errors exprs
      `(on-err [do (pr "Error: ") (prn (details _))]
               (fn () ,@exprs)))

Side note: paging through your source code, I notice you have a few functions to support to-readable-string. I believe it could be greatly simplified, because write's job is already to print out values in ways that read can parse back in. Thus, save for the single-quote stuff, I think you could boil it all down to tostring:write. Play around with it and see if it's what you want:

    arc> (tostring:write (list 'a "b" (obj c 'd)))
    "(a \"b\" #hash((c . d)))"

Because I'm not satisfied with crappy behavior. It makes readability worse, and debugging harder.

I'll take a look to see if I can catch it better; reading over my code, some of it does seem to be convoluted, if working. I've never quite been happy with how the failure messages are calculated; if that changes, I can easily change how we handle printing the errors.

But there's definitely something busted about this. In anarki:

  arc> (= x "abc")
  arc> (err x)
  Error: "abc"           ; ok, looks good
  arc> (= x 'abc)
  arc> (err x)
  Error: "error: abc"    ; whaa..

  arc> (= x "abc")
  arc> (err x " shouldn't be a string")
  Error: "abc \" shouldn't be a string\""

  Error: "abc" shouldn't be a string

  Error: "\"abc\" shouldn't be a string"

http://docs.racket-lang.org/reference/exns.html#%28def._%28%...

- (error sym) creates a message string by concatenating "error: " with the string form of sym. Use this form sparingly.

- (error msg v ...) creates a message string by concatenating msg with string versions of the vs (as produced by the current error value conversion handler; see error-value->string-handler). A space is inserted before each v. Use this form sparingly, because it does not conform well to Racket’s error message conventions; consider raise-arguments-error, instead.

- (error src frmat v ...) creates a message string equivalent to the string created by

  (format (string-append "~s: " frmat) src v ...)

  >>> map(bool, [False, 0, 0.0, 0L, 0j, "", (), {}, [], set(), frozenset(), None])
  [False, False, False, False, False, False, False, False, False, False, False, False]
  >>> class C1:
  ...     def __len__(self): return 0
  ... 
  >>> class C2:
  ...     def __nonzero__(self): return False
  ... 
  >>> map(bool, [C1(), C2()])
  [False, False]

I dunno. When using Python, I lament that the overloading is too inexplicit. But languages with exact boolean types feel too restrictive. (Such is the curse of using multiple languages: while programming in X I want to selectively cherry-pick features from !X.) I make it by fine in Python, though. It can certainly help with code golf, but often it just makes me paranoid about my if conditions.

Usually I find myself leaning towards the "one universal false value, everything else is true" camp, just because it's highly predictable yet flexible. With distinct boolean types, you have the consistency/predictability, but not so much flexibility. In Arc (and similar), there happens to be the falsehood-creep into the empty list. I'm not sure I really like that, because it isn't maximally consistent: why aren't other empty sequences false, too? Just do away with the question by having a canonical false value all its own. Then you still get some of the code-golf benefits of having everything else be true.

I like the idea of the main (if ...) semanics being just another equality check or dynamic type check: "Is this nil?" If falsiness overlaps with multiple other dynamic types, then we end up having confusing crosshatching where one extension wants to do X with any falsy value and another extension wants to do Y with any list.

  (a < b < c)
  => (< (< a b) c)   ; watch out if b is nil

  (< nil x)          ; should always return nil

a) There's still no boolean type. The type of false is symbol. (The type of nil has always been nil; maybe I'll now make it list.)

b) if treats both nil and false as false-y values.

c) nil and false are not equal.

d) Comparison operators now short-circuit on false BUT NOT nil.

I can mostly use either in place of the other. But I'm trying to be disciplined about returning false from predicates and nil from functions returning lists.

Wart now has four hard-coded symbols: nil, object, caller_scope and false.[1]

Thoughts? It was surprisingly painless to make all my tests pass. Can anybody think of bugs with this kinda-unconventional framework? If you want to try it out:

  $ git clone http://github.com/akkartik/wart
  # Optionally "git checkout 0ff47b6bce" if I later revert this experiment.
  $ cd wart
  $ ./wart
  ready! type in an expression, then hit enter twice. ctrl-d exits.

  let foo fn (foo () 34)
  => (object function {sig, body})

  $ time ./wart
  ready! type in an expression, then hit enter twice. ctrl-d exits.
  => nil

  real    0m29.200s
  user    0m27.602s
  sys     0m0.000s

  (if t 'hi 'bye)
  020lookup.cc:28 no binding for t
  => bye

  (<- t 't)
  => t
  (if t 'hi 'bye)
  => hi

Once I got the landscape laid out in my head, I started objecting to it less, because I could make sense of it. You're most of the way there:

- false is a separate, canonical false value.

- t (if you chose to have it) is a separate, canonical truth value.

- nil is an empty list, but empty lists are false.

Compare to Python's True, False, and []. The major differences being:

1. No first class boolean type. In wart, this produces more of a disconnect between t and false. t (i.e., 't) is just a normal symbol whose truth value is incidental. But false is a special, unassignable keyword.

  (<- false 'hi)
  => hi
  false
  => false

  >>> False < 10
  True
  >>> 867 + True
  868
  >>> isinstance(True, int)
  True
  >>> isinstance(0, bool)
  False
  >>> True, False = 0, 1
  >>> if True: print "hi"
  ...
  >>> if False: print "hi"
  ...
  hi

I hadn't realized how close to python I've gotten. Seems right given how the whitespace and keyword args are inspired by it. On rosetta code I found a cheap way to get syntax highlighting was to tag my wart snippets with lang python :)

I've been using 1 as the default truth value, and it's not assignable either. I was trying to avoid an extra hard-coded symbol, but now that I've added false perhaps I should also add true.. I'm not averse to going whole-hog on a boolean type, I'd just like to see a concrete use case that would benefit from them. pos seems a reasonable case for keeping 0 truth-y, and the fact that lists include the empty list seems a reasonable case so far to keep nil false-y. But you're right, I might yet make empty strings and tables false-y.

While I personally like 0 being truthy, I don't see this as a convincing reason.

I'd treat 'pos exactly the same way as 'find. They're even conceptually similar, one finding the key and the other finding the value. For 'find, the value we find might be falsy, so truthiness isn't enough to distinguish success from failure. The same might as well be true for 'pos.

---

"But you're right, I might yet make empty strings and tables false-y."

What if the table is mutable? That's an interesting can of worms. :)

JavaScript has 7 falsy values, all of which are immutable. If we know something's always falsy, we also know it encodes a maximum of ~2.8 bits of information--and usually much less than that. It takes unusual effort to design a program that uses all 7 of those values as distinct cases of a single variable.

This means if we have a variant of Arc's (and ...) or (all ...) that short-circuits when it finds a truthy value, we don't usually have to worry about skipping over valuable information in the falsy values.

If every mutable table is falsy as long as it's empty, then a falsy value can encode some valuable information that a practical program would care about, namely the reference to a particular mutable table.

---

"(True, False = 0, 1 :( That's the ugliest thing I've ever seen python allow. At least throw a warning, python! Better no booleans than this monstrosity.)"

There's some rationale here:

http://www.python.org/dev/peps/pep-0285/

http://docs.python.org/2/whatsnew/2.3.html

http://www.python.org/download/releases/2.2.1/NEWS

The PEP describes the design and rationale of introducing booleans to Python this way. Version 2.3 implements this. Version 2.2.1 preemptively implements bool(), True, and False to simplify backporting from 2.3.

Notably, the variable names "True" and "False" were chosen to be similar to the variable name "None", and all three of these are just variables, not reserved words.

Later, version 2.4 made it an error to assign to None:

http://docs.python.org/2/whatsnew/2.4.html

  (aif (mem f seq)
    <operate on car.it>)

  (aif (pos f seq)
    <operate on seq.it>)

I think the error is that None, False and True were ever 'constants' rather than literals.

http://python-history.blogspot.com/2013/11/story-of-none-tru...

Speaking of which, why are you making false and nil count as symbols at all?

  $ wart
  g++ -O3 -Wall -Wextra -fno-strict-aliasing boot.cc -o wart_bin        # (takes ~15 seconds)
  starting up...       (takes ~15 seconds)
  ready! type in an expression, then hit enter twice. ctrl-d exits.

  ; Won't work on nil, whatever.  Just a case in point.

  (def my-push (x addr)
    (let old-car (car addr)
      (scar addr x)
      (scdr addr (cons old-car (cdr addr)))
      addr))

  arc> (= xs (= ys '(1 2 3)))
  (1 2 3)
  arc> (my-push 4 ys)
  (4 1 2 3)
  arc> ys
  (4 1 2 3)
  arc> xs
  (4 1 2 3)

  ; versus

  arc> (= xs (= ys '(1 2 3)))
  (1 2 3)
  arc> (push 4 ys)
  (4 1 2 3)
  arc> ys
  (4 1 2 3)
  arc> xs
  (1 2 3)

Yeah, it's an interesting problem. One that I should probably understand better... I mean, I "get" it: the RAM machine model is simple. But I've not programmed enough C (or similar) to understand how far the semantics would permeate day-to-day programs.

There's the part of me that's like "oh, just have primitives to reference & dereference addresses; easy". I seem to recall Lisps that use something like (ref x) and (deref x), and the explicitness pleases me, coming from "modern" languages where you have to remember odd rules about whether/where things are passed as pointers. But then I read C code and see all these pointers-to-pointers all over the place---in spots of code where I normally wouldn't think of pointers at all. Then again, that might be endemic to C, where you're probably just being destructive by default.

What do you mean by this? Something like the following?

  arc> (-> 1 2 /)
  2

  (mac -> (x . rest)
    (if (no rest)
        x
        (let (expr . more) rest
          (if more         `(-> (-> ,x ,expr) ,@more)
              (acons expr) `(,(car expr) ,x ,@(cdr expr))
                           (list expr x)))))

  arc> (macex '(-> 1 2 (fn (x y) (/ x y))))
  (fn (-> 1 2) (x y) (/ x y))

I like the simplicity of something like this:

  (mac -> exprs
    (reduce (fn (l r) (list r l)) exprs))

Maybe this?

  (def -> exprs
    (reduce (fn (l r)
              (let ls (check l alist (list l))
                (if (~isa r 'fn) ; but what about callable objs?
                    (cons r ls)
                    (apply r ls))))
            exprs))

  arc> (def flip (f) (fn (y x) (f x y)))
  #<procedure: flip>
  arc> (-> 1 2 + [fn (x) (+ x _)] '(1 2 3) (flip map))
  (4 5 6)

Here's the current varargs version of -> in wart:

  mac (transform x ... fs|thru)
    if no.fs
      x
      `(transform (,x -> ,car.fs) ,@cdr.fs)

  (transform 3 :thru (fn(_) (_ * 2))
                     (fn(_) (_ + 1)))

  (transform 1 2 :thru (fn(a b) (a * b))
                       (fn(_) (_ + 1)))

  (transform 1*2 :thru (fn(_) (_ + 1)))

        *[s [5 0 1]]
  i.e., *[s [5 [0 1]]]  -- because [a b c] == [a [b c]]
  i.e., *[s 5 [0 1]]    -- because [a [b c]] == [a b c]
     => ^*[s [0 1]]     -- by *[a 5 b] => ^*[a b]
  i.e., ^*[s 0 1]       -- because [a [b c]] == [a b c]
     => ^/[1 s]         -- by *[a 0 b] => /[b a]
     => ^s              -- by /[1 a] => a
     => (s + 1)         -- by ^a => (a + 1)

Good work! Looks like you have all the angles covered in your point-by-point breakdown at the end, and evaluating is really all the CL version is doing too. Honestly, the biggest "gotcha" for me is point 2, but you neatly deal with that. The tradeoff is totally worth it for having on-line "redefinition" of the macros you're testing. Just make sure 2 is documented as a caveat, and you're good to go.

               -- (bottom) n
               --          ^

   <-          -- (bottom) n
               -- ^^^^^^^^

   { '*' << }  -- (bottom) { '*" << } n
               --          ^^^^^^^^^^

   ->          -- (bottom) { '*' << } n
               --                     ^

   times

               -- (bottom) a b c
               --              ^

  <-           -- (bottom) a b c
               --            ^

  <-           -- (bottom) a b c
               --          ^

  operate_on_a -- (bottom) whatever operate_on_a produces b c
               --                                ^^^^^^^^

  ->           -- (bottom) whatever operate_on_a produces b c
               --                                         ^

Also, it seems to me the language isn't really "typeless"; rather, the programs aren't generally type-directed. The system appears similar to Arc's, where you have a few already-used type tags (string, int, num), but in principle the tags are arbitrary. I suppose one distinction could be the treatment of the data under certain operations: Bipedal has syntax for strings and integers, but what happens when you call + on a string and an integer? Is it just treated like adding the string's address with the integer, perhaps?

  (~all t (map dead threads))

  (~all dead threads)

  (while (~all dead threads)
    (sleep 1))

  (until (all dead threads)
    (sleep 1))