[fonc] quasiquoting in maru

[Aaron Burrow]

Hey and thanks for promptly responding to my last query,

a few remarks on the semantics of quasiquoting,

Why support only one pair of quasiquote and unquote?

ie

###########
# in maru
###########

.`,2
=> 2
.`1
=> 1
.``,,1

error: undefined variable: unquote
... unquote
<stdin>:4 (unquote 1)
<stdin>:4 (cons (unquote 1) (quote ()))
<stdin>:4 (cons (quote quasiquote) (cons (unquote 1) (quote ())))

###########
# in common lisp
###########


* `,2

2
* `1

1
* ``,,1

1
* ``,,,1

debugger invoked on a SB-INT:SIMPLE-READER-ERROR in thread
#<THREAD "initial thread" RUNNING {1002998F23}>:
Comma not inside a backquote.

Line: 1, Column: 4, File-Position: 4

Stream: #<SB-IMPL::STRING-INPUT-STREAM {100493CDC3}>

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
0: [ABORT] Exit debugger, returning to top level.

(SB-INT:SIMPLE-READER-ERROR
#<SB-IMPL::STRING-INPUT-STREAM {100493CDC3}>
"Comma not inside a backquote.")


Not that the common lisp way is inherently better, just curious as to why
the quasiquote is the way it is.

We can see in the quasiquote function that it effectively recurses on the
car of the list if it too is a list and once we find 'unquote we just
return the cdr. There is also no further accounting of nested quasiquote
symbols.


My second question is with respect to unquote splicing. Particularly, this
case.

###########
# in maru
###########

.`(,@3)
=> 3
.`,@3
=> (unquote-splicing 3)
.`,@(3)
=> (unquote-splicing (3))

common lisp errors on all three.

Are these semantics arbitrary because unquote-splicing doesn't make sense
for an atom?

High level design intent of maru's quasiquote would also be interesting.

[Faré]

Post by Aaron Burrow
a few remarks on the semantics of quasiquoting,
[...]
High level design intent of maru's quasiquote would also be interesting.

My guess would be that maru's quasiquote is somewhat buggy. Quasiquote
is really difficult to implement right. I tried once, and failed to
optimize the expansion in a way that handles ,@,@ then eventually fell
back to closely following the reference implementation
http://cliki.net/fare-quasiquote

Also note that the semantics of quasiquote is underspecified in Common
Lisp, as to how it interacts with the special syntaxes of various
other data structure constructors (e.g. what is `#3(1 ,@'(2 3)) ? If
you have other builtin or user-defined structure constructor syntaxes,
how does it interact with quasiquoting?). I am not sure how Scheme or
Clojure resolve the issue... probably not in a well-designed way.
That's an area where indeed maru could improve on CL, by e.g.
specifying a meta-quasiquote protocol for how quoting interacts with
user-defined syntax.

If you're interested, there's experimentation and design to do, and
probably a paper to publish.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
"Computer programming is omnipotence without omniscience."
— Prospero, as cited by Eliezer Yudkowsky

[Darius Bacon]

For a quasiquote in Scheme that works like the Common Lisp one:
https://github.com/darius/sketchbook/blob/master/misc/quasiquote.scm

Alan Bawden's paper referenced from there gives the rationale.

Post by Faré
That's an area where indeed maru could improve on CL, by e.g.
specifying a meta-quasiquote protocol for how quoting interacts with
user-defined syntax.

It might be worth looking at E's quasiliterals design for ideas there.
http://erights.org/elang/grammar/quasi-overview.html

Darius

Post by Faré

Post by Aaron Burrow
a few remarks on the semantics of quasiquoting,
[...]
High level design intent of maru's quasiquote would also be interesting.

My guess would be that maru's quasiquote is somewhat buggy. Quasiquote
is really difficult to implement right. I tried once, and failed to
back to closely following the reference implementation
http://cliki.net/fare-quasiquote
Also note that the semantics of quasiquote is underspecified in Common
Lisp, as to how it interacts with the special syntaxes of various
you have other builtin or user-defined structure constructor syntaxes,
how does it interact with quasiquoting?). I am not sure how Scheme or
Clojure resolve the issue... probably not in a well-designed way.
That's an area where indeed maru could improve on CL, by e.g.
specifying a meta-quasiquote protocol for how quoting interacts with
user-defined syntax.
If you're interested, there's experimentation and design to do, and
probably a paper to publish.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
http://fare.tunes.org
"Computer programming is omnipotence without omniscience."
— Prospero, as cited by Eliezer Yudkowsky
_______________________________________________
fonc mailing list
http://vpri.org/mailman/listinfo/fonc

[Faré]

Post by Darius Bacon
https://github.com/darius/sketchbook/blob/master/misc/quasiquote.scm
Alan Bawden's paper referenced from there gives the rationale.

Your implementation is so simple that I'd be happily surprised
if it got things like ,@, and ,@,@ processed correctly.
And it obviously doesn't handle #() and such.
Once again, see my http://cliki.net/fare-quasiquote
for a complete CL implementation.

Post by Darius Bacon

Post by Faré
That's an area where indeed maru could improve on CL, by e.g.
specifying a meta-quasiquote protocol for how quoting interacts with
user-defined syntax.

It might be worth looking at E's quasiliterals design for ideas there.
http://erights.org/elang/grammar/quasi-overview.html

It has some good ideas, but plenty of bad ideas too.
It makes ${0} ${1}, etc., without providing hygiene for cases where
users would like ${0} as an actual literal in the text (e.g. because
of recursive patterns). A kludgy solution along those lines would at
least use a cryptographic gensym to prevent collisions, and pass that
as argument in the expansion, and/or somehow escape the dollars in the
text. A real solution would have a notion of parametrized extensible
grammars, so that the escaping happens properly at all levels. A
formalization of this extension mechanism is what I'm seeking.

E also falls short by distinguishing quasiquoting for expressions and
patterns ${x} and @{x}. The two should be dual and disambiguation
should happen from context, and to get the equivalent of E's ${x} in a
pattern context should just be @{kwote(x)}, where (kwote x) is as in
traditional Lisp: (defun kwote (x) (list 'quote x)).

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
There are three types of people in the world;
those who can count, and those who can't.

[Andre van Delft]

Post by Faré

Post by Darius Bacon

Post by Faré
That's an area where indeed maru could improve on CL, by e.g.
specifying a meta-quasiquote protocol for how quoting interacts with
user-defined syntax.

It might be worth looking at E's quasiliterals design for ideas there.
http://erights.org/elang/grammar/quasi-overview.html

It has some good ideas, but plenty of bad ideas too.
It makes ${0} ${1}, etc., without providing hygiene for cases where
users would like ${0} as an actual literal in the text (e.g. because
of recursive patterns). A kludgy solution along those lines would at
least use a cryptographic gensym to prevent collisions, and pass that
as argument in the expansion, and/or somehow escape the dollars in the
text. A real solution would have a notion of parametrized extensible
grammars, so that the escaping happens properly at all levels. A
formalization of this extension mechanism is what I'm seeking.
E also falls short by distinguishing quasiquoting for expressions and
should happen from context, and to get the equivalent of E's ${x} in a
traditional Lisp: (defun kwote (x) (list 'quote x)).

Quasiquotes and string interpolation are being added to Scala;
these don't seem to have the two drawbacks that you mentioned for E's design.

The $ may be escaped just by doubling:

scala> val name = "foo"
name: String = foo

scala> s"my.package.$name$$"
res0: String = my.package.foo$
http://stackoverflow.com/questions/16875530/escape-a-dollar-sign-in-string-interpolation

As I understand from the links below, the $ variables should also work for pattern matching,
but I don't get these to work yet (maybe I need a newer version).

http://infoscience.epfl.ch/record/185242/files/QuasiquotesForScala.pdf
http://docs.scala-lang.org/overviews/core/string-interpolation.html
https://groups.google.com/forum/#!topic/scala-internals/AmZl7VqV_rk
http://docs.scala-lang.org/overviews/macros/quasiquotes.html
http://scalamacros.org/paperstalks/2013-04-22-LetOurPowersCombine.pdf page 8
http://parleys.com/play/51c16dffe4b0d38b54f46216/chapter0/about

Presentation by Eugene Burmako:
http://parleys.com/play/51c16dffe4b0d38b54f46216/chapter17/about

Presentation by Adam Warski:
http://vimeo.com/74553075 from 46:40
http://www.slideshare.net/adamw1pl/scala-macros slide 28

[Faré]

On Wed, Nov 27, 2013 at 11:07 AM, Andre van Delft

Post by Andre van Delft
Quasiquotes and string interpolation are being added to Scala;
these don't seem to have the two drawbacks that you mentioned for E's design.
[...]
http://infoscience.epfl.ch/record/185242/files/QuasiquotesForScala.pdf

Thanks Andre for your many links of which I copied but one.

Scala quasiquotes look nice indeed, and seem to handle
the common and simple cases very well, but
they are not a general mechanism for arbitrary grammatical non-terminals,
and they are not designed to nest without a lot of clumsy escaping.
It seems to me they are not implicitly hygienic, either,
but that's asking a lot.

A more general approach for a language with a rich grammar
with arbitrary many (and extensible) non-terminal types might be that of
Racket's syntax-parse by Ryan Culpepper which has #`quasiquotations, or
Jon Rafkind's honu syntax for Racket, which I believe has the same.
I believe Dave Moon's PLOT may have something, too.

In any case, it's possible to have better macros and quasiquotations

in an infix language than E or Scala provides.

I can't say at this point how to make it work in the context of maru
and its extensible parsers,

but the idea would probably be to add extra parametrization to the parsers,

to allow for an optional "escape up".


—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The secret of getting ahead is getting started. The secret of getting started
is breaking your complex overwhelming tasks into small manageable tasks, and
then starting on the first one. — Mark Twain

[Julian Leviston]

Post by Faré
If you're interested, there's experimentation and design to do, and
probably a paper to publish.

Forgive me if I'm barking up the wrong tree, but wouldn't it be solved by not using text for source code?

Julian