srfi-88 keyword / symbol ambiguity
Hi,
It looks like the changes to the reader to support SRFI-88-style keywords
lead to some ambiguities when it comes to whether a token is a symbol or a
keyword. Specifically, it's no longer possible to create a symbol via
quoting if that symbol ends in a colon:
guile> (use-modules (srfi srfi-88))
guile> (keyword? foo:)
#t
guile> (keyword? 'foo:)
#t
guile> (symbol->string 'foo:)
Backtrace:
In standard input:
6: 0* [symbol->string {#:foo}]
standard input:6:1: In procedure symbol->string in expression
(symbol->string (begin #)):
standard input:6:1: Wrong type argument in position 1 (expecting symbol):
#:foo
ABORT: (wrong-type-arg)
This is particularly bad because it breaks a lot of code that calls
`use-modules' with the :prefix or :rename syntax -- from looking at some of
the core libraries, it seems like it's pretty common to use rename-prefixes
that end in a colon. So, for example, the ice-9 debugger modules don't work
after loading `(srfi srfi-88)'.
I'm not sure yet what the fix would be -- maybe the reader should avoid
converting a token into a postfix-style keyword if it's obvious from the
read state that a symbol is desired (i.e., the quote character is prefixed),
but that probably doesn't cover all the possibilities.
Regards,
Julian
Re: What new libraries or functionality does Guile need?
Hello!
Mike Gran <[EMAIL PROTECTED]> writes:
> Hi- If you could ask someone to write a library or package a set of
> functionality for Guile that it doesn't currently have, what would it
> be?
Unicode support in core Guile, FUSE bindings & GNU Hurd file system
library bindings (a unified interface to both could be provided),
reviving DMD ("Daemon managing Daemons", a replacement for `init')
and... actual integration of Guile in a variety of applications, with
teasers showing how cool it is. :-)
(Of course, I could think of many other ideas... ;-))
> (My personal projects are near completion, and I may have some
> Saturdays free.) -Mike
Great! So Gano itself is nearing completion? If so, that's good news.
I'm sure some of your free time could be used maintaining it then. ;-)
Cheers,
Ludo'.
Re: Getting a type of a variable
Hello, "Maciek Godek" <[EMAIL PROTECTED]> writes: > The solution of my dreams is that it would turn out > that there's a function defined in the scm api: > scm_t_bits scm_get_type(SCM *var) > that returns a type tag and that there's a way to decipher > the contents of this return value, and that it is wisely > defined for all builtin types. If you are to dive into such low-level things, you could implement in Scheme type tag "deciphering". You'd use the `object-address' procedure, and then re-implement type tag encoding/decoding from "libguile/tags.h" at the Scheme level. That'd be an interesting exercise as the Scheme implementation would be readily understandable (compared to obscure C macros and informal comments). Otherwise, Andy's suggestion may be wiser. ;-) Thanks, Ludovic.
Re: What new libraries or functionality does Guile need?
--- On Sun, 7/20/08, Ludovic Courtès <[EMAIL PROTECTED]> wrote: > > Great! So Gano itself is nearing completion? If so, > that's good news. > I'm sure some of your free time could be used > maintaining it then. ;-) Ha ha. My real-world has moved away from ncurses and the console. So, there will never be a Gano toy editor. I just intend to finish the wrap and documentaton of ncurses (core, panel, form, menu) and call that the endpoint. Maintenance shouldn't be a problem, since all my code is always perfectly bug free. :-) -Mike
Re: What new libraries or functionality does Guile need?
() Mike Gran <[EMAIL PROTECTED]> () Fri, 18 Jul 2008 10:13:04 -0700 (PDT) If you could ask someone to write a library or package a set of functionality for Guile that it doesn't currently have, what would it be? I would ask for an API-upgrade program. This program would scan C source to identify API elements that newer Guile no longer supports and substitute them with equivalent constructs that newer Guile does support. It should be able to operate w/o modifying the original tree, support an interactive repl for human-override, and keep a database of the override decisions (w/ annotations). The database should be exportable and have a published access / modification protocol. thi
