scm_i_print_symbol_name() in libguile/print.c ...

scm_i_print_symbol_name() in libguile/print.c ...

[Wolfgang J Moeller]

scm_i_print_symbol_name() in libguile/print.c ought not insert backslashes
into "weird" symbol names that it prints using #{ ... }#,
because the "extended read syntax" (in agreement with the documentation)
doesn't treat backslashes specially, nor _usually_ needs escaping. (*)

I notice that the bug is already present in GUILE V1.8 .

(*) Apparently, reading a "weird" symbol whose name contains "}#"
    isn't provided for.


Example:

===

scheme@(guile-user)> (string-length (symbol->string '#{a b}#))
$1 = 3
scheme@(guile-user)> (string-length (symbol->string (with-input-from-string
                      (with-output-to-string (lambda () (display '#{a b}#)))
                      (lambda () (read)))))
$2 = 4

===

Best regards,

Wolfgang J. Moeller, Tel. +49 551 47361, wjm<AT>heenes.com
37085 Goettingen, Germany | Disclaimer: No claim intended!
http://www.wjmoeller.de/ -+-------- http://www.heenes.com/

Re: scm_i_print_symbol_name() in libguile/print.c ...

[Andy Wingo]

On Tue 05 Apr 2011 17:27, Wolfgang J Moeller <wjm@heenes.com> writes:

> scm_i_print_symbol_name() in libguile/print.c ought not insert backslashes
> into "weird" symbol names that it prints using #{ ... }#,
> because the "extended read syntax" (in agreement with the documentation)
> doesn't treat backslashes specially, nor _usually_ needs escaping. (*)

Fixed now, I think.

Thanks for the report,

Andy
-- 
http://wingolog.org/

Re: scm_i_print_symbol_name() in libguile/print.c ...

[Wolfgang J Moeller]

On Mon, 11 Apr 2011, Andy Wingo wrote:

> On Tue 05 Apr 2011 17:27, Wolfgang J Moeller <wjm@heenes.com> writes:
>
> > scm_i_print_symbol_name() in libguile/print.c ought not insert backslashes
> > into "weird" symbol names that it prints using #{ ... }#,
> > because the "extended read syntax" (in agreement with the documentation)
> > doesn't treat backslashes specially, nor _usually_ needs escaping. (*)
>
> Fixed now, I think.
>
> Thanks for the report,

Subsequently I noticed that `psyntax-pp.scm' is full of symbols
#{name\ number}# which so far, would _not_ be read in
as the original "gensym"s.

This is going to change if you re-generate `psyntax-pp.scm'
using the "fixed" GUILE. Hope it doesn't hurt ...

Thanks,

Wolfgang J. Moeller, Tel. +49 551 47361, wjm<AT>heenes.com
37085 Goettingen, Germany | Disclaimer: No claim intended!
http://www.wjmoeller.de/ -+-------- http://www.heenes.com/

Re: scm_i_print_symbol_name() in libguile/print.c ...

[Andy Wingo]

Hi,

On Mon 11 Apr 2011 14:23, Wolfgang J Moeller <wjm@heenes.com> writes:

> Subsequently I noticed that `psyntax-pp.scm' is full of symbols
> #{name\ number}# which so far, would _not_ be read in
> as the original "gensym"s.
>
> This is going to change if you re-generate `psyntax-pp.scm'
> using the "fixed" GUILE. Hope it doesn't hurt ...

No, it doesn't.  The backslash was an accident, and anyway after fixing
the reader too #{foo\ bar}# reads the same as #{foo bar}#.  Those
symbols need to be unique lexically, but not globally, so it's not a big
deal.  At some point we will need globally unique gensyms but this
change does not adversely impact the current state of things.

Cheers,

Andy
-- 
http://wingolog.org/

Re: scm_i_print_symbol_name() in libguile/print.c ...

[Andy Wingo]

Hi Wolfgang,

On Tue 05 Apr 2011 17:27, Wolfgang J Moeller <wjm@heenes.com> writes:

> scm_i_print_symbol_name() in libguile/print.c ought not insert backslashes
> into "weird" symbol names that it prints using #{ ... }#,
> because the "extended read syntax" (in agreement with the documentation)
> doesn't treat backslashes specially, nor _usually_ needs escaping. (*)
>
> I notice that the bug is already present in GUILE V1.8 .

Indeed, good catch.  I had seen this before but didn't fully understand
it.

> (*) Apparently, reading a "weird" symbol whose name contains "}#"
>     isn't provided for.

Also; irritating.  Relatedly it does not seem that Guile supports R6RS
hex escapes in symbols.  I guess the right thing to do is to allow for
R6RS hex escapes in symbols, and escape '}', along with anything that's
not a printable character.

Andy
-- 
http://wingolog.org/

Re: scm_i_print_symbol_name() in libguile/print.c ...

[Wolfgang J Moeller]

On Mon, 11 Apr 2011, Andy Wingo wrote:

>[...]
> > (*) Apparently, reading a "weird" symbol whose name contains "}#"
> >     isn't provided for.
>
> Also; irritating.  Relatedly it does not seem that Guile supports R6RS
> hex escapes in symbols.  I guess the right thing to do is to allow for
> R6RS hex escapes in symbols, and escape '}', along with anything that's
> not a printable character.

Having any sort of escapes mixed with #{ }# notation would be incompatible -
maybe you ought no longer generate #{ }# on output, but switch to R6RS escapes
throughout. Since there has been (in my understanding) no way to read symbols
containing "}#" so far, just keep the "transparent" treatment of those
guile-private brackets on input.

Best regards,

Wolfgang J. Moeller, Tel. +49 551 47361, wjm<AT>heenes.com
37085 Goettingen, Germany | Disclaimer: No claim intended!
http://www.wjmoeller.de/ -+-------- http://www.heenes.com/

Re: scm_i_print_symbol_name() in libguile/print.c ...

[Andy Wingo]

Hello again :)

On Mon 11 Apr 2011 15:08, Wolfgang J Moeller <wjm@heenes.com> writes:

> Having any sort of escapes mixed with #{ }# notation would be incompatible -
> maybe you ought no longer generate #{ }# on output, but switch to R6RS escapes
> throughout. Since there has been (in my understanding) no way to read symbols
> containing "}#" so far, just keep the "transparent" treatment of those
> guile-private brackets on input.

We have a choice of ensuring that:

  (equal? (with-input-from-string (object->string sym) read) sym)

or preserving the old behavior that introduced spurious backslashes in
the symbol names.  Incidentally it does appear that }# could be read, in
theory, given the fact that }# in a name would be written out as }\#.
Strange stuff.  I think interpreting \ as a general escape is compatible
with the intentions of that code, and \x...; is generally compatible as
well, if we assume that nobody was escaping x in their own code, because
Guile sure wasn't.

Anyway, I do think that providing an option to just use r6rs syntax for
serialization is a good idea.  Unfortunately you can't do it in general,
because there is the #{}# case to deal with, but oh well.

Cheers,

Andy
-- 
http://wingolog.org/