Re: Uninterned symbols

[Martin Grabmueller]

> From: Marius Vollmer <address@hidden>
> Date: 17 May 2001 00:50:30 +0200
> 
> The canonical solution is to have uninterned symbols, i.e. symbols
> that are not in the global hash table.

So this part would be quite easy, wouldn't it?  Just create a symbol
without looking at the global table.  I can do that if you haven't
started yet.

> They are easy to provide, but we should also think about printing and
> reading uninterned symbols then.  I think it's OK to print uninterned
> symbols somewhat specially (and readably) and use the mechanism for
> printing shared structure to identify `eq' uninterned symbols.
> 
> (Incidentally, can `read' cope with shared structures?  It doesn't
> look like it can.  Things like `#0#' conflict with the array syntax
> since the hash extension don't deal with e general number prefix.  One
> more thing to fix...)

Do we really need this?  I don't think `read' is supposed to work with
shared structures.  After all, there is quite a bunch of thing which
can be printed but not read in (procedures, smobs. etc.)

> What about using some variant of #{...}# to print uninterned symbols?
> Would be people feel comfortable about changing it incompatibly?  Or
> should we invent a new hash dispatch, like `#~unique'?  Or a new
> syntax altogether?
> 
> (The uninternedness of a symbol can be flagged by one bit of its
> hashing value).

Personally, I would favor using SRFI-10s ,#() construct for that, but
other's may think different.  Why invent a new syntax when we can have
one without using a valuable # code.  I imagine something like this:

,#(uninterned-symbol foobar)
=>
<symbol which is not eq? to any symbol except one read in by another
 ,#(uninterned-symbol foobar)>

Hmm, after thinking about this: We would need a second global table
for uninterned symbols if we wish to read them in again, regardless of
the printing method we choose.

While we're at it: would anyone mind if I changed the reader to
_first_ look for hash reader extensions _before_ checking the builtin
ones?  That would make it possible to overwrite existing hash reader
characters, for example for overwriting #f for providing SRFI-4
homogeneous vectors (which are much cleaner as Guile's ones, IMHO.)

Regards,
  'martin