Arc Forumnew | comments | leaders | submitlogin
1 point by akkartik 4347 days ago | link | parent

I haven't looked at your link yet, but I want to clarify my comment first so that we can attack it together after I'm updated. ^_^

My solution relies on unquote and therefore on backquote. I don't recall Kernel mentioning them; scheme seems to ignore them in general. But let's assume that they are implementable just like quote. When I say "quote" I mean this holy trinity :)

I know Kernel doesn't prevent quote, but it discourages it. Even if you got apply working with backquoted macros in Kernel, it wouldn't be very helpful if most macros were backquote-less as a matter of course. This seems like a limitation of the philosophy.

More strongly, I want to argue that having syntax for quote/backquote/unquote is valuable. In wart all symbols are overrideable[1]. It uses punctuation for quote/backquote/unquote/splice to highlight that they are different from symbols, more fundamental to the programming model. Supporting apply for macros has made them even more so, even more fundamentally entangled together and baked into the interpreter.

[1] The one exception is fn. Perhaps I should make it λ? Nah, that doesn't solve the problem. Hmm, the only punctuation character wart hasn't already put to use is #.. :D



2 points by rocketnia 4344 days ago | link

"My solution relies on unquote and therefore on backquote."

Oh, right.

---

"More strongly, I want to argue that having syntax for quote/backquote/unquote is valuable."

I don't think that's as expressive as infix syntax. With the right kind of a.b syntax, we could write `(a b ,c) as qq.(a b uq.c), trading in some readability for the flexibility to define our own variants.[1] Would you still want to have dedicated quasiquotation syntax then?

(Even I might answer yes sometimes. The staged fexpr system I describe at http://arclanguage.org/item?id=15868 uses unquote syntax as a way to compute during a previous stage of the command processor.)

[1] Penknife does something like this, but the use of structured string manipulation instead of s-expressions forces it to use a string-like escaping mechanism for unquote: qq.[a b \,c]

-----

1 point by akkartik 4344 days ago | link

Yeah, that's really interesting.

But is it convincing that existing lisp syntax is more valuable than Kernel's approach of no syntax?

-----

1 point by rocketnia 4344 days ago | link

"But is it convincing that existing lisp syntax is more valuable than Kernel's approach of no syntax?"

Well, I'd say so, yeah. I'd say `foo is a less helpful syntax than a.b, but still helpful.

-----

1 point by akkartik 4344 days ago | link

Thanks. I'm going to keep the qq.() idea up my sleeve. It's totally consistent with my idea that symbols should be overrideable and syntax should not.

-----