(define (ac-call fn args env)
      (let ((macfn (ac-macro? fn)))
  -     (cond (macfn
  +     (cond ((and macfn (not (lex? fn env)))
               (ac-mac-call macfn args env))
  --ac.scm

(See also: http://arclanguage.org/item?id=13581 and http://arclanguage.org/item?id=11685. I learned this from the latter thread.)

Edit: It is probably a hard problem to diagnose if you just leave it there and someone uses it and is like "why is this screwing up?". So if you intend for others to use it, you could put in a thing like this:

  (mac achtung (x) `(+ ,x 2))
  (let achtung [+ _ 5]
    (unless (is (achtung 0) 5)
      (err "Oh god you have a bad Arc compiler.  Fix that crap:
            http://arclanguage.org/item?id=13606")))

I'm all too happy to do that. ^_^ Note that it'll probably mean I've introduced bugs to Rainbow and Jarc. :-p

Part of the reason I've harped on the state of affairs that causes me to write (do x), as well as the reason the state of affairs isn't altogether bad (that it makes macros that generate macro forms a tiny bit less susceptible to variable capture), has been in the hope that people will become confident that it's really annoying. ^^;

I honestly didn't know I'd be the only one actively defending it (rather than merely leaving things the way they are or upvoting), so I continued to give it the benefit of the doubt. Let's not do that. :)

> it probably won't even cause problems most of the time, because it's kind of a rare case

Actually, I use local variable names that clash with macros all the time, and that's why I started my (do x) and (call x) patterns in the first place. :) If I remove the cruft right away, my code will almost certainly break until everyone has upgraded. Dunno if anyone but me is going to suffer from my (published) code breaking, but hey. :-p

---

(I ended up moving the check for lexical variables into the extension to ac-call to simplify macex).

However, this raises an interesting issue.

setforms calls macex which calls ac-macro?.

So do we still have the same bug with set expressions?

  (= foo (table) bar (table) baz (table) qux (table)
     quux (list nil nil))
  (mac get1 (x) `(,x 1))
  (let ref bar (= (ref foo) 2))
  (let get idfn (= ((get baz) qux) 3))
  (let cadr car (= (cadr quux) 4))

It's not as big a problem as it may seem. You don't have to worry about future macros shadowing lexical bindings as long as they load afterwards.

The biggest compromise I've had to make because of this: using call-fn (which doesn't expand macros) in accumulate (https://github.com/akkartik/wart/blob/ed9a7d4da1fa017188fce2...) because I wanted to name one of the keyword args unless. So you seem to be watching over your creation after it's left the nest :)

(tangent)

I spent an embarrassingly long time trying to have lexical bindings override macros, before realizing that's impossible in wart: macros get expanded long before lexical bindings are created. So this is a case where you really need a full interpreter; any macro you write can't inspect lexical bindings up the call stack. (oh, for python's nested namespaces..)

(even bigger tangent)

Wart update: arc.arc is just about done. I'm going to start on the webserver, probably not srv.arc but palsecam's http.arc (http://www.arclanguage.org/item?id=11337).

Hmm... I'm totally guessing, but this might do the trick:

  -(defmacro call(f &rest args)
  +(defmacro call(f &rest args &environment env)
     (cond
  -    ((macp f)   `(,f ,@args))
  +    ((and (symbolp f) (macro-function f env))   `(,f ,@args))
       ((compose-form-p f)   (expand-composition f args))
       (t  `(call-fn (fslot ,f) ,@args))))

But it doesn't seem to quite work:

  $ sbcl
  * (macro-function 'unless)
  #<FUNCTION (MACRO-FUNCTION UNLESS) {1000ADDAB9}>
  * (macro-function 'foo)
  NIL
  * (let ((unless 34)) (macro-function 'unless))
  #<FUNCTION (MACRO-FUNCTION UNLESS) {1000ADDAB9}>
  * (defmacro macp(x &environment env) (macro-function x env))
  MACP
  * (let ((unless 34)) (macp unless))
  #<FUNCTION (MACRO-FUNCTION UNLESS) {1000ADDAB9}>
  * (let ((unless 34)) (macp foo))
  NIL

  (macrolet ((unless() nil)) (macp unless))  ; should be truthy
  (flet ((unless() nil)) (macp unless))      ; should be falsy

I have a macro called call. Given (call f arg), I would like to return:

if f is a local lambda, (call-fn f arg)

if f is a macro, (f arg)

otherwise, (call-fn f arg)

  f.arg -> (call f arg)
  f@arg -> (f arg)

Ok, I started reading wart. :)

(b) can be easily handled in other ways (e.g. in CL, you say "&rest args" instead of ". args").

(a) is extremely rare, and it's never necessary in code--you could replace it with (cons 1 2). There is the fact that, inside the body of a function, (cons 1 2) will create a new cons cell every time the function is called, whereas '(1 . 2) will always refer to the same cons cell[1]; however, you could fix this by wrapping it in (let u (cons 1 2) ...) and referring to u instead of '(1 . 2).

The only potential problem I see (with dropping dotted lists) is that you might need to read (or print) dotted s-expressions as data. That does come up now and then; you might represent some compound data structure (like a rational number) with a cons cell, which is slightly more efficient than using a two-element list (two cons cells) and perhaps nicer. Also, Racket prints hash tables with dots--I'm sure you routinely see things like #hash((a . 1) (b . 2)). And someone might create some kind of tree structure with conses.

You could dotted lists for now, then, when you find them necessary, create a private notation for non-proper-list trees (say, using ^ in place of . in trees). Then there would be no problem except dealing with tree output from other Lisp implementations, which is rare enough that you can probably afford to ignore it for now, and if it comes up, just write something to translate back and forth. That would be my advice.

As for unquote-splicing: Most of the time I use it in macro definitions, most of the time for "body" arguments. Here is a handy terminal command to illustrate:

  $ egrep -o ',@[^ )]+' a | sort | uniq -c
     2 ,@(apply
     1 ,@(explode
     1 ,@(flat1
     2 ,@(if
     5 ,@(map
     1 ,@(mappend
     5 ,@args
     1 ,@binds
    16 ,@body
     1 ,@indices
     1 ,@leads.expr
     2 ,@vars

[1] For example:

  arc> (def meh (x) '(1 . 2))
  #<procedure: meh>
  arc> (meh 2)
  (1 . 2)
  arc> (= (car (meh 2)) 5)
  5
  arc> (meh 3)
  (5 . 2)
  arc> (def uch (x) (cons 1 2))
  #<procedure: uch>
  arc> (= (car (uch 2)) 5)
  5
  arc> (uch 3)
  (1 . 2)

Lathe already defines (= global.x desired-value) so that it behaves just like (eval `(= ,x (',(fn () desired-value)))). As an everyday expression, global.x behaves like (bound&eval x), which makes (zap _ global.x) a bit more intuitive. This utility works on Arc 3.1, Anarki, Rainbow, and Jarc.

Finally, it's easier to see "symbol-value" written in the language description and use it than to figure out how to use the 'eval method properly. Just look at how complex your definition is; even I, who do see why it's necessary to go ',desired-value instead of ,desired-value in my version [if objs in code worked properly, you could use the former version for a while without noticing it was wrong], I don't see why it's necessary to go (',(fn () desired-value)), and I certainly wouldn't think of it myself. (I still don't believe it's actually necessary, but I won't press the point.) Like the case of (++ (car (pop xs))), this is one of the things a core language is good for: the implementor has considered and avoided all the subtle pitfalls for you. (Actually, implementing it as a primitive with the "namespace-..." functions, there aren't any pitfalls to avoid.)

By the way, I don't know if the core of the language is supposed to be all that axiomatic. It should be clean, certainly, but by its nature it should provide more than minimal axioms. In an essay[1], Paul Graham talks about "the core language—those operators that are neither primitives like car and cdr, nor special-purpose library functions. I mean operators like CL's mapcar, let, remove-if-not, and so on."

At any rate, here's what I think: (a) There will be people who need the equivalents of 'symbol-value and (setf symbol-value)--people who write module libraries or debugging facilities or for whatever reason[2] want to determine names at runtime. (b) This might be enough by itself to warrant placement in the core language, but (c) it is extremely easy, not to mention efficient, to implement these as primitives, while it is subtle, error-prone, and inefficient to implement it with 'eval. Therefore, it should be built into the language. (Technically, if it's a primitive, then it's not part of the core language by the implicit definition from the essay, but whatever you call it, it should be built in.)

I feel better about rambling/ranting when I also produce something tangible, like working code. So, here you go:

  (def symbol-value (x)
    ($.namespace-variable-value $.ac-global-name.x))
  
  (defset symbol-value (x)
    (w/uniq g
      (list `(,g ,x)
            `(symbol-value ,x)
            `(fn (val) (($ namespace-set-variable-value!)
                        ($.ac-global-name ,x)
                        val)
               val))))

[2] I once did the following in a chess program:

  (each p '(r k n)
    (each a '(a b c d e f g h)
      (each n '(1 2 3 4 5 6 7 8)
        (setf (symbol-function (symb p a n))
              (fn () ...)))))

That's why it's in Lathe, too. ^_^ Since it's there to implement the module system, it's one of only a couple dozen Lathe utilities that isn't in a module, but I find it useful enough that I like it that way.

I don't see why it's necessary to go (',(fn () desired-value))

If you embed a literal vector in an expression (for instance, a tagged value), Racket will evaluate that expression as a copy of the vector. So (let foo (annotate 'a 'b) (= global!x foo) (is global!x foo)) would return nil, which I find frustrating. ^^ (There might be significant mutations-aren't-reflected-in-both-copies gotchas too, but I'm not sure right now.)

If you embed a procedure instead, I don't know if it copies that too, but it doesn't matter 'cause a copy of the procedure should still close over the same bindings. In practice, (let foo (annotate 'a 'b) (= global!x foo) (is global!x foo)) works, so I'm satisfied.

By the way, I don't know if the core of the language is supposed to be all that axiomatic. It should be clean, certainly, but by its nature it should provide more than minimal axioms.

This is a point I just acknowledged but challenged at http://arclanguage.org/item?id=13266. I'm not sure entirely whether and how I (dis)believe it, so a response is welcome. ^_^

it is extremely easy, not to mention efficient, to implement these as primitives, while it is subtle, error-prone, and inefficient to implement it with 'eval.

Sure. Implementing 'symbol-value in terms of 'eval is a pretty big abstraction inversion, and it causes lots of unnecessary consing and compilation at runtime. I'm kinda conviced. ^_^

working code

Incidentally, official Arc allows you to say (assign a.b t) and observe (bound 'a.b). Your 'symbol-value makes it possible to get the value of 'a.b again, whereas there's no non-exploit way to do that with 'eval. ^_^ (You can use the (cdr `(0 . ,_a.b)) bug, lol.)

I agree with this. Compare it with having naming and anaphoric macros: iflet and aif, rfn and afn, even fn and []; I'd add awhile and whilet to the list even though awhile isn't in official Arc, and fromfile, tofile, and ontofile[1].

In fact, it is a very general practice in (functional?) programming to first write a function that handles something basic, then write another function on top of it that's more pleasant to work with. It really is ubiquitous. It's good because it separates the primitives from the high-level interfaces; if you want to change the primitives, you don't need to concern yourself with the high-level interface, and if you want to change the high-level interface, you don't need to concern yourself with the primitives. And macros give you flexibility, the ability to construct pleasant interfaces in ways you can't do with pure functions; for example, functions must evaluate all their arguments once, from left to right, while macros don't have to.

In this case, I don't think we have a function that directly does what you're asking for (i.e. it operates like obj except it evaluates the keys). I consider this a problem. Note that in Scheme and CL, we can go (vector x y z) instead of crap like (let u (make-vector 3) (= u.0 x u.1 y u.2 z) u). We should likewise have a good table-constructing function even if it isn't strictly necessary as a primitive. At the moment, this is the closest we have:

  (apply listtab (pair:list 'a 1 'b 2))
  =
  (obj a 1 b 2)

  (def ???? args
    (apply listtab pair.args)) 

  (xdef table (lambda args
                (let ((h (make-hash-table 'equal)))
                  (if (pair? args) ((car args) h))
                  h)))
  --ac.scm

  (table 
     [each ip ips
       (= (_ ip) (dedup (map !by (+ (bads ip) (goods ip)))))]))

  (table [each-loaded-item i
           (awhen (and i!dead (check (sitename i!url) banned-sites*))
             (push i (_ it)))]))

  (let u (table)
     (each ip ips
        (= (u ip) ...))
     u)

  (w/table u
     (each ip ips
        (= (u ip) ...)))

So. Options: (1) Have table do alternating key-value stuff; if there's one argument remaining at the end, apply it to the table; then return the table. (2) Have table do alternating key-value stuff; signal an error if there's an odd number of arguments [and Paul Graham can get used to w/table], or (2a) if there's one argument, apply that function to the table, while if there are an odd number ≥3 of arguments, signal an error. (3) Leave table as is, and find a new name for our function.

I think (1) is the best thing to do at the moment, and (2) is probably a better future goal but I would be fine being overruled on that (its single advantage is error-reporting when you accidentally give table an odd number of arguments). I think (2a) is a stupid hack and (3) is bad. As such, here is an implementation of (1). Replace the old '(xdef table ...' definition in ac.scm with the following:

  (xdef table (lambda args
                (let ((h (make-hash-table 'equal)))
                  (define (slave xs)
                    (cond ((null? xs) 'nonce)
                          ((null? (cdr xs))
                           ((car xs) h))
                          (else (hash-table-put! h (car xs) (cadr xs))
                                (slave (cddr xs)))))
                  (slave args)
                  h)))
  ;Usage
  arc> (table)
  #hash()
  arc> (table [= _!a 1 _!b 2])
  #hash((a . 1) (b . 2))
  arc> (table 'a 1 'b 2)
  #hash((a . 1) (b . 2))
  arc> (table 'a 1 'b 2 [= _!b 3 _!c 4])
  #hash((a . 1) (b . 3) (c . 4))

I gave two ways we can already accomplish the behavior somewhat conveniently even if we don't have something sensible like your version of 'table:

  (copy (table) 'a 1 'b 2)
  (listtab:pair:list 'a 1 'b 2)

  (def - args
     (if (no cdr.args)  ;or no:cdr.args with my recent hack[1]
         (* -1 car.args)
         (+ car.args (* -1 (apply + cdr.args)))))

Taking '- as the example: there are a few non-obvious things about it (how it works with more than 2 arguments, or how it works with 1 argument), and people could reasonably end up with different versions of it (I do think the current version is best, but I wouldn't blame anyone for not thinking about the 3-or-more-variable case or for implementing it differently).

This is not a problem if you use '- as a utility in the definition of your library functions and someone else just imports the exported functions of your library and uses them. But if you intend to, say, paste code on the Arc Forum and expect anyone to understand it, or if you want people to be able to download the source code of your library and make improvements to it, then there's a cost to every non-standard definition you use: the reader has to learn it. If the language doesn't provide "map" and "let" and "with" (which are certainly not primitive; in fact, they're defined in arc.arc), then either you don't use those operators (and your code will suffer for it), or you do use them and that's one more thing the reader needs to learn to understand your code. It's not the end of the world, it's not a game-breaker for all projects, but it's one more obstacle to people understanding your code, and if you can get rid of it, then that is all to the good.

That's a good point. ^_^ I don't use Anarki- or Lathe-specific stuff in my examples if I can help it. And I recently mused on[1] the trend for a language to incorporate a lot of features in the standard so as to improve the common ground, so I should have seen that point to begin with.

[1] http://arclanguage.org/item?id=13139

Namespaces solve the problem flawlessly only if you plan for no one to work on or read anyone else's code, ever.

I've sorta been banking on the idea that everyone programs to their own languages of utilities anyway, and that each of those languages can be talked about, accepted as a common topic, promoted by its proponents, and standardized just like language cores can. Certainly CMSes and game engines have those kinds of communities. :)

Multiple independently developed libraries won't always work together well enough to all be clearly canon components of the language's identity, but I think they are more likely to be interoperable than are things designed from the outset to be entirely new languages.[2] So I don't think it's important for the core libraries to be cutting-edge in practice. The core can fade into the background to a degree.

I haven't thought about this stuff very deeply yet, and it's not rooted in a lot of fact, so please feel free to disillusion me. ^^

With ssyntax, you usually only have to add "inc:" or "inc." to the left side of an expression (depending on whether it's already a function/macro call or just a symbol). This is why I love the hell out of ssyntax. It only doesn't work if the expression is already of the form "a.b", in which case you have to add some parentheses. Currently, "inc:inc.2" expands to "(compose inc inc.2)".

Recommendation: Have "a:b.c" expand to (a:b c); this will make it always, or nearly always (I haven't thought much about using it with quote or quasiquote), possible to tack an extra function/macro call onto an expression with a single edit. I think it's also more consistent: currently we have a.b.c -> (a.b c) [-> ((a b) c)], which is useful for referencing nested data structures; and it fits that pattern to have a:b.c -> (a:b c) [-> ((compose a b) c) -> (a (b c))]. I really think this would be a big improvement.

Anyway, this ssyntax stuff has the major advantage that it works to tack on any single-argument function/macro, rather than just the very few that are important enough to have their own special character. I find this extremely convenient: I can add "time:" and "prn:" to an expression when I want to debug it, and then remove it just as easily. Combined with my 'cp function (http://arclanguage.org/item?id=12873), this has in my past made for some very pleasant debugging.

Aesthetically, tacking "func:" onto "expr" is like adding an element to the tree (in fact, it literally does "expr -> (list func expr) = (cons func (cons expr nil))"), which is an O(1) operation, and it makes sense for it to always be a simple O(1) editing operation. (Adding something to the left side, then remembering to look for the right side so you can add a close-paren, is not O(1) to me.) In fact, it's a common O(1) operation, and it should be O(1); and the same should go for its opposite, removing an element previously tacked on.

Imma go figure out how to change ac.scm. ...And I've kludged it by making . and ! expand before : and ~ in the definition of "expand-ssyntax" in ac.scm.

  ((or (insym? #\. sym) (insym? #\! sym)) expand-sexpr) ;switched order
  ((or (insym? #\: sym) (insym? #\~ sym)) expand-compose)
  --ac.scm

Arc seems to load properly, and the ssyntax works the way I like it.

  arc> factorial.3
  6
  arc> inc:factorial.3
  7
  arc> factorial:inc:factorial.3
  5040

Anyway, what you're talking about is already how Penknife works: Infix operators on the right are always handled first. An interesting result is that a!b ssyntax is a bit redundant under this setup. Here's an Arc demonstration:

  ; with ! ssyntax
  a.b!c.d        ->  (a.b!c d)
                 ->  ((a.b (quote c)) d)
  
  ; without ! ssyntax
  a.b:quote.c.d  ->  (a.b:quote.c d)
                 ->  ((a.b:quote c) d)
                 ->  (((compose a.b quote) c) d)
                 ->  ((a.b (quote c)) d)

  a!b  -> a:quote.b
  .a   -> get.a
  !a   -> get:quote.a
  ~a   -> no:a

In Penknife, I've been thinking about having infix operator such that a`b.c is (b a c). Arc could do this if a`b expanded to something like (opcurry b a), where 'opcurry was a metafn such that ((opcurry a b c) d e f) expanded to (a b c d e f). Then the only essential ssyntaxes would be a`b and a.b:

  a&b  -> a`andf.b
  a:b  -> a`compose.b
  a!b  -> a`compose.quote.b
  .a   -> get.a
  !a   -> get`compose.quote.a
  ~a   -> no`compose.a

Maybe it'll be useful in an axiomatic way. Perhaps a Penknife-like or Arc-like language can have ` and . as its only basic infix operators, with all other infix operators being abbreviations defined in terms of those two....

Hmm, an alternate axiomatic approach is to treat a`b.c as a single ternary operator a{b}c.

  a&b  -> a{andf}b
  a:b  -> a{compose}b
  a.b  -> a{call-op}b  ; where (call-op a b) expands to (a b)
  a!b  -> a{compose}quote{call-op}b
  .a   -> get{call-op}a
  !a   -> get{compose}quote{call-op}a
  ~a   -> no{compose}a

Wart unconsciously got this right (compose is ^):

  wart> (wt-transform 'a^b.c)
  (call* (compose* a b) c)

1. Have the Arc process running something like this:

  (while t
    (sleep .2)
    (awhen (car:errsafe:readfile "ARC_ORDERS")
      (pr "Input> ")
      write.it
      (prn)
      (rmfile "ARC_ORDERS")
      (write:eval it)
      (prn)))

This might be a horrible hack, but it's awesome, and it presents a very easy interface--e.g. if you have a program that lets you bind keys to shell scripts, then you can have a shell script say, like, "echo '(do-this-stuff)' > ARC_ORDERS".

First of all, you can create a named pipe in a directory with the command "mkfifo name".

Then, I have a shell script in mzscheme (should probably update to Racket soon) for launching arc that sets up the long running process with normal output redirected to a log file and a second repl redirected to two named pipes "in" and "out". The important part is

  (parameterize ((current-output-port (open-output-file "out" 'update))
                 (current-input-port (open-input-file "in"))
                 (current-error-port (current-output-port)))
                (file-stream-buffer-mode (current-output-port) 'none)
                (tl))

  (w/stdin (infile "in")
    (w/stdout (outfile "out")
      ($:tl)))    ;whatever method you use to get to racket and call the repl

Anyway, once you have the pipes set up, you can echo and cat them like any other file. The main difference being that they are treated exactly like a normal repl, and shouldn't have the overhead of sleeping and reading/erasing a file. I use a shell script to connect to them as a repl most of the time:

  #! /bin/bash
  
  bash -c "cat <out &
  cat >in"

  (as string
      (big long
           (hairy gigantic)
           (immense and complicated (function))))

  (coerce (big long
               (hairy gigantic
               (immense and complicated (function)))
          'string)

  (mac as (type x)
    `(coerce ,x ',type))

  (string:big long
    (hairy gigantic)
    (immense and complicated (function)))

  (as:string:big long
    (hairy gigantic)
    (immense and complicated (function)))

(Note from the future: What follows doesn't really continue that response. I just started randomly considering a few more angles. ^_^ )

Most of the time, [coerce _ 'string], [coerce _ 'sym], and so forth just end up being more verbose ways of saying things like [string _] and [sym _]. Almost all the uses of 'coerce in Arc 3.1 and Anarki are like that, where they hard code the target type, so that it's just like the name is coerce-cons or coerce-string but without any synergy with ssyntax. There are two exceptions:

  (def sort (test seq)
    (if (alist seq)
        (mergesort test (copy seq))
        (coerce (mergesort test (coerce seq 'cons)) (type seq))))

  (def inc (x (o n 1))
    (coerce (+ (coerce x 'int) n) (type x)))

Now that I think about this, my position has softened even more, but I'm still a bit stubborn. Even if 'coerce is only used as a way to convert something back from the type a calculation needs to manipulate it in, there's still an arbitrary choice being made between multiple behaviors. If some generic string utility wants to convert '(#\[ #\1 #\]) to "[1]" and back, but some JSON utility wants to convert '(1) to "[1]" and back, then (coerce "[1]" 'cons) needs to have two meanings at once.

Of course, if it comes to that, it's easy to just make the JSON utility convert from '(1) to (annotate 'json-encoded "[1]") and back instead. I think I have no escape from that. XD Any corner case I come up with is going to be at least as you're-not-gonna-need-it as 'coerce is. ^_-

Nevertheless, while I was arguing with myself, I came up with an experimental type-independent (and therefore 'coerce free) way to model back-and-forth transformations. It's a pretty obvious design, but I somehow managed to make it complicated and arbitrary in certain ways. :-p Here it is in case anyone's interested:

  (def encode-int (unencoded)
    (list `(type ,type.unencoded) int.unencoded))
  
  (def decode-int (recovery-notes encoded)
    (let fail (fn () (err "Unexpected 'decode-int case!"))
      (case do.recovery-notes.0 type
        (case do.recovery-notes.1
          string  string.encoded
          int     encoded
                  (do.fail))
        (do.fail))))
  
  (= encoding-int (annotate 'encoding
                    ; This is more hackable than
                    ; (list encode-int decode-int).
                    (list (fn args (apply encode-int args))
                          (fn args (apply decode-int args))))
  
  (def fn-through (encoding unencoded body)
    (withs ((encode decode) rep.encoding
            (recovery-notes encoded) do.encode.unencoded)
      (do.decode recovery-notes do.body.encoded)))
  
  (mac through (encoding var . body)
    `(fn-through ,encoding ,var (fn (,var) ,body)))
  
  (def inc (x (o n 1))
    (through encoding-int x
      (+ x n)))

Ah, now I follow. But often there's one kind that applies far more often than alternatives. And it's good for coerce to give it. For other type combinations it's good to know that coerce is complete, and that it'll give some sort of conversion. But you're right, I don't know if this ever makes code shorter. Perhaps this is yet another example of programmer's OCD, that insidious need to have things be aesthetic even when they don't matter.

I just started randomly considering a few more angles. ^_^

I'm starting to realize that's the reason I have a hard time following what you write :) If I may make a suggestion, make a list. I find your long comments are often too terse. Often they contain enough stuff for three or four distinct postings or comments. But the transitions are abrupt, perhaps because you're trying not to be even more long-winded. If you gave each idea its own post or comment it would have more room to breathe, and I'd be able to return to each one at my leisure. Feel free to post new submissions with substantial ideas. We hardly have enough submissions here.

Like your code idea at the end of the comment, and the suggestion that it's like monad transformers. I'd love to see a post elaborating on it. I'd love even more to see a yegge-sized elaboration of all your thoughts on coerce and what 'synergy with ssyntax' means. Perhaps they haven't settled down yet, but keep it in mind when they do :)

Sometimes I feel I would spend an hour with any one of your ideas if you'd spent just a few extra minutes with it.

Thanks for telling me that. ^^;

My usual process is that I'll take a few hours to write a comment, then I'll run out of time and decide to come back later to finish it up, and then I'll never go back to that draft (but I might start from scratch on the same topic). Occasionally I'll finish something in time to post it.

Recently, I have less time than I'm used to, so I've been posting things even if they're rough, in case someone gets value out of it anyway. I guess this makes my posts into scatterings of half-ideas, based on things I've been thinking to myself but only now had a reasonable excuse to mention. (Usually I shoot for a few organized, mostly full ideas, which also have very good excuses to be mentioned. :-p )

  arc> aps.map
  (deep-map map map-chooses map-more map-subperms map1 mapn mappend maptable s-map s-map1)

  (def arc-namespace ()
    (map [sym:cut string._ 1]
         (keep [is string._.0 #\_]
               ($.namespace-mapped-symbols))))
  (def apropos-fn (x)
    (sort < (map sym (keep [findsubseq x _]
                           (map string (arc-namespace))))))
  (mac aps (x) `(apropos-fn (string ',x)))

Though it's more limited, you might even just use sig in vanilla Arc.

  (mac apropos (name)
    (list 'quote
           (sort (compare < string)
                 (keep [findsubseq (string name) (string _)] (keys sig)))))