The quoting-related operators should be optionally available in their raw form.

[dead-claudia]

This is complicating anko/eslisp#13 and anko/eslisp#23 majorly.

[dead-claudia]

This can be done by using the options object to take an optional option like rawQuoting. It will require a different, new node type for each node, though.

[anko]

What do you mean by their “raw” form? An example would help.

[dead-claudia]

Like this:

// 'foo
{
  type: "quote",
  value: {type: "atom", value: "foo"}
}

// `foo
{
  type: "quasiquote",
  value: {type: "atom", value: "foo"}
}

// ,foo
{
  type: "unquote",
  value: {type: "atom", value: "foo"}
}

// ,@foo
{
  type: "unquote-splicing",
  value: {type: "atom", value: "foo"}
}

It would make handling those operators consistently tremendously easier in
Eslisp itself, as they're their own data type.

On Sat, Jan 2, 2016, 18:35 An [email protected] wrote:

What do you mean by their “raw” form? An example would help.

—
Reply to this email directly or view it on GitHub
#3 (comment).

[dead-claudia]

And after #4, it would be literally trivial. Just making this function, depending on the option, return the two-item list or @node quote, @parseExpr!.

[anko]

The ``` ' `,` `,@` are intended only to be syntactic sugar for calling `quasiquote`, `quote`, `unquote` and `unquote-splicing`. Exposing in the parser results how exactly one of those was written sounds like it's mixing concerns, which makes maintenance and changing parsers in the future harder. Is this really necessary? Why?

[dead-claudia]

It's not so much mixing concerns. It's making assumptions about how the
output is read and used. Maybe, the API consumer is a custom Lisp
interpreter, and those symbols map to a different type name. Maybe it's an
s-expression based XML template system that has a special syntax for quoted
expressions, but it wants to permit quote to be open for custom mixins.
Maybe it's an s-expression based language that uses symbol instead of
quote, and needs a different data type.

To get the old behavior from this proposal, you'd simply walk the tree and
convert appropriately. So, in other words, this mixes fewer concerns by
assuming less about what the consumer does with the API. It's less
coupled to Eslisp, so it's more inviting to other projects that need it.

On Sun, Jan 10, 2016, 14:59 An [email protected] wrote:

The ` ' , ,@ are intended only to be syntactic sugar for calling
quasiquote, quote, unquote and unquote-splicing. Exposing in the parser
results how exactly one of those was written sounds like it's mixing
concerns https://en.wikipedia.org/wiki/Separation_of_concerns, which
makes maintenance and changing parsers in the future harder. Is this really
necessary? Why?

—
Reply to this email directly or view it on GitHub
#3 (comment).

[anko]

I've thought about this.

To get the old behavior from this proposal, you'd simply walk the tree and convert appropriately. So, in other words, this mixes fewer concerns by assuming less about what the consumer does with the API. It's less coupled to Eslisp, so it's more inviting to other projects that need it.

That's a flawed line of reasoning. We could make even fewer assumptions by exposing the entire input string character-by-character to the consumer, but that would make this module redundant. Consumers could then get the "old behaviour" by reimplementing this module.

What makes this parser a useful point on the continuum between exposing nothing and exposing everything is that S-expressions are a frequently understood standard; a structure consisting of lists, atoms and strings. The exact way an atom was written (e.g. 'a vs (quote a)) doesn't figure into that standard. If we expose the way-of-writing information, this would stop being a well-understood standard S-expression parser and start being a poorly understood custom S-expression-and-special-quote-symbols parser, or whatever we'd want to call that.

Maybe it's an s-expression based XML template system that has a special syntax for quoted
expressions, but it wants to permit quote to be open for custom mixins. Maybe it's an s-expression based language that uses symbol instead of quote, and needs a different data type.

Languages that require AST primitives in addition to just atoms, strings and lists are by definition not S-expression-based languages. This is the sacrifice one makes for a simple AST format.

We'll just have to live with (mymacro 'a 'b) and (mymacro (quote a) (quote b)) being indistinguishable.

I feel like the question behind your question here is the currently proposed implementation for anko/eslisp#13 and anko/eslisp#23, which is to reuse the quotes inside the . macro so (. a b)→a[b]; and (. a 'b) → a.b;. I think that would be better to do by having the . macro look through its arguments for lists that start with a quote atom and replacing them with the appropriate estree identifier nodes. The parser doesn't need to care. It would cause (. a (quote b)) → a.b;, but I think that's OK.

[dead-claudia]

@anko I see what you're talking about now. On that note, this is worthy of closing, since you are probably right in that the best way to go for that particular macro is to check against list(atom("quote"), atom("foo")) instead of quote(atom("foo")). I didn't think of that when I initially wrote the patch. 😄

Closing, as this is rather moot now.