Re: usage of various characters '[', ']', and ':'

[Per Bothner <per at bothner dot com>]

Felix S Klock II <pnkfelix@MIT.EDU> writes:

> Kawa's handling of the colon character seems to violate R5RS,

Yes, technically it does.  That is why Guile picked the rather horrid
'#:KEYWORD' syntax.

> and thus
> sticks out like a sore thumb for my work.  I can't currently support
> handling the ":=" operator in the language I'm parsing because of
> Kawa's handling of colon. 
> Here are some example evaluations:
> 
>   (quote :=)		==>	=: 
> 
>   ':=asfda		==>	=asfda:

You do have the option of quoting the colon (as in Common Lisp):
(quote |:=|) or (quote \:\=)

> All this of course is probably be considered perfectly valid, given
> the description of Keywords in section 7.3 of the Kawa manual.  But I
> would like a way to treat the colon in an R5RS compliant manner, even
> if it were a command-line or environmental option to disable Keywords,
> [which I don't use]

Well, I have considered a --pedantic or a --r5rs flag which would force
strict R5RS behavior.  See below.

It would also restrict inlining (which
should also have a separate flag).

> Another option (which is probably cleaner, in terms of overall design)
> would be to make quotation a higher precedence operation on tokens
> than keywordization (in other words, if I say ':asfdasasfsasa, I'm
> saying I want a symbol, not a keyword).

I don't think it is cleaner - it' rather a kludge.  You can of course
quite keywords too, though since they are self-evaluating you would
seldom need to.

> Quote is a special form
> anyway, so I don't believe that giving it this behavior is out of
> line.

The ' prefix is read syntax.  Special forms are handled at a later
stage, so special handling in the quote special form woudl be too late.

> In any case, I got around the problem by hacking the code, breaking
> keywords in the process, but I would like to see a real solution in
> the main repository that still provided keyword support.

Well, if the escape character solution is unacceptable (it is also
non-R5RS), then I think a --rs5s flag seems a good choice.  Ideally,
--rs5s should be considered a language specification, just like
the existing --scheme and --commonlisp flags.  In the current
framework, you'd make a sub-class of Scheme and perhaps ScmRead.
(At least the latter can be avoided by having Scheme or its subclass
copy some flags over to ScmRead.)

> On the other topic, I haven't been able to discern what status '[' and
> ']' have been given in Kawa's Scheme system.  They seem to do
> SOMETHING, but its unclear to me what it is.

They are meant to be synonyms for '(' and ')', which is feature (?)
that some other Lisp implementations have.  It is supposed to make
it easier to match parens.
> 
> 	   [+ 2 3 ]	   ==>	 5
> 	   [+ 2 3]	   ==>  ...prompts for further input

Yes, this is because ']' isn't recognized as a delimiter,
only when standalone.  This may have broken when I implemented
the reader framework.  It is a bit ugle, because I have things
like '<int[]>' which I want to have parsed as a 7-character symbol
(which names a Java array type).

> Is thips just some special casing of brackets to deal with array types,
> and I am exploring dark dark terrain that I shouldn't be poking my
> nose into? 

Yes and no.  If '[' and ']' are supported, they should work.
But '<int[]>' also needs to work, and that is more important.
It is possible to make both work (for example see if the token
contains a previous '[') though perhaps it is not worth it.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/