Re: Parse inline scheme using per-expression port (issue 557330043 by address@hidden)

[Han-Wen Nienhuys]

On Fri, Feb 7, 2020 at 5:39 PM David Kastrup <address@hidden> wrote:

>
> Private reply intended?  Feel free to copy this to the review if you
> want to.
>

yes, but if you are fine, then back to the list.


> Han-Wen Nienhuys <address@hidden> writes:
>
> > Just so you know, I am confused by this conversation.
> >
> > I am trying to ask you to review this code. It's not clear to me whether
> > you prefer the code I wrote here, or the 2014 code.
>
> I think it is overkill and/or counterproductive for the intermediate
> goal of getting stuff to work under Guilev2+ in its original unchanged
> form, and I think it would be easier to evaluate whether your approach
> is desirable and/or necessary once we have achieved that intermediate
> goal.
>
> That intermediate goal seems important to me in order not to have the
> migration effort run out of steam eventually (like it previously did
> after a lot of tiresome back-and-forth with Guile central) but I cannot
> properly estimate or direct the amount of steam you have at your
> disposal.
>

Here is my take on things.  Even though GUILE 2.x is not optimal, because
the GC is more expensive, it is unfeasible and undesirable to stay on an
unmaintained and ancient branch of GUILE. I don't see fundamental problems
with migrating to 2.x, and I think we should do it ASAP. I'd rather get in
the hands of users sooner than later.

I think GUILE 2.2 with its slower BDW garbage collector but faster
evaluation would let us throw away a lot of very finicky code for dealing
with memory management. This comes at the price of a slightly slower
execution. However, since our largest problem is that almost nobody
understands the code base well enough, something that drastically
simplifies the code is at a moderate price is a good tradeoff.

This code would not be my choice since it goes to a lot of effort in
> order to achieve nothing substantially different from what we had before
> and what the referenced patch tries coaxing the Guile port machinery to
> do.  Changing encoding methods in midstream, which is what your patch
> essentially does, is a nightmare for keeping input locations work, like
> they are needed in point-and-click and in error message locators.
>

Why do you say it is a nightmare? All the input locations are char* as
before and they are computed exactly in the same way as before. There is
also no such concept as "mid-stream", as this change creates a separate
mini-stream for each scheme expression we parse.

The only distasteful part is the code for the 1.8 API for ports, which we
could drop once we move to 2.x

But I don't see a clear path for a migration strategy to "UTF-8 like
> Guile intended" either.


Why not? The Guile unicode strings are lazy, so they are free if you don't
use unicode, and we mostly don't.


>   So my first choice was to stick with the "UTF-8
> but don't tell Guile" strategy we had before, get things working in that
> context, and see whether this makes it easier to find a better path from
> there.
>

FWIW, the 2014 commit lacks explanation and comments of what is going on. I
would rather see "production quality" code that we submit to master, so we
have  a precise record of what is going on, and can make sure the code
keeps working.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen