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 2 of 2 — ← Prev page 1 [2]

#10122

Alex McDonald wrote:
> 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?

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.

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

#10125

"Ed" <nospam@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

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

#10127

Rod Pemberton wrote:

> "Ed" <nospam@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.

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

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

#10129

Peter Knaggs <pjk@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.

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

#10132

Andrew Haley <andrew29@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.

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

#10134

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@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.

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

#10179

Rod Pemberton wrote:
> "Ed" <nospam@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

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

#10185

"Ed" <nospam@invalid.com> writes:
>Rod Pemberton wrote:
>> "Ed" <nospam@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.

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

#10195

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> "Ed" <nospam@invalid.com> writes:
>>Rod Pemberton wrote:
>>> "Ed" <nospam@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.

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

#10201

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.

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

#10204

"Ed" <nospam@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.

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

#10212

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/

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

#10131

"Ed" <nospam@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
-- 
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]

#10121

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web