Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Optional text interpreter input number conversions

323 views
Skip to first unread message

Harold

unread,
Jan 11, 2018, 7:43:05 PM1/11/18
to
One of the big advantages of Forth historically was the ability to bootstrap a standards-compliant high level language implementation on bare metal microprocessor hardware with no operating system and very minimal software tool support. The definition of standardized optional word sets allows the implementer to provide a minimal set of words, and still be able to claim standards compliance.

But the same isn't true of the text interpreter. The Forth 2012 standard imposes new requirements on the text interpreter beyond what was formerly sufficient, specifically in the area of input number conversion.

3.4.1.3 Text interpreter input number conversion
When converting input numbers, the text interpreter shall recognize integer numbers in the form <anynum>.
<anynum> := { <BASEnum> | <decnum> | <hexnum> | <binnum> | <cnum> }

Prior to 2012, the text interpreter was only required to provide the <BASEnum> functionality. Now, an implementation that was compliant with Forth 1994 can no longer claim compliance with Forth 2012, since the other four input conversion syntaxes aren't optional. That is clearly implied by "... shall recognize ..." IMO, this imposes an unreasonable burden on minimal implementations where code size is at a premium.

With the advent of recognizer technology, it would restore the status quo ante if a standards-compliant implementation was allowed to provide a subset of the input number conversion options for the text interpreter. This subset would of course be documented as an implementation-defined option.

-- Harold

hughag...@gmail.com

unread,
Jan 11, 2018, 8:13:41 PM1/11/18
to
Your phrase, "With the advent of recognizer technology," is quite humorous!
I have no use for recognizers --- they are a gross violation of Forth tradition in which there is no syntax.
Recognizers are just Alex McDonald's goofy idea ---
a complete lack of common-sense on the part of the Forth-200x committee would be required for them to be accepted into Forth-200x.

I'm designing a standard that will certainly not have recognizers.
Some minor elements of syntax will be introduced, including a syntax for numbers, but this will be standardized and documented.
The problem with recognizers is that there could be a wide variety of recognizers in use, all of which clash with each other --- ambiguity!

In my novice-package (unreleased) I have STR>NUM that converts strings into numbers:

\ STR>INT converts strings to integers, either singles and doubles.
\ An integer is a string of digits. There may be commas throughout.
\ An integer may have a $ # or % at the front, signifying that it is hexadecimal, decimal or binary. If none of these are present, then BASE is used.
\ An integer may have a + or - at the front (after the base signifier if there is one), signifying non-negative or negative, but otherwise it is non-negative.
\ A comma at the beginning (after the sign signifier if there is one) signifies that the integer is a double, but otherwise it is a single.

\ These are valid integers:
\ $-,123,456 double: -123456 hexadecimal
\ -,123,456 double: -123456
\ ,123,456 double: 123456
\ 123,456 single: 123456

\ STR>FLT converts strings to floats.
\ A float is a string of digits. There may be commas throughout. All floats are in decimal.
\ A comma in the front is legal but should not be used as STR>NUM will interpret this as an invalid double.
\ There must be either a decimal-point or an exponent-signifier (either 'E' or 'e') or both.
\ If there is a decimal-point, there must be digits either before or after or both.
\ The first digits are the integer part. The digits after the decimal-point, if there is a decimal-point, are the fraction part.
\ The digits after the exponent-signifier, if there is an exponent-signifier, are the exponent part (scientific notation).
\ If there is an exponent-signifier, and there are no digits after it, then the exponent is assumed to be 0.
\ An exponent may have a + or - at the front, signifying non-negative or negative, but otherwise it is non-negative.

\ STR>NUM converts strings to either integers or floats.

\ These are valid floats:
\ -123,456.78 float: -123456.78
\ -123,456.78E4 float: -1234567800
\ -123,456.78E-4 float: -12.345678
\ 123E4 float: 1230000
\ 123E float: 123

0 constant #invalid
1 constant #single
2 constant #double
3 constant #float
\ these are the kinds of numbers

