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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#46616 — Re: Double and FP syntax

On Saturday, April 9, 2016 at 5:25:59 PM UTC-7, Elizabeth D. Rather wrote:
> On 4/8/16 11:19 PM, Anton Ertl wrote:
> > Bernd Paysan <bernd.paysan@gmx.de> writes:
> >> Am Fri, 08 Apr 2016 10:26:41 +0000 schrieb Anton Ertl:
> >>> What is a major problem is the standard double number syntax.  For a
> >>> newcomer, "1." does something completely unexpected, and pretty
> >>> puzzling.  And when you explain what it does, the image of an obsolete
> >>> language will consolidate.  We should switch to a different doubles
> >>> syntax so that we can (eventually, after a long cooldown time) use "1."
> >>> for FP.
> 
> This issue is only one of a great many unexpected things the newcomer 
> has to learn in order to use Forth. Having a test precede IF, for 
> example, and postfix notation in general, are hurdles, even though they 
> are minor ones easily accommodated, in my experience. "1." is just 
> another, and a pretty minor one.

Postfix is pretty fundamental to Forth --- the use of the decimal-point to indicate double-precision integers rather than floating-points is just a bad design from C.M. that he did in the 1970s because he wasn't predicting a future in which Forth would have floating-point.

You are fixated on 1970s Forth! You want Forth to remain frozen in the 1970s and never advance at all --- this is because you don't know how to program --- you remember that C.M. knew how to program, and so you want to stick with C.M.'s design decisions of the 1970s forever.

> > We discussed the issue at the 2014 Forth-200x meeting, and my notes
> > about that say:
> >
> > |Input: We may want a way to make 100. an FP number in the text
> > |interpreter.  And a way to allow a more liberal FP number.  Solution:
> > |use prefixes: *123 and *$-a for doubles and !1 for floats.  At some
> > |point we deprecate "1." as long, and systems are free to use 1. as FP
> > |number.  Allow "," in >float and in prefixed floats.  For FP numbers,
> > |the last separator is the decimal separator.  Action: SP
> >
> > I don't remember why we wanted another floating-point syntax, but at
> > the time, among a few options, we selected a * prefix as double
> > indicator.
> 
> Appalling. Programmers aren't the only people who type numbers to a 
> Forth program, users do, as well. The whole concept of how the text 
> interpreter processes numbers, from ~1970 on, has been to let users type 
> numbers in as natural a way as possible. Human nature (expressed in the 
> Rule of 7) means that most all large numbers are broken up by some kind 
> of punctuation, so by accepting them as doubles, data entry becomes 
> quite natural. Further validation is the province of the application.

Elizabeth Rather appointed Anton Ertl to the job of chair-person of the Forth-200x committee, but now she says that his thinking about Forth is "appalling."

This looks bad for Anton Ertl --- he is on the verge of getting fired --- that is normally what happens after the boss describes your work as being "appalling."

