Arc Forumnew | comments | leaders | submitlogin
1 point by absz 3115 days ago | link | parent

The behaviour of the [] syntax makes perfect sense, if you think about it. First, [...] is just an abbreviation for (fn (_) ...) to save typing.[1] Second, `(...) is just an abbreviation for (quasiquote '(...)). Thus [`(...)] is [(quasiquote ...)], which is (fn (_) ((quasiquote ...)). If [] stripped off the outer layer of parentheses, then [+ _ 1] would become (fn (_) + _ 1), which is clearly wrong. Thus, we see that it makes more sense to use fn, since the whole point of [] and ` is to save typing and make code clearer, neither of which they can do here.

Another, possibly nicer, way to think about it is that [] just represents a delayed function call; you're trying to delay an object, and since [] is a function call, you're calling it instead. Either way, the point is that this is the consistent and desirable way for [] to work.

[1]: On Anarki, you also get _1, _2, etc., and __ for varargs, but that's not important for this discussion.



1 point by shader 3114 days ago | link

Yep. Unfortunately, in this case it's practically shorter, and more readable, to use the fn form:

  (fn (_) `(= ,_ ,form))
because you don't have to type out the whole name "quasiquote".

-----

1 point by Adlai 3114 days ago | link

Just a little curious idea:

What about a special syntax (for this one situation), where you can put the backquote thus: [` = ,_ ,form] which would read-macro-expand to (fn (_) `(= ,_ ,form))

I guess it's just a question of how common this problem is, and how difficult it would be to implement this type of read-macro. I guess brackets.scm goes on my list of files to check out...

-----