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

Groups > comp.arch.embedded > #23449 > unrolled thread

Decimal Point vs. Decimal Comma

Back to article view | Back to comp.arch.embedded

Contents

  Decimal Point vs. Decimal Comma rickman <gnuarm@gmail.com> - 2016-04-02 17:49 -0400
    Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-03 06:23 +0000
      Re: Decimal Point vs. Decimal Comma rickman <gnuarm@gmail.com> - 2016-04-03 02:59 -0400
      Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-03 23:14 +0000
        Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-04 07:18 +0300
          Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-04 07:48 +0300
    Re: Decimal Point vs. Decimal Comma upsidedown@downunder.com - 2016-04-03 09:45 +0300
    Re: Decimal Point vs. Decimal Comma Nils M Holm <nmh@ananda.local> - 2016-04-03 07:32 +0000
    Re: Decimal Point vs. Decimal Comma George Neuner <gneuner2@comcast.net> - 2016-04-03 05:25 -0400
      Re: Decimal Point vs. Decimal Comma Robert Wessel <robertwessel2@yahoo.com> - 2016-04-03 17:22 -0500
    Re: Decimal Point vs. Decimal Comma Norbert_Paul <norbertpauls_spambin@yahoo.com> - 2016-04-03 14:05 +0200
    Re: Decimal Point vs. Decimal Comma Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-04-03 14:18 +0200
      Re: Decimal Point vs. Decimal Comma upsidedown@downunder.com - 2016-04-03 20:24 +0300
        Re: Decimal Point vs. Decimal Comma Niklas Holsti <niklas.holsti@tidorum.invalid> - 2016-04-03 21:05 +0300
          Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-04 09:00 +0000
        Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-03 21:16 +0300
          Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-04 09:17 +0000
            Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-04 12:46 +0300
              Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-05 06:02 +0000
        Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-03 23:21 +0000
          Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-04 07:11 +0000
            Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-04 21:11 +0000
        Re: Decimal Point vs. Decimal Comma Robert Wessel <robertwessel2@yahoo.com> - 2016-04-04 00:13 -0500
          Re: Decimal Point vs. Decimal Comma "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2016-04-04 14:06 +0200
        Re: Decimal Point vs. Decimal Comma Nobody <nobody@nowhere.invalid> - 2016-04-05 03:32 +0100
          Re: Decimal Point vs. Decimal Comma upsidedown@downunder.com - 2016-04-05 09:56 +0300
            Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-05 10:03 +0000
              Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-05 21:42 +0000
            Re: Decimal Point vs. Decimal Comma George Neuner <gneuner2@comcast.net> - 2016-04-05 11:11 -0400
              Re: Decimal Point vs. Decimal Comma Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-05 11:33 -0500
              Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-06 12:50 +0000
          Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-05 07:15 +0000
            Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-05 21:50 +0000
              Re: Decimal Point vs. Decimal Comma Dimiter_Popoff <dp@tgi-sci.com> - 2016-04-06 01:18 +0300
                Re: Decimal Point vs. Decimal Comma Charles Allen <ccallen@iceland.freeshell.org> - 2016-04-06 15:20 +0000
                  Re: Decimal Point vs. Decimal Comma Dimiter_Popoff <dp@tgi-sci.com> - 2016-04-06 18:58 +0300
                  Re: Decimal Point vs. Decimal Comma Ed Prochak <edprochak@gmail.com> - 2016-04-07 07:04 -0700
                    Re: Decimal Point vs. Decimal Comma Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2016-04-07 23:40 +0200
                      Re: Decimal Point vs. Decimal Comma lasselangwadtchristensen@gmail.com - 2016-04-07 16:04 -0700
                        Re: Decimal Point vs. Decimal Comma David Brown <david.brown@hesbynett.no> - 2016-04-08 09:50 +0200
                          Re: Decimal Point vs. Decimal Comma rickman <gnuarm@gmail.com> - 2016-04-09 01:01 -0400
                            Re: Decimal Point vs. Decimal Comma David Brown <david.brown@hesbynett.no> - 2016-04-09 13:48 +0200
                    Re: Decimal Point vs. Decimal Comma mac <acolvin@efunct.com> - 2016-04-11 18:52 +0000
                Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-08 23:11 +0000
                  Re: Decimal Point vs. Decimal Comma Dimiter_Popoff <dp@tgi-sci.com> - 2016-04-09 03:19 +0300
                    Re: Decimal Point vs. Decimal Comma Ed Prochak <edprochak@gmail.com> - 2016-04-09 15:04 -0700
                      Re: Decimal Point vs. Decimal Comma Dimiter_Popoff <dp@tgi-sci.com> - 2016-04-10 01:49 +0300
                        Re: Decimal Point vs. Decimal Comma Ed Prochak <edprochak@gmail.com> - 2016-04-12 11:48 -0700
                          Re: Decimal Point vs. Decimal Comma Dimiter_Popoff <dp@tgi-sci.com> - 2016-04-12 22:53 +0300
                            Re: Decimal Point vs. Decimal Comma Paul <paul@pcserviceselectronics.co.uk> - 2016-04-12 23:03 +0100
                              Re: Decimal Point vs. Decimal Comma David Brown <david.brown@hesbynett.no> - 2016-04-13 09:21 +0200
                                Re: Decimal Point vs. Decimal Comma Paul <paul@pcserviceselectronics.co.uk> - 2016-04-13 16:51 +0100
                    Re: Decimal Point vs. Decimal Comma mac <acolvin@efunct.com> - 2016-04-11 18:52 +0000
                      Re: Decimal Point vs. Decimal Comma Dimiter_Popoff <dp@tgi-sci.com> - 2016-04-11 23:39 +0300
        Re: Decimal Point vs. Decimal Comma Ed Prochak <edprochak@gmail.com> - 2016-04-07 06:39 -0700

