unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
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)

  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).