From: Mikael Djurfeldt <mikael@djurfeldt.com>
To: Mark H Weaver <mhw@netris.org>
Cc: guile-devel <guile-devel@gnu.org>
Subject: Re: Precedence for reader extensions
Date: Tue, 19 Feb 2013 17:42:02 +0100 [thread overview]
Message-ID: <CAA2Xvw+W6M8Nm2h_e0BE0o=pE0ntwwv3-QZrfVcefOuq9b9otw@mail.gmail.com> (raw)
In-Reply-To: <87a9r0gvld.fsf@tines.lan>
[-- Attachment #1: Type: text/plain, Size: 2452 bytes --]
On Tue, Feb 19, 2013 at 4:41 PM, Mark H Weaver <mhw@netris.org> wrote:
> Mikael Djurfeldt <mikael@djurfeldt.com> writes:
>> On Tue, Feb 19, 2013 at 12:33 AM, Mark H Weaver <mhw@netris.org> wrote:
>>> Mikael Djurfeldt <mikael@djurfeldt.com> writes:
>>>> I propose to simplify this to only two levels:
>>>>
>>>> 1. %read-hash-procedures
>>>> 2. predefined syntax
>>
>> It turns out that the change I propose above was already implemented
>> in read.c. The effect just wasn't visible due to a bug in flush_ws
>> which caused all #! to be erroneously removed if they exist as the
>> outermost expression.
>
> I'm not sure that I consider this a bug.
In this reply I've attached a file mit-reader-scm which installs a
hash-read-procedure for #\!.
What I wanted to say above is that scm_read_sharp (in HEAD) is
implemented with the priorities I list above while flush_ws is
implemented with other priorities. Here's a demo of the consequences
of this bug:
scheme@(guile-user)> (load "mit-reader.scm")
scheme@(guile-user)> (quote #!optional)
... !# hi)
$1 = hi
scheme@(guile-user)> '#!optional
$2 = #:optional
> [...]
> I'm uncomfortable with globally overriding standard read syntax. In a
> large scheme system such as Guile, there are many modules that use
> 'read' and expect it to act in accordance with standard lexical
> conventions.
Well, in the mit-scheme compatibility module, my intention was to use
dynamic-wind to modify #!-syntax while loading mit-scheme-specific
files. Note that %read-hash-procedures is a fluid, so this will be
absolutely local and won't leak out in any way to the rest of the
system.
> The problem with this approach is that it does not compose.
Let's now patch guile according to the diff I sent... there!
scheme@(guile-user)> (load "mit-reader.scm")
scheme@(guile-user)> (quote #!optional)
$1 = #:optional
scheme@(guile-user)> '#!optional
$2 = #:optional
scheme@(guile-user)> (quote #!hi!# #!optional)
$3 = #:optional
My take on this is:
* The %read-hash-procedures API is not pretty
* The suggested change doesn't make things prettier
* The suggested change *does* make things conceptually simpler and
more flexible (= you can always override hash syntax if you want;
compared to the current: you can override #| but not other hash
syntax)
* The suggested change fixes a bug
* The suggested change does compose and different syntax can be
confined to a module by using dynamic-wind
Best regards,
Mikael
[-- Attachment #2: mit-reader.scm --]
[-- Type: application/octet-stream, Size: 774 bytes --]
(define (%read-mit-constants c port)
(define (try-read string)
(let ((length (string-length string)))
(let loop ((i 0))
(cond ((= i length) (symbol->keyword (string->symbol string)))
((not (char=? (peek-char port) (string-ref string i)))
(unread-string (substring string 0 i) port)
*unspecified*)
(else (read-char port)
(loop (+ 1 i)))))))
(case (peek-char port)
((#\o) (try-read "optional"))
((#\r) (try-read "rest"))))
(define (install-hash-procedure! c proc)
(let ((als (fluid-ref %read-hash-procedures )))
(cond ((assv c als)
=> (lambda (p)
(set-cdr! p proc)))
(else
(fluid-set! %read-hash-procedures
(cons (cons c proc) als))))))
(install-hash-procedure! #\! %read-mit-constants)
next prev parent reply other threads:[~2013-02-19 16:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-18 21:05 Precedence for reader extensions Mikael Djurfeldt
2013-02-18 21:07 ` Mikael Djurfeldt
2013-02-18 21:26 ` Mikael Djurfeldt
2013-02-18 21:42 ` Mikael Djurfeldt
2013-02-18 23:33 ` Mark H Weaver
2013-02-19 10:14 ` Mikael Djurfeldt
2013-02-19 15:41 ` Mark H Weaver
2013-02-19 16:42 ` Mikael Djurfeldt [this message]
2013-02-19 16:58 ` Mikael Djurfeldt
2013-02-20 14:21 ` Ludovic Courtès
2013-02-22 2:52 ` Mark H Weaver
2013-02-22 9:36 ` Mikael Djurfeldt
2013-02-22 15:45 ` Ludovic Courtès
2013-02-22 15:54 ` Ludovic Courtès
2013-02-19 23:51 ` Mikael Djurfeldt
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/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA2Xvw+W6M8Nm2h_e0BE0o=pE0ntwwv3-QZrfVcefOuq9b9otw@mail.gmail.com' \
--to=mikael@djurfeldt.com \
--cc=guile-devel@gnu.org \
--cc=mhw@netris.org \
/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.
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).