Patch: Arbitrary Symbols between ||

[Robert Pfeiffer]

Hello everybody,

this patch implements a pipe-delimited syntax for symbols. The Reader
parses |this symbol| and one symbol. Symbols containing clojure syntax
are printed in this form, so they can be printed and read in again.

example: (.toString (symbol "()")) => "|()|"

What do you think?

Robert Pfeiffer

[Rich Hickey]

On Jan 13, 4:56 pm, "Robert Pfeiffer" <pfeiffer.rob...@googlemail.com>
wrote:

I am interested in symbols with arbitrary names, but I don't think
this is the right approach. First, it can't have such a detrimental
effect on normal symbols - the toString in the patch is quite
inefficient. Second, it would be better not to replicate the logic for
macro characters etc that already exists in the reader. That's not to
say the reader stuff is ready for reuse as is, but making it so is the
right thing.

I haven't fully thought out how this ought to work (there's likely a
speed/space tradeoff somewhere), and it is pretty low priority.

Rich

[Christian Vest Hansen]

On Wed, Jan 14, 2009 at 1:59 PM, Rich Hickey <richh...@gmail.com> wrote:
>
> I am interested in symbols with arbitrary names,
>

Why is this interesting?

--
Venlig hilsen / Kind regards,
Christian Vest Hansen.

[Robert Pfeiffer]

On 14 Jan., 13:59, Rich Hickey <richhic...@gmail.com> wrote:

> [...] the toString in the patch is quite
> inefficient.

Because symbols are immutable, they could cache the printable
representation in an extra field, but this would double the space
occupied by them.

> Second, it would be better not to replicate the logic for
> macro characters etc that already exists in the reader. That's not to
> say the reader stuff is ready for reuse as is, but making it so is the
> right thing.

Issue 13 is related to this. Syntactic validation of symbols in
clojure.core/symbol depends on the reader syntax of clojure also.

Would this patch eliminate the need to validate symbols? Are there
other constraints than that the printed representation read again
should result in the same symbol?

Robert Pfeiffer

[Rich Hickey]

On Jan 14, 8:47 am, "Christian Vest Hansen" <karmazi...@gmail.com>
wrote:
> On Wed, Jan 14, 2009 at 1:59 PM, Rich Hickey <richhic...@gmail.com> wrote:
>
> > I am interested insymbolswith arbitrary names,
>
> Why is this interesting?
>

It supports working with names from some arbitrary external namespace
symbolically.

Rich

[Rich Hickey]

On Jan 14, 10:53 am, Robert Pfeiffer <pfeiffer.rob...@googlemail.com>
wrote:

> On 14 Jan., 13:59, Rich Hickey <richhic...@gmail.com> wrote:
>
> > [...] the toString in the patch is quite
> > inefficient.
>

> Becausesymbolsare immutable, they could cache the printable

> representation in an extra field, but this would double the space
> occupied by them.
>
> > Second, it would be better not to replicate the logic for
> > macro characters etc that already exists in the reader. That's not to
> > say the reader stuff is ready for reuse as is, but making it so is the
> > right thing.
>
> Issue 13 is related to this. Syntactic validation ofsymbolsin
> clojure.core/symbol depends on the reader syntax of clojure also.
>

> Would this patch eliminate the need to validatesymbols? Are there

> other constraints than that the printed representation read again
> should result in the same symbol?
>

Again, I haven't thought this through, but the general idea is to put
this logic in a single place.

Rich