* Keyword syntax
@ 2004-10-04 18:27 Marius Vollmer
2004-10-04 18:44 ` Roland Orre
2004-10-04 18:51 ` Paul Jarc
0 siblings, 2 replies; 4+ messages in thread
From: Marius Vollmer @ 2004-10-04 18:27 UTC (permalink / raw)
Hi,
I'm considering to change keywords are read or written by Guile, to
make the two operations more consistent with each other.
Right now, keywords are read as a single token and a part of that
token is made the keyword name, which is a symbol.
For example, a token can be "#:foo" (without the double quotes) and
the name of the keyword is the symbol named "foo". Also, "#:12" gives
a keyword with a symbol as the name that itself has the name "12".
Now, "12" is not a valid way to write this symbol in Scheme, and there
for Guile writes the keyword #:12 in the following funny way:
guile> #:12
#:#{12}#
The "#{12}#" is the syntax to write a symbol with an arbitrary name.
However, reading this printed form gives a different keyword.
guile> #:#{12}#
#:#{\#{12}\#}#
I can see two ways to fix this: 1) changing the way keywords are read and
2) changing the way they are printed.
As to 1), the simplest change would be to just do the equivalent of
(symbol->keyword (read port)). Thus, the name of a keyword is read as
a general Scheme datum, and is then validated to be a symbol and
converted to a keyword.
For 2), we would have to print keyword without using the symbol
printer and would have to explicitely deal with 'weird' keyword names
ourselves.
I have implemented 1) in CVS head as an experiment. Below is a sample
session, showing the differences.
I like 1) more than 2) (by a small margin) although it is a more
radical change since keywords right now are defined to have symbols as
names anyway and because it is equivalent to doing
(read-hash-extend #\:
(lambda (chr port)
(symbol->keyword (read port))))
which I like because it is very straightforward.
Previously
guile> #:12
#:#{12}#
guile> #:#{12}#
#:#{\#{12}\#}#
guile> #:(a b c)
#:#{}#
ERROR: In expression (a b c):
Unbound variable: a
guile> #: foo
#:#{}#
ERROR: Unbound variable: foo
With 1)
guile> #:12
ERROR: Wrong type (expecting symbol): 12
guile> #:#{12}#
#:#{12}#
guile> #:(a b c)
ERROR: Wrong type (expecting symbol): (a b c)
guile> #: foo
#:foo
Opinions?
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Keyword syntax
2004-10-04 18:27 Keyword syntax Marius Vollmer
@ 2004-10-04 18:44 ` Roland Orre
2004-10-04 18:51 ` Paul Jarc
1 sibling, 0 replies; 4+ messages in thread
From: Roland Orre @ 2004-10-04 18:44 UTC (permalink / raw)
Cc: guile-user
I like 1 more also. (I often use the non standard scheme way of
reading values with #something but I don't think that will
be a problem)
Roland
On Mon, 2004-10-04 at 20:27, Marius Vollmer wrote:
> Hi,
>
> I'm considering to change keywords are read or written by Guile, to
> make the two operations more consistent with each other.
>
> Right now, keywords are read as a single token and a part of that
> token is made the keyword name, which is a symbol.
>
> For example, a token can be "#:foo" (without the double quotes) and
> the name of the keyword is the symbol named "foo". Also, "#:12" gives
> a keyword with a symbol as the name that itself has the name "12".
> Now, "12" is not a valid way to write this symbol in Scheme, and there
> for Guile writes the keyword #:12 in the following funny way:
>
> guile> #:12
> #:#{12}#
>
> The "#{12}#" is the syntax to write a symbol with an arbitrary name.
>
> However, reading this printed form gives a different keyword.
>
> guile> #:#{12}#
> #:#{\#{12}\#}#
>
>
> I can see two ways to fix this: 1) changing the way keywords are read and
> 2) changing the way they are printed.
>
> As to 1), the simplest change would be to just do the equivalent of
> (symbol->keyword (read port)). Thus, the name of a keyword is read as
> a general Scheme datum, and is then validated to be a symbol and
> converted to a keyword.
>
> For 2), we would have to print keyword without using the symbol
> printer and would have to explicitely deal with 'weird' keyword names
> ourselves.
>
> I have implemented 1) in CVS head as an experiment. Below is a sample
> session, showing the differences.
>
> I like 1) more than 2) (by a small margin) although it is a more
> radical change since keywords right now are defined to have symbols as
> names anyway and because it is equivalent to doing
>
> (read-hash-extend #\:
> (lambda (chr port)
> (symbol->keyword (read port))))
>
> which I like because it is very straightforward.
>
>
> Previously
>
> guile> #:12
> #:#{12}#
> guile> #:#{12}#
> #:#{\#{12}\#}#
> guile> #:(a b c)
> #:#{}#
> ERROR: In expression (a b c):
> Unbound variable: a
> guile> #: foo
> #:#{}#
> ERROR: Unbound variable: foo
>
> With 1)
>
> guile> #:12
> ERROR: Wrong type (expecting symbol): 12
> guile> #:#{12}#
> #:#{12}#
> guile> #:(a b c)
> ERROR: Wrong type (expecting symbol): (a b c)
> guile> #: foo
> #:foo
>
> Opinions?
>
>
> _______________________________________________
> Guile-user mailing list
> Guile-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/guile-user
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Keyword syntax
2004-10-04 18:27 Keyword syntax Marius Vollmer
2004-10-04 18:44 ` Roland Orre
@ 2004-10-04 18:51 ` Paul Jarc
2004-10-18 11:56 ` Marius Vollmer
1 sibling, 1 reply; 4+ messages in thread
From: Paul Jarc @ 2004-10-04 18:51 UTC (permalink / raw)
Cc: guile-user
Marius Vollmer <marius.vollmer@uni-dortmund.de> wrote:
> As to 1), the simplest change would be to just do the equivalent of
> (symbol->keyword (read port)).
I like this way too.
> guile> #:12
> ERROR: Wrong type (expecting symbol): 12
You could add a bit of backward compatibility:
(let ((obj (read port)))
(symbol->keyword
(if (symbol? obj)
obj
(string->symbol (object->string obj)))))
But I'm not sure this would be worth it, or if there may be corner
cases where it produces a different keyword.
paul
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Keyword syntax
2004-10-04 18:51 ` Paul Jarc
@ 2004-10-18 11:56 ` Marius Vollmer
0 siblings, 0 replies; 4+ messages in thread
From: Marius Vollmer @ 2004-10-18 11:56 UTC (permalink / raw)
prj@po.cwru.edu (Paul Jarc) writes:
> Marius Vollmer <marius.vollmer@uni-dortmund.de> wrote:
>> As to 1), the simplest change would be to just do the equivalent of
>> (symbol->keyword (read port)).
>
> I like this way too.
Ok, I'll keep it that way then.
>> guile> #:12
>> ERROR: Wrong type (expecting symbol): 12
>
> You could add a bit of backward compatibility:
>
> (let ((obj (read port)))
> (symbol->keyword
> (if (symbol? obj)
> obj
> (string->symbol (object->string obj)))))
>
> But I'm not sure this would be worth it, or if there may be corner
> cases where it produces a different keyword.
This wouldn't be very much backwards compatible, I'm afraid, since
'read' is very much different from reading a token (with an internal
reader function).
We could keep more backwards compatability by continuing to read the
keyword name as a token, but only acception names that are proper
symbol names. Should we?
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2004-10-18 11:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-04 18:27 Keyword syntax Marius Vollmer
2004-10-04 18:44 ` Roland Orre
2004-10-04 18:51 ` Paul Jarc
2004-10-18 11:56 ` Marius Vollmer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).