[Top][All Lists]

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

Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as tople

From: Daniel Colascione
Subject: Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling
Date: Tue, 22 Apr 2014 10:22:51 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

On 04/22/2014 08:06 AM, Stefan Monnier wrote:
> And if you insist on doing it this way, you can wrap the cl-defstruct
> within an eval-and-compile.
> The problem with relying on CL semantics, is that it means that your
> iface-declare will only work at top-level, e.g. not within a `cl-letf'
> or a `cl-flet' or ...
> a
> So while the current semantics bites you, CL's semantics will also bite
> you in other cases.  IOW They just try to avoid biting you in a couple
> more cases, but they can't avoid the fundamental problem.
> The above example doesn't convince me yet that the convenience of hiding
> the fundamental problem in those few cases is worth the trouble.
> Maybe to solve this problem right, we'd need to do it in
> macroexpand-all: detect a "defmacro" and add the corresponding macro to
> macroexpand-all-environment for the rest of the expansion.  Not sure
> it'd be worth the trouble, but at least it would fix this "toplevel
> special case".

That's fine too, provided we handle the toplevel case correctly. Would
you accept a change that did that?

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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