Page 1 of 3  [1] 2 3  Next page →

#23449 — Decimal Point vs. Decimal Comma

I know that roughly half the world uses a period to separate the 
fractional part of a number from the integer part.  Roughly half the 
world uses a comma for the same purpose.  But what about in computer 
languages?  A little research showed that Algol was specified to work 
with either.  Other computer languages seem to work primarily or 
exclusively with a period (point).

Are there any languages that support both formats without special 
programming?

-- 

Rick

[toc] | [next] | [standalone]

#23451

rickman <gnuarm@gmail.com> writes:
>I know that roughly half the world uses a period to separate the 
>fractional part of a number from the integer part.  Roughly half the 
>world uses a comma for the same purpose.  But what about in computer 
>languages?  A little research showed that Algol was specified to work 
>with either.

Not really.  Algol 60 (not sure about 68) did not specify the concrete
representation of the lexemes.  So one compiler could accept 123.45
and a different compiler could accept 123,45 as concrete syntax of the
same number.  But the compilers would not necessarily accept the other
syntax.  A typical standardization cockup.

>Are there any languages that support both formats without special 
>programming?

Some Forth implementations do.  E.g., SwiftForth and bigForth:

                       ANS bigFORTH 386-Linux rev. 2.3.1

123.45 d. 12345  ok
123,45 d. 12345  ok

A very early version of Gforth also worked that way, but I removed
this feature, because it's more important to be able to get a useful
error message if you use "2,", but the Forth system does not define
it.  I have not missed this feature, and I come from the part of the
world that uses decimal comma.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#23453

On 4/3/2016 2:23 AM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> I know that roughly half the world uses a period to separate the
>> fractional part of a number from the integer part.  Roughly half the
>> world uses a comma for the same purpose.  But what about in computer
>> languages?  A little research showed that Algol was specified to work
>> with either.
>
> Not really.  Algol 60 (not sure about 68) did not specify the concrete
> representation of the lexemes.  So one compiler could accept 123.45
> and a different compiler could accept 123,45 as concrete syntax of the
> same number.  But the compilers would not necessarily accept the other
> syntax.  A typical standardization cockup.
>
>> Are there any languages that support both formats without special
>> programming?
>
> Some Forth implementations do.  E.g., SwiftForth and bigForth:
>
>                         ANS bigFORTH 386-Linux rev. 2.3.1
>
> 123.45 d. 12345  ok
> 123,45 d. 12345  ok
>
> A very early version of Gforth also worked that way, but I removed
> this feature, because it's more important to be able to get a useful
> error message if you use "2,", but the Forth system does not define
> it.  I have not missed this feature, and I come from the part of the
> world that uses decimal comma.