: str>num ( adr cnt -- #invalid | n #single | d #double | #float ) \ float: -- f (if we return a #float on the data-stack)
...

dxf...@gmail.com

unread,
Jan 12, 2018, 3:27:19 AM1/12/18
to
Even under Forth-94 chances were slim a minimal
implementation could load a standard program
or library targetted at a desktop. Claiming
compliance was easy with ANS, even if useless
in practice. ANS didn't want to alienate
anyone following the 79/83 vendor splits. 200x
OTOH doesn't believe there is anyone of
consequence left to alienate. Which is probably
true.

Anton Ertl

unread,
Jan 12, 2018, 3:57:40 AM1/12/18
to
Harold <hzra...@gmail.com> writes:
>One of the big advantages of Forth historically was the ability to bootstra=
>p a standards-compliant high level language implementation on bare metal mi=
>croprocessor hardware with no operating system and very minimal software to=
>ol support. The definition of standardized optional word sets allows the im=
>plementer to provide a minimal set of words, and still be able to claim sta=
>ndards compliance.=20
>
>But the same isn't true of the text interpreter. The Forth 2012 standard im=
>poses new requirements on the text interpreter beyond what was formerly suf=
>ficient, specifically in the area of input number conversion.
>
>3.4.1.3 Text interpreter input number conversion
>When converting input numbers, the text interpreter shall recognize integer=
> numbers in the form <anynum>.
><anynum> :=3D { <BASEnum> | <decnum> | <hexnum> | <binnum> | <cnum> }
>
>Prior to 2012, the text interpreter was only required to provide the <BASEn=
>um> functionality. Now, an implementation that was compliant with Forth 199=
>4 can no longer claim compliance with Forth 2012, since the other four inpu=
>t conversion syntaxes aren't optional. That is clearly implied by "... shal=
>l recognize ..."

Yes, documenting the other number syntaxes as optional would have lead
to unwieldy language in the document.

> IMO, this imposes an unreasonable burden on minimal implem=
>entations where code size is at a premium.

These minimal systems play a big role in discussions about the
standard, but despite Forth-94 bending over backwards for these
systems, they failed to materialize. Systems on small hardware takes
the "portable programmer" attitude towards Forth-94: When convenient,
they implement standard words as specified in the standard, when not,
not. They can do the same for input number conversion.

>With the advent of recognizer technology, it would restore the status quo a=
>nte if a standards-compliant implementation was allowed to provide a subset=
> of the input number conversion options for the text interpreter. This subs=
>et would of course be documented as an implementation-defined option.

A minimal system could provide a <BASEnum> recognizer (or even just a
single-cell <BASEnum> recognizer) by default, and an <anynum>
recognizer as a loadable option as a way to satisfy standard
requirements. We will see if any such systems materialize.

Concerning making the additional syntaxes optional, that would lead to
unwieldy language as before. If we specified a <BASEnum> or
<BASEsingle> recognizer, and an <anynum> recognizer, it would be
somewhat easier to make the <anynum> recognizer optional. But again,
I doubt that a focus on minimalism in the standard would really
benefit anybody. Standardizing the standard input number conversion
recognizers would be helpful IMO, though.

- 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 2017: http://euro.theforth.net/

a...@littlepinkcloud.invalid

unread,
Jan 12, 2018, 3:59:51 AM1/12/18
to
Harold <hzra...@gmail.com> wrote:

> One of the big advantages of Forth historically was the ability to
> bootstrap a standards-compliant high level language implementation
> on bare metal microprocessor hardware with no operating system and
> very minimal software tool support. The definition of standardized
> optional word sets allows the implementer to provide a minimal set
> of words, and still be able to claim standards compliance.
>
> But the same isn't true of the text interpreter. The Forth 2012
> standard imposes new requirements on the text interpreter beyond
> what was formerly sufficient, specifically in the area of input
> number conversion.
>
> 3.4.1.3 Text interpreter input number conversion
> When converting input numbers, the text interpreter shall recognize
> integer numbers in the form <anynum>.
> <anynum> := { <BASEnum> | <decnum> | <hexnum> | <binnum> | <cnum> }
>
> Prior to 2012, the text interpreter was only required to provide the
> <BASEnum> functionality. Now, an implementation that was compliant
> with Forth 1994 can no longer claim compliance with Forth 2012,
> since the other four input conversion syntaxes aren't optional.

Yeah, I know, it sucks. :-(

Having said that, an implementation can fairly easily vector number
conversion so that number prefixes are only supported in
standard-compiliant mode. and of course you can recompile from source
in just a few seconds, so I don't think this is a practical problem.

> That is clearly implied by "... shall recognize ..." IMO, this
> imposes an unreasonable burden on minimal implementations where code
> size is at a premium.
>
> With the advent of recognizer technology, it would restore the
> status quo ante if a standards-compliant implementation was allowed
> to provide a subset of the input number conversion options for the
> text interpreter.

Well, yes, but that is to use a sledgehammer to crack a nut.

Andrew.

NN

unread,
Jan 13, 2018, 12:21:36 PM1/13/18
to
Has forth 2012 been standardised ?

NN

Anton Ertl

unread,
Jan 13, 2018, 12:39:07 PM1/13/18
to
NN <novembe...@gmail.com> writes:
>Has forth 2012 been standardised ?

It is the current standard as far as the committee is concerned.

If you mean if it has ANSI or ISO blessing: no, nobody was interested
enough in that to do the necessary work and pay the necessary fees.

Cecil Bayona

unread,
Jan 13, 2018, 1:45:19 PM1/13/18
to
On 1/13/2018 11:36 AM, Anton Ertl wrote:
> NN <novembe...@gmail.com> writes:
>> Has forth 2012 been standardised ?
>
> It is the current standard as far as the committee is concerned.
>
> If you mean if it has ANSI or ISO blessing: no, nobody was interested
> enough in that to do the necessary work and pay the necessary fees.
>
> - anton
>
So has Forth 2012 been frozen as a Standard with a new one being debated
or is it a still changing Standard, not quite finished.

--
Cecil - k5nwa

Anton Ertl

unread,
Jan 13, 2018, 1:49:24 PM1/13/18
to
Cecil Bayona <cba...@cbayona.com> writes:
>So has Forth 2012 been frozen as a Standard with a new one being debated
>or is it a still changing Standard, not quite finished.

The former: Forth-2012 is frozen, and any debated changes are for the
next standard.

Cecil Bayona

unread,
Jan 13, 2018, 1:57:34 PM1/13/18
to
On 1/13/2018 12:47 PM, Anton Ertl wrote:
> Cecil Bayona <cba...@cbayona.com> writes:
>> So has Forth 2012 been frozen as a Standard with a new one being debated
>> or is it a still changing Standard, not quite finished.
>
> The former: Forth-2012 is frozen, and any debated changes are for the
> next standard.
>
> - anton
>

Thanks I have a printout of the 2012 Standard and wanted to make sure it
stayed up to date, frozen is good.

--
Cecil - k5nwa

Alex

unread,
Jan 13, 2018, 3:28:04 PM1/13/18
to
On 13-Jan-18 17:36, Anton Ertl wrote:
> NN <novembe...@gmail.com> writes:
>> Has forth 2012 been standardised ?
>
> It is the current standard as far as the committee is concerned.
>
> If you mean if it has ANSI or ISO blessing: no, nobody was interested
> enough in that to do the necessary work and pay the necessary fees.

Both the cost & work required are significant. Without the support of a
ISO/IEC PAS (Publicly Available Specifications) organization (here's a
list
https://isotc.iso.org/livelink/livelink?func=ll&objId=8913248&objAction=browse&sort=name)
it will be near impossible. The last standard I had dealings with cost
in excess of $35K for approval.


--
Alex

NN

unread,
Jan 14, 2018, 7:07:15 AM1/14/18
to
On Saturday, 13 January 2018 20:28:04 UTC, Alex wrote:
> On 13-Jan-18 17:36, Anton Ertl wrote:
Its seems to me that unless there is an argument to be made that ISO/ANSI/IEC... use forth/promote forth - having their approval on it is something to endeavour for; would it not be both simpler and cost effective to say "we are the forth committee" and we say this is the current standard.

I am aware of forth-2012 but I have not followed it simply because I thought it was work in progress and when everyone was happy it would be presented as the current standard with all the fanfare. I cant be the only one here who thinks this !



Anton Ertl

unread,
Jan 14, 2018, 9:36:59 AM1/14/18
to
NN <novembe...@gmail.com> writes:
>would it not be both simpler and cost effective to say "we =
>are the forth committee" and we say this is the current standard.

That's what we do.

>I am aware of forth-2012 but I have not followed it simply because I though=
>t it was work in progress and when everyone was happy it would be presented=
> as the current standard with all the fanfare.

Maybe it could have been presented with more fanfare, but I am sure
that many would have missed it anyway. There is a bit of a lack of
venues for presenting the standard with fanfare. There were two
articles in the German Vierte Dimension about Forth-2012 (in issues
4d2014-03/04 and 4d2016-03). On www.forth200x.org Forth-2012 is
featured prominently, but maybe we could make it clearer that this is
the current standard. What other fanfare would you suggest?

NN

unread,
Jan 14, 2018, 2:34:56 PM1/14/18
to
On Sunday, 14 January 2018 14:36:59 UTC, Anton Ertl wrote:
1) from : http://www.forth200x.org/documents/forth-2012.pdf

Status of this Document
This is a draft proposed Standard to replace ANSI X3.215-1994. As such, this is not a completed standard.
The Standardisation Committee may modify this document during the course of its work.

Should be changed.

2) Perhaps the FAQs http://www.faqs.org/faqs/computer-lang/forth-faq/part7/
could be changed to reflect this.

3) When someone new comes to check out the language the first place they are likely to start is the free software.

