Question on CHAR and [CHAR]

[Rod Pemberton]

In interactive mode, CHAR gives:

CHAR A . 65 <ok>

In compilation mode, [CHAR] gives:

: T [CHAR] A . ; <ok>
T 65 <ok>

However, the three ANS Forths I tried *also* support the following usage:

: T CHAR 'A' . ; <ok>
T 65 <ok>

Now, AFAICT, CHAR and [CHAR] were originally defined for ANS. They aren't
defined for fig-Forth, F79, or F83. Although I expect 'A' to work from my
experiences with other languages and that's how I stumbled across this, I
see no mention of this syntax in ANS. The supported syntax also uses CHAR
in compile mode instead of [CHAR] ... It doesn't seem to fit F83's
definition of ASCII either ... So, where does this usage come from?


Rod Pemberton

[Andrew Haley]

Now try

: T 'A' . ;

Andrew.

[Coos Haak]

Op Sun, 11 Mar 2012 06:10:12 -0400 schreef Rod Pemberton:

It's just like your question about tick. CHAR may be used in a definition.
: [CHAR] CHAR POSTPONE LITERAL ; IMMEDIATE

What dos your definition do?
1. CHAR parses a word and put the value of the first character on the stack
2. 'A' pushes the value of the character A on the stack.
3. Prints 65.
After executing T there is still a number on the stack, from CHAR.
Try: T What?
It prints 65
.S shows that 87 is left on the stack because it is the value of W

--
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html

[Josh Grams]

Rod Pemberton wrote: <jjhtn6$b3r$1...@speranza.aioe.org>

> However, the three ANS Forths I tried *also* support the following usage:
>
>: T CHAR 'A' . ; <ok>
> T 65 <ok>

You should get in the habit of checking whether your definitions leave
stack junk -- CHAR is redundant there:

T B . 65 66 <ok>

The character literal syntax isn't in any standard; it's just a
common-sense thing which some Forth systems support. IIRC gforth
supported 'A but not 'A' for a while...

--Josh

[Jean-Bernard Faucon]

: T CHAR . ;

t a 97 ok
t b 98 ok
t n 110 ok
t t 116 ok
t u 117 ok

[BruceMcF]

On Mar 11, 6:10 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> In interactive mode, CHAR gives:

>   CHAR A . 65 <ok>
>
> In compilation mode, [CHAR] gives:
>
>   : T [CHAR] A . ; <ok>
>   T 65 <ok>

> However, the three ANS Forths I tried *also* support the following usage:
>
> : T CHAR 'A' . ; <ok>
> T 65 <ok>

When in gforth I try:

: test [char] 'A' . ;

I get 39, as the standard required. It parses a blank delimited token
and returns the first character in the token.

[Rod Pemberton]

"Rod Pemberton" <do_no...@noavailemail.cmm> wrote in message
news:jjhtn6$b3r$1...@speranza.aioe.org...

Ok, you guys answered:

"The 'n' syntax is separate from and unrelated to CHAR."

So, clearly ' followed by a non-space indicates a character ... Otherwise,
it'd be ' (tick).

It seems (as someone mentioned) that some Forths require two apostrophe's
while others only need one, e.g., 'A vs. 'A' .

Does this syntax work for space too? E.g.,

