Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #9995 > unrolled thread

Question on CHAR and [CHAR]

Back to article view | Back to comp.lang.forth

Contents

  Question on CHAR and [CHAR] "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-11 06:10 -0400
    Re: Question on CHAR and [CHAR] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-11 06:03 -0500
    Re: Question on CHAR and [CHAR] Coos Haak <chforth@hccnet.nl> - 2012-03-11 13:09 +0100
      Re: Question on CHAR and [CHAR] "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-12 19:43 -0400
        Re: Question on CHAR and [CHAR] "Elizabeth D. Rather" <erather@forth.com> - 2012-03-12 16:22 -1000
          Re: Question on CHAR and [CHAR] Mark Wills <markrobertwills@yahoo.co.uk> - 2012-03-13 03:23 -0700
          Re: Question on CHAR and [CHAR] Josh Grams <josh@qualdan.com> - 2012-03-13 12:51 +0000
    Re: Question on CHAR and [CHAR] Josh Grams <josh@qualdan.com> - 2012-03-11 17:11 +0000
      Re: Question on CHAR and [CHAR] Jean-Bernard Faucon <jb@nospam.com> - 2012-03-11 21:34 +0100
      Re: Question on CHAR and [CHAR] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-12 10:45 +0000
    Re: Question on CHAR and [CHAR] BruceMcF <agila61@netscape.net> - 2012-03-11 13:57 -0700
    Re: Question on CHAR and [CHAR] "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-11 17:06 -0400
      Re: Question on CHAR and [CHAR] Josh Grams <josh@qualdan.com> - 2012-03-11 21:38 +0000
        Re: Question on CHAR and [CHAR] "Elizabeth D. Rather" <erather@forth.com> - 2012-03-11 14:12 -1000
      Re: Question on CHAR and [CHAR] BruceMcF <agila61@netscape.net> - 2012-03-11 18:42 -0700
      Re: Question on CHAR and [CHAR] Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-03-12 11:13 +0000
        Re: Question on CHAR and [CHAR] "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-12 19:46 -0400
          Re: Question on CHAR and [CHAR] "Elizabeth D. Rather" <erather@forth.com> - 2012-03-12 16:56 -1000
    Re: Question on CHAR and [CHAR] "Ed" <nospam@invalid.com> - 2012-03-14 16:35 +1100
      Re: Question on CHAR and [CHAR] Alex McDonald <blog@rivadpm.com> - 2012-03-14 08:49 -0700
        Re: Question on CHAR and [CHAR] "Ed" <nospam@invalid.com> - 2012-03-15 12:29 +1100
          Re: Question on CHAR and [CHAR] "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2012-03-15 04:11 -0400
            Re: Question on CHAR and [CHAR] "Peter Knaggs" <pjk@bcs.org.uk> - 2012-03-15 10:24 +0000
              Re: Question on CHAR and [CHAR] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-15 06:23 -0500
                Re: Question on CHAR and [CHAR] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-15 12:05 +0000
                  Re: Question on CHAR and [CHAR] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-15 08:19 -0500
            Re: Question on CHAR and [CHAR] "Ed" <nospam@invalid.com> - 2012-03-17 13:17 +1100
              Re: Question on CHAR and [CHAR] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-17 15:13 +0000
                Re: Question on CHAR and [CHAR] Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-03-18 06:07 -0500
                Re: Question on CHAR and [CHAR] "Ed" <nospam@invalid.com> - 2012-03-18 23:01 +1100
                  Re: Question on CHAR and [CHAR] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-18 15:21 +0000
                  Re: Question on CHAR and [CHAR] Bernd Paysan <bernd.paysan@gmx.de> - 2012-03-18 23:15 +0100
          Re: Question on CHAR and [CHAR] anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-03-15 11:59 +0000
      Re: Question on CHAR and [CHAR] "Ed" <nospam@invalid.com> - 2012-03-15 12:29 +1100

Page 1 of 2  [1] 2  Next page →

#9995 — Question on CHAR and [CHAR]

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

[toc] | [next] | [standalone]

#9996

Rod Pemberton <do_not_have@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>
> 
> 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?

Now try

: T 'A' . ;

Andrew.

[toc] | [prev] | [next] | [standalone]

#10000

Op Sun, 11 Mar 2012 06:10:12 -0400 schreef 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

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 

[toc] | [prev] | [next] | [standalone]

#10071

"Coos Haak" <chforth@hccnet.nl> wrote in message
news:o6b4roy5ij8c.1j293hswccmz0.dlg@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

[toc] | [prev] | [next] | [standalone]

#10073

On 3/12/12 1:43 PM, Rod Pemberton wrote:
> "Coos Haak"<chforth@hccnet.nl>  wrote in message
> news:o6b4roy5ij8c.1j293hswccmz0.dlg@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 90045
http://www.forth.com

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

[toc] | [prev] | [next] | [standalone]

#10085

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.1j293hswccmz0.dlg@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.

:-)

[toc] | [prev] | [next] | [standalone]

#10086

Elizabeth D. Rather wrote: <4bmdnUTOyI_yMsPSnZ2dnUVZ_uudnZ2d@supernews.com>
> On 3/12/12 1:43 PM, Rod Pemberton wrote:
>> "Coos Haak"<chforth@hccnet.nl>  wrote in message
>> news:o6b4roy5ij8c.1j293hswccmz0.dlg@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

[toc] | [prev] | [next] | [standalone]

#10005

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

[toc] | [prev] | [next] | [standalone]

#10010

Le 11/03/2012 18:11, Josh Grams a écrit :
> 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

: T CHAR  . ;

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

[toc] | [prev] | [next] | [standalone]

#10041

Josh Grams <josh@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/

[toc] | [prev] | [next] | [standalone]

#10012

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.

[toc] | [prev] | [next] | [standalone]

#10013

"Rod Pemberton" <do_not_have@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).

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

[toc] | [prev] | [next] | [standalone]

#10019

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

[toc] | [prev] | [next] | [standalone]

#10028

On 3/11/12 11:38 AM, Josh Grams wrote:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#10034

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.

[toc] | [prev] | [next] | [standalone]

#10040

In article <jjj451$k5r$1@speranza.aioe.org>,
Rod Pemberton <do_not_have@noavailemail.cmm> wrote:
>"Rod Pemberton" <do_not_have@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

[toc] | [prev] | [next] | [standalone]

#10072

"Albert van der Horst" <albert@spenarnc.xs4all.nl> wrote in message
news:m0rr5v.2kk@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

[toc] | [prev] | [next] | [standalone]

#10077

On 3/12/12 1:46 PM, Rod Pemberton wrote:
> "Albert van der Horst"<albert@spenarnc.xs4all.nl>  wrote in message
> news:m0rr5v.2kk@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
>
>


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

[toc] | [prev] | [next] | [standalone]

#10106

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.

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

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

[toc] | [prev] | [next] | [standalone]

#10109

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?

>
> As the saying goes "sorry for any inconvenience caused".
>
> Understanding Forth today, also requires an understanding of
> Forth politics.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web