Win32forth comes bundled with the dpans document and perhaps this can be updated to include the new one. I cant speak for other forths, but perhaps they can too to emphasize this.

Just a thought ( and not a complaint )!

Phillip Eaton

unread,
Jan 14, 2018, 3:16:55 PM1/14/18
to
I think that's a bit of a drawback...if you go to the effort of getting ANSI/ISO approval for a standard, and later want to supercede it, you really need to get the same certification, else the update lacks credibility. IMHO.

minf...@arcor.de

unread,
Jan 14, 2018, 4:01:22 PM1/14/18
to
The FAQ is outdated.

AFAIK you are not allowed to distribute original standard documents.
One has to buy them from the standard organizations.

Forth-2012 is just a draft standard proposal like Forth-dpANS94. It still has
queer things like multiple overloaded TO.

Alex

unread,
Jan 14, 2018, 4:23:25 PM1/14/18
to
On 14-Jan-18 21:01, minf...@arcor.de wrote:
> AFAIK you are not allowed to distribute original standard documents.
> One has to buy them from the standard organizations.

Copyright (c) 1994 by Technical Committee X3J14. All rights reserved.

This is a working document of Technical Committee X3J14 which represents
the last draft of ANS Forth submitted to ANSI for publication.
Permission is hereby granted to copy this document provided that it is
copied in its entirety without alteration or as altered by

