[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Improved source properties and errors; => within case

From: Mark H Weaver
Subject: Re: [PATCH] Improved source properties and errors; => within case
Date: Wed, 08 Feb 2012 17:30:07 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

Hello all,

I have committed an improved version of this patch set to stable-2.0.
See below for more.

I wrote:
> Hmm.  I don't know if this is what you meant, but it occurs to me that
> as I've currently implemented them, both (cond (else (define x 5) x))
> and (case 1 (else (define x 5) x)) are allowed.  I'll have to make sure
> that those raise errors.

In the end, I decided that I couldn't safely make this change.  In
earlier versions of Guile, and in the reference implementations of the
R5RS/R7RS, (cond (else e e* ...)) and (case x (else e e* ...)) expand to
(begin e e* ...), and thus allow internal definitions.  Even though the
docs don't explicitly specify that this is allowed, I was uncomfortable
going out of my way to disallow this.

Also, this reminds me of another change in 'case' introduced by my patch
set (now committed to stable-2.0) that I forgot to mention before:

Previously (and in the reference implementations), (case expr c c* ...)
expands to (let ((key expr)) (case key c c* ...)) if and only if 'expr'
is a parenthesized expression.  Now, we introduce the 'let' in _all_
cases.  The reason is that, in the presence of identifier-syntax, a bare
identifier could expand into anything.

Andy Wingo <address@hidden> writes:
> And is it useful to have an exception for empty strings?  I would think
> that it would be fine to return fresh empty strings.  The compiler would
> DTRT.  I don't care much though.

Good point.  'read' now returns fresh strings in all cases, even for
empty strings, and thus we can apply source properties to empty strings
(and now we do).

Noah Lavine <address@hidden> writes:
>> I guess that means I'll have to insert a '#f'
>> like I did for local-eval.  Do you see a better way?
> This makes me think that we should have a macro called
> expression-context for putting things in expression context. It's not
> that it's hard to insert #f, but that makes the source code less clear
> unless people know why a random `#f' would appear in the code. What
> does everyone else think?

Currently, it seems that (ice-9 local-eval) would be its only user, but
nonetheless this sounds like a good idea to me.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]