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

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

Decimal Point vs. Decimal Comma

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

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 Coos Haak <chforth@hccnet.nl> - 2016-04-03 17:33 +0200
        Re: Decimal Point vs. Decimal Comma "Elizabeth D. Rather" <erather@forth.com> - 2016-04-03 21:21 -1000
          Re: Decimal Point vs. Decimal Comma Paul Rubin <no.email@nospam.invalid> - 2016-04-04 01:42 -0700
            Re: Decimal Point vs. Decimal Comma hughaguilar96@gmail.com - 2016-04-04 02:00 -0700
              Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-04 10:00 +0000
                Re: Decimal Point vs. Decimal Comma hughaguilar96@gmail.com - 2016-04-04 03:04 -0700
                Re: Decimal Point vs. Decimal Comma "Elizabeth D. Rather" <erather@forth.com> - 2016-04-04 11:16 -1000
            Re: Decimal Point vs. Decimal Comma "Elizabeth D. Rather" <erather@forth.com> - 2016-04-03 23:28 -1000
              Re: Decimal Point vs. Decimal Comma Paul Rubin <no.email@nospam.invalid> - 2016-04-04 02:38 -0700
                Re: Decimal Point vs. Decimal Comma "Elizabeth D. Rather" <erather@forth.com> - 2016-04-04 11:09 -1000
              Re: Decimal Point vs. Decimal Comma "HAA" <someone@microsoft.com> - 2016-04-08 00:18 +1000
                Re: Decimal Point vs. Decimal Comma Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-08 03:27 -0500
                  Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-08 08:30 +0000
                    Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-08 12:00 +0300
                      Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-08 10:25 +0000
                        Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-08 13:34 +0300
                          Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-08 11:46 +0000
                            Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-08 15:20 +0300
                    Re: Decimal Point vs. Decimal Comma Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-08 04:08 -0500
                      Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-08 10:26 +0000
                        Re: Decimal Point vs. Decimal Comma Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-08 10:37 -0500
                          Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-09 15:28 +0000
                            Re: Decimal Point vs. Decimal Comma Paul Rubin <no.email@nospam.invalid> - 2016-04-09 10:17 -0700
                              Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-11 14:45 +0000
                                Re: Decimal Point vs. Decimal Comma Ron Aaron <rambamist@gmail.com> - 2016-04-12 10:18 +0300
                        Re: Decimal Point vs. Decimal Comma hughaguilar96@gmail.com - 2016-04-08 09:05 -0700
                          Re: Decimal Point vs. Decimal Comma hughaguilar96@gmail.com - 2016-04-08 10:14 -0700
                            Re: Decimal Point vs. Decimal Comma Julian Fondren <julian.fondren@gmail.com> - 2016-04-08 15:51 -0700
                              Re: Decimal Point vs. Decimal Comma Julian Fondren <julian.fondren@gmail.com> - 2016-04-08 16:11 -0700
                          Re: Decimal Point vs. Decimal Comma "WJ" <w_a_x_man@yahoo.com> - 2016-05-09 01:16 +0000
                        Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-04-08 22:18 +0000
                          Re: Decimal Point vs. Decimal Comma Paul Rubin <no.email@nospam.invalid> - 2016-04-08 20:33 -0700
                            Re: Decimal Point vs. Decimal Comma mhx@iae.nl - 2016-04-09 01:20 -0700
                              Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-09 11:03 +0000
                            Re: Decimal Point vs. Decimal Comma mhx@iae.nl - 2016-04-09 01:29 -0700
                          Double and FP syntax (was: Decimal Point vs. Decimal Comma) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-09 09:19 +0000
                            Re: Double and FP syntax "Elizabeth D. Rather" <erather@forth.com> - 2016-04-09 14:25 -1000
                              Re: Double and FP syntax hughaguilar96@gmail.com - 2016-04-10 21:48 -0700
                            Re: Double and FP syntax (was: Decimal Point vs. Decimal Comma) stephen@mpeforth.com (Stephen Pelc) - 2016-04-15 10:17 +0000
                              Re: Double and FP syntax (was: Decimal Point vs. Decimal Comma) hughaguilar96@gmail.com - 2016-04-17 16:48 -0700
                              Re: Double and FP syntax (was: Decimal Point vs. Decimal Comma) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-24 16:03 +0000
          Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-04 09:27 +0000
        Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-04 08:52 +0000
      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 hughaguilar96@gmail.com - 2016-04-03 19:27 -0700
        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 hughaguilar96@gmail.com - 2016-04-04 19:52 -0700
          Re: Decimal Point vs. Decimal Comma upsidedown@downunder.com - 2016-04-05 09:56 +0300
            Re: Decimal Point vs. Decimal Comma hughaguilar96@gmail.com - 2016-04-05 00:13 -0700
              Re: Decimal Point vs. Decimal Comma anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-04-05 09:44 +0000
                Re: Decimal Point vs. Decimal Comma Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-04-05 12:38 +0000
            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 hughaguilar96@gmail.com - 2016-04-05 11:58 -0700
              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 hughaguilar96@gmail.com - 2016-04-05 01:12 -0700
            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 hughaguilar96@gmail.com - 2016-04-05 23:47 -0700
                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 hughaguilar96@gmail.com - 2016-04-08 22:06 -0700
                    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 endlessboomcapitalism@gmail.com - 2016-05-02 15:29 -0700
      Re: Decimal Point vs. Decimal Comma rickman <gnuarm@gmail.com> - 2016-05-02 22:27 -0400
        Re: Decimal Point vs. Decimal Comma Gerard Sontag <gerardsontag@gmail.com> - 2016-05-03 05:06 -0700
        Re: Decimal Point vs. Decimal Comma Bernd Paysan <bernd.paysan@gmx.de> - 2016-05-06 23:42 +0000
          Re: Decimal Point vs. Decimal Comma rickman <gnuarm@gmail.com> - 2016-05-06 20:37 -0400

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#46472

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]