(1) adding text that is clearly marked as an insertion;
(2) shading or highlighting existing text; and/or
(3) deleting examples.

Specifically, permission is granted to use this working document as the
foundation for textbooks, system manuals, and online documentation so
long as the requirements in the preceding paragraph are met and the
resulting product addresses a technical need that is not practically met
by the official ANS.


--
Alex

Rod Pemberton

unread,
Jan 14, 2018, 10:06:09 PM1/14/18
to
On Sun, 14 Jan 2018 21:23:23 +0000
Alex <al...@rivadpm.com> wrote:

> On 14-Jan-18 21:01, minf...@arcor.de wrote:

> > AFAIK you are not allowed to distribute original standard
> > documents. One has to buy them from the standard organizations.
>
> Copyright (c) 1994 by Technical Committee X3J14. All rights reserved.

Just an FYI, due to Supreme Court rulings in the U.S., anything in a
copyrighted specification which is required to comply with the
implementation of that specification will not have it's copyrights
enforced on that aspect under U.S. copyright laws. See, e.g., Baystate
v. Bentley, Mitel Inc v. Iqtel, Sega Enterprises Ltd. v. Accolade, Lotus
v. Borland, Apple Computer v. Microsoft, Synercom v. University
Computing, Feist Publications v. Rural Tel. Serv. Co, Computer
Associates v. Altai, Bateman v. Mnemonics, Oracle v. Google, etc.


Rod Pemberton
--
"White Privilege - The privilege of being called 'racist' by people who
see nothing else about you except your race." - Internet meme

minf...@arcor.de

unread,
Jan 15, 2018, 1:45:15 AM1/15/18
to
Yes, for the draft proposal.

What does the final ISO Standard say?