But neither of these are "correct".  I was talking about the radix point 
that separates the fraction from the integer portion of a number.

-- 

Rick

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

#23463

Am Sun, 03 Apr 2016 06:23:56 +0000 schrieb Anton Ertl:

> A very early version of Gforth also worked that way, but I removed this
> feature, because it's more important to be able to get a useful error
> message if you use "2,", but the Forth system does not define it.  I
> have not missed this feature, and I come from the part of the world that
> uses decimal comma.

VFX has dp-char and fp-char to store the currently used decimal separator 
for doubles and floats (actually, a zero-terminated string of a few 
characters), by default, dp-char is both '.' and ',', so you can enter 
both forms:

 VFX Forth for Linux IA32

123,456 d. 123456  ok
123.456 d. 123456  ok

fp-char is by default just '.'.

Gforth's current development versions also have dp-char and fp-char, but 
only one possible character; default is ".".  This allows to change the 
character in case you want to read localized numbers.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#23465

On 04/04/2016 02:14, Bernd Paysan wrote:

> VFX has dp-char and fp-char to store the currently used decimal separator 
> for doubles and floats (actually, a zero-terminated string of a few 
> characters), by default, dp-char is both '.' and ',', so you can enter 
> both forms

8th doesn't distinguish doubles and floats (it just has 'numbers').  But
it does let you set the (output) values of the decimal and thousands
separators using .# and ,# respectively.  You cannot query the current
values; they default to . and ,

One weakness is that for example, outputting numbers for Indian users is
more difficult, since 8th has no internal concept of 'locale' and the
built-in ,# will only cause 'thousands separators' every three
characters, unlike the normal Indian formatting.  That would have to be
done manually using e.g. "s:strfmt" or other words.

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

#23466

On 04/04/2016 07:18, Ron Aaron wrote:
> 

> One weakness is that for example, outputting numbers for Indian users is
> more difficult...

Here's one way to do it:
http://8th-dev.com/forum/index.php/topic,893.0.html

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

#23452

On Sat, 2 Apr 2016 17:49:07 -0400, rickman <gnuarm@gmail.com> wrote:

>I know that roughly half the world uses a period to separate the 
>fractional part of a number from the integer part.  Roughly half the 
>world uses a comma for the same purpose.  But what about in computer 
>languages?  A little research showed that Algol was specified to work 
>with either.  Other computer languages seem to work primarily or 
>exclusively with a period (point).
>
>Are there any languages that support both formats without special 
>programming?

In COBOL:
DECIMAL-POINT IS COMMA

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

#23454

In comp.arch.embedded rickman <gnuarm@gmail.com> wrote:
> Are there any languages that support both formats without special 
> programming?

        ENVIRONMENT DIVISION.
        CONFIGURATION SECTION.
            DECIMAL-POINT IS COMMA.

COBOL :)

-- 
Nils M Holm  < n m h @ t 3 x . o r g >  www.t3x.org

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

#23455

On Sat, 2 Apr 2016 17:49:07 -0400, rickman <gnuarm@gmail.com> wrote:

>I know that roughly half the world uses a period to separate the 
>fractional part of a number from the integer part.  Roughly half the 
>world uses a comma for the same purpose.  But what about in computer 
>languages?  A little research showed that Algol was specified to work 
>with either.  Other computer languages seem to work primarily or 
>exclusively with a period (point).
>
>Are there any languages that support both formats without special 
>programming?

If I understand correctly that you're asking about numeric literals in
program source, then I think the answer is COBOL and very possibly
nothing else.  

It's trivial to make a lexer accept either number format, but many
languages use commas as separators for, e.g., function arguments,
array and list elements, etc. ...  so also using commas as decimal
marks would cause problems.

Consider:     x = f( 1,9 );

Is that one argument or two?  Depends on number lexing.  Given a
particular lexing, one of the two possible parses is an error - but
which depends on the declaration of f().  This could be extremely
confusing to a programmer.  The only way around it is to also change
the argument separator, or to enforce that truly separate values be
separated by whitespace in addition to the separator.

Pretty much only the whitespace separated sexpr syntax of Lisp (and
Scheme) is immune to the parsing issue ... languages like ML and
Haskel, etc. don't necessarily need commas for function calls, but
they still do use them for other things.

I'm not aware of any language that specifically addresses this issue
regarding its source code - all that I am familar with simply use the
dot syntax for decimals.  Number formats often are addressed as locale
issues for I/O libraries, but not for program source.

Many compilers now allow Unicode in their source, but programmers
still are actively discouraged from using non-ASCII characters.  And
non-English speaking programmers almost are forced to program in
English for portability.  English is the lingua franca of programming.
There have been compilers designed specifically for certain locales,
but sans government mandate of their use, none has ever been very
successful.


Incidentally, I'm not sure what you saw re: Algol, but neither Algol
60 nor 68 permitted commas as decimal marks - both used the dot
syntax.  I don't have a reference for Algol 58, but all the Algols
used commas as argument and array separators, so they all would have
been susceptible to the parsing issue described above.  

YMMV,
George

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

#23462

On Sun, 03 Apr 2016 05:25:10 -0400, George Neuner
<gneuner2@comcast.net> wrote:

>On Sat, 2 Apr 2016 17:49:07 -0400, rickman <gnuarm@gmail.com> wrote:
>
>>I know that roughly half the world uses a period to separate the 
>>fractional part of a number from the integer part.  Roughly half the 
>>world uses a comma for the same purpose.  But what about in computer 
>>languages?  A little research showed that Algol was specified to work 
>>with either.  Other computer languages seem to work primarily or 
>>exclusively with a period (point).
>>
>>Are there any languages that support both formats without special 
>>programming?
>
>If I understand correctly that you're asking about numeric literals in
>program source, then I think the answer is COBOL and very possibly
>nothing else.  
>
>It's trivial to make a lexer accept either number format, but many
>languages use commas as separators for, e.g., function arguments,
>array and list elements, etc. ...  so also using commas as decimal
>marks would cause problems.
>
>Consider:     x = f( 1,9 );
>
>Is that one argument or two?  Depends on number lexing.  Given a
>particular lexing, one of the two possible parses is an error - but
>which depends on the declaration of f().  This could be extremely
>confusing to a programmer.  The only way around it is to also change
>the argument separator, or to enforce that truly separate values be
>separated by whitespace in addition to the separator.
>
>Pretty much only the whitespace separated sexpr syntax of Lisp (and
>Scheme) is immune to the parsing issue ... languages like ML and
>Haskel, etc. don't necessarily need commas for function calls, but
>they still do use them for other things.
>
>I'm not aware of any language that specifically addresses this issue
>regarding its source code - all that I am familar with simply use the
>dot syntax for decimals.  Number formats often are addressed as locale
>issues for I/O libraries, but not for program source.
>
>Many compilers now allow Unicode in their source, but programmers
>still are actively discouraged from using non-ASCII characters.  And
>non-English speaking programmers almost are forced to program in
>English for portability.  English is the lingua franca of programming.
>There have been compilers designed specifically for certain locales,
>but sans government mandate of their use, none has ever been very
>successful.
>
>
>Incidentally, I'm not sure what you saw re: Algol, but neither Algol
>60 nor 68 permitted commas as decimal marks - both used the dot
>syntax.  I don't have a reference for Algol 58, but all the Algols
>used commas as argument and array separators, so they all would have
>been susceptible to the parsing issue described above.  


Cobol has the same issue, so if you use DECIMAL POINT IS COMMA, you
need to be more careful with whitespace in some places.  But
subscripting is not one of them, since only integers are allowed there
(I think this might have changed in modern Cobol so that you can have
full expressions in subscripts, but I'm not sure).

Cobol is full of weird parsing rules.

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

#23456

rickman wrote:
> I know that roughly half the world uses a period to separate the
> fractional part of a number from the integer part. Roughly half the
> world uses a comma for the same purpose. But what about in computer
> languages? A little research showed that Algol was specified to work
> with either. Other computer languages seem to work primarily or
> exclusively with a period (point).
>
> Are there any languages that support both formats without special
> programming?
>
Maybe by modfying the read-table of Common Lisp.
But this might already be "special programming"
and I don't even know exactly if this is possible
(but I very much suppose so).

http://clhs.lisp.se/Body/02_.htm
--> http://clhs.lisp.se/Body/02_aa.htm

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

#23457

Am 02.04.2016 um 23:49 schrieb rickman:
> I know that roughly half the world uses a period to separate the
> fractional part of a number from the integer part.  Roughly half the
> world uses a comma for the same purpose.  But what about in computer
> languages?

In computer languages we have barely enough punctuation letters 
available as it is, to express all the necessary things without being 
overly verbose.  Wasting one on a luxury item like that would IMHO be 
unjustifiable.

Programs need to be able to handle localized formats on input and 
output, but not in the source itself.

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

#23459

On Sun, 3 Apr 2016 14:18:56 +0200, Hans-Bernhard Bröker
<HBBroeker@t-online.de> wrote:

>Am 02.04.2016 um 23:49 schrieb rickman:
>> I know that roughly half the world uses a period to separate the
>> fractional part of a number from the integer part.  Roughly half the
>> world uses a comma for the same purpose.  But what about in computer
>> languages?
>
>In computer languages we have barely enough punctuation letters 
>available as it is, to express all the necessary things without being 
>overly verbose.  Wasting one on a luxury item like that would IMHO be 
>unjustifiable.

Some computer languages like COBOL and FORTRAN could be written with 6
bit codes (like FIELDDATA).
 
Unfortunately languages like C and Pascal used characters from ISO-686
character sets, including characters reserved for national variants.


>Programs need to be able to handle localized formats on input and 
>output, but not in the source itself.

What is the problem of using Latin-1 (ISO 8859-1) in a programming
language ?

In fact it would be a great thing, if you could use UTF-8 in
programming, e.g. Greek letters Alfa and Beta as program variables ?
No need to do any translitteration from any textbok variables.

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

#23460

On 16-04-03 20:24 , upsidedown@downunder.com wrote:
> On Sun, 3 Apr 2016 14:18:56 +0200, Hans-Bernhard Bröker
> <HBBroeker@t-online.de> wrote:
>
> What is the problem of using Latin-1 (ISO 8859-1) in a programming
> language ?

Allowed in Ada.

> In fact it would be a great thing, if you could use UTF-8 in
> programming, e.g. Greek letters Alfa and Beta as program variables ?
> No need to do any translitteration from any textbok variables.

You can do that in Ada. Whether it makes sense is another question.

I usually keep to alphanumerics, but sometimes I use accented letters 
when I write Ada in a Finnish context, with Finnish names for variables.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

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

#23471

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

>On 16-04-03 20:24 , upsidedown@downunder.com wrote:
>> On Sun, 3 Apr 2016 14:18:56 +0200, Hans-Bernhard Bröker
>> <HBBroeker@t-online.de> wrote:
>>
>> What is the problem of using Latin-1 (ISO 8859-1) in a programming
>> language ?

>Allowed in Ada.

>> In fact it would be a great thing, if you could use UTF-8 in
>> programming, e.g. Greek letters Alfa and Beta as program variables ?
>> No need to do any translitteration from any textbok variables.

>You can do that in Ada. Whether it makes sense is another question.

>I usually keep to alphanumerics, but sometimes I use accented letters
>when I write Ada in a Finnish context, with Finnish names for variables.

What Algol68 does makes much more sense. It defines symbols
that makes sense for the language. Like "less or equal" (a kind of
underscored <) and bold stropping. That makes Algol68 look very
good in publications.  Relevant to this discussion: the exponent
E that we have is a subscripted e in Algol 68.
Now how to use those in a particular implementation
is implementation defined.

There is a burden when copying program sources. We have that problem
in Forth too, in particular with meta sources. Maybe it is better
to permanently realize that a program always uses a character
representation that is somewhat arbitrary and must be part of
defining a standard.

>--
>Niklas Holsti

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]