#46498

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]

#46452

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]

#46461

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Am Sun, 03 Apr 2016 20:24:10 +0300 schrieb upsidedown:
>> 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).

Actually Forth-2012 falls slightly short of actually guaranteeing that
this works, because it does not require that the Forth system supports
UTF-8.

Fortunately, UTF-8 is designed to be compatible with existing code, so
if the system is 8-bit clean and does not do funny things for
recognizing white space, it will pretty much work with UTF-8.  An
example is old versions of Gforth (long before anybody thought about
the Xchar wordset), where everything but command-line editing works
with UTF-8.

An example of UTF-8 variables in Forth (and other languages on the
same page) is shown on
<http://rosettacode.org/wiki/Unicode_variable_names#Forth>.

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

#46487

Am Mon, 04 Apr 2016 07:11:32 +0000 schrieb Anton Ertl:

>>Forth-2012 with the Xchar wordset allows all XChar printable characters
>>as part of a Forth word (usually UTF-8).
> 
> Actually Forth-2012 falls slightly short of actually guaranteeing that
> this works, because it does not require that the Forth system supports
> UTF-8.

In the rationale, we recommend implementing support for UTF-8.  It's a 
weak recommendation, not a strong requirement, so it's up to observation 
what kind of common practice will emerge.

Most systems that have been tried with UTF-8 sources have no special 
support for it, e.g. the amForth programs in VF 2015/03-04 is compiled on 
an amForth without any xchar extension.  VFX and SwiftForth also don't 
come with xchars compiled into the default image, and yet, UTF-8-based 
source code works on both.  There are some minor issues in the command 
line editor when you try editing that stuff, which doesn't exist in an 
xchar-aware command line editor like Gforth's, though.

But we have to implement a good locate before complaining about VFX 
again ;-).

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

#46455

On Sunday, April 3, 2016 at 10:24:05 AM UTC-7, upsid...@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.

The Go language from Google uses UTF-8 --- it is possible to have a variable theta for an angle, for example.

They have functions for converting to upper-case or lower-case --- I don't know how they work --- that is pretty complicated.

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

#46458

On Sun, 03 Apr 2016 20:24:10 +0300, upsidedown@downunder.com wrote:

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


You've always been able to do that in Java, although it's UCS-2 (old
versions) or UTF-16 (current), not UTF-8.

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

#46482

Op Mon, 04 Apr 2016 07:13:44 +0200 schreef Robert Wessel  
<robertwessel2@yahoo.com>:
> On Sun, 03 Apr 2016 20:24:10 +0300, upsidedown@downunder.com wrote:
>> 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:
>> [...]
>>
>> 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've always been able to do that in Java, although it's UCS-2 (old
> versions) or UTF-16 (current), not UTF-8.

javac has the -encoding option, so you can use anything you want.


-- 
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

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

#46489

On Sun, 03 Apr 2016 20:24:10 +0300, upsidedown wrote:

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

The problem is that it raises the bar for any system needing to touch the
code. It creates problems for printing the code using non-graphical
printers, editing the code on a character-based terminal, transmitting it
through a 7-bit channel, or embedding it in any data format with a limited
character set.

Most computer systems only allow a small number of characters to be
entered without having to resort to numeric codes or searching through
tables for something to be clicked with the mouse. Homoglyphs create
confusion.

