From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Reader macros Date: Fri, 23 Jan 2015 13:27:52 +0100 Message-ID: <87fvb165rr.fsf@fencepost.gnu.org> References: <54C15ECA.5050008@dancol.org> <54C18A06.7090404@dancol.org> <87sif16duj.fsf@fencepost.gnu.org> <54C2346B.4090800@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1422016094 15867 80.91.229.3 (23 Jan 2015 12:28:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Jan 2015 12:28:14 +0000 (UTC) Cc: Oleh , Stefan Monnier , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 23 13:28:12 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YEdLQ-0005tF-7v for ged-emacs-devel@m.gmane.org; Fri, 23 Jan 2015 13:28:12 +0100 Original-Received: from localhost ([::1]:58385 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEdLP-0006pN-Gu for ged-emacs-devel@m.gmane.org; Fri, 23 Jan 2015 07:28:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEdLB-0006p7-4F for emacs-devel@gnu.org; Fri, 23 Jan 2015 07:27:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YEdL8-0005aO-QU for emacs-devel@gnu.org; Fri, 23 Jan 2015 07:27:57 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEdL8-0005Zz-Mp for emacs-devel@gnu.org; Fri, 23 Jan 2015 07:27:54 -0500 Original-Received: from localhost ([127.0.0.1]:38907 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YEdL7-0005H3-45; Fri, 23 Jan 2015 07:27:53 -0500 Original-Received: by lola (Postfix, from userid 1000) id 98A70E05F5; Fri, 23 Jan 2015 13:27:52 +0100 (CET) In-Reply-To: <54C2346B.4090800@dancol.org> (Daniel Colascione's message of "Fri, 23 Jan 2015 03:45:47 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:181668 Archived-At: Daniel Colascione writes: > On 01/23/2015 01:33 AM, David Kastrup wrote: >> Daniel Colascione 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 # and make the reader return >>>> >>>> (funcall (cdr (assq reader-macro-alist)) ) >>> >>> >>> That's an excellent idea. >> >> Doesn't work well where 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 >> but rather with . 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 # or $ (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 # or $ 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