: T ' ' . ;
(space inside apostrophe's)

As expected, that seems to not recognize a space ...

This use of ' for a character raises another question too. How does the
character syntax with ' work with a space delimited parser like that used in
Forth? I.e., there is no space afterwards.


Rod Pemberton

[Josh Grams]

Rod Pemberton wrote: <jjj451$k5r$1...@speranza.aioe.org>

> Does this syntax work for space too? E.g.,
>
>: T ' ' . ;
> (space inside apostrophe's)
>
> As expected, that seems to not recognize a space ...

Right. That would return the XT of ' (tick).

> This use of ' for a character raises another question too. How does
> the character syntax with ' work with a space delimited parser like
> that used in Forth? I.e., there is no space afterwards.

Generally it comes at the end of the recognition chain somewhere. Parse
a word, look it up. If it's not a previously defined word, try to
recognize it as an integer, or a floating-point number, or a character
literal, or whatever. Some systems have prefixes for numbers in
different bases too, e.g. $DEADBEEF for hex.

--Josh

[Elizabeth D. Rather]

Exactly. Checking for a "magic" leading character should be the last
thing the interpreter tries. Not only is it the least-likely occurrence,
this order also ensures that there is no ambiguity such as there would
be with the ' ' example above. The interpreter will simply find ' as a
word first, which is as it should be.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[BruceMcF]

On Mar 11, 5:06 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> Does this syntax work for space too?

It couldn't conceivable ~ first the token is parsed, then its checked
to see if it can be found in a dictionary, then its checked to see if
its an integer and then, on *some* implementations, its checked to see
if its a special token.

Forth94 in 3.4 defines the first two steps, then it says:
...
d) If unsuccessful, an ambiguous condition exists

That's where an implementation is allowed to add its own special thing
like $1F as hexadecimal or 'A as a character literal. If its defined
to take the second character in the token as the literal, then it
*can*, if you wish, ignore the rest of the token, allowing 'A' if
someone prefers to write it that way.

[Albert van der Horst]

In article <jjj451$k5r$1...@speranza.aioe.org>,

Rod Pemberton <do_no...@noavailemail.cmm> wrote:
>"Rod Pemberton" <do_no...@noavailemail.cmm> wrote in message
>news:jjhtn6$b3r$1...@speranza.aioe.org...
>>
>> In interactive mode, CHAR gives:
>>
>> CHAR A . 65 <ok>
>>
>> In compilation mode, [CHAR] gives:
>>
>> : T [CHAR] A . ; <ok>
>> T 65 <ok>
>>
>> However, the three ANS Forths I tried *also* support the following usage:
>>
>> : T CHAR 'A' . ; <ok>
>> T 65 <ok>
>>
>> Now, AFAICT, CHAR and [CHAR] were originally defined for ANS. They aren't
>> defined for fig-Forth, F79, or F83. Although I expect 'A' to work from my
>> experiences with other languages and that's how I stumbled across this, I
>> see no mention of this syntax in ANS. The supported syntax also uses CHAR
>> in compile mode instead of [CHAR] ... It doesn't seem to fit F83's
>> definition of ASCII either ... So, where does this usage come from?
>>
>
>Ok, you guys answered:
>
> "The 'n' syntax is separate from and unrelated to CHAR."
>
>So, clearly ' followed by a non-space indicates a character ... Otherwise,
>it'd be ' (tick).

And it is a reason to hate the syntax, because it is confusing.

>
>It seems (as someone mentioned) that some Forths require two apostrophe's
>while others only need one, e.g., 'A vs. 'A' .

The second apostrophe is superfluous in Forth and is a typical c-ism.
It is interesting that where it would be beneficial (using 0x over $
to indicate hex) Forthers shy away from c-isms.

[I could easily make $HOME work in ciforth but $ for hex is in the way.]

>
>Does this syntax work for space too? E.g.,
>
>: T ' ' . ;
>(space inside apostrophe's)

Have you even read Starting Forth? Have you even read through a
glossary and wondered why BL is defined?

>
>As expected, that seems to not recognize a space ...
>
>This use of ' for a character raises another question too. How does the
>character syntax with ' work with a space delimited parser like that used in
>Forth? I.e., there is no space afterwards.
>
>
>Rod Pemberton

Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Anton Ertl]

Josh Grams <jo...@qualdan.com> writes:
>The character literal syntax isn't in any standard;

It's part of the "number prefixes" proposal
<http://www.forth200x.org/number-prefixes.html> that was accepted in
2007. The standardized proposal for characters is: 'a'

>IIRC gforth
>supported 'A but not 'A' for a while...

'A' does not work as standardized on Gforth 0.6.2 and earlier, but
works as standardized on 0.7.0, which came out in 2008.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2011: http://www.euroforth.org/ef11/

[Rod Pemberton]

"Coos Haak" <chf...@hccnet.nl> wrote in message
news:o6b4roy5ij8c.1j...@40tude.net...
> [...]

> It's just like your question about tick. CHAR may be used in a definition.
> : [CHAR] CHAR POSTPONE LITERAL ; IMMEDIATE
>

Once you have [CHAR] defined in terms of CHAR, where do you need CHAR inside
a definition?


Rod Pemberton

[Rod Pemberton]

"Albert van der Horst" <alb...@spenarnc.xs4all.nl> wrote in message
news:m0rr5...@spenarnc.xs4all.nl...
> [...]

> Have you even read Starting Forth?

Yeah, I think so. I'm not sure anymore. That would've been about '92, if I
did ...

I have looked at the online version. Unfortunately, it seems it's been
updated to modern ANS Forth. So, testing examples from it in a Forth which
is closer to fig-Forth is not good.

> Have you even read through a glossary and wondered why BL is defined?
>

1) So that hardcoded values for characters of a specific character set, say
ASCII, are not present in the source?