Elizabeth D. Rather

unread,
Jan 15, 2018, 3:17:00 AM1/15/18
to
It's tightly restricted and very expensive. But the text is identical to
the dpANS described above except for the notice that it is an approved
standard. Therefore, many programmers have found it useful.

Cheers,
Elizabeth

--
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA 90045
USA

Anton Ertl

unread,
Jan 15, 2018, 3:45:33 AM1/15/18
to
I don't think many programmers have found the final ISO standard
useful, simply because very few, if any, have it. If its content was
different from that of dpANS6, would anybody notice? And which would
be the real standard: The one written by a committee of Forth experts
after years of deliberation, implemented by many Forth systems, and
used by many Forth programmers; or one with changes from an unknown
source, implemented by no Forth system, and used by no Forth
programmer, but with an ISO stamp on top?

Anton Ertl

unread,
Jan 15, 2018, 3:53:44 AM1/15/18
to
NN <novembe...@gmail.com> writes:
>On Sunday, 14 January 2018 14:36:59 UTC, Anton Ertl wrote:
>> NN <> writes:
>> >would it not be both simpler and cost effective to say "we =
>> >are the forth committee" and we say this is the current standard.
>>
>> That's what we do.
...
>1) from : http://www.forth200x.org/documents/forth-2012.pdf
>
>Status of this Document
>This is a draft proposed Standard to replace ANSI X3.215-1994. As such, this is not a completed standard.
>The Standardisation Committee may modify this document during the course of its work.

That's the case as far as ANSI is concerned. It's a consequence of
the original TC's transfer of the copyright to ANSI.

>Should be changed.

In order to change that, you (yes, you) would have to sponsor official
ANSI blessing, or rewrite the document in a way that is identical in
meaning, but does not contain any of the text that Forth-94 contains.

>2) Perhaps the FAQs http://www.faqs.org/faqs/computer-lang/forth-faq/part7/
>could be changed to reflect this.

Thanks, I will.

>3) When someone new comes to check out the language the first place they are likely to start is the free software.
>
>Win32forth comes bundled with the dpans document and perhaps this can be updated to include the new one. I cant speak for other forths, but perhaps they can too to emphasize this.

That would be helpful.

Note that SwiftForth comes with a copy of the forth-2012 document.

Anton Ertl

unread,
Jan 15, 2018, 3:56:10 AM1/15/18
to
Phillip Eaton <pjea...@gmail.com> writes:
>I think that's a bit of a drawback...if you go to the effort of getting ANSI/ISO approval for a standard, and later want to supercede it, you really need to get the same certification, else the update lacks credibility. IMHO.

I think that, once enough systems that claim compliance with
Forth-2012 are out, that problem solves itself.

Elizabeth D. Rather

unread,
Jan 15, 2018, 5:13:58 PM1/15/18
to
The fact of its having that stamp made it more credible to managers and
executives who are far less interested in the content, while it's the
content that's important to programmers.

dxf...@gmail.com

unread,
Jan 15, 2018, 8:49:00 PM1/15/18
to
Do you mean the standard which has generated
copious public argument on virtually every submission while attracting less than a handful
of public votes for or against - or some other?

Also I don't know what you mean by "use". I don't
consider implementing a wordset as use - a
precursor possibly. Organizing a party isn't the
same as having one.

a...@littlepinkcloud.invalid

unread,
Jan 16, 2018, 5:25:08 AM1/16/18
to
dxf...@gmail.com wrote:
> On Monday, January 15, 2018 at 7:45:33 PM UTC+11, Anton Ertl wrote:
>> "Elizabeth D. Rather" <era...@forth.com> writes:
>> >On 1/14/18 8:45 PM, minf...@arcor.de wrote:
>> >It's tightly restricted and very expensive. But the text is identical to
>> >the dpANS described above except for the notice that it is an approved
>> >standard. Therefore, many programmers have found it useful.
>>
>> I don't think many programmers have found the final ISO standard
>> useful, simply because very few, if any, have it. If its content
>> was different from that of dpANS6, would anybody notice? And which
>> would be the real standard: The one written by a committee of Forth
>> experts after years of deliberation, implemented by many Forth
>> systems, and used by many Forth programmers;
>
> Do you mean the standard which has generated copious public argument
> on virtually every submission

