Re: defining new character names?

[Matthias Koeppe]

"Lars J. Aas" <address@hidden> writes:

> The most "transparent" solution would be to allow
>
>   (define #\paren-close #\051)
>
> [If the first token looks like a character constant, the second must
> be one too?]  Would that be possible to implement without any overhead
> on the define implementation?  Would it break something?

It would break everything.

DEFINE does not operate on "tokens".  You seem to be missing that
there are two phases when you feed forms into Guiles:

 1. The reader reads the string "(define paren-close-character #\051)".
    It turns the tokens "define" and "paren-close-character" into
    symbols and handles the read-syntax "#\", turning "#\051" into a
    character object.  It returns a list of two symbols and a
    character object.

 2. The evaluator evaluates this list.

Because in your example #\paren-close is not known read-syntax, the
reader will signal an error.

As I wrote before, I believe you are misunderstanding the role of the
#\ read syntax.  It is not meant as a syntax for character constants;
rather it is a way to specify literal characters, like

       #\c

There is also no special syntax for string constants, or integer
constants in Guile; there only is read syntax for literal strings, like
        
        "Error",

and literal numbers, 

        314159265.

If you want to create a named constant, you simply do

   (define error-message "Error")
   (define scaled-pi 314159265)
   
In the same way, you do
   
   (define paren-close-char #\051)

or

   (define paren-close-char (integer->char 41))

What I think _would_ be useful for Guile is a new DEFINE form that
creates constant variables, like DEFINE-CONSTANT, so you could say
        
   (define-constant paren-close-char (integer->char 41)).

This may serve useful for compiler optimizations, because the compiler
(if any) could assume that the value of the variable never changes.

Regards,

-- 
Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe