GNU bug report logs - #21829
guix import hackage failures

Previous Next

Package: guix;

Reported by: Paul van der Walt <paul <at> denknerd.org>

Date: Wed, 4 Nov 2015 16:26:03 UTC

Severity: normal

Done: ludo <at> gnu.org (Ludovic Courtès)

Bug is archived. No further changes may be made.

Full log


Message #50 received at 21829 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Federico Beffa <beffa <at> ieee.org>
Cc: 21829 <at> debbugs.gnu.org, Paul van der Walt <paul <at> denknerd.org>
Subject: Re: guix import hackage failures
Date: Thu, 26 Nov 2015 09:46:00 +0100
Federico Beffa <beffa <at> ieee.org> skribis:

> On Wed, Nov 25, 2015 at 10:45 PM, Ludovic Courtès <ludo <at> gnu.org> wrote:
>> Federico Beffa <beffa <at> ieee.org> skribis:
>
> [...]
>
>>>>> +      ;; indentation based block recognition.
>>>>> +      (begin (unread-char #\newline port) (read-char port) 0)
>>>>
>>>> Isn’t this equivalent to: 0 ?
>>>
>>> No. This is because at the start of a new line we check if and how
>>> many indentation blocks have ended. If the last line doesn't terminate
>>> this check is no done.
>>
>> More generally, it looks like:
>>
>>   (begin (do-effect!) (undo-effect!) val)
>>
>> which I thought reduces to:
>>
>>   val
>
> Since we are doing IO, there are side effects. The key difference is
> the result of '(port-column port)' and that triggers what I mentioned.

Oooh, I see, thanks for explaining!  Then what about a comment like:

  Read a newline from PORT to reset its ‘port-column’, as expected by
  the indentation-based block recognition code.

I think it would be helpful for those like me who are hard of hearing.
;-)

Ludo’.




This bug report was last modified 9 years and 239 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.