Actually, no. Most changes are uncontroversial. Ypu notice the
controversial ones.

> while attracting less than a handful of public votes for or against
> - or some other?

The public doesn't get to vote. The TC does.

> Also I don't know what you mean by "use". I don't consider
> implementing a wordset as use - a precursor possibly. Organizing a
> party isn't the same as having one.

This complaint makes no sense. Elizabeth was talking about use by
programmers. What other use of a programming language can there be?

Andrew.

Anton Ertl

unread,
Jan 16, 2018, 10:21:02 AM1/16/18
to
dxf...@gmail.com writes:
>On Monday, January 15, 2018 at 7:45:33 PM UTC+11, Anton Ertl wrote:
>> "Elizabeth D. Rather" <era...@forth.com> writes:
>> >On 1/14/18 8:45 PM, minf...@arcor.de wrote:
>> >> What does the final ISO Standard say?
>> >
>> >It's tightly restricted and very expensive. But the text is identical to
>> >the dpANS described above except for the notice that it is an approved
>> >standard. Therefore, many programmers have found it useful.
>>
>> I don't think many programmers have found the final ISO standard
>> useful, simply because very few, if any, have it. If its content was
>> different from that of dpANS6, would anybody notice? And which would
>> be the real standard: The one written by a committee of Forth experts
>> after years of deliberation, implemented by many Forth systems, and
>> used by many Forth programmers;
>
>Do you mean the standard which has generated
>copious public argument on virtually every submission while attracting less than a handful
>of public votes for or against - or some other?

I mean Forth-94 (the only one which has been turned into an ISO
standard). It has generated public argument during its public comment
periods and more since then, but I think you are thinking more of the
Forth-200x process, where the proposals are public and have public
comments, with a poll after the proposal is frozen.

>Also I don't know what you mean by "use". I don't
>consider implementing a wordset as use - a
>precursor possibly.

It's a use by a system implementor. However, for Forth programmers, I
consider it a use if they look the specification of a word up in the
standard. Many programmers (not only in Forth) go by secondary
literature, such as the system documentation; I guess I would not
count that as a use, although, if the documentation contains the
standard text of the word's specification verbatim, it should probably
count; or it should probably count as a secondary use, or somesuch.

<http://forth-standard.org/> should be quite helpful for increased
usage by programmers.

Anton Ertl

unread,
Jan 16, 2018, 10:53:50 AM1/16/18
to
a...@littlepinkcloud.invalid writes:
>dxf...@gmail.com wrote:
>> Do you mean the standard which has generated copious public argument
>> on virtually every submission
>
>Actually, no. Most changes are uncontroversial. Ypu notice the
>controversial ones.

Not in my experience. There are some where I don't remember copious
public argument, if they are specialized (e.g.,
<http://www.forth200x.org/fasinh-lt0.html>); their specialty makes
them a nuclear reactor in terms of Parkinson's law of triviality.

However, most proposals are treated as bike sheds, and are copiously
discussed by some; and that's independent of whether the proposal is
common practice or not. Even proposals with universal practice, such
as <http://www.forth200x.org/twos-complement.html>, get copious public
discussion.

>> while attracting less than a handful of public votes for or against
>> - or some other?
>
>The public doesn't get to vote. The TC does.

There is a poll step when a Forth200x proposal is frozen, in which
system implementors state whether they have implemented or are
planning to implement the proposal, and where programmers state
whether they use or are planning to use the proposed features. This
step is intended to give an idea of whether the idea is common
practice.

Some committee members (you obviously among them) pretty much ignore
this data. This goes as far as having no public record of the poll
for <http://www.forth200x.org/text-substitution.txt>. Did we even
have such a poll?

Anyway, the idea of Forth200x is (was?) that we have public input in
the form of discussions and polls in order to support the committee's
decision (and the cost of this is a certain amount of bike-shedding).
That some committee member act more as if it was just their private
specification is a shame.

dxf...@gmail.com

unread,
Jan 17, 2018, 7:00:34 PM1/17/18
to
So the goal of the standard is to get your
word/proposal in because systems will then be
forced to implement it. While the standard may
be used to write portable programs, all the
evidence since Forth-94 is nobody was seriously
interested in that aspect anyway.

An accurate summary?

hughag...@gmail.com

unread,
Jan 19, 2018, 9:57:34 PM1/19/18
to
On Tuesday, January 16, 2018 at 8:53:50 AM UTC-7, Anton Ertl wrote:
> Anyway, the idea of Forth200x is (was?) that we have public input in
> the form of discussions and polls in order to support the committee's
> decision (and the cost of this is a certain amount of bike-shedding).
> That some committee member act more as if it was just their private
> specification is a shame.

All of this "bike-shedding" is why you lost your job as Forth-200x chair-person.
Your job was to fake up the image of Forth-200x being a grassroots project based on common Forth programmers opinions.
This required you to "bike-shed" --- allow tedious debates about idiotic ideas (recognizers) drag on for years.
All of this was fake anyway, because in the end Forth Inc. and MPE decide what will be the standard.
The bike-shedding was done to give the image that the common Forth programmers opinions mattered, but let their ideas just fizzle out over time.
Also your definition of "common Forth programmer" was too liberal --- you allowed Alex McDonald promote his ideas, despite the fact that he is an idiot.
The years turned into decades and the ideas debated became increasingly idiotic (recognizers), so you lost your job.

Now Emperor Pelc is in charge --- faking up an image of a grass-roots project has been abandoned --- he will just declare VFX to be the new standard.
That was what was going to happen anyway --- the grass-roots image was fake --- but now it will happen sooner. Finally some progress will be made!
Of course, this "progress" is actually the ruination of the Forth programming language --- MPE's profit was nobody's goal except Stephen Pelc.

Also, I think you got your chair-person position taken away from you as punishment for inventing disambiguifiers.
Elizabeth Rather doesn't want ANS-Forth's bugs to be fixed, because doing so necessarily involves admitting that ANS-Forth has bugs.
Elizabeth Rather demands loyalty --- ANS-Forth is a cult --- thinking will get you in trouble...

hughag...@gmail.com

unread,
Jan 19, 2018, 10:30:41 PM1/19/18
to
On Wednesday, January 17, 2018 at 5:00:34 PM UTC-7, dxf...@gmail.com wrote:
> So the goal of the standard is to get your
> word/proposal in because systems will then be
> forced to implement it. While the standard may
> be used to write portable programs, all the
> evidence since Forth-94 is nobody was seriously
> interested in that aspect anyway.
>
> An accurate summary?

What makes you think that getting your word/proposal in Forth-200x will force Stephen Pelc to include it in VFX? Will you pay him to do this?
MPE's profit is the only thing that Stephen Pelc cares about. Your opinion is not important to him --- mine neither, but he made that clear in 2009.
Emperor Pelc will declare VFX to be the standard whether it conforms to the Forth-200x standard document or not.
Forth-200x will conform to VFX, not the other way around.

Here is some Shakespeare for you:
GLENDOWER. I can call spirits from the vasty deep.
HOTSPUR. Why, so can I, or so can any man; But will they come when you do call for them?

This thread is about converting text to numbers. I'm the only one who has written code to do that. I posted the documentation above.
The code to do this is quite complicated --- that is why nobody writes code to do this --- note that VFX's outer-interpreter has a bug in this code.
This is very common --- threads full of tedious opinions of self-proclaimed Forth experts --- I'm the only one who writes working Forth code.
Actually I think Ilya has string to number code in his Quark Forth outer-interpreter, but I haven't examined it.

ANS-Forth used the dot to indicate double-precision integers --- this was a holdover from the 1970s when floating-point wasn't in Forth ---
this syntax was intended to fake up the image of having floating-point, without actually having floating-point --- dumb even by the low standards of the 1970s.
Most likely when Charles Moore was working on Forth in the 1970s (he got kicked out of Forth Inc. in 1982) he did not foresee a day when Forth would have
floating-point, so he introduced this fake syntax that looks like floating-point, but it is fixed-point so the user has to adjust after * and / is done.
I doubt that Charles Moore expected his goofy fake syntax to be put in ANS-Forth in 1994, or to still be a problem in 2018 --- he must be laughing! (or crying)

Gerry Jackson

unread,
Jan 22, 2018, 5:27:01 AM1/22/18
to
On 20/01/2018 03:30, hughag...@gmail.com wrote:
> This thread is about converting text to numbers. I'm the only one
> who has written code to do that.

Really! I wonder how every author of a Forth system managed to get an
outer interpreter to work without writing code to convert text to numbers.

> I posted the documentation above.
> The code to do this is quite complicated --- that is why nobody
> writes code to do this --- note that VFX's outer-interpreter has a
> bug in this code.

What code? You wrote that nobody has ever written such code except for you.

> This is very common --- threads full of tedious opinions of
> self-proclaimed Forth experts --- I'm the only one who writes
> working Forth code.

Surely not.

--
Gerry

Rod Pemberton

unread,
Jan 22, 2018, 7:34:24 PM1/22/18
to
On Mon, 22 Jan 2018 10:27:00 +0000
Gerry Jackson <do-no...@swldwa.uk> wrote:

> On 20/01/2018 03:30, hughag...@gmail.com wrote:

> > This thread is about converting text to numbers. I'm the only one
> > who has written code to do that.
>
> Really! I wonder how every author of a Forth system managed to get an
> outer interpreter to work without writing code to convert text to
> numbers.
>

Uh, well, ...

My Forth's back-end is in C, not assembly, as are many other Forth's.
C has functions to do numeric conversion. If I had to do
number-to-text in assembly, it'd have been a total PIA, IMO.

Alex

unread,
Jan 22, 2018, 8:57:13 PM1/22/18
to
On 22-Jan-18 16:36, Rod Pemberton wrote:
> On Mon, 22 Jan 2018 10:27:00 +0000
> Gerry Jackson <do-no...@swldwa.uk> wrote:
>
>> On 20/01/2018 03:30, hughag...@gmail.com wrote:
>
>> > This thread is about converting text to numbers. I'm the only one
>> > who has written code to do that.
>>
>> Really! I wonder how every author of a Forth system managed to get an
>> outer interpreter to work without writing code to convert text to
>> numbers.
>>
>
> Uh, well, ...
>
> My Forth's back-end is in C, not assembly, as are many other Forth's.
> C has functions to do numeric conversion. If I had to do
> number-to-text in assembly, it'd have been a total PIA, IMO.

Do you mean text to number? It's not that much.

>NUMBER ( ud1 c-addr1 u1 -- ud2 c-addr2 u2 )

ud2 is the unsigned result of converting the characters within the
string specified by c-addr1 u1 into digits, using the number in BASE,
and adding each into ud1 after multiplying ud1 by the number in BASE.
Conversion continues left-to-right until a character that is not
convertible, including any "+" or "-", is encountered or the string is
entirely converted. c-addr2 is the location of the first unconverted
character or the first character past the end of the string if the
string was entirely converted. u2 is the number of unconverted
characters in the string. An ambiguous condition exists if ud2 overflows
during the conversion.

code >number ( ud1 c-addr1 u1 –– ud2 c-addr2 u2 )
4 4 in/out
test eax eax \ check if anything to convert
je short @@4 \ zero, so skip
mov ecx eax \ len in ecx
mov esi { ebp } \ esi = address
mov edi { base ebx } \ get the number base
@@1: movzx eax byte { esi } \ get next digit
cmp eax '0'
jb short @@3 \ if below '0' branch to done
cmp eax '9'
jbe short @@2 \ go convert it
and eax $df \ convert to uppercase
cmp eax 'A' \ if below 'A'
jb short @@3 \ then branch to done
sub eax 7 \ adjust to be contiguous numeric
@@2: sub eax '0' \ de-ASCIIfy
cmp eax edi \ test against current base
jae short @@3 \ out of base range
mov edx eax
mov eax { cell ebp } \ swap eax <-> { cell ebp }
mov { cell ebp } edx
mul edi \ multiply by base
mov edx eax
mov eax { 2 cells ebp } \ swap eax <-> { 2 cells ebp }
mov { 2 cells ebp } edx
mul edi \ multiply by base
add eax { cell ebp } \ add
adc edx { 2 cells ebp } \ and +carry for the double
mov { 2 cells ebp } eax \ store result
mov { cell ebp } edx \ store result
add esi 1
sub ecx 1
jnz short @@1
@@3: mov eax ecx
mov { ebp } esi \ address of unconvertable digit
@@4: next;



--
Alex
0 new messages