Re: syntax-local-binding

[Mark H Weaver]

Andy Wingo <address@hidden> writes:

>> Your priorities are reversed from what they ought to be.
>>
>> What you _should_ be worried about is making commitments in our API that
>> we must continue to support forever.  This is a _real_ problem, since it
>> constrains our ability to modify our implementation in the future.
>
> I know I'm going to sound like Mr. Collins in Pride and Prejudice here,
> but I flatter myself that I know a thing or two about managing change --
> I mean, replacing the lazy-memoizing evaluator with the compiler,
> retrofitting psyntax into Guile, the whole subr mess, etc.

These are certainly impressive accomplishments, and I salute you for
this excellent work! :)

However, these accomplishments do not demonstrate that you understand
the importance of hiding implementation details so that future Guile
hackers can make similar transformations a decade or two from now.

For example, you seem unabashedly content to lock us into using psyntax
forever, despite the fact that it has known deficiencies having to do
with its phase story, as well as limitations in its handling of hygiene
in complex macros.  (c.f. "Improved hygiene", SRFI 72).  I don't mean to
suggest that we should replace psyntax anytime soon, but we might want
to replace it in a decade or two.  Therefore, it concerns me when I see
internal psyntax representations exported in our API.

> But frankly though, regarding change, while we do need the freedom to
> modify some things, some other practical freedoms just don't make the
> cost/benefit cut, for me.

I agree that sometimes practical necessity outweighs the need to hide
implementation details.  However, in this case, the only "benefit" is to
satisfy your desire to keep `the-environment' out of psyntax.

> This conservatism is preventing Guile from adding features.  And we do
> need features -- local-eval and syntax-parse among them.

For the record, I absolutely want Stefan to have what he needs to
implement `syntax-parse'.  My understanding is that all he needs is a
way to associate properties with syntactic keywords.  Toward that end, I
proposed that we should add something analogous to procedure properties
for macros.  This can be done without exposing internal details as you
have done.

> But what if they're the wrong interface?
>
> Well, then we use the normal deprecation mechanism to get rid of them,
> eventually (in the 2.2 series, for example).  We learned something.
> Users get warned off the code.  Life goes on.

Yes, this is always an option, but it is a _painful_ option for all
involved.  If we can already foresee the need to deprecate an interface,
wouldn't it be better not to add it in the first place?

* * * * *

Anyway, I can plainly see that your mind is set on this, and that all of
the above words were a waste of effort, so I'm going to try to drop it.

I just have one final request: please at least change the lexical
environments in your `local-eval' implementation to use the future-proof
`evaluator procedure' representation, as I have done in mine.

FWIW, criticisms aside, I _do_ very much appreciate that you heard my
plea for local-eval in 2.0.4, and that you have put so much time into
this.  Thanks for that, and for all the wonderful things you have done
for Guile and GNU.

      Mark