[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Guile-commits] GNU Guile branch, string_abstraction2, updated. 823e

From: Andy Wingo
Subject: Re: [Guile-commits] GNU Guile branch, string_abstraction2, updated. 823e444052817ee120d87a3575acb4f767f17475
Date: Fri, 29 May 2009 11:35:33 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)

Hey Mike,

On Thu 28 May 2009 21:57, Mike Gran <address@hidden> writes:

> Also, just for the record, it seems obvious that this character 
> encoding pragma should only work on files, which is fine.  I think
> that is the way it would work.  Once could imagine a use where
> someone loaded code into a string and then passed it to scm_read()
> for interpretation.  In this case, I think "coding: XXXX" or
> whatever should not be interpreted.

Hmm, dunno. I feel like many of Guile's users might be doing this. OTOH
they don't have `coding' support. I guess I can see your point here.

> scm_read() can't handle this on its own because it has no "state".
> It is called once per expression.

If scm_read() looks for the coding as a property of a port, I can
imagine it mutating that value too.

> The procedure scm_read is firm API and takes a port, which means 
> that the s-expression it reads will be interpreted in the context of
> the port's encoding.  It is the default reader.
> But, if the reader is modified to take its character encoding from
> the top of the file, then the reader can't use scm_read directly 
> as it would use the port's encoding.

Why not allow scm_read() to detect this, and modify the port's encoding?

Apologies if I missed the explanation :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]