Re: [Emacs-diffs] trunk r117002: Correctly treat progn contents as toplevel forms when byte compiling

[Stefan Monnier]

>> That's not the kind of example I was thinking if.  Do you have a real
>> example, maybe?
> Try writing a macro that emits a defstruct, then a function that uses
> cl-typep for that struct, all wrapped in the same toplevel progn.

That's getting closer to an actual example.  I still can't think of
a case where you'd want to use cl-typep in this way, tho.

> The reason we have automated tests is to make sure we can maintain this
> "level of detail". That it's not immediately useful to you isn't a
> reason not to include it. I can't believe this issue is even
> contentious: the current behavior is a clear bug.

It's a clear bug if we assume Common-Lisp semantics.  But in many cases,
Elisp chooses to provide simpler semantics, to allow a simpler and/or
more naive implementation.

I'm not yet convinced either way, but claiming it's a bug won't sway me.

We've lived with a "simpler" semantics for 30 years and you're the first
to complain about this limitation, so I'd really want to see clear
evidence that it's worth adding this complexity.

> we'd macroexpand-all?) in addition to emiting defmacros? What if the
> macro generation is implicit, as it is with defstruct, so that the
> top-level form doesn't even realize it has to employ this awful hack?

Yes, the defstruct+typep example above sounds like a good example where
my suggestion is not really workable.


        Stefan