2) Because various bootstrap character constants are required to implement a
Forth interpreter.

3) Because 'n' character syntax didn't exist as formal syntax, as Anton
noted, until 2007 ...

4) Because CHAR and [CHAR] did not exist in a formal Forth specification
prior to ANS, as I noted. Similar functionality was available in Forth83 as
ASCII. It seems no equivalent functionality was present for Forth79 or
fig-Forth.


And, lastly, the answer you're wanting:

5) Because a Forth parser uses a space.


Am I to guess at which answer is the correct one to your question? Never
hint. People miss hints.


Rod Pemberton

[Elizabeth D. Rather]

In a definition that wants to read one character from the input stream.
I can think of a lot of reasons for doing that!

[Elizabeth D. Rather]

On 3/12/12 1:46 PM, Rod Pemberton wrote:
> "Albert van der Horst"<alb...@spenarnc.xs4all.nl> wrote in message
> news:m0rr5...@spenarnc.xs4all.nl...
>> [...]
>> Have you even read Starting Forth?
>
> Yeah, I think so. I'm not sure anymore. That would've been about '92, if I
> did ...
>
> I have looked at the online version. Unfortunately, it seems it's been
> updated to modern ANS Forth. So, testing examples from it in a Forth which
> is closer to fig-Forth is not good.
>
>> Have you even read through a glossary and wondered why BL is defined?
>>
>
> 1) So that hardcoded values for characters of a specific character set, say
> ASCII, are not present in the source?

Always good practice to avoid these. But it's easy to get visible
characters using CHAR, [CHAR], or their predecessors, in ways that are
self-documenting. "Invisible" characters are a lot harder.

> 2) Because various bootstrap character constants are required to implement a
> Forth interpreter.

Yeah, BL is one of them, but there are others: most of which are
non-printing characters. Giving them names makes them much easier to
specify. Some systems will treat all "white space" characters as blanks.

> 3) Because 'n' character syntax didn't exist as formal syntax, as Anton
> noted, until 2007 ...

Well, it's been around longer than that. But it's impractical for
non-printing characters.

> 4) Because CHAR and [CHAR] did not exist in a formal Forth specification
> prior to ANS, as I noted. Similar functionality was available in Forth83 as
> ASCII. It seems no equivalent functionality was present for Forth79 or
> fig-Forth.

Well, polyFORTH and its predecessors had ASCII (interpretive) and
[ASCII] as compile-only. And there were other approaches around as well.

> And, lastly, the answer you're wanting:
>
> 5) Because a Forth parser uses a space.

That's really a subset of the answer to #2, IMO.

Cheers,
Elizabeth

> Am I to guess at which answer is the correct one to your question? Never
> hint. People miss hints.
>
>
> Rod Pemberton
>
>

[Mark Wills]

On Mar 13, 2:22 am, "Elizabeth D. Rather" <erat...@forth.com> wrote:
> On 3/12/12 1:43 PM, Rod Pemberton wrote:
>

> > "Coos Haak"<chfo...@hccnet.nl>  wrote in message

> >news:o6b4roy5ij8c.1j...@40tude.net...
> >> [...]
> >> It's just like your question about tick. CHAR may be used in a definition.
> >> : [CHAR] CHAR POSTPONE LITERAL ; IMMEDIATE
>
> > Once you have [CHAR] defined in terms of CHAR, where do you need CHAR inside
> > a definition?
>
> > Rod Pemberton
>
> In a definition that wants to read one character from the input stream.
> I can think of a lot of reasons for doing that!
>
> Cheers,
> Elizabeth
>
> --
> ==================================================
> Elizabeth D. Rather   (US & Canada)   800-55-FORTH
> FORTH Inc.                         +1 310.999.6784
> 5959 West Century Blvd. Suite 700

