Does `call_arg` introduces an unnecessary level of nesting?

[rebcabin]

ASDL:

call_arg = (expr? value)

A conforming instance

((Var 3 x))

Another conforming instance

(())

Why the extra level of nesting?

[certik]

The call_arg can be nil, specifying that the argument is not provided for optional arguments.

[rebcabin]

(expr? value) looks like an ASDL tuple with zero or one expr s in it. So I read the following as valid call_arg s in --show-asr printout

()
(nil)    ;; problematic in Clojure, where () is not nil
((Var 42 i))

[certik]

Almost: the (expr? value) is a tuple with exactly one item in it, always. So () is not allowed. But (()) is as well as ((Var 42 i)).

[rebcabin]

(s/def ::call-arg
  (s/coll-of ::expr?
             :min-count 1   ;; WEIRD
             :max-count 1)) ;; Issue 32

[rebcabin]

does the above

[certik]

The issue is that we need a list of call_arg* in ASDL. If it was just one call_arg, then we would write it as expr? arg, but we can't do expr?* arg, so we instead do call_arg* with call_arg = (expr? value). It's a small workaround.

Regarding Clojure, I don't know how you represent optional values, but I would start with exactly the same approach as in ASDL, so first define call_arg being a tuple of expr? arg, and then create a list of call_arg.

[rebcabin]

I have several approaches to optional values. I've picked one approach: a list containing 0 or 1 items, because that seems to fit some of the printout conventions of --show-asr. There are other approches with tradeoffs that I might try in the future.

[rebcabin]

reopening as documentation reminder as requested by @certik

[rebcabin]

I changed my approach to optional values. I now represent them with s/or and an empty or a non-empty.

This change required getting rid of s/conform in favor of s/valid? because s/or introduces "branch keys" in a conformed instance, and I have to fish out and remove those keys. They're gone now.