defining new character names?

defining new character names?

[Lars J. Aas]

  Hi folks,

I'd like to be able to do something like this:

(define-character "paren-close" #\051) ; 051 is ")"

and then later

(string-index line #\paren-close)

I can of course define a normal variable for this, but then
it won't shine from the usage that it is a character in the
way the above does.

I've looked in libguile/chars.{c,h} and the guile docs, but
didn't find any obvious way to do this.  Is it possible?

The reason i'd like to do this is that inserting #\) in the
scheme file makes the vim "%" command unusable over those
blocks (and it's not as easy on the eye either), and there was
no alternate name for that char other than using the octal
ascii value.

Cheers,

  Lars J


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Marius Vollmer]

"Lars J. Aas" <larsa@sim.no> writes:

> I'd like to be able to do something like this:
> 
> (define-character "paren-close" #\051) ; 051 is ")"
> 
> and then later
> 
> (string-index line #\paren-close)
>
> [...]
> I've looked in libguile/chars.{c,h} and the guile docs, but
> didn't find any obvious way to do this.  Is it possible?

Not currently, but I think it's a good idea.

> The reason i'd like to do this is that inserting #\) in the
> scheme file makes the vim "%" command unusable over those
> blocks

vim should be fixed then, no? ;)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Keith Wright]

> Cc: guile-user@gnu.org
> From: Marius Vollmer <mvo@zagadka.ping.de>
> 
> "Lars J. Aas" <larsa@sim.no> writes:
> 
> > I'd like to be able to do something like this:
> > 
> > (define-character "paren-close" #\051) ; 051 is ")"
> >   and then later
> > (string-index line #\paren-close)
> 
> Not currently, but I think it's a good idea.

(A) Only in the context of a general mechanism to define constants.
(B) The double quotes around "paren-close" in the definition
     are surely wrong.

> > The reason i'd like to do this is that inserting #\) in the
> > scheme file makes the vim "%" command unusable over those
> > blocks
> 
> vim should be fixed then, no? ;)

Maybe so.  Not my job.

In the meantime, why not say
  (define close-char #\( ) % define )
  (string-index line close-char)

-- 
     -- Keith Wright  <kwright@free-comp-shop.com>

Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
         ---  Food, Shelter, Source code.  ---


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Keith Wright]

> From: Keith Wright <kwright@gis.net>
> 
> In the meantime, why not say
>   (define close-char #\( ) % define )
                             ^ oops, I meant ";" not "%", I got TeX brain
>   (string-index line close-char)

 Sorry.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Lars J. Aas]

Keith Wright <kwright@gis.net> wrote:
: > Cc: guile-user@gnu.org
: > From: Marius Vollmer <mvo@zagadka.ping.de>
: > "Lars J. Aas" <larsa@sim.no> writes:
: > 
: > > I'd like to be able to do something like this:
: > > 
: > > (define-character "paren-close" #\051) ; 051 is ")"
: > >   and then later
: > > (string-index line #\paren-close)
: > 
: > Not currently, but I think it's a good idea.
: 
: (A) Only in the context of a general mechanism to define constants.

Yes, that's what I was looking for.

: (B) The double quotes around "paren-close" in the definition
:      are surely wrong.

Yes, I wrote "something like" because I don't know what would be
possible for accomplishing this.  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?

: > > The reason i'd like to do this is that inserting #\) in the
: > > scheme file makes the vim "%" command unusable over those
: > > blocks
: > 
: > vim should be fixed then, no? ;)

Hehe, I sensed there was a generic problem below my concrete problem,
hence the mail.  If I thought this would only be good for vim-users,
I wouldn't have bothered...

  Lars J


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[rm]

On Wed, Aug 21, 2002 at 10:12:10AM +0200, Lars J. Aas wrote:
> Keith Wright <kwright@gis.net> wrote:
[...]
> : (B) The double quotes around "paren-close" in the definition
> :      are surely wrong.
> 
> Yes, I wrote "something like" because I don't know what would be
> possible for accomplishing this.  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?

Hmm, that most likely won't work. The interpretation of the '#\...'
tokens is done by the reader, and that will complain about an
'Unknown # object:'. I think one would have to extend guiles read-option
interface and create a new set of primitives to manipulate the readers
#\-object table.

  (set-char-constant! 'paren-close #\051)

or, probably

    (set-char-constant! 'paren-close 051)

Ralf Mattes



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Matthias Koeppe]

"Lars J. Aas" <larsa@sim.no> 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


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Lars J. Aas]

Matthias Koeppe <mkoeppe@mail.Math.Uni-Magdeburg.De> wrote:
: "Lars J. Aas" <larsa@sim.no> 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:

Sorry if I come across as a moron here ;)  I know it would only work
if define was handled closely integrated with the reader, which I now
know it obviously is not.

: 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.

Yes, this would be nice - it could perhaps also help catch bugs by throwing
exceptions when constants are tried modified.

Anyways, what I feel would be nice is to have modify/extend-access to
the reader's table of #\... character keywords, so I wouldn't be limited
to the existing set defined in libguile/chars.c.  Anyways, I'll have
to do without it for now obviously.  I'll leave it up to you Guile
wizards to decide on whether this would be something worth adding to a
future version of Guile or not.

  Lars J


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[rm]

On Wed, Aug 21, 2002 at 10:51:38AM +0200, Matthias Koeppe wrote:
[...]
> 
> It would break everything.

I agree with that (see previous post)

[...]

> 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

Hmm, what's the difference between 'character constant' and 'literal characters'
for you? The way i understand the '#\...' read extension, it also provides a
mean to ease writing hard-to-write/read character constants (like tab,
space, dc1, page, null etc.). Since it's really hard to read the following
code:
 
   (if (eq? the-char #\
   ) (display 'yes))

there is the convenience of writing:
  
  (if (eq? the-char #\newline) (display 'yes))

Now, the notion of 'hard to read/write' character is different for different
users (not _only_ vim users, french/german accented characters can be tricky
too :), so why not extend guiles read options to tailor the set of "named"
characters to the users needs?


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

Are you focusing on the 'constant'-ness?

>         "Error"

_is_ constant, afaik.
and so is 314159265

> and literal numbers, 
> 
>         314159265.
> 
> If you want to create a named constant, you simply do
> 
>    (define error-message "Error")
>    (define scaled-pi 314159265)

No. 'error-message' is not constant after that:

   (set! error-message 'moep?)

> 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.

Yes, but that's an enirely different topic ....

  Ralf

> Regards,
> 
> -- 
> Matthias K?ppe -- http://www.math.uni-magdeburg.de/~mkoeppe
> 
> 
> _______________________________________________
> Guile-user mailing list
> Guile-user@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-user


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Matthias Koeppe]

rm@fabula.de writes:

> On Wed, Aug 21, 2002 at 10:51:38AM +0200, Matthias Koeppe wrote:
>> If you want to create a named constant, you simply do
>> 
>>    (define error-message "Error")
>>    (define scaled-pi 314159265)
>
> No. 'error-message' is not constant after that:
>
>    (set! error-message 'moep?)

Don't do that then.  (What was your point?)

A named constant simply is a variable that you promise not to change.
I proposed a DEFINE-CONSTANT special form that makes the promise more
explicit.

Regards,

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


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Rob Browning]

Marius Vollmer <mvo@zagadka.ping.de> writes:

>> (string-index line #\paren-close)
>>
>> [...]
>> I've looked in libguile/chars.{c,h} and the guile docs, but
>> didn't find any obvious way to do this.  Is it possible?
>
> Not currently, but I think it's a good idea.

I'm not so sure I agree, at least not as a mechanism intended for
general use or unless we're planning to do it as part of a new SRFI.
It seems like the added benefit here (syntax hilighting or
readability?)  over just binding the char to a suitably named variable
isn't often likely to justify the immediate loss of code portability.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> Marius Vollmer <mvo@zagadka.ping.de> writes:
> 
> >> (string-index line #\paren-close)
> >>
> >> [...]
> >> I've looked in libguile/chars.{c,h} and the guile docs, but
> >> didn't find any obvious way to do this.  Is it possible?
> >
> > Not currently, but I think it's a good idea.
> 
> I'm not so sure I agree, at least not as a mechanism intended for
> general use or unless we're planning to do it as part of a new SRFI.
> It seems like the added benefit here (syntax hilighting or
> readability?)  over just binding the char to a suitably named variable
> isn't often likely to justify the immediate loss of code portability.

Yep, I have changed my mind already.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Matthias Koeppe]

"Lars J. Aas" <larsa@sim.no> writes:

> I'd like to be able to do something like this:
>
> (define-character "paren-close" #\051) ; 051 is ")"
>
> and then later
>
> (string-index line #\paren-close)
>
> I can of course define a normal variable for this, but then
> it won't shine from the usage that it is a character in the
> way the above does.

Why not use the name `paren-close-character' then.

#\ is read-syntax for literal character constants.  It is not a "type
annotation".  (If you define constant numeric variables like `pi', the
name will not start with a digit either.)

> I've looked in libguile/chars.{c,h} and the guile docs, but
> didn't find any obvious way to do this.  Is it possible?

> The reason i'd like to do this is that inserting #\) in the
> scheme file makes the vim "%" command unusable over those
> blocks (and it's not as easy on the eye either), and there was
> no alternate name for that char other than using the octal
> ascii value.

I think it's a bad idea to change the language only to make sure that
a simplistic editor implementation works with it.  File a bug report
with vim instead; I'm sure it is easy to fix.

Regards,

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


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[rm]

On Tue, Aug 20, 2002 at 10:20:05AM +0200, Matthias Koeppe wrote:
> "Lars J. Aas" <larsa@sim.no> writes:
> 
> > I'd like to be able to do something like this:
> >
> > (define-character "paren-close" #\051) ; 051 is ")"
> >
> > and then later
> >
> > (string-index line #\paren-close)
> >
> > I can of course define a normal variable for this, but then
> > it won't shine from the usage that it is a character in the
> > way the above does.
> 
> Why not use the name `paren-close-character' then.

Because the first solution is read syntax: it's clear that
#\paren-close is a character constant. 

> #\ is read-syntax for literal character constants.  It is not a "type
> annotation".  (If you define constant numeric variables like `pi', the
> name will not start with a digit either.)

Yes, but scheme provides a special syntax for character constants.
I have to admit that i toyed with the idea of extending guiles 
scm_charnames[] array in chars.c myself. My idea was to extend the
table to use the names also used for ISO 8879 character entities 
(mostly known from their use in HTML pages). Since such entities are
specific to an encoding it would make sense to make the table extensible
(i guess this would need to be done by extending the read-options inter-
face).

> 
> I think it's a bad idea to change the language only to make sure that
> a simplistic editor implementation works with it.  File a bug report
> with vim instead; I'm sure it is easy to fix.

Yes, if this would be just to accomodate vi(m) this would be a bad idea,
but this sounds like a reasonable extension to guile (after all: why
#\dc3 but not #\copy ?)

  Ralf Mattes


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Matthias Koeppe]

rm@fabula.de writes:

> I have to admit that i toyed with the idea of extending guiles 
> scm_charnames[] array in chars.c myself. My idea was to extend the
> table to use the names also used for ISO 8879 character entities 
> (mostly known from their use in HTML pages). Since such entities are
> specific to an encoding it would make sense to make the table extensible
> (i guess this would need to be done by extending the read-options inter-
> face).

I think that it is a bad idea to make Guile's characters
encoding-specific.  This is not the right way to internationalize
Guile.

Instead, we should change Guile's characters to Unicode.  Then, of
course, it makes sense to allow Unicode character names (and ISO 8879
character entities) for #\ syntax.

The encoding of characters should only be an issue for input/output
and interaction with C libraries.

Is anyone working on Unicode support for Guile?

Regards,

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


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[rm]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 1884 bytes --]

On Wed, Aug 21, 2002 at 11:20:28AM +0200, Matthias Koeppe wrote:
> rm@fabula.de writes:
> 
> > I have to admit that i toyed with the idea of extending guiles 
> > scm_charnames[] array in chars.c myself. My idea was to extend the
> > table to use the names also used for ISO 8879 character entities 
> > (mostly known from their use in HTML pages). Since such entities are
> > specific to an encoding it would make sense to make the table extensible
> > (i guess this would need to be done by extending the read-options inter-
> > face).
> 
> I think that it is a bad idea to make Guile's characters
> encoding-specific.  This is not the right way to internationalize
> Guile.

Hmm, as i understand it right now, a character in guile is never
encoding-specific (and i never suggested making it so).
What i (and Lars, i guess) suggest, is to make guile's list of _named_ 
character literals configurable. Nothing more. Since this is a question
of the _reader_ it won't change anything. Whether i type #\Auml or 'Ä'
(that's an capital 'a' with a german umlaut accent for those non-iso-8859-1ers)
doesn't make any difference to the guile interpreter, or?

> Instead, we should change Guile's characters to Unicode.  Then, of
> course, it makes sense to allow Unicode character names (and ISO 8879
> character entities) for #\ syntax.
> 
> The encoding of characters should only be an issue for input/output
> and interaction with C libraries.
> 
> Is anyone working on Unicode support for Guile?

Good question! The current state of unicode support makes it impossible to
use guile with XML, i'm affraid :-(

  Ralf
> Regards,
> 
> -- 
> Matthias K?ppe -- http://www.math.uni-magdeburg.de/~mkoeppe


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Marius Vollmer]

Matthias Koeppe <mkoeppe@mail.Math.Uni-Magdeburg.De> writes:

> I think that it is a bad idea to make Guile's characters
> encoding-specific.  This is not the right way to internationalize
> Guile.
>
> Instead, we should change Guile's characters to Unicode.  Then, of
> course, it makes sense to allow Unicode character names (and ISO 8879
> character entities) for #\ syntax.

Yep, agreed.  We should wait with extensible character names until we
have a good plan for unicode/mule/whatever support in Guile.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Lynn Winebarger]

On Wednesday 21 August 2002 03:12, Lars J. Aas wrote:
> 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?

     Given the raging debate on this, I'll point out that Chez Scheme
has a function char-name that does this job.  
(char-name #\space) => 'space
(char-name 'space) => #\space
(char-name 'sym) => #f
(char-name #\b) => #f

(char-name 'paren-close #\051) => unspecified
(char-name #\paren-close) => 'paren-close

    Seems like a pretty good solution to me.
    
Lynn


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Keith Wright]

> From: Lynn Winebarger <owinebar@free-expression.org>
> 
> Given the raging debate on this, I'll point out that Chez
> Scheme has a function char-name that does this job.

The debate is over a mechanism to define new character names
(or possibly more general constants).  This appears to be
a function (or macro?) that fetches an already defined
character name.  I don't see the relevance.

> (char-name #\space) => 'space
> (char-name 'space) => #\space

So given a character it returns the name as a symbol,
but given a symbol it returns a named character?
Is that not a bit goofy?
You don't give CHAR->INTEGER an integer and expect
to get a character.

> (char-name 'sym) => #f
> (char-name #\b) => #f

Why is that not (char-name #\b) => 'b ?

> (char-name 'paren-close #\051) => unspecified

Now it's got two arguments instead of one.  WTF!?

> (char-name #\paren-close) => 'paren-close

Am I meant to guess that the preceding function
(macro?) call with too many arguments was actually
a definition?

>     Seems like a pretty good solution to me.

I understand it not at all.  Are you sure those
examples are correct?

-- 
     -- Keith Wright  <kwright@free-comp-shop.com>

Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
         ---  Food, Shelter, Source code.  ---


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Lynn Winebarger]

On Wednesday 21 August 2002 12:33, Keith Wright wrote:
> > From: Lynn Winebarger <owinebar@free-expression.org>
> > 
> > Given the raging debate on this, I'll point out that Chez
> > Scheme has a function char-name that does this job.
> 
> The debate is over a mechanism to define new character names
> (or possibly more general constants).  This appears to be
> a function (or macro?) that fetches an already defined
> character name.  I don't see the relevance.

      It serves multiple purposes.
      As for constants, there's no reason to believe we want
character names to be constant.  There's plenty of reason
to consider forms for setting constants, but this is not one of
them.  Consider

(char-name 'separator #\tab)
 ....
         (begin (display (format "~s~s~s" a #\separator b)) (newline))
 ....
(char-name 'separator #\space)

Sure it's ugly, but some people like that sort of thing.

> > (char-name 'sym) => #f
> > (char-name #\b) => #f
> 
> Why is that not (char-name #\b) => 'b ?
      Because b is the literal value of the character, not the
symbolic representation.  Of course, you could make it
so any non-numeric representation is considered symbolic,
that's just not how chez defines it.
       Then again, it might be that Dybvig didn't think
(char-name 'b #\a) would be a very useful thing to do,
so prohibited it.

> 
> > (char-name 'paren-close #\051) => unspecified
> 
> Now it's got two arguments instead of one.  WTF!?

     Perhaps you've heard of functions with a variable number
of arguments?

> > (char-name #\paren-close) => 'paren-close
> 
> Am I meant to guess that the preceding function
> (macro?) call with too many arguments was actually
> a definition?

      Yes, and it's a procedure.

> I understand it not at all.  Are you sure those
> examples are correct?
> 
     I just hope it's not a copyright violation, as it's almost
verbatim from the chez user's guide.

Lynn


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[rm]

On Wed, Aug 21, 2002 at 01:27:23PM -0500, Lynn Winebarger wrote:
> On Wednesday 21 August 2002 12:33, Keith Wright wrote:
> > > From: Lynn Winebarger <owinebar@free-expression.org>
> > > 
> > > Given the raging debate on this, I'll point out that Chez
> > > Scheme has a function char-name that does this job.
> > 
> > The debate is over a mechanism to define new character names
> > (or possibly more general constants).  This appears to be
> > a function (or macro?) that fetches an already defined
> > character name.  I don't see the relevance.
> 
>       It serves multiple purposes.

I assume this was clear to Keith. 
Still, the name is not really, um, wisely chosen. There's no reason
for not expressing the functions effect in its name. 

 (name-of-char #\tab) => 'tab
 (symbol->char 'newline) => #\12
 (name-char! #\12 #\newline) 
 
>       As for constants, there's no reason to believe we want
> character names to be constant.  There's plenty of reason
> to consider forms for setting constants, but this is not one of
> them.  Consider
> (char-name 'separator #\tab)
>  ....
>          (begin (display (format "~s~s~s" a #\separator b)) (newline))
>  ....
> (char-name 'separator #\space)
> 
> Sure it's ugly, but some people like that sort of thing.

I'd feel uneasy with _that_. Here #\separator is not used as a character
constant but rather as a symbolic constant. Those are semantically different
things. Also, your use would imply that the following works:

 (define (bla blub)
   (char-name 'separator #\tab)
   (display (format "~s~s~s" a #\separator b)) (newline))

which will probably _not_ do what you expect it to do since #\separator
in the display statement will be expanded during _read_ time (when the
program code gets parsed by guile), so the call to 'char-name' at runtime
will not affect it.

   
> 
> > 
> > > (char-name 'paren-close #\051) => unspecified
> > 
> > Now it's got two arguments instead of one.  WTF!?
> 
>      Perhaps you've heard of functions with a variable number
> of arguments?
> 
> > > (char-name #\paren-close) => 'paren-close
> > 
> > Am I meant to guess that the preceding function
> > (macro?) call with too many arguments was actually
> > a definition?
> 
>       Yes, and it's a procedure.
> 
> > I understand it not at all.  Are you sure those
> > examples are correct?
> > 
>      I just hope it's not a copyright violation, as it's almost
> verbatim from the chez user's guide.

I guess Keith is using irony here. The naming really is unusually bad here.
Something (function? macro?) that modifies its parameters usually has a 
name ending in '!'. 

We need to be carefull here to not mix two very different things. Extending
guiles set of named character constants and maybe making this names changeable
(not a bad thing in my opinion) and, otoh, mixing character constants with
symbolic constants (irritating and not neccessary IMHO).

  Ralf
> Lynn
> 
> 
> _______________________________________________
> Guile-user mailing list
> Guile-user@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-user


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Lynn Winebarger]

On Wednesday 21 August 2002 14:06, rm@fabula.de wrote:
> Still, the name is not really, um, wisely chosen.
    I'm not married to it.
> There's no reason
> for not expressing the functions effect in its name. 
> 
>  (name-of-char #\tab) => 'tab
>  (symbol->char 'newline) => #\12
>  (name-char! #\12 #\newline) 
      Fine by me.     

> > [ ugliness deleted]
> I'd feel uneasy with _that_. Here #\separator is not used as a character
> constant but rather as a symbolic constant.
      No, here `separator' is a variable in a completely different namespace
from Scheme variables.   I'm not sure why you consider it a constant of any
sort, symbolic or otherwise.  One character names and numeric representations
- those should be considered constants.

> Those are semantically different
> things. Also, your use would imply that the following works:
> 
>  (define (bla blub)
>    (char-name 'separator #\tab)
>    (display (format "~s~s~s" a #\separator b)) (newline))
> 
> which will probably _not_ do what you expect it to do since #\separator
> in the display statement will be expanded during _read_ time (when the
> program code gets parsed by guile), so the call to 'char-name' at runtime
> will not affect it.

       True enough. 

> We need to be carefull here to not mix two very different things. Extending
> guiles set of named character constants and maybe making this names changeable
> (not a bad thing in my opinion) and, otoh, mixing character constants with
> symbolic constants (irritating and not neccessary IMHO).
>       
      I would say you're interacting with the reader's evaluation of identifiers in the
#\ language (a very simple language, you're either a constant or an identifier that 
directly corresponds to a constant).  You could even change it so that the reader
parses character names into different types of objects than characters, and delay
evaluation of them until execution.

Lynn


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Keith Wright]

> From: rm@fabula.de
> 
> >       It serves multiple purposes.
> 
> I assume this was clear to Keith. 

You overestimate me.  At the time I wrote that, I had not
noticed that it was both fetching values and acting as
some kind of DEFINE.  I noticed the two argument use
in the course of writing and only then began to comprehend
the true horror.

> > > I understand it not at all.  Are you sure those
> > > examples are correct?
> > > 
> >      I just hope it's not a copyright violation, as it's almost
> > verbatim from the chez user's guide.
> 
> I guess Keith is using irony here.

Not really.  I was having (still having) a lot of trouble
trying to guess the three different semantics from a few
examples.  I have posted messages with typo's recently
and thought that was the simplest explanation.

-- 
     -- Keith Wright  <kwright@free-comp-shop.com>

Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
         ---  Food, Shelter, Source code.  ---


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Keith Wright]

> From: rm@fabula.de
> 
> >       It serves multiple purposes.
> 
> I assume this was clear to Keith. 

You overestimate me.  At the time I wrote that, I had not
noticed that it was both fetching values and acting as
some kind of DEFINE.  I noticed the two argument use
in the course of writing and only then began to comprehend
the true horror.

> > > I understand it not at all.  Are you sure those
> > > examples are correct?
> > > 
> >      I just hope it's not a copyright violation, as it's almost
> > verbatim from the chez user's guide.
> 
> I guess Keith is using irony here.

Not really.  I was having (still having) a lot of trouble
trying to guess the three different semantics from a few
examples.  I have posted messages with typo's recently
and thought that was the simplest explanation.

-- 
     -- Keith Wright  <kwright@free-comp-shop.com>

Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
         ---  Food, Shelter, Source code.  ---


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Marius Vollmer]

Lynn Winebarger <owinebar@free-expression.org> writes:

> Consider
> 
> (char-name 'separator #\tab)
>  ....
>          (begin (display (format "~s~s~s" a #\separator b)) (newline))
>  ....
> (char-name 'separator #\space)

There, there!  We could use fluid-let for that!  (Only kidding :-)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Keith Wright]

> From: Lynn Winebarger <owinebar@free-expression.org>
> 
> Given the raging debate on this, I'll point out that Chez
> Scheme has a function char-name that does this job.
> 
>       It serves multiple purposes.

I endorse everthing Ralf said about the need for multiple
names for multiple purposes, without prejudice to the
question of whether any of it is any good at all.

>       As for constants, there's no reason to believe we want
> character names to be constant.  There's plenty of reason
> to consider forms for setting constants, but this is not one of
> them.

What is a settable constant if not a variable?

> Consider
> 
> (char-name 'separator #\tab)
>  ....
>          (begin (display (format "~s~s~s" a #\separator b)) (newline))
>  ....
> (char-name 'separator #\space)

How is this different from
  (define separator #\tab)
  (format #t "~a~a~a~%" a separator b)
  (define separator #\space)
?

> Sure it's ugly, but some people like that sort of thing.

Surely they would like even better a beautiful thing of the same sort!

> Perhaps you've heard of functions with a variable number
> of arguments?

Yes, of course.  They include + and *, which do the same thing
to all arguments, and READ and LOAD, which supply a useful
default for a missing argument.

If there is another example of one that changes from fetching
to defining based upon the number of arguments, then I suggest
we kill it before it breeds.

> I just hope it's not a copyright violation, as it's almost
> verbatim from the chez user's guide.

It is fair use to take a short quote for criticism.

Sorry about the double post earlier.

-- 
     -- Keith Wright  <kwright@free-comp-shop.com>

Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
         ---  Food, Shelter, Source code.  ---


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Lynn Winebarger]

On Wednesday 21 August 2002 23:12, Keith Wright wrote:
> I endorse everthing Ralf said about the need for multiple
> names for multiple purposes, without prejudice to the
> question of whether any of it is any good at all.
> 
> >       As for constants, there's no reason to believe we want
> > character names to be constant.  There's plenty of reason
> > to consider forms for setting constants, but this is not one of
> > them.
> 
> What is a settable constant if not a variable?

      By setting constants, I meant binding a name to a value
and that value not being allowed to change during its lifetime.
It's not quite the same as a "settable constant".

> How is this different from
>   (define separator #\tab)
>   (format #t "~a~a~a~%" a separator b)
>   (define separator #\space)
> ?
> 
> > Sure it's ugly, but some people like that sort of thing.
> 
> Surely they would like even better a beautiful thing of the same sort!
> 
     Beauty's in the eye of the beholder.  Maybe they like Perl.
     If you considered my last email's proposal of making character
names be variables evaluated in "character space", it might even
be useful for switching charactersets on the fly.  Slow, but it could
work.  Just swap in an entirely different table, and boom, the same
lambda will use different integers for the same character names. 
Of course, I don't know much about that problem, so that solution 
might not be useful at all.

> If there is another example of one that changes from fetching
> to defining based upon the number of arguments, then I suggest
> we kill it before it breeds.
> 
       Well, it's not particularly unusual as a way of getting/setting fields
of an object implemented by a letrec.  Although they'll only set, never
bind.

> > I just hope it's not a copyright violation, as it's almost
> > verbatim from the chez user's guide.
> 
> It is fair use to take a short quote for criticism.
> 
       My own attempt at facetiousness.  Dybvig's put the whole thing
on scheme.com, so you don't have to rely on my little outtake.  He 
puts it under the heading of I/O control operations.

Lynn


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[rm]

On Thu, Aug 22, 2002 at 12:16:24AM -0500, Lynn Winebarger wrote:
> On Wednesday 21 August 2002 23:12, Keith Wright wrote:
> > I endorse everthing Ralf said about the need for multiple
> > names for multiple purposes, without prejudice to the
> > question of whether any of it is any good at all.
> > 
> > >       As for constants, there's no reason to believe we want
> > > character names to be constant.  There's plenty of reason
> > > to consider forms for setting constants, but this is not one of
> > > them.
> > 
> > What is a settable constant if not a variable?
> 
>       By setting constants, I meant binding a name to a value
> and that value not being allowed to change during its lifetime.
> It's not quite the same as a "settable constant".

Hmm, but where then is the difference to a plain ol' variable?
A variable is a symbolic name that stands for 'something'. That
'something' can be changed (by means of 'set!', for example), even
so most functional programmers try to avoid it.

> > 
>      Beauty's in the eye of the beholder.  Maybe they like Perl.
>      If you considered my last email's proposal of making character
> names be variables evaluated in "character space", it might even
> be useful for switching charactersets on the fly.  Slow, but it could
> work.  Just swap in an entirely different table, and boom, the same
> lambda will use different integers for the same character names. 
> Of course, I don't know much about that problem, so that solution 
> might not be useful at all.

This is exactly what variables are for. It seems to me that what you
suggest is: #\abcd is a variable that can be changed during program
run time (where the '#\' part of the symbol is just an indication that
the 'something' that is bound to it is a character). This has two
consequences: 

 - you leave scheme's weak typing system (where a variable
   can be bound to things of different type). There's nothing
   like "character space" is scheme, as much as there isn't a
   "function space" (as there is in LISP).
 
 - You leave rNrs: the character sequence '#\' is reserved to
   start a character constant (r5rs, Section 6.3.4). 
   
[...]

>        My own attempt at facetiousness.  Dybvig's put the whole thing
> on scheme.com, so you don't have to rely on my little outtake.  He 
> puts it under the heading of I/O control operations.

Thank's for the pointer, i'll have to check that. Strange, i'm getting
really curious to see how Chez does this.

 Ralf

> Lynn
> 
> 
> _______________________________________________
> Guile-user mailing list
> Guile-user@gnu.org
> http://mail.gnu.org/mailman/listinfo/guile-user


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user

Re: defining new character names?

[Lynn Winebarger]

On Thursday 22 August 2002 02:42, rm@fabula.de wrote:
> On Thu, Aug 22, 2002 at 12:16:24AM -0500, Lynn Winebarger wrote:
> > 
> >       By setting constants, I meant binding a name to a value
> > and that value not being allowed to change during its lifetime.
> > It's not quite the same as a "settable constant".
> 
> Hmm, but where then is the difference to a plain ol' variable?
> A variable is a symbolic name that stands for 'something'. That
> 'something' can be changed (by means of 'set!', for example), even
> so most functional programmers try to avoid it.

   It's a variable, just not a scheme variable. 
   And Scheme is not a pure functional language.  It's about as close to 
assembly as a higher level language can get (thanks to the tail 
recursion requirement and set!).  Unless gcc's computed goto
feature has been made part of the C standard, it's closer 
than even C in that regard.

> This is exactly what variables are for. It seems to me that what you
> suggest is: #\abcd is a variable that can be changed during program
> run time (where the '#\' part of the symbol is just an indication that
> the 'something' that is bound to it is a character). This has two
> consequences: 
> 
>  - you leave scheme's weak typing system (where a variable
>    can be bound to things of different type). There's nothing
>    like "character space" is scheme, as much as there isn't a
>    "function space" (as there is in LISP).

     There's no prohibition against it.  As you point out below,
anything beginning with #\ is _not_ a Scheme variable. 

>  
>  - You leave rNrs: the character sequence '#\' is reserved to
>    start a character constant (r5rs, Section 6.3.4). 
>    
     Here's the funny thing.  My proposal would have the property
that such character names would be constant _as far as the scheme
code could tell_.  That is, even if chose to change the lookup
table, those values could not get captured by scheme code. (But they
could compare to differently named character constants differently).
For example:
(set-char-name! 'foo #\a)
(define a #\foo)
(eq? a #\a) => #t
(eq? a #\b) => #f
(set-char-name! 'foo #\b)
(define b #\foo)
(eq? a #\a) => #f
(eq? a #\b) => #t
(eq? a b) => #t 
    R5RS says character constants are self-evaluating, which it then
defines as "they do not have to be quoted in programs."  Well, this proposal
has that property.  The only time these character variables would be looked
up is when comparing two characters (as above) or when reading/writing
them.  Either way they don't have to be quoted (except to the extent you
consider #\ a form of quotation).
     
Lynn


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-user