#23461

On 03/04/2016 20:24, upsidedown@downunder.com wrote:

> In fact it would be a great thing, if you could use UTF-8 in
> programming, e.g. Greek letters Alfa and Beta as program variables ?
> No need to do any translitteration from any textbok variables.

You can.  In 8th you certainly can, and I don't see why a standard Forth
would disallow a UTF-8 name.

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

#23472

Ron Aaron <rambamist@gmail.com> writes:



>On 03/04/2016 20:24, upsidedown@downunder.com wrote:

>> In fact it would be a great thing, if you could use UTF-8 in
>> programming, e.g. Greek letters Alfa and Beta as program variables ?
>> No need to do any translitteration from any textbok variables.

>You can.  In 8th you certainly can, and I don't see why a standard Forth
>would disallow a UTF-8 name.

You can have a certain leeway as implementor, because non-ascii characters
are "implementation defined". This makes the use of the IBM box-printing
characters a portable program with dependancies.

I've a different strategy in ciforth. A name is a string of bytes,
not characters. That is why I detest case insensitivity.
The interpretation mechanism just looks up a byte string.
So a name can contain sequences that turn the current foreground
color green then red, so as to have names that look like colorforth
if printed on an appropriate device (a VT100 would not do).

Instead of manipulating >IN ciforth has lifted to an ever so slightly
higher abstraction, PP@@.
PP@@ returns an incremented parse pointer and the next character (that
must fit in 64 bits). By revectoring PP@@ one can redefine how word
names are interpreted into characters, or escape sequences.

A practical application is com-4e5 . Any function keys are just
stored in the dictionary. Press a function key while in communication
mode and it will just be executed. Press an as yet undefined key
and you get the chance to define it.

If you use this, your program is no longer ascii and looses the
epitethon "Forth with environmental dependancies".

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]

#23473

On 04/04/2016 12:17, Albert van der Horst wrote:

> You can have a certain leeway as implementor, because non-ascii characters
> are "implementation defined". This makes the use of the IBM box-printing
> characters a portable program with dependancies.

Right; I assumed that since Forths parse whitespace-delimited words, any
bytes which are not whitespace would be ok for names.


> I've a different strategy in ciforth. A name is a string of bytes,
> not characters. That is why I detest case insensitivity.

Me too :o

...
> A practical application is com-4e5 . Any function keys are just
> stored in the dictionary. Press a function key while in communication
> mode and it will just be executed. Press an as yet undefined key
> and you get the chance to define it.

That is very cool, hadn't thought of that idea.

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

#23494

Ron Aaron <rambamist@gmail.com> writes:
>
>
>On 04/04/2016 12:17, Albert van der Horst wrote:
>
>> You can have a certain leeway as implementor, because non-ascii characters
>> are "implementation defined". This makes the use of the IBM box-printing
>> characters a portable program with dependancies.
>
>Right; I assumed that since Forths parse whitespace-delimited words, any
>bytes which are not whitespace would be ok for names.

It turns out that that's the case in mainstream Forth systems.

fig-Forth used the highest bit for marking the end of the stored part
of the name in a dictionary entry, but that practice apparently died
out together with the practice of being able to store only a part of
the name.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#23464

Am Sun, 03 Apr 2016 20:24:10 +0300 schrieb upsidedown:

>>Programs need to be able to handle localized formats on input and
>>output,
>>but not in the source itself.
> 
> What is the problem of using Latin-1 (ISO 8859-1) in a programming
> language ?
> 
> In fact it would be a great thing, if you could use UTF-8 in
> programming,
> e.g. Greek letters Alfa and Beta as program variables ? No need to do
> any translitteration from any textbok variables.

Forth-2012 with the Xchar wordset allows all XChar printable characters 
as part of a Forth word (usually UTF-8).  People use that; we recently 
had an article about a Chinese student team using Forth to win a 
competition, and one of the two programmers used Chinese for his own 
definitions.

As far as I can test here, all Forth systems I tested have no problems 
with this approach; just case insensitivity is limited to ASCII (which 
the standard recommends, we have case insensitivity to write words in 
lower case which have been standardized in upper case).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web