RE: `thunk-let'?

[Drew Adams]

> I think it certainly is useful.  And it allows you to write nicer code
> because you don't have to use (low-level) thunk objects explicitly
> (thus, it's a reasonable abstraction).  I'm just only 97%, and not 100%,
> sure that it is the optimal solution for the problem it solves.
>
> So, "half baked" is an exaggeration.  Anyway, the macro makes it much
> easier to write more efficient code in an easy way and clean style, so I
> don't doubt it is useful now, in Emacs.

FWIW: I'm the one who used the term "half-baked".  But I did not
mean to suggest that this contribution is in any way half-baked.
Knowing your work a bit, Michael, I'd assume that this is not at
all half-baked.  (Not that there is anything wrong with stuff
that is half-baked - it too can be useful.)

I questioned only the purpose of having a library, apparently
`subr.el', whose _purpose_ is to act as a sort of sandbox of
stuff that, for whatever reason, someone doesn't consider quite
ready for primetime.

To me, whatever we deliver as part of Emacs should be
considered supported (until it's not).  If we're really worried
about the quality of something then the choice is not to deliver
it. If we deliver something to users we should put it in an
appropriate file to begin with, not in a special "sandbox" file.

And whether to document something in the manuals should not
depend on how polished we think it might be.  Other criteria
(the usual ones) should decide inclusion in a manual.

Those are the only points I meant to make, when I said:

"Whether we should have a library that is for "half-baked"
stuff is debatable."

"I don't think it makes sense to decide whether something
gets documented in the manuals based on how well baked we
think it is."

"We should WANT users to try half-baked stuff that we
deliver.  That's how it gets improved."