> Los Angeles, CA 90045http://www.forth.com

>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

I've used it for defining key codes to make source code much more
readable. Not a lot else, to be honest.

I.e. in a pac-man game (My Forth system is mostly targeted at retro
games writers):

CHAR E CONSTANT KEY_UP
CHAR S CONSTANT KEY_LEFT
CHAR D CONSTANT KEY_RIGHT
CHAR X CONSTANT KEY_DOWN

...

: MOVE-MAN
KEY? CASE
KEY_UP OF MAN_UP ENDOF
KEY_LEFT OF MAN_LEFT ENDOF
KEY_RIGHT OF MAN_RIGHT ENDOF
KEY_DOWN OF MAN_DOWN ENDOF
ENDCASE
;

Very readable source code, IMO.

:-)

[Josh Grams]

Elizabeth D. Rather wrote: <4bmdnUTOyI_yMsPS...@supernews.com>

> On 3/12/12 1:43 PM, Rod Pemberton wrote:
>> "Coos Haak"<chf...@hccnet.nl> wrote in message
>> news:o6b4roy5ij8c.1j...@40tude.net...
>>> [...]
>>> It's just like your question about tick. CHAR may be used in a definition.
>>> : [CHAR] CHAR POSTPONE LITERAL ; IMMEDIATE
>>>
>>
>> Once you have [CHAR] defined in terms of CHAR, where do you need CHAR inside
>> a definition?
>

> In a definition that wants to read one character from the input stream.
> I can think of a lot of reasons for doing that!

e.g.

: CTRL ( "char" -- char ) CHAR 96 INVERT AND ;
CTRL A . 1 ok

--Josh

[Ed]

"If in Forth you don't like something - just change it."

Some implementers either didn't know - or didn't like - Forth Inc's
CHAR [CHAR]. When ANS subsequently standardized it, they
obviously missed out. The result is that 200x now supports *two*
distinct syntax for literal chars.

As the saying goes "sorry for any inconvenience caused".

Understanding Forth today, also requires an understanding of
Forth politics.

[Alex McDonald]

On Mar 14, 5:35 am, "Ed" <nos...@invalid.com> wrote:
> Rod Pemberton wrote:
> > In interactive mode, CHAR gives:
>
> >   CHAR A . 65 <ok>
>
> > In compilation mode, [CHAR] gives:
>
> >   : T [CHAR] A . ; <ok>
> >   T 65 <ok>
>
> > However, the three ANS Forths I tried *also* support the following usage:
>
> > : T CHAR 'A' . ; <ok>
> > T 65 <ok>
>
> > Now, AFAICT, CHAR and [CHAR] were originally defined for ANS.  They aren't
> > defined for fig-Forth, F79, or F83.  Although I expect 'A' to work from my
> > experiences with other languages and that's how I stumbled across this, I
> > see no mention of this syntax in ANS.  The supported syntax also uses CHAR
> > in compile mode instead of [CHAR] ...  It doesn't seem to fit F83's
> > definition of ASCII either ...  So, where does this usage come from?
>
> "If in Forth you don't like something - just change it."
>
> Some implementers either didn't know - or didn't like - Forth Inc's
> CHAR [CHAR].  When ANS subsequently standardized it, they
> obviously missed out.  The result is that 200x now supports *two*
> distinct syntax for literal chars.

Which two? CHAR and [CHAR] do quite different things.

: foo char . ;
: bar [char] X . ;

foo X 130 ok
bar 130 ok

CHAR is to [CHAR} as ' is to ['].

Or are you referring to single quote literals like 'X' which are not
in the standard?

[Ed]

Ed wrote:
> ...

> Some implementers either didn't know - or didn't like - Forth Inc's
> CHAR [CHAR].

I should have stated that better. It was ASCII [ASCII] that was employed
in PolyForth. Since some forths already had a state-smart ASCII , ANS
had no option but change the names. The new ones are nicer anyway :)

[Ed]

The latter.

Rod's mention of quoted characters ('A') in other languages and
his examples involving CHAR [CHAR] suggests to me he
probably intended to write:

: T [CHAR] 'A' . ;

rather than

: T CHAR 'A' . ;

While Forth-94 precludes [CHAR] 'A' from working, it's not
unreasonable that someone might expect it to given 200x
adoption of single quotes to denote chars.