Even regular punctuation is bad enough, as most of it requires using the
little fingers or reaching for the top row, possibly along with the use of
the shift (or even AltGr) key.

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

#46491

On Monday, April 4, 2016 at 7:32:16 PM UTC-7, Nobody wrote:
> On Sun, 03 Apr 2016 20:24:10 +0300, upsidedown wrote:
> 
> > 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.
> 
> The problem is that it raises the bar for any system needing to touch the
> code. It creates problems for printing the code using non-graphical
> printers, editing the code on a character-based terminal, transmitting it
> through a 7-bit channel, or embedding it in any data format with a limited
> character set.
> 
> Most computer systems only allow a small number of characters to be
> entered without having to resort to numeric codes or searching through
> tables for something to be clicked with the mouse. Homoglyphs create
> confusion.
> 
> Even regular punctuation is bad enough, as most of it requires using the
> little fingers or reaching for the top row, possibly along with the use of
> the shift (or even AltGr) key.

I agree with this. In Go code (Google's language) I have noticed that most people stick with ASCII anyway. Using theta for an angle is somewhat cool, but it is not essential --- you can also just use "theta" for your variable name.

In my own FloatForth I originally felt inspired by Go to support UTF-8, but then I changed my mind and decided that source-code should be ASCII although FloatForth would support UTF-8 strings. The programmers have to write in English though (for one thing, all the words such as SWAP BEGIN WHILE REPEAT etc. are English). It can be used for programs that communicate with the users in a foreign language though, which is useful (I am in favor of letting Mexican-Americans use Spanish if they like it, and not forcing them to use English).

I mentioned elsewhere that I'm learning Ido. One of the many reasons why Ido is an improvement over Esperanto is that Ido uses the regular alphabet whereas Esperanto uses a funky alphabet in which some of the letters have little hats. Esperanto was invented in the 19th century prior to the invention of typewriters when everybody wrote documents by long-hand --- putting little hats on the letters is easy enough with a pen and paper --- it is, as you said, much more difficult with a computer.

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

#46505

On Tue, 05 Apr 2016 03:32:54 +0100, Nobody <nobody@nowhere.invalid>
wrote:

>On Sun, 03 Apr 2016 20:24:10 +0300, upsidedown wrote:
>
>> 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.
>
>The problem is that it raises the bar for any system needing to touch the
>code.

Windows NT has supported Unicode from the beginning in the 1990's
(UTF-16) and Linux for a long time (UTF-8). Smart phones also have
some kind of support.
 
> It creates problems for printing the code using non-graphical
>printers, 

Can you still buy printers with built in character ROMs ?

>editing the code on a character-based terminal, 

Anybody using VT-100 terminals for program development ?

>transmitting it
>through a 7-bit channel, 

Latin-x (8859-x) character sets support most European languages and it
requires 8 bit characters. If insisting of using 7 (or 6) bit
channels, some encapsulation methods are needed to carry the 8 bit
Latin character sets. The same encapsulation method should be able to
carry UTF-8.

>or embedding it in any data format with a limited
>character set.
>
>Most computer systems only allow a small number of characters to be
>entered without having to resort to numeric codes or searching through
>tables for something to be clicked with the mouse. Homoglyphs create
>confusion.

I have done (with code pages) bilingual (Latin/Cyrillc and
Latin/Arabic) systems. Usually you had a special key for toggling
between languages, no big deal. These days any touch screen virtual
keyboard it is even more trivial.

>Even regular punctuation is bad enough, as most of it requires using the
>little fingers or reaching for the top row, possibly along with the use of
>the shift (or even AltGr) key.

Your arguments might have been valid in the beginning of this century,
but these days they are non-issues.

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

#46509

On Monday, April 4, 2016 at 11:56:15 PM UTC-7, upsid...@downunder.com wrote:
> Latin-x (8859-x) character sets support most European languages and it
> requires 8 bit characters. 

The problem I have with UTF-8 for source-code is that I don't know how to write a function to convert text into upper-case --- this is necessary for case-insensitive code, which is used in Forth these days --- I'd be okay with ASCII-8859 though, because such a function is trivial with it.

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

#46521

hughaguilar96@gmail.com writes:
>The problem I have with UTF-8 for source-code is that I don't know how to w=
>rite a function to convert text into upper-case --- this is necessary for c=
>ase-insensitive code, which is used in Forth these days

What's more important than your lack of knowledge is that the case
conversion outside the ASCII range depends on the encoding.  I.e.,
with UTF-8 you get one case conversion, with Latin-1 a different one,
with Latin-2 yet another one, with KOI8-R yet another one etc.  So if
we used case conversion for non-ASCII characters, we would have to
ensure that the Forth system knows the encoding of the program.  Also,
case conversion in general is much more complicated than for ASCII,
and language-dependent.  E.g., in Turkish the conversions for i and I
are different than in most other languages.

Gforth's solution to that (and one that I recommend for all systems)
is to be case-insensitive only for the ASCII characters.  The
motivation for case insensitivity is that the standard words are in
upper case, while most programmers nowadays prefer to write and read
most of them in lower case, and that's covered by that solution.  For
programmer-defined words, who needs case-insensitivity?

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

#46522

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

<SNIP>

>Gforth's solution to that (and one that I recommend for all systems)
>is to be case-insensitive only for the ASCII characters.  The
>motivation for case insensitivity is that the standard words are in
>upper case, while most programmers nowadays prefer to write and read
>most of them in lower case, and that's covered by that solution.  For
>programmer-defined words, who needs case-insensitivity?

Right, but I would restrict it even more. I would have:
    For all words defined in this standard, words where "A-Z" is
    replaced by a corresponding "a-z" must be accepted by a standards
    conforming implementation. If such word is redefined by a
    program, a non-conforming system results.

This deletes the reference to ASCII and in fact the word case-sensitive
needs not enter.
(I would rather not apply it to numbers, because I like to keep the
possibility of base >36 open. This is probably a hobby horse, and
I'd gladly give that up if the standard settles this one and for all.)

Let's finally rid us of the curse of the FORTRAN punch cards.

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

#46520

upsidedown@downunder.com writes:

>On Tue, 05 Apr 2016 03:32:54 +0100, Nobody <nobody@nowhere.invalid>
>wrote:

>>On Sun, 03 Apr 2016 20:24:10 +0300, upsidedown wrote:
>>
>>> 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.
>>
>>The problem is that it raises the bar for any system needing to touch the
>>code.

>Windows NT has supported Unicode from the beginning in the 1990's
>(UTF-16) and Linux for a long time (UTF-8). Smart phones also have
>some kind of support.
>
>> It creates problems for printing the code using non-graphical
>>printers,

>Can you still buy printers with built in character ROMs ?

>>editing the code on a character-based terminal,

>Anybody using VT-100 terminals for program development ?

>>transmitting it
>>through a 7-bit channel,

>Latin-x (8859-x) character sets support most European languages and it
>requires 8 bit characters. If insisting of using 7 (or 6) bit
>channels, some encapsulation methods are needed to carry the 8 bit
>Latin character sets. The same encapsulation method should be able to
>carry UTF-8.

>>or embedding it in any data format with a limited
>>character set.
>>
>>Most computer systems only allow a small number of characters to be
>>entered without having to resort to numeric codes or searching through
>>tables for something to be clicked with the mouse. Homoglyphs create
>>confusion.

>I have done (with code pages) bilingual (Latin/Cyrillc and
>Latin/Arabic) systems. Usually you had a special key for toggling
>between languages, no big deal. These days any touch screen virtual
>keyboard it is even more trivial.

>>Even regular punctuation is bad enough, as most of it requires using the
>>little fingers or reaching for the top row, possibly along with the use of
>>the shift (or even AltGr) key.

>Your arguments might have been valid in the beginning of this century,
>but these days they are non-issues.

All the above arguments are eminently valid. I'm a productive programmer
which implies I'm a ten finger blind typist. That means that I restrict
the language I type in to the keyboard layout I'm used to.
Using a touch keyboard on a notepad is already a great slow down.
Remember, when I'm typing, I'm not typing, I'm thinking. I can't
have the distraction of " how was the theta symbol again" if I'm
trying to define a class for computation of continued fractions.

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]

#46535

Am Tue, 05 Apr 2016 10:03:07 +0000 schrieb Albert van der Horst:

> All the above arguments are eminently valid. I'm a productive programmer
> which implies I'm a ten finger blind typist. That means that I restrict
> the language I type in to the keyboard layout I'm used to.
> Using a touch keyboard on a notepad is already a great slow down.
> Remember, when I'm typing, I'm not typing, I'm thinking. I can't have
> the distraction of " how was the theta symbol again" if I'm trying to
> define a class for computation of continued fractions.

The way to deal with symbols is to have an IME.  fcitx supports 
Quickphrase LaTeX for symbols:

https://fcitx-im.org/wiki/QuickPhrase_Latex

Or math-latex(m17n), there the same names apply, but instead of using \ 
to switch into the symbol mode, you can use the mode hotkey to get there.

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

#46526

On Tue, 05 Apr 2016 09:56:20 +0300, upsidedown@downunder.com wrote:

>On Tue, 05 Apr 2016 03:32:54 +0100, Nobody <nobody@nowhere.invalid>
>wrote:
>
>> [Unicode] creates problems for printing the code using non-graphical
>>printers, 
>
>Can you still buy printers with built in character ROMs ?

Yes.  There are dot matrix printers still available from a number of
vendors.  Lasers cannot handle multi-part forms. 


>>editing the code on a character-based terminal, 
>
>Anybody using VT-100 terminals for program development ?

A lot of people develop scripts using terminal editors.  Does that
count?

George
[I still have two working Okidata dot matrix, one original and one
with the IBM character ROM.]

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

#46527

In comp.lang.forth George Neuner <gneuner2@comcast.net> wrote:
> On Tue, 05 Apr 2016 09:56:20 +0300, upsidedown@downunder.com wrote:
> 
>>On Tue, 05 Apr 2016 03:32:54 +0100, Nobody <nobody@nowhere.invalid>
>>wrote:
>>
>>Anybody using VT-100 terminals for program development ?
> 
> A lot of people develop scripts using terminal editors.  Does that
> count?

Not really, no.  Xterms seem to work fine with UTF-8, and so does the
GNOME terminal emulator.  I think we're just about done.  And being
able to use real symbols in programs is very nice.

Andrew.

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

#46532

On Tuesday, April 5, 2016 at 8:11:03 AM UTC-7, George Neuner wrote:
> On Tue, 05 Apr 2016 09:56:20 +0300, upsidedown@downunder.com wrote:
> 
> >On Tue, 05 Apr 2016 03:32:54 +0100, Nobody <nobody@nowhere.invalid>
> >wrote:
> >
> >> [Unicode] creates problems for printing the code using non-graphical
> >>printers, 
> >
> >Can you still buy printers with built in character ROMs ?
> 
> Yes.  There are dot matrix printers still available from a number of
> vendors.  Lasers cannot handle multi-part forms. 

When I was working as an IBM370 programmer we took data to a place that did printing (these were form letters being sent out for voter registration or some such thing). I think what they had was a "line printer" of some kind, although I don't really know much about the subject. It could print out letters hella fast! This was in the 1990s though, so maybe all that is obsolete now --- I doubt it though, as the the equipment was plenty fast then, and should still be fast enough now --- actually, what is obsolete is snail-mail, so the volume needed to be printed is less nowadays rather than more.

All of this is irrelevant though because we are talking about source-code. I think that ASCII, or possibly ASCII-8859, is adequate for source-code. Using funky characters in source-code is mostly a gee-gaw, but not really necessary.

As for text going to the customers, I think that UTF is a good idea --- there are plenty of people in America who prefer some foreign-language to English, plus obviously foreign countries tend to be full of foreign people --- I don't think anybody disagrees with this.

> >>editing the code on a character-based terminal, 
> >
> >Anybody using VT-100 terminals for program development ?
> 
> A lot of people develop scripts using terminal editors.  Does that
> count?

There are still a lot of Forth systems around that run on the target hardware, and most of these connect to a terminal emulator. I remember also running a Z80 assembler/simulator/debugger on a Linux system that used a VT-100 terminal emulator --- that was in the 1990s though, so maybe obsolete now (actually, the Z80 was obsolete even then).

All in all, I think that UTF-8 for source-code is an unnecessary complication --- we do have the technology to do it --- it is just a distraction though, as most programmers' main problem is getting their code debugged, but making the source-code look spiffy isn't really a big concern anywhere.

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

#46554

George Neuner <gneuner2@comcast.net> writes:
>On Tue, 05 Apr 2016 09:56:20 +0300, upsidedown@downunder.com wrote:
>
>>On Tue, 05 Apr 2016 03:32:54 +0100, Nobody <nobody@nowhere.invalid>
>>wrote:
>>
>>> [Unicode] creates problems for printing the code using non-graphical
>>>printers, 
>>
>>Can you still buy printers with built in character ROMs ?
>
>Yes.  There are dot matrix printers still available from a number of
>vendors.

Matrix printers are graphical.  As for "character ROMs", pretty much
every printer can print plain text and has a "character ROM" for that.
There used to be dumb printers (aka GDI printers or Winprinters) that
just took some bitmap prepared one the PC; I don't know if these still
exist, but in my experience they do not play a noticable role.

Anyway, the existence of a "character ROM" does not make the printer
non-graphical.

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

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

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

csiph-web