Ultimately, Forth-200x is just a hobby for Anton Ertl --- unlike myself, he has never written a commercial product in Forth --- he could just go back to programming in GCC and forget about Forth (all of his "Forth programming" now is actually GCC programming anyway, and it is becoming increasingly frustrating for him because the GCC committee aren't listening to him in regard to following the ANSI-C standard).

Lots of people get fired from their jobs, and then afterward they grumble about how the boss is an idiot --- but this is irrelevant because the boss is the boss, idiot or not.

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

#46662 — Re: Double and FP syntax (was: Decimal Point vs. Decimal Comma)

On Sat, 09 Apr 2016 09:19:00 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>Bernd Paysan <bernd.paysan@gmx.de> writes:
>>VFX by default for quite some time accepted only ',' as indicator for 
>>double numbers, and has '.' for floats.  That's non-standard, and broke 
>>e.g. MINOS, so the MINOS harness sets dp-char to '.', and then compiles.  
>>That's also bad, because then, other programs written for VFX don't 
>>load... but the general idea is in the right direction.
>
>The general idea to go away from "." for doubles and use something
>else is in the right direction, yes.  The general idea of DP-CHAR is
>bad, as demonstrated above.

This debate has been going on for over 25 years. It's about being able
to use our tools in applications, e.g. number conversion data during
data entry, and when the need occurs, e.g. compile-time and run-time.
A secondary need is to make numbers easy to read.

In ANS and Forth-2012, allowing for common practice, we need to be
able to set
  double number indicator, usually ',' or '.'
  floating point indicator, usually '.' for English speakers
  ignored characters, typically '_' and/or ':'
The ignored characters are usually used for hex numbers in bit masks
and addresses in embedded systems code, e.g.
  $2000:0000 equ RAM-BASE
Ignorable characters are even more useful for 64 bit systems.

VFX has 4-byte arrays
  DP-CHAR
  FP-CHAR
  IGN-CHAR
They are just the mechanism. They are there because of customer 
request.

Being able to change these is no worse than being able to change
BASE. What is bad is having no easy way to revert to standard
behaviour.

If we go back to Elizabeth's telephone number example to treat
punctuation as double number indicators, then we need to be able
to set a suitable list of indicators/separators.

>The syntax is something we have to decide as a community.  Chickening
>out by providing configuration options (and worse, as global state) to
>individual programmers only leads to problems.  System implementors
>may decide to inflict such problems on their users by providing such
>options in order to support legacy code (but a conversion tool would
>be better), but such kludges have no place in the standard.

We are not supporting legacy code. We are supporting application
need. We are exposing rather than burying our tools.

And this where we disagree. Options can be set, and a word provided
to restore standard behaviour. It's no worse than HEX ... DECIMAL.
These options exist because there is a need for them.

This discussion is in the same place as recognisers, which can
unleash a whole new world of features and pain. A word to restore
standard behaviour is still needed, e.g.
  STANDARD-NUMBERS ( -- )

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#46675 — Re: Double and FP syntax (was: Decimal Point vs. Decimal Comma)

On Friday, April 15, 2016 at 3:17:05 AM UTC-7, Stephen Pelc wrote:
> A word to restore
> standard behaviour is still needed, e.g.
>   STANDARD-NUMBERS ( -- )

QUIT is the word that should restore standard behavior. This has been discussed before:

https://groups.google.com/forum/#!topic/comp.lang.forth/tLZLCc02gmk%5B1-25%5D

On Thursday, March 5, 2015 at 7:09:57 PM UTC-7, hughag...@gmail.com wrote:
> On Wednesday, March 4, 2015 at 12:22:47 AM UTC-7, Michael Barry wrote:
> > On Sunday, March 1, 2015 at 3:37:55 PM UTC-8, hughag...@gmail.com wrote:
> > > 
> > > [ ... snip ... ]
> > > 
> > > One of the more screw-ball aspects of ANS-Forth is that QUIT (called by
> > > ABORT) doesn't put the system back into a rational state. If the system
> > > state (such as BASE, or the word-list stack) is screwed up, it will still
> > > be screwed up after the abort --- it remains screwed up until the user
> > > figures out what is wrong and explicitly fixes the problem.
> > >  
> > > [ ... snip ... ]
> > 
> > C'mon, Hugh.  Even a dense n00b like me knows that after a Forth crash,
> >  "All your BASE are belong to us". ;-)
> > 
> > Mike
> 
> It would be best if ABORT put the system back in a rational state, rather than leave it screwed-up. ABORT already does put the data-stack back in a rational state (empty), so Charles Moore obviously knew that getting back to a rational state after an abort was a good idea. ABORT does not put BASE and the word-list stack and CURRENT back into a rational state however --- most likely, because Charles Moore simply forgot about those --- now, in 2015, we are getting a lot of hokey explanations about how there was supposedly some purpose to this all along (rather than just admit that it was a bug in Charles Moore's 1970s Forth).
> 
> You are saying that the user should be required to type this out after every abort:
> 
> ONLY FORTH DEFINITIONS  DECIMAL
> 
> That is a lot of typing! ABORT could do this internally. Also, as I said, this isn't guaranteed to work because FORTH isn't in the core word-set, but is in an extension word-set instead (why is FORTH not in the core? I don't know!).
> 
> Also, this safety code is not necessary most of the time. Usually (for me anyway), the system is in FORTH for both context and current, and is in decimal, so manually putting it back into this state is redundant. It is easy to get into the habit of not typing this safety code out after every abort --- an abort is pretty common when debugging code (especially code that I wrote!) --- so no problems occur 99% of the time (this is most likely why Charles Moore didn't notice that he had a bug). Occasionally however, the ABORT occurs when BASE is not decimal (as in Gerry's code where he temporarily switched to HEX) or when the context and current aren't FORTH (as in my cross-compiler, where they are always something else), and then the poor programmer is totally baffled because his system is acting bizarre (and, if FORTH-WORDLIST is not in the search order, most users are not going to know how to make the system work again and they will just reboot).
> 
> The ANS-Forth standard was written without a reference compiler, so it was never tested --- this is why it fails to catch a problem like this that may only occur 1% of the time (nobody noticed). How often the problem occurs will vary quite a lot depending upon what kind of application is being written --- for example, programs that work with I/O will use HEX and BINARY a lot, whereas database programs will just stay in DECIMAL all the time.
> 
> You're an auto mechanic --- imagine telling your customer that you have installed brake calipers that will work 99% of the times that the driver presses the brake pedal (the other 1% of the time, the brake pedal hits the floor and the horn automatically honks) --- even if you offered a 50% discount on the price, you would still have an unhappy customer.

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

#46743 — Re: Double and FP syntax (was: Decimal Point vs. Decimal Comma)

stephen@mpeforth.com (Stephen Pelc) writes:
>On Sat, 09 Apr 2016 09:19:00 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>>The general idea to go away from "." for doubles and use something
>>else is in the right direction, yes.  The general idea of DP-CHAR is
>>bad, as demonstrated above.
>
>This debate has been going on for over 25 years. It's about being able
>to use our tools in applications, e.g. number conversion data during
>data entry, and when the need occurs, e.g. compile-time and run-time.
>A secondary need is to make numbers easy to read.
>
>In ANS and Forth-2012, allowing for common practice, we need to be
>able to set
>  double number indicator, usually ',' or '.'

In Forth-94 and -2012, just a trailing ".".

However, getting back to the original question of an alternative way
to indicate doubles, a leading ",", i.e.,

,1234

might be another way.  It is already supported by several systems,
does not have the conflict with "2," or any other conflict I know of.
A disadvantige is the small visual distance from ".", but if used only
as a prefix, the difference is hopefully big enough.

>  floating point indicator, usually '.' for English speakers

And for programmers in general; but not in standard Forth.  The
conflict of that with the standard double indicator is the reason for
this thread.

>  ignored characters, typically '_' and/or ':'

I don't see any conflicts involving '_', but ':' is often used in time
specifications.

>The ignored characters are usually used for hex numbers in bit masks
>and addresses in embedded systems code, e.g.
>  $2000:0000 equ RAM-BASE
>Ignorable characters are even more useful for 64 bit systems.
>
>VFX has 4-byte arrays
>  DP-CHAR
>  FP-CHAR
>  IGN-CHAR
>They are just the mechanism. They are there because of customer 
>request.

The customers requested exactly this mechanism?  If so, it shows that
customers are not always so great at devising solutions for their
problems.

>Being able to change these is no worse than being able to change
>BASE.

Right, making these variables part of the interface is just as bad as
making BASE part of the interface.  Unfortunately, BASE is standard,
so we cannot easily avoid this particular mistake, we can offer ways
to avoid it by providing number prefixes (in Forth-2012) and words
like BASE-EXECUTE (not standardized).  Anyway, the experience with
BASE is a good reason to avoid DP-CHAR etc.

>If we go back to Elizabeth's telephone number example to treat
>punctuation as double number indicators, then we need to be able
>to set a suitable list of indicators/separators.

Her telephone number example does not work for countries that can have
significant leading zeroes in telephone numbers (all countries known
to me).  We have a better way to deal with that: recognizers (in the
RfD stage).

>>The syntax is something we have to decide as a community.  Chickening
>>out by providing configuration options (and worse, as global state) to
>>individual programmers only leads to problems.  System implementors
>>may decide to inflict such problems on their users by providing such
>>options in order to support legacy code (but a conversion tool would
>>be better), but such kludges have no place in the standard.
>
>We are not supporting legacy code. We are supporting application
>need.

There is non-legacy application need to switch around between
different interpretations of "1234." in the text interpreter?  What
application need is that?

In particular, and related to the topic, is there a non-legacy
application need to text-interpret "1234." as a double number once we
provide a standard alternative syntax?

>We are exposing rather than burying our tools.

Rule #14 in Forth discussions: If you provide a bad interface rather
than working on a good interface, justify it with "not burying your
tools".

>And this where we disagree. Options can be set, and a word provided
>to restore standard behaviour. It's no worse than HEX ... DECIMAL.

Which are pretty bad.

>These options exist because there is a need for them.

For me, not any longer in program text.

>This discussion is in the same place as recognisers, which can
>unleash a whole new world of features and pain.

True, one can write a recognizer that uses DP-CHAR etc.  One can
certainly write completely non-sensical recognizers, just as one can
write non-sensical Forth programs.

But the point is not to prevent people from shooting themselves in the
foot if they want to, but to give them ways to avoid doing that
accidentially.  And I think that recognizers, even in their current
raw state, are much better at this than BASE and DP-CHAR.  I had
several occurences of accidentially shooting myself in the foot with
BASE (typically in some program written by someone else), and one
where a trailing "," as double indicator resulted in foot-shooting.

By contrast, I have not yet had one occurence where the new number
prefix recognizers resulted in foot-shooting.  Why not?  Because they
were chosen to avoid conflicts.

Now for the user-defined recognizers, I expect that responsible
programmers will define recognizers that are unlikely to lead to
conflicts.  If there are conflicts, there's a recognizer stack that
specifies how to resolve the conflict.

Of course, this being Forth, there will still be cowboy programmers
that define recognizers that match pretty much everything, or that use
configuration variables like DP-CHAR to configure what is matched, but
at least there is a way to do better for programmers who want to do
better.

>A word to restore
>standard behaviour is still needed, e.g.
>  STANDARD-NUMBERS ( -- )

In the context of recognizers, you just put the word, number, and FP
recognizers on the recognizer stack.  However, this kind of global
reset is not useful in the context of reusable code.

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

#46468

"Elizabeth D. Rather" <erather@forth.com> writes:

>On 4/3/16 5:33 AM, Coos Haak wrote:
>> Op Sun, 03 Apr 2016 06:23:56 GMT schreef Anton Ertl:
>>
>...
>>>> 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
>>
>> To my surprise, the current versions of Gforth have it.
>> Win32Forth does not have 2,
>> SF (2011) does not have it either.

>Not sure what you mean by that. In SwiftForth (and all other FORTH, Inc.
>systems since the 70's) 2, is a perfectly good double integer whose
>value is 2.

What he means that in gforth
   12. PAD 2!    PAD 2@ D.
works and also
   HERE 12. 2, HERE 2@

The latter examples fails on Swiftforth because the word 2, is
not present, it is interpreted as a number.

With all those recognizers around the chance increases that
a word (mistyped or not) is mistaken for a number.
(Remember CD and DEADBEEF? )

>Cheers,
>Elizabeth

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]

#46464

Coos Haak <chforth@hccnet.nl> writes:

>Op Sun, 03 Apr 2016 06:23:56 GMT schreef Anton Ertl:

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

>To my surprise, the current versions of Gforth have it.
>Win32Forth does not have 2,
>SF (2011) does not have it either.

ciforth interprets it as a single precision number, but
WANT 2, works. This is a pitfall. Maybe I should put  it
in the kernel, though it doesn't belong there.

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

#46451

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]

#46456

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]

#46457

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]

#46432

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]

#46435

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]

#46438

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]

#46450

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]

#46443

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]

#46444

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]

#46446

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]

#46447

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]

#46465

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]

#46449

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]

#46467

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]

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

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

csiph-web