I'm not suprised Rod was confused. I would be too if I saw
such mixing of ideas in forth code.

[Rod Pemberton]

"Ed" <nos...@invalid.com> wrote in message
news:jjrggf$jp7$2...@news-01.bur.connect.com.au...
> [...]

> Rod's mention of quoted characters ('A') in other languages
> and his examples involving CHAR [CHAR] suggests to me
> he probably intended to write:
>
> : T [CHAR] 'A' . ;
>
> rather than
>
> : T CHAR 'A' . ;
>

In this case, what I wrote was what I intended. I didn't know that 'n'
style syntax was entirely separate from CHAR for Forth. Single quotes are
usually required to delimit a character in other languages. In fact, I
couldn't find mention of it in the spec's. In other languages, you can't
have a A or Z etc by itself and it be a character. It must be 'A' or 'Z'
etc delimited by single-quotes. So, I took CHAR 'A' in a definition to
place a character value for A on the stack. However, as others replied,
CHAR gets a character from the input stream to the stack and 'A' by itself
places a character value on the stack.


Rod Pemberton

[Peter Knaggs]

This is correct. The 200x document introduced 'A' as a character literal
that will leave the ordinal value of A on the stack. Thus,

'A' is equivalent to [CHAR] A'

So,

: T CHAR 'A' . ;
T X . gives 65 88

The CHAR works on the next character from the input stream (X).

While the 2x document requires both an open and close quote, I have
implemented it as an abbreviation for [CHAR], so the closing quote is
optional.

With the introduction of the character literal, [CHAR] is no longer
required, it is retained for backward compatibility.

--
Peter Knaggs

[Andrew Haley]

Peter Knaggs <p...@bcs.org.uk> wrote:
>
> The 200x document introduced 'A' as a character literal
> that will leave the ordinal value of A on the stack. Thus,
>
> 'A' is equivalent to [CHAR] A'
>
> So,
>
> : T CHAR 'A' . ;
> T X . gives 65 88
>
> The CHAR works on the next character from the input stream (X).
>
> While the 2x document requires both an open and close quote, I have
> implemented it as an abbreviation for [CHAR], so the closing quote is
> optional.
>
> With the introduction of the character literal, [CHAR] is no longer
> required, it is retained for backward compatibility.

Well, they are redundant language feaures: you might as well say that
given [char], the characher literal is not required. Why should
anyone prefer the "new" syntax? AFAICS its only advantage is that
it's more familiar to C programmers. Which is perhaps the point?

Andrew.

[Anton Ertl]

"Ed" <nos...@invalid.com> writes:
>he
>probably intended to write:
>
> : T [CHAR] 'A' . ;

...

>While Forth-94 precludes [CHAR] 'A' from working, it's not
>unreasonable that someone might expect it to given 200x
>adoption of single quotes to denote chars.

: T [CHAR] 'A' . ;

is Forth-94 compliant (and also Forth 200x compliant), and is
equivalent to

: T [CHAR] ' . ;

[Anton Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>Well, they are redundant language feaures: you might as well say that
>given [char], the characher literal is not required. Why should
>anyone prefer the "new" syntax? AFAICS its only advantage is that
>it's more familiar to C programmers. Which is perhaps the point?

A few advantages that you failed to see:

+ Code containing literals works the same inside and outside of colon
definitions, in contrast to code containing [CHAR] or CHAR.

+ Character literals are shorter.

The familiarity to C is, of course, a big disadvantage in the eyes of
some; maybe we should have standardized ~*A=! as syntax instead of 'A'
to eliminate this disadvantage, despite 'A' being common practice (I
also considered 'A, but it was less common).

While we are at similarities to C, somebody complained that we
standardized $ff instead of 0xff. I considered both (plus ffH) in my
proposal; $ff was supported by all systems I looked at, while 0xff had
significantly less support, and ffH even less.

[Andrew Haley]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>Well, they are redundant language feaures: you might as well say that
>>given [char], the characher literal is not required. Why should
>>anyone prefer the "new" syntax? AFAICS its only advantage is that
>>it's more familiar to C programmers. Which is perhaps the point?
>
> A few advantages that you failed to see:
>
> + Code containing literals works the same inside and outside of colon
> definitions, in contrast to code containing [CHAR] or CHAR.
>
> + Character literals are shorter.

I didn't fail to see them: they don't strike me as particularly
advantageous, although the first one is perhaps a nice feature. Is it
worth the redundancy, though? I imagine there are as many opinions
about that as there are Forth programmers.

> The familiarity to C is, of course, a big disadvantage in the eyes
> of some; maybe we should have standardized ~*A=! as syntax instead
> of 'A' to eliminate this disadvantage, despite 'A' being common
> practice (I also considered 'A, but it was less common).

I agree that if we're going to have character literals this is the
best choice, but I'm not sure about the trailing ' .

At the time it seemed to me that this was so obviously pointless an
idea that it wouldn't get through, since we had a perfectly good
syntax for character literals already. So it goes; it's all too late
now.

> While we are at similarities to C, somebody complained that we
> standardized $ff instead of 0xff. I considered both (plus ffH) in my
> proposal; $ff was supported by all systems I looked at, while 0xff had
> significantly less support, and ffH even less.

This one is rather painful because it makes Forth look rather like
assembly language, which perhaps is an unfortunate connotation to
reinforce.

Andrew.

[Ed]

Rod Pemberton wrote:
> "Ed" <nos...@invalid.com> wrote in message
> news:jjrggf$jp7$2...@news-01.bur.connect.com.au...
> > [...]
> > Rod's mention of quoted characters ('A') in other languages
> > and his examples involving CHAR [CHAR] suggests to me
> > he probably intended to write:
> >
> > : T [CHAR] 'A' . ;
> >
> > rather than
> >
> > : T CHAR 'A' . ;
> >
>
> In this case, what I wrote was what I intended.

Even more disturbing :)

> I didn't know that 'n'
> style syntax was entirely separate from CHAR for Forth.

Precisely so. Not only is 'n' superfluous, its presence is now a source
of confusion to users as your post demonstrates.

While such confusion may be tolerable in individual implementations
on the basis one is free to do anything (literally), deliberately creating
confusion in a language when it was entirely avoidable is another.

This is Forth. It was intended to be a minimalist language. We have
RPN and the stack, not because it is pretty or readable, but because
it permitted implementations to be smaller and simpler. And with
simplicity comes a sense of "rightness".

"Perfection is achieved, not when there is nothing more
to add, but when there is nothing left to take away."

- Antoine de Saint Exupery

[Anton Ertl]

"Ed" <nos...@invalid.com> writes:
>Rod Pemberton wrote:
>> "Ed" <nos...@invalid.com> wrote in message
>> news:jjrggf$jp7$2...@news-01.bur.connect.com.au...
>> > [...]
>> > Rod's mention of quoted characters ('A') in other languages
>> > and his examples involving CHAR [CHAR] suggests to me
>> > he probably intended to write:
>> >
>> > : T [CHAR] 'A' . ;
>> >
>> > rather than
>> >
>> > : T CHAR 'A' . ;
>> >
>>
>> In this case, what I wrote was what I intended.
>
>Even more disturbing :)
>
>> I didn't know that 'n'
>> style syntax was entirely separate from CHAR for Forth.
>
>Precisely so. Not only is 'n' superfluous, its presence is now a source
>of confusion to users as your post demonstrates.

His postings demonstrate that CHAR and [CHAR] are a source of
confusion, so if we want to get rid of this redundancy, we should get
rid of these words.

>This is Forth. It was intended to be a minimalist language. We have
>RPN and the stack, not because it is pretty or readable, but because
>it permitted implementations to be smaller and simpler. And with
>simplicity comes a sense of "rightness".

I don't see how parsing words like CHAR [CHAR] etc. are examples of
the use of RPN and the stack, simplicity, minimality, and rightness.
If Chuck Moore had done number literals through parsing words (say,
NUM 1234, [NUM] 1234, DOUBLE 1234567 and [DOUBLE] 1234567), then CHAR
and [CHAR] would be the way to go, but we have number literals that
are handled by the text interpreter, and dealing with character
literals in the same way has a sense of rightness.

[Andrew Haley]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> "Ed" <nos...@invalid.com> writes:
>>Rod Pemberton wrote:
>>> "Ed" <nos...@invalid.com> wrote in message
>>> news:jjrggf$jp7$2...@news-01.bur.connect.com.au...

>>> I didn't know that 'n'
>>> style syntax was entirely separate from CHAR for Forth.
>>
>>Precisely so. Not only is 'n' superfluous, its presence is now a source
>>of confusion to users as your post demonstrates.
>
> His postings demonstrate that CHAR and [CHAR] are a source of
> confusion, so if we want to get rid of this redundancy, we should
> get rid of these words.

That is a pretty good point. The redundant representations of
character literals in Forth source are an ugly wart on the language;
it's just silly to have multiple ways to represent something as basic
as 'C' .

Time to deprecate [CHAR] CHAR, I think; implememters will keep the
form forever for backwards compatibility, but that's up to them.

Andrew.

[Ed]

Anton Ertl wrote:
> ...

> I don't see how parsing words like CHAR [CHAR] etc. are examples of
> the use of RPN and the stack, simplicity, minimality, and rightness.

I can see.

I can see Forth already had CHAR [CHAR] for denoting character literals
albeit under a different name. I can see how the functionality was added
portably without any need to hack the compiler. Perhaps Forth really is
simple.

I can also see how adding an *additional* syntax for character literals
was superfluous. I can see the confusion that it has caused by reading
this thread.

How is it that you cannot see these things?

> If Chuck Moore had done number literals through parsing words (say,
> NUM 1234, [NUM] 1234, DOUBLE 1234567 and [DOUBLE] 1234567), then CHAR
> and [CHAR] would be the way to go, but we have number literals that
> are handled by the text interpreter, and dealing with character
> literals in the same way has a sense of rightness.

I don't know of any computing language that handles simple numbers
in the manner you are suggesting. Character literals are not numbers.

[Anton Ertl]

"Ed" <nos...@invalid.com> writes:
>Anton Ertl wrote:
>> ...
>> I don't see how parsing words like CHAR [CHAR] etc. are examples of
>> the use of RPN and the stack, simplicity, minimality, and rightness.
>
>I can see.
>
>I can see Forth already had CHAR [CHAR] for denoting character literals
>albeit under a different name. I can see how the functionality was added
>portably without any need to hack the compiler. Perhaps Forth really is
>simple.
>
>I can also see how adding an *additional* syntax for character literals
>was superfluous. I can see the confusion that it has caused by reading
>this thread.
>
>How is it that you cannot see these things?

Maybe you should read what I have written.

>> If Chuck Moore had done number literals through parsing words (say,
>> NUM 1234, [NUM] 1234, DOUBLE 1234567 and [DOUBLE] 1234567), then CHAR
>> and [CHAR] would be the way to go, but we have number literals that
>> are handled by the text interpreter, and dealing with character
>> literals in the same way has a sense of rightness.
>
>I don't know of any computing language that handles simple numbers
>in the manner you are suggesting.

So what? I don't know any other computer language that handles simple
character literals like Forth-94 does; most do it in the 'A' way. So
if you take other languages as yardstick for rightness, don't complain
about 'A'.

If, OTOH, the ability to do literals (whether numbers or characters)
without extra code in the text interpreter is your yardstick, as you
argue above, then NUM [NUM] DOUBLE [DOUBLE] FLOAT [FLOAT] CHAR [CHAR]
are the way to do literals.

What we have in Forth-94 is a mixture. We now move towards the text
interpreter approach, and hopefully we will get rid of CHAR [CHAR] one
day.

> Character literals are not numbers.

Is that supposed to be an argument? 1 is not 2, yet we don't use
different approaches for 1 and 2 as literals.

[Bernd Paysan]

Ed wrote:
> I don't know of any computing language that handles simple numbers
> in the manner you are suggesting.

Well, people have had h# in Forth as opposed to the $ prefix. But
otherwise, yes, nobody has these prefixes for normal literals.

> Character literals are not numbers.

Yes, they are. Even in C. This compiles without any warning:

#include <stdio.h>
int main()
{
char a=34;
char b='+';
printf("%c%c%c", a, b, 10);
return 0;
}

Integer literals and character literals are interchangible, they have
the same implicit data types (and propagation rules), and that's how it
should be. A character is just a code point in a code table (usually
something the language already specifies, e.g. ASCII in the case of
Forth), and the literal is either its numerical value or the character
literal, and then it's a number.

So if everybody deals with character literals as if they were numbers,
we can do so, too.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/