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

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Sun, Feb 9, 2020 at 7:00 PM <address@hidden> wrote:
>
>>
>> Now my original solution was aimed at staying in binary even during
>> Scheme times while Antonio Ospite does go all-in on UTF-8 in Scheme.  So
>> the result of combining my and his work is a chimæra which I am less
>> confident about than my own code on its own.  Being in binary mode for
>> Flex means that we can deal robustly with code that is not properly in
>> UTF-8.  For example, we had input files that were ASCII-only except for
>> some comments containing latters in the Latin-1 plane.  In binary mode,
>> our lexer deals gracefully with such abominations while Guile balks at
>> such files when doing UTF-8 processing.
>>
>
> The reason we've been doing it this way, is that Gary gave us this code in
> 1999, when we didn't know anything about encodings, ports or Scheme, and it
> worked.
>
> However, there is no good reason why we should have port for the entire
> file.

Error message context possibly?  #{ ... #} is interpreted from a string
which means that the context is missing (I've thought about diverting a
larger string for that purpose but that seems awkward).  Not having the
context for #anything seems like more of a nuisance.  Can this be an
issue?

> If you have a .ly file that doesn't have a single # , then there is no
> reason to have a port at all.

Well, on the other hand few documents don't have even a single # since
it is used for banal things like number entry.  And not having a few
thousand port openings is possibly advantageous.  Usually a port should
be easier to reposition than to open, though our way of repositioning,
if I am not mistaken, is not particularly efficient.

-- 
David Kastrup