From: David Kastrup <dak@gnu.org>
To: Daniel Colascione <dancol@dancol.org>
Cc: Oleh <ohwoeowho@gmail.com>,
Stefan Monnier <monnier@iro.umontreal.ca>,
emacs-devel@gnu.org
Subject: Re: Reader macros
Date: Fri, 23 Jan 2015 13:27:52 +0100 [thread overview]
Message-ID: <87fvb165rr.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <54C2346B.4090800@dancol.org> (Daniel Colascione's message of "Fri, 23 Jan 2015 03:45:47 -0800")
Daniel Colascione <dancol@dancol.org> writes:
> On 01/23/2015 01:33 AM, David Kastrup wrote:
>> Daniel Colascione <dancol@dancol.org> writes:
>>
>>> On 01/22/2015 03:36 PM, Stefan Monnier wrote:
>>>> Maybe we could introduce a more limited form of reader macros.
>>>> E.g. allow #<letter><sexp> and make the reader return
>>>>
>>>> (funcall (cdr (assq <letter> reader-macro-alist)) <sexp>)
>>>
>>>
>>> That's an excellent idea.
>>
>> Doesn't work well where <letter> is an unmatched delimiter like ( or [.
>
> So? The point isn't to support every conceivable syntax, but to cover
> the most common use cases without fundamentally changing the lexical
> structure of the source. Requiring #f() instead of #() is no great crime.
>
>> Also would not work with #r"xxx" raw strings.
>
> Arguably a feature, not a bug.
>
>> I think it makes more
>> sense (like Guile does it) to make this kind of funcall not with <sexp>
>> but rather with <port>. If indeed a sexp is wanted, calling `read' is
>> trivial.
>
> Sure, it's possible to do it that way, but then reader macros can break
> the lexical structure of the program.
Shrug. That's LilyPond's way of embedding LilyPond code in Scheme.
Here is one arbitrary example: One escapes from LilyPond to Scheme
writing #<sexp> or $<sexp> (with slightly different semantics) and from
Scheme to LilyPond writing #{ code... #}, with arbitrary nesting and
full lexical closure:
incipit =
#(define-music-function (parser location incipit-music) (ly:music?)
#{
\once \override Staff.InstrumentName.stencil =
#(lambda (grob)
(let* ((instrument-name (ly:grob-property grob 'long-text))
(align-x (ly:grob-property grob 'self-alignment-X 0))
(align-y (ly:grob-property grob 'self-alignment-Y 0)))
(set! (ly:grob-property grob 'long-text)
#{ \markup {
\score
{
\new MensuralStaff \with {
\override InstrumentName.self-alignment-X = #align-x
\override InstrumentName.self-alignment-Y = #align-y
instrumentName = #instrument-name
}
{
$incipit-music
}
\layout {
$(ly:grob-layout grob)
indent-incipit-default = 15\mm
line-width = #(primitive-eval
'(or (false-if-exception indent)
indent-incipit-default))
indent = #(primitive-eval
'(or (false-if-exception (- line-width incipit-width))
(* 0.5 line-width)))
ragged-right = ##f
ragged-last = ##f
system-count = 1
\context {
\Score
\remove "Default_bar_line_engraver"
}
}
}
}
#})
(set! (ly:grob-property grob 'self-alignment-Y) #f)
(set! (ly:grob-property grob 'self-alignment-X) RIGHT)
(system-start-text::print grob)))
#}
)
As you can see, it is one merry back-and-forth. The implementation of
the LilyPond-within-Scheme embedding indeed uses a GUILE reader macro by
registering #{ and, upon being called, reading the string delimited by
#} from the port for later interpretation and registering each #<sexp>
or $<sexp> combination for potential lexical closure.
Now GUILE is touted more as a language-building tool than Elisp, of
course. However, being able to adapt the Lisp reader to the task of
reading Scheme and even LilyPond/Scheme would make several parsing tasks
for LilyPond-mode easier, not just #{ ... #}. For example, there is
#:xxx for keywords, and #(a b c d) for vectors and #\x for characters.
Being able to nudge the Elisp reader into dealing with this kind of sexp
would make for more robust detection of LilyPond vs Scheme code.
> The only legitimate use case Stefan's idea doesn't cover is
So reading Scheme or Scheme/LilyPond code is illegitimate? Who gets to
decide this?
> raw strings (and maybe here docs), for which I would be willing to add
> a special case to the reader if we decided we wanted them.
--
David Kastrup
next prev parent reply other threads:[~2015-01-23 12:27 UTC|newest]
Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-21 21:38 [PATCH] Clojure-like syntactic sugar for an anonymous function literal Oleh
2015-01-21 22:28 ` samer
2015-01-21 22:37 ` Oleh
2015-01-21 23:36 ` Artur Malabarba
2015-01-21 23:46 ` Oleh
2015-01-22 0:54 ` Artur Malabarba
2015-01-22 0:57 ` Artur Malabarba
2015-01-22 1:29 ` Daniel Colascione
2015-01-22 2:21 ` Drew Adams
2015-01-22 13:35 ` Lars Brinkhoff
2015-01-22 7:20 ` Stephen J. Turnbull
2015-01-22 8:04 ` Oleh
2015-01-22 8:16 ` David Kastrup
2015-01-22 9:07 ` Andreas Schwab
2015-01-22 9:19 ` Oleh
2015-01-22 8:52 ` René Kyllingstad
2015-01-22 9:17 ` David Kastrup
2015-01-22 9:27 ` Oleh
2015-01-22 9:38 ` Daniel Colascione
2015-01-22 9:45 ` Oleh
2015-01-22 9:50 ` Daniel Colascione
2015-01-22 9:52 ` Oleh
2015-01-22 9:57 ` Daniel Colascione
2015-01-22 10:05 ` Oleh
2015-01-22 16:57 ` Ivan Andrus
2015-01-23 0:54 ` Leo Liu
2015-01-24 23:33 ` Lars Ingebrigtsen
2015-01-22 10:15 ` Stephen J. Turnbull
2015-01-22 10:20 ` David Kastrup
2015-01-22 14:21 ` Stephen J. Turnbull
2015-01-22 14:31 ` Oleh
2015-01-23 1:03 ` Stephen J. Turnbull
2015-01-22 10:22 ` Oleh
2015-01-22 10:32 ` David Kastrup
2015-01-22 10:40 ` Oleh
2015-01-22 10:56 ` Tassilo Horn
2015-01-22 11:03 ` Oleh
2015-01-22 14:35 ` Stephen J. Turnbull
2015-01-22 14:44 ` Oleh
2015-01-23 1:11 ` Stephen J. Turnbull
2015-01-22 14:48 ` Artur Malabarba
2015-01-23 1:17 ` Stephen J. Turnbull
2015-01-22 11:03 ` Phillip Lord
2015-01-22 9:35 ` René Kyllingstad
2015-01-22 9:45 ` Daniel Colascione
2015-01-22 9:49 ` David Kastrup
2015-01-22 9:53 ` Daniel Colascione
2015-01-22 10:22 ` David Kastrup
2015-01-22 12:37 ` Artur Malabarba
2015-01-22 12:46 ` Phillip Lord
2015-01-22 12:49 ` Daniel Colascione
2015-01-22 13:07 ` Oleh
2015-01-22 22:10 ` Richard Stallman
2015-01-23 9:28 ` David Kastrup
2015-01-24 1:09 ` Richard Stallman
2015-01-24 8:29 ` Thien-Thi Nguyen
2015-01-23 10:33 ` Eli Zaretskii
2015-01-22 16:44 ` Stefan Monnier
2015-01-22 17:22 ` Oleh
2015-01-22 20:34 ` Daniel Colascione
2015-01-22 23:36 ` Stefan Monnier
2015-01-22 23:38 ` Reader macros (Was: Re: [PATCH] Clojure-like syntactic sugar for an anonymous function literal) Daniel Colascione
2015-01-23 9:33 ` Reader macros David Kastrup
2015-01-23 11:45 ` Daniel Colascione
2015-01-23 12:27 ` David Kastrup [this message]
2015-01-23 10:34 ` [PATCH] Clojure-like syntactic sugar for an anonymous function literal Phillip Lord
2015-01-23 10:47 ` Oleh
2015-01-23 11:53 ` Phillip Lord
2015-01-23 12:02 ` Daniel Colascione
2015-01-23 11:50 ` Daniel Colascione
2015-01-23 13:18 ` Phillip Lord
2015-01-23 20:24 ` Stefan Monnier
2015-01-23 20:52 ` Stefan Monnier
2015-01-23 22:25 ` Phillip Lord
2015-01-23 7:44 ` Oleh
2015-01-22 23:28 ` Stefan Monnier
2015-01-22 18:30 ` Artur Malabarba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fvb165rr.fsf@fencepost.gnu.org \
--to=dak@gnu.org \
--cc=dancol@dancol.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=ohwoeowho@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).