RFD: TRAVERSE-WORDLIST v6 revision

Alex McDonald

unread,

Jul 25, 2013, 9:40:47 PM7/25/13

to

Comments please.

RfD: TRAVERSE-WORDLIST
----------------------

v1 20 January 2012, Alex McDonald
v2 24 January 2012, Alex McDonald
v3 03 February 2012, Alex McDonald
v4 28 February 2012, Alex McDonald
v4.1 03 March 2012, Alex McDonald
v5 04 September 2012, Alex McDonald
v6 25 July 2013, Alex McDonald

Change history:

20120120 First version
20120124 Minor typos, added section "Order of node visits"
Added to section "Remarks"
20120125 Minor typos, cleanup and added remarks
20120203 Changed order of stack for TRAVERSE-WORDLIST
to place the xt rightmost.
Removed return value from TRAVERSE-WORDLIST.
Changed xt-node halt flag to a continue flag.
Note that if xt-node modifies the wordlist, the
results are undefined.
Specify NAME>... supporting words in section 2.2.
Tidy up & correction of 4. Remarks
20120228 Section 2.1 and 2.2 moved and renumbered.
Rename NAME>... to NT>... to more clearly
indicate a name token rather than a name.
Tidy up table in section 3. Experience, and
add note re NT>... names.
Corrected Bruce McFarling's moniker
20120904 Updates based on comments by Anton Ertl, Peter Knaggs,
Bruce McFarling
20130725 Corrected stack signatures & reduce verbage

1. Problem
----------

There are no standard words in Forth for traversing a WORDLIST and
obtaining basic information about each node. While standard Forth
provides a great many features for extensibility of the language
(with CREATE ... DOES> being the classic example), standard Forth
lacks the basic capability of traversing the wordlist as a part of
the specification.

Such a capability is needed to provide some kinds of advanced
programming tools. For example, the programmer may want to determine
all instances of word name overlaps in all of the wordlists in the
current search order; or count, display or modify words contained in
a specific wordlist.

Many systems provide the TOOLS word WORDS that provides human-
readable output from the current wordlists in CONTEXT. TRAVERSE-
WORDLIST is a usable factor for the implementation of WORDS.

Wordlist traversal functionality is available through very similar
words in Win32Forth (VOC-ITERATE), VFX (WalkWordList), iForth
(doWORDS), lxf/ntf (WALK-WORDLIST), and ciforth (FOR-WORDS).

2. Proposal
-----------

TRAVERSE-WORDLIST ( xt wid -- ) "traverse-wordlist" TOOLS-EXT

Remove wid and xt from the stack. Traverse the wordlist wid,
executing xt (a user-specified word) once for every word in
the wordlist.

The invoked xt has the stack diagram ( nt -- u|0 ).

A non-zero value for u will invoke the xt again with a new nt until
all the nodes in the wordlist have been exhausted. Setting u to zero
(FALSE) terminates this traversal, and xt will not be invoked again.

xt will not be invoked if the wordlist wid is empty.

nt is a system-specific name token for the node. The xt can use this
token to display, count, modify or perform any other action on the
node that the system providing nt permits. The format of nt is
opaque, but it is guaranteed to be unique for each word in the
wordlist.

2.1 Opaque NTs
--------------

Since this proposal introduces the concept of an opaque nt (name
token), the following words allow system independent reference to
specific parts of the node.

NT>STRING ( nt -- addr count ) "name-to-string" TOOLS-EXT

NT>STRING returns the string addr count, the definition name of the
word represented by nt. Case is dependent on the case-sensitivity of
the Forth system (see /DPANS 3.3.1.2 Definition names/). For
restrictions see (3.1 NT>STRING Restrictions)

NT>INTERPRET ( nt -- xt ) "name-to-interpret" TOOLS-EXT

NT>INTERPRET returns an xt (execution token) as discussed in
/DPANS 3.4.3 Semantics/. This xt represents the execution semantics
of the definition. It may be zero if there are no execution semantics.

NT>COMPILE ( nt -- xt ) "name-to-compile" TOOLS-EXT

NT>COMPILE returns an xt (execution token) as discussed in
/DPANS 3.4. 3 Semantics/. This xt represents the compilation
semantics of the definition. It may be zero if there are no
compilation semantics.

Extend /DPANS Table 3.1 Data Types/

Symbol Data type Size on stack
nt name token 1 cell

Add section /DPANS 3.1.3.5 Name tokens/

Different definitions have different name tokens, although
information obtainable from the token may be identical for different
name tokens; for instance, NT>STRING for different values of nt may
return the same string.

2.2 Order of node visits
------------------------

TRAVERSE-WORDLIST gives no guarantee as to any specific order of node
visits to each word through the invoked xt with one exception.

If a wordlist contains duplicate entries, SEARCH-WORDLIST and FIND
for a duplicated name will return the execution token of the last
temporally defined name. For instance

: SAMPLE ... ( 1 ) ;
: TEST ... ;
: RETURNS ... ;
: SAMPLE ... ( 2 ) ;
: SAMPLE ... ( 3 ) ;

defines five words, one of which, SAMPLE, is defined three times.
SEARCH-WORDLIST and FIND will only return the last definition (3).
Whether duplicated nodes are visited or not by TRAVERSE-WORDLIST is
undefined. TRAVERSE-WORDLIST is only obliged to visit the nodes TEST,
RETURNS and SAMPLE (3) from the wordlist, and can do so in any order.

Some systems may permit visiting the node for the second and
subsequent definitions of SAMPLE. Exceptionally in this case,
TRAVERSE-WORDLIST *must* visit multiply defined nodes in the order
newest to oldest (but not necessarily consecutively); that is, SAMPLE
(3) must be returned before (2), and (2) before (1).

The remaining unique nodes can appear in any order, and may be
interspersed between the duplicately named and ordered words. If this
ordering is not possible, then TRAVERSE-WORDLIST *must* call xt with
only the FINDable definition of SAMPLE.

TRAVERSE-WORDLIST is affected by the operation of FORGET or MARKER,
and the results of a traversal *must not* return words that are
unFINDable after execution of FORGET or MARKER. Additionally, any
operation during the execution of xt-node that modifies the structure
of the wordlist (that is, defining words such as : (colon) or CREATE,
or execution of FORGET or MARKER) results in undefined behaviour.

3. Rationale
------------

3.1 NT>STRING Restrictions
--------------------------

Implementations may choose to point to the string in the word's header
built when the word is defined: point to a static buffer that is
reused on each call; point to a dynamic buffer that is replaced on
each call: or some other method. Whatever technique is used, the
following are required of the string returned by NT>STRING;

The string is read-only; operations that write to the string are not
permitted.
Reading outside of the bounds (addr) to (addr+count) is not
permitted.
The lifetime of the string is only guaranteed up to the next call of
NT>STRING; subsequent calls to NT>STRING must assume that a different
address, length and contents will be returned.

If the string is needed outside of this lifetime, it must be copied to
another buffer. The alternative - providing a buffer for NT>STRING's
used - has been rejected on the grounds that the buffer would have to
be of an unknown length. Although names of definitions are required
to be at least 31 characters in length (/DPANS 3.3.1.2 Definition
names/) there is no specified upper limit.

3.2 Order of node visits
------------------------

There are a number of orders in which nodes may be visited in a
wordlist, each of which depends on the specific implementation of
wordlists. Although they are often based on hash tables, no
assumptions are made in the ANS Forth specification about internal
implementations.

To conform with this and to simplify implementation of TRAVERSE-
WORDLIST and to allow various techniques to be used for wordlists, no
guarantee is given as to any specific order of node visits to each
word with the exception given in 2.2.

3.3 Use of the stack by TRAVERSE-WORDLIST
-----------------------------------------

Removal of the xt and wid by TRAVERSE-WORDLIST before invoking the xt
ensures that the data stack is not blocked; it is not permitted to
maintain control information for the traversal on the data stack.
This is to allow parameters beyond the nt to be passed to xt.
For instance, the caller may wish to maintain a count of nodes
visited on the stack.

4. Examples
-----------

: WORDS-COUNT ( x nt -- x' u ) DROP 1+ TRUE ;
0 ' WORDS-COUNT WID TRAVERSE-WORDLIST . ( count of nodes visited)

prints x', where x' is a count of the total number of nodes in the
wordlist WID.

: ALL-WORDS NT>STRING CR TYPE TRUE ;
['] ALL-WORDS GET-CURRENT TRAVERSE-WORDLIST

prints the names of words in the current compilation wordlist.

: CONTAINS-STRING NT>STRING 2OVER
SEARCH IF CR TYPE THEN FALSE ;
S" COM" ['] CONTAINS-STRING GET-CURRENT TRAVERSE-WORDLIST

prints the name of a word containing the string "COM", if it exists,
and then terminates.

4. Experience
-------------

The wordlist traversal functionality is available through very
similar words in

Win32Forth VOC-ITERATE
VFX WalkWordList
iForth doWORDS
ciForth FOR-WORDS
lxf/ntf WALK-WORDLIST

Commonly used to implement WORDS, these functions and others are
individual solutions with onflicting stack requirements and names.
However, all provided similar functionality to the proposed TRAVERSE-
WORDLIST, namely, the ability to inspect the individual entries in a
wordlist.

5. Remarks
----------

For this version V5 of the RFD dated 25 July 2013:

None so far.

For previous versions:

Krishna Myneni raised the topic in the comp.lang.forth newsgroup (http:
//groups.google.com/group/comp.lang.forth/browse_frm/thread/
b5f6ad076607e0b8/0dde8de4c483b9e2#0dde8de4c483b9e2)

Krishna Myneni requested specific orderings. As there are many
possible orderings that may be useful for processing nodes, TRAVERSE-
WORDLIST can be used to support them by, for instance, building a
list during execution of xt-node and sorting the results.

Peter Fälth adds: "My system (lxf/ntf) supports such a word (but with
some differences); my name is WALK-WORDLIST ( xt wid -- ). I have
also a WALK-ALL-WORDLISTS ( xt -- ) that actually is more used I
suggest also to add such a word."

Bruce McFarling requested: that words with multiple definitions are
returned in newest to oldest order. Addressed above, but a use case
and rationale would be useful.

Bruce McFarling and Peter Fälth would prefer that xt-node use a "halt?"
flag; i.e., to halt on a non-zero return value, rather than on zero.
Due to changes in the TRAVERSE-WORDLIST signature, halt on zero has
been reinstated for xt-node.

Peter Fälth, Anton Ertl and others do not like the nt return value
from TRAVERSE-WORDLIST. It has been removed, and xt-node word can use
one of its agreed parameters to return a flag or last nt.

Stephen Pelc suggested that the stack signature be simplified to
TRAVERSE-WORDLIST ( xt-node wid -- ) with xt-node ( nt -- u ). Bruce
McFarling notes that there is a loss of functionality as xt-node
cannot operate on additional information on the stack; since under
the modified signature, the TRAVERSE-WORDLIST word is free to be
using the stack underneath the nt for its own purposes.

Various discussions on return flag values, the position of the xt on
the stack for TRAVERSE-WORDLIST, the return values have been
addressed.

Bruce McFarling proposes NAME>... here described as NT>... words.

Andrew Haley proposes a completely different mechanism for traversal;
although interesting, it has not been fully explored and is not
explained here.

Alex McDonald

unread,

Jul 26, 2013, 12:14:39 AM7/26/13

to

On Thursday, 25 July 2013 18:40:47 UTC-7, Alex McDonald wrote:
[errata]
> ['] ALL-WORDS GET-CURRENT TRAVERSE-WORDLIST
...

> S" COM" ['] CONTAINS-STRING GET-CURRENT TRAVERSE-WORDLIST

s/[']/'/ in the Examples section.

Albert van der Horst

unread,

Jul 26, 2013, 6:36:13 AM7/26/13

to

In article <kssjn5$cf3$1...@dont-email.me>,

>Peter F�lth adds: "My system (lxf/ntf) supports such a word (but with

>some differences); my name is WALK-WORDLIST ( xt wid -- ). I have
>also a WALK-ALL-WORDLISTS ( xt -- ) that actually is more used I
>suggest also to add such a word."
>
>Bruce McFarling requested: that words with multiple definitions are
>returned in newest to oldest order. Addressed above, but a use case
>and rationale would be useful.
>

>Bruce McFarling and Peter F�lth would prefer that xt-node use a "halt?"

>flag; i.e., to halt on a non-zero return value, rather than on zero.
>Due to changes in the TRAVERSE-WORDLIST signature, halt on zero has
>been reinstated for xt-node.
>

>Peter F�lth, Anton Ertl and others do not like the nt return value

>from TRAVERSE-WORDLIST. It has been removed, and xt-node word can use
>one of its agreed parameters to return a flag or last nt.
>
>Stephen Pelc suggested that the stack signature be simplified to
>TRAVERSE-WORDLIST ( xt-node wid -- ) with xt-node ( nt -- u ). Bruce
>McFarling notes that there is a loss of functionality as xt-node
>cannot operate on additional information on the stack; since under
>the modified signature, the TRAVERSE-WORDLIST word is free to be
>using the stack underneath the nt for its own purposes.
>
>Various discussions on return flag values, the position of the xt on
>the stack for TRAVERSE-WORDLIST, the return values have been
>addressed.
>
>Bruce McFarling proposes NAME>... here described as NT>... words.
>
>Andrew Haley proposes a completely different mechanism for traversal;
>although interesting, it has not been fully explored and is not
>explained here.
>

This presupposes an opaque namethingy (called DEA in ciforth).

ciforth has had the following since day one (ca 2002).
It is used to implement `` WORDS ''
From the glossary (` means italix)

"
FOR-WORDS

STACKEFFECT: x1...xn xt wid --- x1...xn

DESCRIPTION:

For all words from a word list identified by `wid execute `xt with as
data `x1..xn plus the DEA of those words. `xt must have the stack
diagram `x1..`xn `dea --- `x1..`xn.
"

[Note (only for ciforth) : you can use the DEA of any
word as a WID and the remainder of the word list will be searched. ]

There is no control over the order in which the wid is traversed.
I don't think it should.

: WORDS ['] ID. CONTEXT @ FOR-WORDS ;

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

Lars Brinkhoff

unread,

Jul 26, 2013, 9:19:03 AM7/26/13

to

Albert van der Horst wrote:
> This presupposes an opaque namethingy (called DEA in ciforth).

It's right there in the text you quoted:
> > 2.1 Opaque NTs

> FOR-WORDS

> For all words from a word list identified by `wid execute `xt with as
> data `x1..xn plus the DEA of those words.

I have been using Alex' TRAVERSE-WORDLIST for most of my wordlist-
traversal needs, and for some use cases it's nice to be able to halt
the traversal in a simple way (i.e. not using R> DROP or THROW).

Stephen Pelc

unread,

Jul 26, 2013, 9:44:17 AM7/26/13

to

On Thu, 25 Jul 2013 18:40:47 -0700, "Alex McDonald" <bl...@rivadpm.com>
wrote:

>Comments please.

An xt is already an opaque type. I ask again, why do we need another
one just to get at names/headers? I suspect that there are a few
systems in which an xt corresponds to a CFA (code field address)
and from which names are either tedious or impossible to find.
There are certainly issues in cross compilers, but we (MPE) have
not found them to be insuperable.

Since the original intention of an xt was to be a "single point
of reference" to a word, I believe that a system in which you
cannot get from xt to name is probably broken, if only in spirit.
It seems a little bizarre to support these systems by introducing
another opaque type and then to introduce words to convert between
these opaque types. Perhaps these spritually broken systems should
be named.

Note that it is not TRAVERSE-WORDLIST that I object to, only the
introduction of another opaque type.

Stephen

--
Stephen Pelc, steph...@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

Andrew Haley

unread,

Jul 26, 2013, 9:55:17 AM7/26/13

to

Stephen Pelc <steph...@mpeforth.com> wrote:
> On Thu, 25 Jul 2013 18:40:47 -0700, "Alex McDonald" <bl...@rivadpm.com>
> wrote:
>
>>Comments please.
>
> An xt is already an opaque type. I ask again, why do we need another
> one just to get at names/headers? I suspect that there are a few
> systems in which an xt corresponds to a CFA (code field address)
> and from which names are either tedious or impossible to find.
> There are certainly issues in cross compilers, but we (MPE) have
> not found them to be insuperable.
>
> Since the original intention of an xt was to be a "single point
> of reference" to a word, I believe that a system in which you
> cannot get from xt to name is probably broken, if only in spirit.
> It seems a little bizarre to support these systems by introducing
> another opaque type and then to introduce words to convert between
> these opaque types. Perhaps these spritually broken systems should
> be named.
>
> Note that it is not TRAVERSE-WORDLIST that I object to, only the
> introduction of another opaque type.

I'm sure you're right about that. Maybe it's one area in which ANS
gave implementors too much leeway.

Andrew.

Bernd Paysan

unread,

Jul 26, 2013, 10:10:56 AM7/26/13

to

Stephen Pelc wrote:

> On Thu, 25 Jul 2013 18:40:47 -0700, "Alex McDonald" <bl...@rivadpm.com>
> wrote:
>
>>Comments please.
>
> An xt is already an opaque type. I ask again, why do we need another
> one just to get at names/headers? I suspect that there are a few
> systems in which an xt corresponds to a CFA (code field address)
> and from which names are either tedious or impossible to find.
> There are certainly issues in cross compilers, but we (MPE) have
> not found them to be insuperable.
>
> Since the original intention of an xt was to be a "single point
> of reference" to a word, I believe that a system in which you
> cannot get from xt to name is probably broken, if only in spirit.

What about synonyms? Example: I implement WORDS with

: WORDS [: NT>STRING TYPE SPACE 0 ;] CURRENT @ TRAVERSE-WORDLIST ;

If I have a wordlist with

: foo ;
synonym bar foo

I expect WORDS to output

bar foo ok

The xt of both bar and foo can be the same, as bar is just a synonym for
foo. Note that VFX does not implement it that way, it's synonyms have
separate xts, but other systems (like current Git Gforth) implement synonyms
in that way.

Note that it is no good idea to have a single xt for NT>COMPILE (which is
called NAME>COMP in Gforth), because compilation semantics is either
COMPILE, or EXECUTE an xt (depending on immediacy).

NT>STRING is called NAME>STRING in Gforth. If Alex McDonald wants to be
taken serious, he should at least not invent new names for words that
already exist in some systems.

> It seems a little bizarre to support these systems by introducing
> another opaque type and then to introduce words to convert between
> these opaque types. Perhaps these spritually broken systems should
> be named.
>
> Note that it is not TRAVERSE-WORDLIST that I object to, only the
> introduction of another opaque type.

I've crossed my light saber over that topic with Anton Ertl for the last
year, and the Forth is strong in Anton. So now it's your turn ;-). Anton's
position is that true monotoken systems like VFXForth are non-standard.

--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

Anton Ertl

unread,

Jul 26, 2013, 11:24:29 AM7/26/13

to

steph...@mpeforth.com (Stephen Pelc) writes:
>On Thu, 25 Jul 2013 18:40:47 -0700, "Alex McDonald" <bl...@rivadpm.com>
>wrote:
>
>>Comments please.
>
>An xt is already an opaque type. I ask again, why do we need another
>one just to get at names/headers? I suspect that there are a few
>systems in which an xt corresponds to a CFA (code field address)
>and from which names are either tedious or impossible to find.

Got it in one.

>Since the original intention of an xt was to be a "single point
>of reference" to a word

Says who?

> I believe that a system in which you
>cannot get from xt to name is probably broken, if only in spirit.
>It seems a little bizarre to support these systems by introducing
>another opaque type and then to introduce words to convert between
>these opaque types. Perhaps these spritually broken systems should
>be named.

Gforth 0.7.0.

- 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 2013: http://www.euroforth.org/ef13/

Andrew Haley

unread,

Jul 26, 2013, 11:55:52 AM7/26/13

to

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:

> steph...@mpeforth.com (Stephen Pelc) writes:
>
>>I believe that a system in which you cannot get from xt to name is
>>probably broken, if only in spirit. It seems a little bizarre to
>>support these systems by introducing another opaque type and then to
>>introduce words to convert between these opaque types. Perhaps these
>>spritually broken systems should be named.
>
> Gforth 0.7.0.

Shoulda guessed. Any more?

Andrew.

Elizabeth D. Rather

unread,

Jul 26, 2013, 2:32:42 PM7/26/13

to

On 7/26/13 5:24 AM, Anton Ertl wrote:
> steph...@mpeforth.com (Stephen Pelc) writes:
>> On Thu, 25 Jul 2013 18:40:47 -0700, "Alex McDonald" <bl...@rivadpm.com>
>> wrote:
>>
>>> Comments please.
>>
>> An xt is already an opaque type. I ask again, why do we need another
>> one just to get at names/headers? I suspect that there are a few
>> systems in which an xt corresponds to a CFA (code field address)
>> and from which names are either tedious or impossible to find.
>
> Got it in one.
>
>> Since the original intention of an xt was to be a "single point
>> of reference" to a word
>
> Says who?

Well, that's my recollection of the intent of the Forth94 committee.

Cheers,
Elizabeth

>> I believe that a system in which you
>> cannot get from xt to name is probably broken, if only in spirit.
>> It seems a little bizarre to support these systems by introducing
>> another opaque type and then to introduce words to convert between
>> these opaque types. Perhaps these spritually broken systems should
>> be named.
>
> Gforth 0.7.0.
>
> - anton
>

--

==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

m...@iae.nl

unread,

Jul 26, 2013, 2:50:53 PM7/26/13

to

On Friday, July 26, 2013 4:10:56 PM UTC+2, Bernd Paysan wrote:Bernd Paysan <bernd....@gmx.de> writes Re: RFD: TRAVERSE-WORDLIST v6 revision
[..]

> NT>STRING is called NAME>STRING in Gforth. If Alex McDonald wants to be
> taken serious, he should at least not invent new names for words that
> already exist in some systems.

[..]

On the contrary, he should invent new names when at least two systems
have the same name for a (possibly) different thing.

This my take on this (note Albert's guidance):

FORTH> words: NAME
>HEAD HEAD>exec HEAD>comp HEAD'
HEAD>FLAGS HEAD>LOCATE HEAD>FORGET HEAD>HASH
HEAD> LINK>HEAD HEAD>LINK HEAD>NAME
ok
FORTH> help >HEAD
>HEAD "to-head" IFORTH
( xt -- dea | 0 )
dea is the address of the dictionary entry whose execution token is xt .
If the conversion was not possible a 0 is returned.
ok
FORTH> ' cr >HEAD HEAD>NAME .$ CR ok
FORTH> HEAD' cr HEAD>NAME .$ CR ok

I don't intend to support 8-byte characters, hence .$ ( COUNT TYPE ).
Note that HEAD' can replace '.

-marcel

Bernd Paysan

unread,

Jul 26, 2013, 3:03:30 PM7/26/13

to

m...@iae.nl wrote:

> On Friday, July 26, 2013 4:10:56 PM UTC+2, Bernd Paysan wrote:Bernd Paysan
> <bernd....@gmx.de> writes Re: RFD: TRAVERSE-WORDLIST v6 revision
> [..]
>> NT>STRING is called NAME>STRING in Gforth. If Alex McDonald wants to be
>> taken serious, he should at least not invent new names for words that
>> already exist in some systems.
> [..]
>
> On the contrary, he should invent new names when at least two systems
> have the same name for a (possibly) different thing.

He should first research the names, and *if* there are such collisions, then
it's time to suggest something else. But not before.

Very classical is

>NAME ( xt -- nt )

Seen in: VFX, bigForth, Gforth, SwiftForth, Win32Forth. Does nothing in VFX
and Gforth git-head.

.NAME ( nt -- )

Seen in bigForth, Gforth, SwiftForth

.NAME ( xt -- )

Seen in win32forth, VFX.

Elizabeth D. Rather

unread,

Jul 26, 2013, 4:38:24 PM7/26/13

to

On 7/26/13 9:03 AM, Bernd Paysan wrote:
> m...@iae.nl wrote:
>
>> On Friday, July 26, 2013 4:10:56 PM UTC+2, Bernd Paysan wrote:Bernd Paysan
>> <bernd....@gmx.de> writes Re: RFD: TRAVERSE-WORDLIST v6 revision
>> [..]
>>> NT>STRING is called NAME>STRING in Gforth. If Alex McDonald wants to be
>>> taken serious, he should at least not invent new names for words that
>>> already exist in some systems.
>> [..]
>>
>> On the contrary, he should invent new names when at least two systems
>> have the same name for a (possibly) different thing.
>
> He should first research the names, and *if* there are such collisions, then
> it's time to suggest something else. But not before.

In particular, if there's a name whose behavior coincides closely enough
with what he wants to do, he should adopt that name and behavior. We
should work towards consensus, where possible!

Cheers,
Elizabeth

Albert van der Horst

unread,

Jul 26, 2013, 9:53:07 PM7/26/13

to

In article <51f27a43....@news.demon.co.uk>,

Stephen Pelc <steph...@mpeforth.com> wrote:
>
>Since the original intention of an xt was to be a "single point
>of reference" to a word, I believe that a system in which you
>cannot get from xt to name is probably broken, if only in spirit.
>It seems a little bizarre to support these systems by introducing
>another opaque type and then to introduce words to convert between
>these opaque types. Perhaps these spritually broken systems should
>be named.

Couldn't agree more. xt was only separated from the name to
serve double as identifying a dictionary entry and at the same
time an anonymous code sequence.
A design error if there was one.

>
>Note that it is not TRAVERSE-WORDLIST that I object to, only the
>introduction of another opaque type.
>
>Stephen
>
>--
>Stephen Pelc, steph...@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

Albert van der Horst

unread,

Jul 26, 2013, 10:10:22 PM7/26/13

to

In article <x7OdnTykJoqVAW_M...@supernews.com>,

iforth apparently, having >HEAD and HEAD> to convert
the opaque types dea and xt.

>Andrew.

peter....@gmail.com

unread,

Jul 27, 2013, 5:32:15 AM7/27/13

to

My system lxf/ntf.

Headers are kept in a separate address space. There is no direct way to get from the XT back to the name. You must use the TRAVERSE-WORDLIST approach. As synonyms have the same XT (would they be synonyms otherwise?)you are not garanteed to get the original name back. Each header has in fact 2 XTs, one execution and one compilation. The only connection between them is thru the header.

Peter Fälth

Alex McDonald

unread,

Jul 27, 2013, 11:44:21 AM7/27/13

to

On Friday, 26 July 2013 13:38:24 UTC-7, Elizabeth D. Rather wrote:
> On 7/26/13 9:03 AM, Bernd Paysan wrote:
>
> > m...@iae.nl wrote:
> >
> >> On Friday, July 26, 2013 4:10:56 PM UTC+2, Bernd Paysan wrote:Bernd Paysan
> >> <bernd....@gmx.de> writes Re: RFD: TRAVERSE-WORDLIST v6 revision
> >> [..]
> >>> NT>STRING is called NAME>STRING in Gforth. If Alex McDonald wants to be
> >>> taken serious, he should at least not invent new names for words that
> >>> already exist in some systems.

I know you wouldn't have replied if you didn't think it worthy of discussion, and I'm taking it seriously.

> >> [..]
> >>
> >> On the contrary, he should invent new names when at least two systems
> >> have the same name for a (possibly) different thing.
> >
> > He should first research the names, and *if* there are such collisions, then
> > it's time to suggest something else. But not before.
>
> In particular, if there's a name whose behavior coincides closely enough
> with what he wants to do, he should adopt that name and behavior. We
> should work towards consensus, where possible!
>
> Cheers,
>
> Elizabeth
>
>

To answer all the naming comments in this part of the discussion...

Agreed, consensus is the purpose of the RFD. Unfortunately, I'm not steeped in Forth's history, nor am I familiar with the range of Forth systems out there (with the exception of slight familiarity with gforth) and the words they may use for these tasks.

Rather than the label I've given them -- which is changeable -- I'm more interested in the issue of the xt TRAVERSE-WORDLIST invokes being passed a "name token", rather than an xt.

Thanks for the input.

Alex McDonald

unread,

Jul 27, 2013, 12:02:10 PM7/27/13

to

I'm concerned that the specification didn't make an xt as "single point of reference" normative. Nor did it get (as far as I can see from the spec) a mention in the non-normative part of the spec.

That makes proposals like this impossible if the spec is to be interpreted in this way. It's true of any spec, actually; compliance can't be decided on the basis of what one wishes to be true. More to the point, unwritten intent and spirit have been overtaken by conforming implementations, and there appear to be (at least) 3 for far; gforth, iforth and lxf/ntf.

Stephen Pelc

unread,

Jul 27, 2013, 12:26:02 PM7/27/13

to

On Fri, 26 Jul 2013 21:03:30 +0200, Bernd Paysan <bernd....@gmx.de>
wrote:

>>NAME ( xt -- nt )
>
>Seen in: VFX, bigForth, Gforth, SwiftForth, Win32Forth. Does nothing in VFX
>and Gforth git-head.

It does plenty in VFX!

>
>.NAME ( nt -- )
>
>Seen in bigForth, Gforth, SwiftForth
>
>.NAME ( xt -- )
>
>Seen in win32forth, VFX.

The VFX version is *documented* and implemented as:
: .NAME \ nfa --
\ *G Display a definition's name given an NFA.

Stephen Pelc

unread,

Jul 27, 2013, 12:46:24 PM7/27/13

to

On Sat, 27 Jul 2013 09:02:10 -0700 (PDT), Alex McDonald
<bl...@rivadpm.com> wrote:

>I'm concerned that the specification didn't make an xt as "single point of =
>reference" normative. Nor did it get (as far as I can see from the spec) a =
>mention in the non-normative part of the spec.=20

I agree with you.

>That makes proposals like this impossible if the spec is to be interpreted =
>in this way. It's true of any spec, actually; compliance can't be decided o=
>n the basis of what one wishes to be true. More to the point, unwritten int=
>ent and spirit have been overtaken by conforming implementations, and there=
> appear to be (at least) 3 for far; gforth, iforth and lxf/ntf.=20

I can understand not having back pointers in space-constrained
implementations and applications, but the named systems are all
desktop systems. As far as I know, there are few Forth applications
whose code exceeds 20Mb. There are also now few desktop systems with
less than 1Gb of RAM. When a large Forth app uses a very few percent
of a desktop, the space savings cannot be an issue any more.

Would the authors of these systems please explain why not being
able to get from an xt to a name is still a good idea?

Albert van der Horst

unread,

Jul 27, 2013, 2:07:35 PM7/27/13

to

In article <51f3f756....@news.demon.co.uk>,

Stephen Pelc <steph...@mpeforth.com> wrote:

>I can understand not having back pointers in space-constrained
>implementations and applications, but the named systems are all
>desktop systems. As far as I know, there are few Forth applications
>whose code exceeds 20Mb. There are also now few desktop systems with
>less than 1Gb of RAM. When a large Forth app uses a very few percent
>of a desktop, the space savings cannot be an issue any more.
>
>Would the authors of these systems please explain why not being
>able to get from an xt to a name is still a good idea?

I can explain why there is a problem getting from an xt to a name
the way an xt is intended by the standard.

:NONAME aap noot mies ; XT>NAME

Huh?

In ciforth you get

:NONAME TASK TASK NOOP ; ID.
NONAME OK

>
>Stephen

Groetjes Albert

Alex McDonald

unread,

Jul 27, 2013, 2:34:08 PM7/27/13

to

on 27/07/2013 11:07:35, wrote:
> In article <51f3f756....@news.demon.co.uk>,
> Stephen Pelc <steph...@mpeforth.com> wrote:
>
>>I can understand not having back pointers in space-constrained
>>implementations and applications, but the named systems are all
>>desktop systems. As far as I know, there are few Forth applications
>>whose code exceeds 20Mb. There are also now few desktop systems with
>>less than 1Gb of RAM. When a large Forth app uses a very few percent
>>of a desktop, the space savings cannot be an issue any more.
>>
>>Would the authors of these systems please explain why not being
>>able to get from an xt to a name is still a good idea?
>
> I can explain why there is a problem getting from an xt to a name
> the way an xt is intended by the standard.

Well, it isn't mandated by the standard.

>
>:NONAME aap noot mies ; XT>NAME
>
> Huh?
>
> In ciforth you get
>
>:NONAME TASK TASK NOOP ; ID.
> NONAME OK
>
>>
>>Stephen
>
> Groetjes Albert

This is why WF32 (my personal Forth) adds dictionary entries with a null
string for :NONAME. This, it may be suggested, is not in the spirit of
the standard, since not creating a dictionary entry is not mentioned; but
it is not disallowed either.

Alex McDonald

unread,

Jul 27, 2013, 3:07:39 PM7/27/13

to

on 27/07/2013 09:46:22, wrote:
> On Sat, 27 Jul 2013 09:02:10 -0700 (PDT), Alex McDonald
> <bl...@rivadpm.com> wrote:
>
>>I'm concerned that the specification didn't make an xt as "single point of =
>>reference" normative. Nor did it get (as far as I can see from the spec) a =
>>mention in the non-normative part of the spec.=20
>
> I agree with you.
>
>>That makes proposals like this impossible if the spec is to be interpreted =
>>in this way. It's true of any spec, actually; compliance can't be decided o=
>>n the basis of what one wishes to be true. More to the point, unwritten int=
>>ent and spirit have been overtaken by conforming implementations, and there=
>> appear to be (at least) 3 for far; gforth, iforth and lxf/ntf.=20
>
> I can understand not having back pointers in space-constrained
> implementations and applications, but the named systems are all
> desktop systems. As far as I know, there are few Forth applications
> whose code exceeds 20Mb. There are also now few desktop systems with
> less than 1Gb of RAM. When a large Forth app uses a very few percent
> of a desktop, the space savings cannot be an issue any more.
>
> Would the authors of these systems please explain why not being
> able to get from an xt to a name is still a good idea?

It's a theoretical question. A proposed change to the standard can't
assume what's not written there; an xt as single point of reference is
not mandated. You're also not going to be any happier when it's answered.

We're left with the alternatives of

1. Mandating xt as a single point of reference
2. Supporting an opaque name token
3. Abandoning any attempt to provide a toolset of words that allows
portable implementation of dictionary introspection.

(1) won't fly; it's too late to retrofit
(2) is part of the proposal and I vote for it, ugly though it may be
(3) is the most likely outcome.

>
> Stephen
>

Bernd Paysan

unread,

Jul 27, 2013, 5:42:03 PM7/27/13

to

Alex McDonald wrote:
> We're left with the alternatives of
>
> 1. Mandating xt as a single point of reference
> 2. Supporting an opaque name token
> 3. Abandoning any attempt to provide a toolset of words that allows
> portable implementation of dictionary introspection.
>
> (1) won't fly; it's too late to retrofit
> (2) is part of the proposal and I vote for it, ugly though it may be
> (3) is the most likely outcome.

Actually, this 1 is still a matter of debate. E.g. though Gforth 0.7.x is
listed amongst the systems that don't have xts as single point of reference,
Gforth git-head does have them (with some minor exceptions that there still
is a name>int and name>comp, which is for backward compatibility, Anton's
interpretation of special compilation semantics, *and* allows to implement
synonyms, and have a not-quite xt as point of reference in the alias, which
gets the real xt with name>int or name>comp).

Gforth 0.7.x also won't support synonyms, another extension of Forth200x.
So actually raising the bar for some extensions a bit higher is not always a
bad idea, because it might drive people to do something better.

m...@iae.nl

unread,

Jul 27, 2013, 5:43:57 PM7/27/13

to

steph...@mpeforth.com (Stephen Pelc) writes Re: RFD: TRAVERSE-WORDLIST v6revision

On Sat, 27 Jul 2013 09:02:10 -0700 (PDT), Alex McDonald <bl...@rivadpm.com>
wrote:

[..]

>> More to the point, unwritten

>> intent and spirit have been overtaken by conforming implementations,
>> and there appear to be (at least) 3 for far; gforth, iforth and lxf/ntf.
[..]

> Would the authors of these systems please explain why not being
> able to get from an xt to a name is still a good idea?

There is a misunderstanding. iForth can do this, although ATM there
is no single word for it; one has to use

: .NAME ( nt -- ) .ID ;
: NT>STRING ( nt -- c-addr u ) HEAD>NAME COUNT ; ( etc.)
: NT>INTERPRET ( nt -- xt ) HEAD>exec ;
: NT>COMPILE ( nt -- xt ) HEAD>comp ;

In case nt is to be an xt, add >HEAD to convert.

:NONAME cr ; >HEAD .ID {no name} ok

-marcel

Bernd Paysan

unread,

Jul 27, 2013, 5:44:46 PM7/27/13

to

Stephen Pelc wrote:

> On Fri, 26 Jul 2013 21:03:30 +0200, Bernd Paysan <bernd....@gmx.de>
> wrote:
>
>>>NAME ( xt -- nt )
>>
>>Seen in: VFX, bigForth, Gforth, SwiftForth, Win32Forth. Does nothing in
>>VFX and Gforth git-head.
>
> It does plenty in VFX!

Ok, sorry; it still does something in VFX, but it does nothing in Gforth
git-head, because one of the motivations to go monotoken in Gforth git-head
is to get rid of the additional superfluous nt type ;-).

>>
>>.NAME ( nt -- )
>>
>>Seen in bigForth, Gforth, SwiftForth
>>
>>.NAME ( xt -- )
>>
>>Seen in win32forth, VFX.
>
> The VFX version is *documented* and implemented as:
> : .NAME \ nfa --
> \ *G Display a definition's name given an NFA.

Yes, the definition is also still the same in Gforth git-head, but there,
nt=xt.

Alex McDonald

unread,

Jul 28, 2013, 5:43:22 PM7/28/13

to

Is there any appetite for this? Gforth, iforth and lxf/ntf
authors/maintaimers would need to make a commitment to change their
systems. I have no desire to take the lead either; I'm not sufficently
qualified or on the Forth200x committee.

Bernd Paysan

unread,

Jul 28, 2013, 7:10:59 PM7/28/13

to

Alex McDonald wrote:
> Is there any appetite for this? Gforth, iforth and lxf/ntf
> authors/maintaimers would need to make a commitment to change their
> systems.

If you had read what I wrote, you would have understood that Gforth already
did that change. But in fact, even though Stephen Pelc advocated against
the nt, it is part of VFX...

> I have no desire to take the lead either; I'm not sufficently
> qualified or on the Forth200x committee.

As it was Stephen's comment which was against introducing a new type, the
nt, he should propose what to do ;-).

Alex McDonald

unread,

Jul 29, 2013, 4:36:05 AM7/29/13

to

On Monday, 29 July 2013 00:10:59 UTC+1, Bernd Paysan wrote:
> Alex McDonald wrote:
>
> > Is there any appetite for this? Gforth, iforth and lxf/ntf
> > authors/maintaimers would need to make a commitment to change their
> > systems.
>
> If you had read what I wrote, you would have understood that Gforth already
> did that change. But in fact, even though Stephen Pelc advocated against
> the nt, it is part of VFX...

OK. I didn't get that from Anton's comment upthread, nor from previous comments he has made on clf.

>
> > I have no desire to take the lead either; I'm not sufficently
> > qualified or on the Forth200x committee.
>
> As it was Stephen's comment which was against introducing a new type, the
> nt, he should propose what to do ;-).
>

Hopefully. Otherwise...

Mark Wills

unread,

Jul 29, 2013, 4:42:24 AM7/29/13

to

On Saturday, July 27, 2013 7:07:35 PM UTC+1, Albert van der Horst wrote:
> I can explain why there is a problem getting from an xt to a name
> the way an xt is intended by the standard.
> :NONAME aap noot mies ; XT>NAME
> Huh?
> In ciforth you get
> :NONAME TASK TASK NOOP ; ID.
> NONAME OK

That can easily be fixed in the standard by adding the following to the descriptopns of XT>NAME and :NONAME

"An ambiguous condition shall exist if XT>NAME is applied to execution tokens created with :NONAME or if the execution token does not have an associated dictionary entry in general.

unread,

Jul 29, 2013, 9:44:20 AM7/29/13

to

Stephen Pelc

unread,

Jul 30, 2013, 6:04:26 AM7/30/13

to

On Mon, 29 Jul 2013 17:21:40 GMT, an...@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>steph...@mpeforth.com (Stephen Pelc) writes:
>>Would the authors of these systems please explain why not being
>>able to get from an xt to a name is still a good idea?

>: noname ." bar" ;
>dup alias bar1
>dup alias bar2
> alias bar3

I understand, but the point is about words with names. I really
thought that was obvious, but ...

>: s"-int ... ;
>: s"-comp ... ;
>' s"-int ' s"-comp interpret/compile: s"

>Which name should you get back at from an xt?

If I understand the obtuse code correctly
S"-INT
Why? Because of the equivalence of
<x>
and
' <x> execute

The original question still has to be answered for words with
names.

Stephen Pelc

unread,

Jul 30, 2013, 6:06:00 AM7/30/13

to

On Mon, 29 Jul 2013 15:25:48 -1000, "Elizabeth D. Rather"
<era...@forth.com> wrote:

>The important thing is that it wasn't written down. If the current
>committee wants to clarify the issue, this is a good time.

Please post that to the Forth200x list.

Stephen Pelc

unread,

Jul 30, 2013, 6:12:30 AM7/30/13

to

On Mon, 29 Jul 2013 01:10:59 +0200, Bernd Paysan <bernd....@gmx.de>
wrote:

>If you had read what I wrote, you would have understood that Gforth already
>did that change. But in fact, even though Stephen Pelc advocated against
>the nt, it is part of VFX...

Bloody language lawyers!

I have never argued for standardising TRAVERSE-WORDLIST. However, if
you want this word in order to write *portable* tools, an nt has to
be an opaque type. I'm just arguing against yet another opaque type.
And in particular, against words for converting from one opaque
type to another.

The VFX documentation is quite clear that WalkWordList and friends
are VFX specific.

Please avoid incorrectly putting words in my mouth.

Anton Ertl

unread,

Jul 30, 2013, 8:09:28 AM7/30/13

to

steph...@mpeforth.com (Stephen Pelc) writes:
>On Mon, 29 Jul 2013 17:21:40 GMT, an...@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>steph...@mpeforth.com (Stephen Pelc) writes:
>>>Would the authors of these systems please explain why not being
>>>able to get from an xt to a name is still a good idea?
>
>>: noname ." bar" ;
>>dup alias bar1
>>dup alias bar2
>> alias bar3
>
>I understand, but the point is about words with names.

There are three names here, all for the same xt. Which one should the
system get back to and why?

And of course xts that are not linked to a name are a very good reason
for not being able to get from the xt to a name.

>>: s"-int ... ;
>>: s"-comp ... ;
>>' s"-int ' s"-comp interpret/compile: s"
>
>>Which name should you get back at from an xt?
>
>If I understand the obtuse code correctly
> S"-INT
>Why? Because of the equivalence of
> <x>
>and
> ' <x> execute

Interesting. What if I code this as

:noname ... ; \ interpretation semantics
:noname ... ; \ compilation semantics
interpret/compile: s"

>The original question still has to be answered for words with
>names.

It has been answered in the posting you replied to:

|There is no 1:1 correspondence between names and xts.

Albert van der Horst

unread,

Jul 30, 2013, 8:27:20 AM7/30/13

to

In article <kt48e3$8l0$1...@online.de>, Bernd Paysan <bernd....@gmx.de> wrote:
>Alex McDonald wrote:
>> Is there any appetite for this? Gforth, iforth and lxf/ntf
>> authors/maintaimers would need to make a commitment to change their
>> systems.
>
>If you had read what I wrote, you would have understood that Gforth already
>did that change. But in fact, even though Stephen Pelc advocated against
>the nt, it is part of VFX...
>
>> I have no desire to take the lead either; I'm not sufficently
>> qualified or on the Forth200x committee.
>
>As it was Stephen's comment which was against introducing a new type, the
>nt, he should propose what to do ;-).

Well, that's clear even to me. The systems that can't implement
TRAVERSE-WORDLIST without introducing a new opaque type,
can't implement TRAVERSE-WORDLIST. That is the consequence of
Stephen's stand.

Now while I've no problem with my Forth (lina) to admit that it doesn't
implement certain extensions of the standard, the big systems
(gforth vfxforth iforth etc.) want to be able to claim to implement all
extensions to the standard, and hence to be able to run all
standard programs. The last thing they want to admit is to having
choosen a model that doesn't allow for some reasonable extensions.

So naturally they oppose extension that go against the model they
adapted for their Forth. Having an xt without a name is part of
some models, and it is explicitly allowed by the standard. It
presents serious problems for TRAVERSE-WORDLIST.

You might have a look at yourforth and ask yourself why we need
complicated models, if we allow for an optimiser to run on the
really time critical programs afterwards. I've long advocated that
a simple model with good introspective possibilities can have an
optimiser that beats everything else.

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

Anton Ertl

unread,

Jul 30, 2013, 8:16:34 AM7/30/13

to

steph...@mpeforth.com (Stephen Pelc) writes:
>On Tue, 30 Jul 2013 07:57:24 GMT, an...@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>Or we write the standard in a way that allows these implementations to
>>be efficient, and EXECUTE would be fast on these systems, and they
>>would be standard-compliant.
>
>I'm not going to be part of a standards operation that favours bad
>implementations.

The current standards operation favours bad implementations by not
standardizing things that require good implementations (and that has
been defended many times as a virtue of Forth-94 (and, by extension,
Forth-200x, which did not change that attitude)). Yet, last I looked,
you were on the committee.

If you stay on the committee and vote against the TRAVERSE-WORDLIST
proposal, you will still be part of a standards operation that favours
(in your opinion) bad implementations, because there will be no reason
to change these implementations. So whether you vote for or against
TRAVERSE-WORDLIST has nothing to do with favouring (in your opinion)
bad implementations.

>The point of this proposal IMHO is to permit people to write
>portable tools. This proposal is not designed to replace the
>existing internal mechanisms of a system. We're talking about
>a proposal that will probably not be standardised for ten
>years. That gives the implementers plenty of time to make
>efficient compliant kernels.

Compliant with what?

And why should the proposal not be standardized for ten years?

m.a.m....@tue.nl

unread,

Jul 30, 2013, 9:31:42 AM7/30/13

to

On Tuesday, July 30, 2013 2:27:20 PM UTC+2, Albert van der Horst wrote:
> In article <kt48e3$8l0$1...@online.de>, Bernd Paysan <bernd....@gmx.de>

[..]

> You might have a look at yourforth and ask yourself why we need
> complicated models, if we allow for an optimiser to run on the
> really time critical programs afterwards. I've long advocated that
> a simple model with good introspective possibilities can have an
> optimiser that beats everything else.

Looks good on paper but full introspection might not work for
non-trivial programs. The main point is the fallacy that programs
contain a very limited amount of hot-spots and speed up hundredths
of times when these are removed.

The second problem: As an architect almost finished building a
pyramid, you don't like Cleopatra coming to your office with the
good news that her astronomer has calculated North with an yet
another decimal and that the building should be rotated over
0.1 degree. You just want to get on with it, retire, and try
your hand on building Escher's waterworks in your backyard.

-marcel

Anton Ertl

unread,

Jul 30, 2013, 8:48:50 AM7/30/13

to

"Alex McDonald" <bl...@rivadpm.com> writes:
>TRAVERSE-WORDLIST ( xt wid -- ) "traverse-wordlist" TOOLS-EXT
>
>Remove wid and xt from the stack. Traverse the wordlist wid,
>executing xt (a user-specified word) once for every word in
>the wordlist.
>
>The invoked xt has the stack diagram ( nt -- u|0 ).
>
>A non-zero value for u will invoke the xt again with a new nt until
>all the nodes in the wordlist have been exhausted. Setting u to zero
>(FALSE) terminates this traversal, and xt will not be invoked again.
>
>xt will not be invoked if the wordlist wid is empty.

It would be a good idea to make the stack effects as follows:

TRAVERSE-WORDLIST ( i*x xt wid -- i*x )
and for the xt ( i*x nt -- i*x f )

Two suggested changes:

1) xt can access the stack items that are passed below the xt to
TRAVERSE-WORDLIST, and pass stack items out to after
TRAVERSE-WORDLIST.

e.g., if you want to count the number of words in FORTH-WORDLIST, you
could do it as follows

0 :noname drop 1+ true ; FORTH-WORDLIST TRAVERSE-WORDLIST .

With the currently proposed interface you would have to put the count
in a variable or something.

2) Instead of u|0, have a flag f. That's all this parameter is used
for.

>NT>COMPILE ( nt -- xt ) "name-to-compile" TOOLS-EXT
>
>NT>COMPILE returns an xt (execution token) as discussed in
>/DPANS 3.4. 3 Semantics/. This xt represents the compilation
>semantics of the definition. It may be zero if there are no
>compilation semantics.

In Gforth-0.7.0 (and, I think, also in the git head, and in many other
systems), for most words there is no xt that represents the
compilation semantics of the word. Instead the compilation semantics
is represented by a pair of xts: xt1 xt2, where xt2 is usually either
EXECUTE or COMPILE,. A system could add an anonymous word for each
named word that represents the compilation semantics, but that seems
to be quite a bit of cost just to implement TRAVERSE-WORDLIST.
Therefore I suggest:

|NT>COMPILE ( nt -- w xt ) "name-to-compile" TOOLS-EXT
|
|xt has the following stack effect: ( i*x w -- j*x ). EXECUTING it
|consumes w and performs the compilation semantics of the word
|represented by xt.

I don't think we need to discuss words without compilation semantics.
At least there are none in the standard, and no way to create such
words.

BTW, given the "name-to-..." pronounciations, maybe these words were
originally intended to be called NAME>... instead of NT>....

>3.3 Use of the stack by TRAVERSE-WORDLIST
>-----------------------------------------
>
>Removal of the xt and wid by TRAVERSE-WORDLIST before invoking the xt
>ensures that the data stack is not blocked; it is not permitted to
>maintain control information for the traversal on the data stack.
>This is to allow parameters beyond the nt to be passed to xt.
>For instance, the caller may wish to maintain a count of nodes
>visited on the stack.

That's not reflected in the stack effect (nor in the rest of the
glossary entry). I think my suggestion above reflects it a little
better.

Otherwise I like the proposal.

Anton Ertl

unread,

Jul 30, 2013, 10:03:27 AM7/30/13

to

alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>You might have a look at yourforth and ask yourself why we need
>complicated models, if we allow for an optimiser to run on the
>really time critical programs afterwards. I've long advocated that
>a simple model with good introspective possibilities can have an
>optimiser that beats everything else.

I am a bit mystified as to how this ties in with "xt as a single point
of reference".

Anyway, your belief in optimizers seems naive to me. What we get from
"really good optimizers" is code that does not behave as intended (aka
"miscompiled code").

Stephen Pelc

unread,

Jul 30, 2013, 11:28:15 AM7/30/13

to

On Tue, 30 Jul 2013 12:09:28 GMT, an...@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>>>: noname ." bar" ;
>>>dup alias bar1
>>>dup alias bar2
>>> alias bar3
>>
>>I understand, but the point is about words with names.
>
>There are three names here, all for the same xt. Which one should the
>system get back to and why?

The only word that has a known xt is the :NONAME one. The standard
says *nothing* about the xt of a synonym. What is ALIAS ? However,
I would expect bar1, bar2 and bar3 to have their own xts in most
implementations.

>Interesting. What if I code this as
>
>:noname ... ; \ interpretation semantics
>:noname ... ; \ compilation semantics
>interpret/compile: s"

There are still xts, but this time no head. And ... your question
is? There are always perverse implementation techniques. And usually
you bleed for using them.

>>The original question still has to be answered for words with
>>names.
>
>It has been answered in the posting you replied to:
>
>|There is no 1:1 correspondence between names and xts.

: foo cr ." hello" ;

You are not seriously suggesting that there is not a 1:1
correspondence between the name "foo" and the xt of "foo".
Or are you?

Yes, there are situations in which the use of :NONAME leads to xts
from which you cannot find a suitable name. That's part of the
definition of :NONAME. It's also a good reason not to use
:NONAME words except in special circumstances.

Albert van der Horst

unread,

Jul 30, 2013, 12:46:51 PM7/30/13

to

In article <2013Jul3...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>You might have a look at yourforth and ask yourself why we need
>>complicated models, if we allow for an optimiser to run on the
>>really time critical programs afterwards. I've long advocated that
>>a simple model with good introspective possibilities can have an
>>optimiser that beats everything else.
>
>I am a bit mystified as to how this ties in with "xt as a single point
>of reference".

In yourforth (or must I say the ciforth model) an xt is a dea, which
is the address of a uniform header with 5 fields. So there is much
an optimiser can rely on that is always true.

>
>Anyway, your belief in optimizers seems naive to me. What we get from
>"really good optimizers" is code that does not behave as intended (aka
>"miscompiled code").

I don't share your distrust in optimizers.
Remember the naive c-code for gcd's that was near-optimally compiled
with `` gcc -O3 ''. I studied the resulting assembler code in detail.
I suspect that gforth relied on some unguaranteed aspects of the
c-compiler, and maybe extensions that were not fully specified.
Exactly the opposite of a simple model with good introspective
possibilities.

Take for instance the intermediate code of Python. Why would there
be miscompilation for such code by optimizers? Forth's intermediate code
would be even simpler, especially if we leave out all the silly
micro optimisation (Oh no, DEFER can't be a regular CREATE-DOES> word,
much too slow etc. Let's make it a code word. Let's try to do some
reaeaeaeally neat assembler tricks. )
The hardest to handle of these micro optimisations is having different
code for compilation and execution, such as a compiling `` + '' that
looks whether the previous instruction is a constant etc.

>
>- anton

Groetjes Albert

Bernd Paysan

unread,

Jul 30, 2013, 7:10:55 PM7/30/13

to

Stephen Pelc wrote:

> On Tue, 30 Jul 2013 12:09:28 GMT, an...@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:
>
>>>>: noname ." bar" ;
>>>>dup alias bar1
>>>>dup alias bar2
>>>> alias bar3
>>>
>>>I understand, but the point is about words with names.
>>
>>There are three names here, all for the same xt. Which one should the
>>system get back to and why?
>
> The only word that has a known xt is the :NONAME one. The standard
> says *nothing* about the xt of a synonym. What is ALIAS ? However,
> I would expect bar1, bar2 and bar3 to have their own xts in most
> implementations.

An ALIAS is another way to define synonyms, but using an xt instead of a
name. VolksForth had ALIASes, and so bigForth and Gforth inherited them;
they are word headers which contains the xt instead of being followed by the
code field. bar1, bar2, and bar3 don't have xts of their own.

In Gforth git-head, with its monotoken system, technically every word
(including an alias) has such a monotoken, but the token of an alias can
only be passed to name>int or name>comp, you can't EXECUTE it. Therefore,
it's not really an xt. However, it's not expensive to change it in a way
that this xt becomes executable (by adding a dodefer doer).

We had quite some Gforth-team-internal discussions over this toppic, and
some spilled even in to c.l.f, but the controversy is summed up by those two
possible systems:

System A has only xts as token, and there is a 1:1 relation between name and
xt (except that :noname definitions don't have a name). To access the
interpretation semantics of a name, you EXECUTE it. To access the
compilation semantics of a name, you check the immediate flag, and if that's
true, you EXECUTE it, otherwise you COMPILE, it. This system doesn't have,
according to Anton, Forth-94 standard-conforming words with special
compilation semantics like S" or TO.

System B has nts and xts as token, where there is a 1:1 relation between
name and nt (and :noname definitions don't have an nt). There are two
words, NAME>INT and NAME>COMP to convert a nt into xts. NAME>INT ( nt -- xt
) returns an executable token for the interpretation semantics, NAME>COMP (
nt -- xt1 xt2 ) returns xt1 for the compilation semantics and xt2 is either
' EXECUTE (for immediate words) or ' COMPILE, (for non-immediate words).
There is no 1:1 relationship between xt and xt1 and the nts.

If you had a NAME>COMP on system A, it would be ( xt -- xt xt2 ), and xt2 is
just depending on the immediate flag, as above. NAME>INT would be a noop on
system A.

Bernd Paysan

unread,

Jul 30, 2013, 7:25:33 PM7/30/13

to

Stephen Pelc wrote:
> The VFX documentation is quite clear that WalkWordList and friends
> are VFX specific.

Yes. But at least they are documented to last, and the nfa (a non-opaque
type) is used in several words, like >NAME, .NAME, NAME> and such.

Stephen Pelc

unread,

Jul 31, 2013, 8:21:57 AM7/31/13

to

On Wed, 31 Jul 2013 01:10:55 +0200, Bernd Paysan <bernd....@gmx.de>
wrote:

>We had quite some Gforth-team-internal discussions over this toppic, and
>some spilled even in to c.l.f, but the controversy is summed up by those two
>possible systems:
>
>System A has only xts as token, and there is a 1:1 relation between name and
>xt (except that :noname definitions don't have a name). To access the
>interpretation semantics of a name, you EXECUTE it. To access the
>compilation semantics of a name, you check the immediate flag, and if that's
>true, you EXECUTE it, otherwise you COMPILE, it. This system doesn't have,
>according to Anton, Forth-94 standard-conforming words with special
>compilation semantics like S" or TO.

VFX corresponds to a system A. S" and TO are not immediate, but have
special compilation semantics. IMMEDIATE and friends are not necessary
for VFX, but are provided to improve standards compliance and reduce
surprises.

Anton has not yet complained that the VFX implementations of S" and TO
are non-compliant.

>System B has nts and xts as token, where there is a 1:1 relation between
>name and nt (and :noname definitions don't have an nt). There are two
>words, NAME>INT and NAME>COMP to convert a nt into xts. NAME>INT ( nt -- xt
>) returns an executable token for the interpretation semantics, NAME>COMP (
>nt -- xt1 xt2 ) returns xt1 for the compilation semantics and xt2 is either
>' EXECUTE (for immediate words) or ' COMPILE, (for non-immediate words).
>There is no 1:1 relationship between xt and xt1 and the nts.
>
>If you had a NAME>COMP on system A, it would be ( xt -- xt xt2 ), and xt2 is
>just depending on the immediate flag, as above. NAME>INT would be a noop on
>system A.

IMHO System Bs' NAME>COMP words require mandating xt2's stack effect
and impinge on implementation strategy. For example, all VFX's
compilation words have the stack effect
xt --
so that the same compiler can be used for all children of VARIABLE.

Other systens use other mechanisms. Forcing a system to expose an
xt2 so close to implementation mechanisms is not a good idea in my
opinion.

Historically, System As have arisen because XTs can be the address
of the routine to EXECUTE. Finding names from xts is usually needed
for human-scale times rather than computer-scale times, so the
performance issues in XT>NAME ( xt -- nt ) are of secondary
importance. Since the worst case cost of a System A over a
system B appears to be a single link, a system can implement
nts as the meaning of an xt with EXECUTE becoming
: EXECUTE ( xt/nt -- ) <lit> - @ call ;
The overhead of
<lit> - @
on desktop CPUs is one instruction and one link. Am I bothered?

I can still see no technical need for anything other than a
single token for each word. I appreciate that some systems
may require changes to be compliant. Requiring additional
tokens and xts is opening cans of worms that will inhibit
new implementation strategies and lead to error.

Anton Ertl

unread,

Jul 31, 2013, 10:34:28 AM7/31/13

to

steph...@mpeforth.com (Stephen Pelc) writes:
>Anton has not yet complained that the VFX implementations of S" and TO
>are non-compliant.

QA of VFX is not my job. But since you ask for it, here's a free sample:

: int1-s" \ interpretation semantics of S"
['] s" execute ;

: [compile,]
compile, ; immediate

: int2-s" \ interpretation semantics of S", another way
[ ' s" ] [compile,] ;

Now if I do

int1-s" foo" type cr

I get

Err# -13 ERR: Undefined word.
-> int1-s" foo" type cr
^

the first time I try it on vfxlin 4.60, but when I do it again, it
works as expected:

int1-s" foo" type cr foo

But

int2-s" bar" type cr

does repeatedly not work as expected:

int2-s" bar" type cr
Err# -13 ERR: Undefined word.
-> int2-s" bar" type cr
^

I also tried it on Gforth 0.7.0 and SwiftForth i386-Linux 3.4.4
31-Jul-2012 and bigforth 2.3.1, and on all of them INT1-S" and INT2-S"
work as expected for the inputs

int1-s" foo" type cr
int2-s" bar" type cr

>IMHO System Bs' NAME>COMP words require mandating xt2's stack effect
>and impinge on implementation strategy.

You want to require systems implementors to abandon their
implementation strategy in favour of yours, without giving any
technical arguments, and you dare criticize NAME>COMP as "impinge on
implementation strategy".

> For example, all VFX's
>compilation words have the stack effect
> xt --
>so that the same compiler can be used for all children of VARIABLE.

It's trivial to implement NAME>COMP in VFX:

: NAME>COMP ['] compile, ;

"Impinge on implementation strategy". Don't be ridiculous!

>Other systens use other mechanisms. Forcing a system to expose an
>xt2 so close to implementation mechanisms is not a good idea in my
>opinion.

xt2 is an abstraction and generalization of the flag returned by FIND.
If NAME>COMP impinges on implementation strategy, FIND does even more
so.

>I can still see no technical need for anything other than a
>single token for each word. I appreciate that some systems
>may require changes to be compliant.

Compliant with what? In any case, the changes you suggest would really
impinge on the implementation strategy.

> Requiring additional
>tokens and xts is opening cans of worms that will inhibit
>new implementation strategies and lead to error.

There is no requirement for additional tokens in Alex McDonald's
proposal. In this proposal you are free to implement the nt as xt; in
addition, the proposal allows implementations to continue to have
separate name tokens. Since it allows more implementation strategies
than the requirement you favour, the existing proposal does not
inhibit new implementation strategies.

Concerning your claim that it will lead to error, please provide
evidence for this claim. We have had separate nts for a long time,
and I don't remember any errors that would have been prevented by
using the xt as nt. Actually there were not many errors in this area
anyway.

Andrew Haley

unread,

Jul 31, 2013, 12:54:56 PM7/31/13

to

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> steph...@mpeforth.com (Stephen Pelc) writes:
>

>>I can still see no technical need for anything other than a
>>single token for each word. I appreciate that some systems
>>may require changes to be compliant.
>
> Compliant with what?

unread,

Aug 1, 2013, 8:08:34 AM8/1/13

to

alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2013Jul3...@mips.complang.tuwien.ac.at>,
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>alb...@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>>You might have a look at yourforth and ask yourself why we need
>>>complicated models, if we allow for an optimiser to run on the
>>>really time critical programs afterwards. I've long advocated that
>>>a simple model with good introspective possibilities can have an
>>>optimiser that beats everything else.
>>
>>I am a bit mystified as to how this ties in with "xt as a single point
>>of reference".
>
>In yourforth (or must I say the ciforth model) an xt is a dea, which
>is the address of a uniform header with 5 fields. So there is much
>an optimiser can rely on that is always true.

Give an example of an optimization enabled by that.

>>Anyway, your belief in optimizers seems naive to me. What we get from
>>"really good optimizers" is code that does not behave as intended (aka
>>"miscompiled code").
>
>I don't share your distrust in optimizers.
>Remember the naive c-code for gcd's that was near-optimally compiled
>with `` gcc -O3 ''. I studied the resulting assembler code in detail.
>I suspect that gforth relied on some unguaranteed aspects of the
>c-compiler, and maybe extensions that were not fully specified.
>Exactly the opposite of a simple model with good introspective
>possibilities.

Well, for Gforth I don't get miscompilation, I only get code that is
typically slower by a factor of 2 from the "really good optimizers" of
recent gccs, compared to the pretty good optimizer of gcc-2.x.

The miscompilation happens to other code (e.g., to one of the SPEC
benchmarks). And yes, the excuse of the gcc maintainers is that the
miscompiled code is non-standard.

Concerning the "simple model with good introspective possibilities", C
as interpreted by the gcc maintainers is the opposite of that. There
are IIRC >180 "undefined behaviour"s in the C standard; it's a
minefield, and I think most real-world C programs contain undefined
behaviour in a number of places. It's everthing but simple.
Concerning introspective possibilities, C has none.

>Take for instance the intermediate code of Python. Why would there
>be miscompilation for such code by optimizers?

It's unclear what scenario you have in mind. Anyway, Python is hard
to optimize, among other things because of its introspective
possibilities.

>Forth's intermediate code
>would be even simpler, especially if we leave out all the silly
>micro optimisation (Oh no, DEFER can't be a regular CREATE-DOES> word,
>much too slow etc. Let's make it a code word. Let's try to do some
>reaeaeaeally neat assembler tricks. )
>The hardest to handle of these micro optimisations is having different
>code for compilation and execution, such as a compiling `` + '' that
>looks whether the previous instruction is a constant etc.

It's unclear what you are claiming here. Do you think that a DEFER
implemented with CREATE...DOES> can be optimized better?

In any case, I would be interested to see a concrete example of what
you actually mean.

Stephen Pelc

unread,

Aug 1, 2013, 9:02:26 AM8/1/13

to

On Thu, 01 Aug 2013 14:49:20 +0200, Bernd Paysan <bernd....@gmx.de>
wrote:

>IMHO, the fix is to fix the specification of COMPILE, to allow it to perform
>compilation semantics (at least of non-immediate words; appending execution
>semantics of immediate words would be backward compatible); Anton thinks
>COMPILE, is fine as it is; but to access compilation semantics in a portable
>way then requires to define COMP'
>
>: comp' ( "name" -- w xt )
> bl word state @ 0= IF ] find postpone [ ELSE find THEN
> dup 0= -13 and throw
> 0< IF ['] compile, ELSE ['] execute THEN ;

You may well be right. However, we need to revisit IMMEDIATE as well.
I'm not sure that it has any point any more. It seems to be a hangover
from way back when. All it says is that the compilation behaviour is
the same as the interpretation behaviour.

Let's save this for the meeting.

Anton Ertl

unread,

Aug 1, 2013, 9:02:49 AM8/1/13

to

Bernd Paysan <bernd....@gmx.de> writes:
>Stephen Pelc wrote:
>
>> On Wed, 31 Jul 2013 14:34:28 GMT, an...@mips.complang.tuwien.ac.at
>> (Anton Ertl) wrote:
>>>: [compile,]
>>> compile, ; immediate
>>>
>>>: int2-s" \ interpretation semantics of S", another way
>>> [ ' s" ] [compile,] ;

...

>The problem is rather the definition of COMPILE, which appends the execution
>semantics of the xt;

The problem is actually in the implementation of COMPILE, in VFX,
which does not append the execution semantics represented by xt. The
definition of COMPILE, is fine, and every other Forth (gforth
SwiftForth bigForth) that I have tried implements COMPILE, correctly.

Andrew Haley

unread,

Aug 1, 2013, 9:20:56 AM8/1/13

to

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>
> The miscompilation happens to other code (e.g., to one of the SPEC
> benchmarks). And yes, the excuse of the gcc maintainers is that the
> miscompiled code is non-standard.

Actually, no. It was very briefly true, but it got fixed. The SPEC
developers argued that it was, although non-standard, a pretty common
idiom, and the GCC maintainer decided that the optimization in
question wasn't worth having anyway.

Andrew.

Anton Ertl

unread,

Aug 1, 2013, 9:07:36 AM8/1/13

to

steph...@mpeforth.com (Stephen Pelc) writes:
>On Tue, 30 Jul 2013 12:09:28 GMT, an...@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>>>: noname ." bar" ;
>>>>dup alias bar1
>>>>dup alias bar2
>>>> alias bar3
>>>
>>>I understand, but the point is about words with names.
>>
>>There are three names here, all for the same xt. Which one should the
>>system get back to and why?
>
>The only word that has a known xt is the :NONAME one. The standard
>says *nothing* about the xt of a synonym. What is ALIAS ? However,
>I would expect bar1, bar2 and bar3 to have their own xts in most
>implementations.

Why should there be several xts? There's only one piece of code that
can be EXECUTEd or COMPILE,d, so only one xt is needed. There is
certainly only one xt involved here in Gforth-0.7.0:

:noname ." bar" ; ok
dup alias bar1 ok
dup alias bar2 ok
alias bar3 redefined bar3 ok
ok
' bar1 . 140737331348320 ok
' bar2 . 140737331348320 ok
' bar3 . 140737331348320 ok

So here you have three names for one xt, and in other cases you have 0
names for one xt.

>>Interesting. What if I code this as
>>
>>:noname ... ; \ interpretation semantics
>>:noname ... ; \ compilation semantics
>>interpret/compile: s"
>
>There are still xts, but this time no head. And ... your question
>is?

The point is that in Gforth-0.7.0 there can be several names or zero
for the same xt and each name can be connected with two xts. Using
the xt to identify the name won't cut it.

>There are always perverse implementation techniques. And usually
>you bleed for using them.

Yes, for example you get a system where COMPILE, does not behave
correctly.

>>|There is no 1:1 correspondence between names and xts.
>
>: foo cr ." hello" ;
>
>You are not seriously suggesting that there is not a 1:1
>correspondence between the name "foo" and the xt of "foo".
>Or are you?

No. So what? A Forth implementation strategy must work for more than
just the FOO word above.

unread,

Aug 2, 2013, 3:56:00 AM8/2/13

to

On Friday, August 2, 2013 1:04:00 AM UTC+2, Coos Haak wrote:
>> Op Thu, 01 Aug 2013 21:41:06 +0100 schreef Gerry Jackson:

[..]

>> It shouldn't surprise you that they don't work, the Forth 200X committee
>> made ' TO and ['] TO ambiguous conditions.

[..]

> I think that this proves that these _do_ work in vfxlin.

Is this a play with words (it works because it is not required to
work), or does the example indeed work in vfxlin? In that case I don't
understand why Anton gave the example (unless he wanted to point out
an consistency in Vfx).

-marcel

BTW, both of Anton's examples wrok in iForth 4.

Andrew Haley

unread,

Aug 2, 2013, 3:59:23 AM8/2/13

to

Bernd Paysan <bernd....@gmx.de> wrote:
>
> If you are on a byte-addressed 32 or 64 bit little or big endian
> two's complement machine, all these things are *well-defined*. What
> happens on an overflow is well defined. What happens when you use a
> byte as index into an array and the byte overflows is well defined.
> Tighten up your specification chain, there is this relation
>
> C standard -implemented by-> compiler -generate code for-> particular
> machine
>
> Each of the arrows tighten up the specs.

And removes optimization opportunities. Given that all these things
that are "broken" by optimizations are bugs, I'd rather have the
optimization. But that's just me, and that's why GCC has switches.

Andrew.

Anton Ertl

unread,

Aug 2, 2013, 9:12:25 AM8/2/13

to

Yes. Various claimed-to-be-ANS-Forth implementations exhibit
non-compliant behaviour in connection with ticking TO. As this
example shows, vfxlin is one of them.

Given the relative frequency of non-compliant (with ANS Forth)
behaviour in systems, and the rarity of ticking TO in existing
programs, I suggested to destandardize ticking TO (while we were at
rewording TO).

Anyway, I think that VFX claims to comply with ANS Forth (Forth-94),
and ' TO is standard in ANS Forth.

Anton Ertl

unread,

Aug 2, 2013, 9:32:11 AM8/2/13

to

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>Given that all these things
>that are "broken" by optimizations are bugs, I'd rather have the
>optimization. But that's just me, and that's why GCC has switches.

GCC usually miscompiles programs by default, and when it first breaks
them, it usually has no switches for disabling the miscompilation.

If the user invoked gcc with gcc -O -ansi -pedantic, then miscompiling
non-standard programs would be ok, but as a default it's an extremely
bad idea. And gcc does not have a -Osane option for only enabling the
sane optimizations (those that were present in gcc-2.x; you may also
call the option -Ogcc-2.x).

Andrew Haley

unread,

Aug 2, 2013, 10:15:05 AM8/2/13

to

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>Given that all these things
>>that are "broken" by optimizations are bugs, I'd rather have the
>>optimization. But that's just me, and that's why GCC has switches.
>
> GCC usually miscompiles programs by default, and when it first breaks
> them, it usually has no switches for disabling the miscompilation.

No it doesn't.

> If the user invoked gcc with gcc -O -ansi -pedantic, then miscompiling
> non-standard programs would be ok, but as a default it's an extremely
> bad idea.

I agree.

Andrew.

Anton Ertl

unread,

Aug 2, 2013, 11:17:29 AM8/2/13

to

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>>Given that all these things
>>>that are "broken" by optimizations are bugs, I'd rather have the
>>>optimization. But that's just me, and that's why GCC has switches.
>>
>> GCC usually miscompiles programs by default, and when it first breaks
>> them, it usually has no switches for disabling the miscompilation.
>
>No it doesn't.

Yes it does (I can answer Haley-style, too).

Andrew Haley

unread,

Aug 2, 2013, 12:28:21 PM8/2/13

to

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>>>Given that all these things
>>>>that are "broken" by optimizations are bugs, I'd rather have the
>>>>optimization. But that's just me, and that's why GCC has switches.
>>>
>>> GCC usually miscompiles programs by default, and when it first breaks
>>> them, it usually has no switches for disabling the miscompilation.
>>
>>No it doesn't.
>
> Yes it does (I can answer Haley-style, too).

No it doesn't. (Looky here, I can also come up with unsupported
assertions, Ertl-style.)

Andrew.

Paul Rubin

unread,

Aug 2, 2013, 1:18:21 PM8/2/13

to

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> And removes optimization opportunities. Given that all these things
> that are "broken" by optimizations are bugs, I'd rather have the
> optimization. But that's just me, and that's why GCC has switches.

You guys might like this paper, about a tool that identifies places in C
programs likely to see unexpected behavior in cases of aggressive
optimizations permitted by the C standard:

http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf

IMHO the problems here really are with C itself.

Alex McDonald

unread,

Aug 2, 2013, 1:17:39 PM8/2/13

to

Pantomime time? Which one of you is the dame?

unread,

Aug 3, 2013, 3:00:00 AM8/3/13

to

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> IMHO the problems here really are with C itself.
> I guess so, although even in Java, which goes much further towards
> making everything well-defined ("write once, run anywhere") there are
> still quite a few instances of unpredictable behaviour.

I wonder if Ada is better about that. I've been interested in it for a
while but have never tried it. It's a closer fit than Java for the
embedded realtime stuff where Forth also operates.

> My view is that most of these areas of C are not really problems in
> the language: they're an example of a well-designed programming
> language that defines what it can, doesn't require implementers to do
> things that would be needlessly difficult, and gives plenty of room
> for optimization.

But this is bad design of the "worse is better" variety. I do remember
some things in Ada are bloody hard to implement, so Ada compiler
implementers just had to bite the bullet, but it made the specification
very solid. More generally, programming languages are human user
interfaces to a computer, so if using one is error-prone, it is designed
badly.

> (I'm sure Forth has plenty of similar lacunae but we've mostly been
> spared from aggressive optimizers.)

Paul Bennett has also spoken of how Forth's semantics are also more
precisely defined than C's, although hmm, part of that involves digging
into the specific implementation in use.

> My quarrel with Anton is that he will not accept that this is a
> legitimate point of view.

I guess Forth is kind of socially defined, rather than legalistically by
the standard, and this works because of the relatively small user
community. C isn't like that, apparently.

unread,

Aug 4, 2013, 4:27:33 AM8/4/13

to

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> I'm thinking that sane languages for large-scale development should
>> 1) follow the principle of least surprise, and 2) have extensive
>> error detection and diagnostics at compile and run time.

> Java, in other words!

Hmm maybe. I've found Java pretty painful though.

> The Linux kernel is one of the core parts of an operating system,
> surely.

It's much more than that. I think it's around 10x the size of the Xen
hypervisor, which can run applications directly:

http://wiki.xen.org/wiki/Xen_Development_Projects#Towards_a_multi-language_unikernel_substrate_for_Xen

So I wonder whether we really need Linux.

> A kernel needs real control over memory allocation, needs to be able
> to lay out structures in memory in a precise way, needs to be able to
> pass around raw untyped pointers, and so on.

I doubt more than 10% of the code in Linux really needs those
capabilities. I wonder how Ada deals with this sort of issue.

> "higher-level" langauges than C and Forth stop you from doing.

Well there is C++, though some say the cure is worse than the
disease. :-)

>>> Think about programming languages as tools. C is a chainsaw.
>> More like a gun that shoots forwards and backwards at the same time ;-).
> I don't think that's fair. Even with a winking smiley!

Heh, I'm pretty terrified of C these days. Paper after paper comes out
like the one I mentioned, where someone develops a bug-finding tool,
runs it over a big FOSS code base, and sure enough hundreds of nasty
bugs fall out. These get reported and fixed, but there are always
plenty left for the next tool to find. Now consider that besides
academic researchers publishing those papers, there are also NSA types
with even bigger budgets, developing comparable tools in secret and
stockpiling zero-day exploits. The people who wrote that code were not
fools, yet those errors keep occurring, many of which wouldn't happen in
other languages. So I think current systems use entirely too much C.

http://www.crash-safe.org/ might be what we really ought to be doing.
It involved tagged hardware, which might be more economically feasible
now than it was in the Lisp machine era.

Andrew Haley

unread,

Aug 4, 2013, 4:29:56 AM8/4/13

to

Paul Rubin <no.e...@nospam.invalid> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>> I'm thinking that sane languages for large-scale development should
>>> 1) follow the principle of least surprise, and 2) have extensive
>>> error detection and diagnostics at compile and run time.
>> Java, in other words!
>
> Hmm maybe. I've found Java pretty painful though.
>
>> The Linux kernel is one of the core parts of an operating system,
>> surely.
>
> It's much more than that. I think it's around 10x the size of the Xen
> hypervisor, which can run applications directly:

Sure, but if you are to be able to pass data around in the form the
kernel wants it, a bondage & discipline language isn't going to do it.
There is a good argument for making the kernel much smaller.

>> A kernel needs real control over memory allocation, needs to be able
>> to lay out structures in memory in a precise way, needs to be able to
>> pass around raw untyped pointers, and so on.
>
> I doubt more than 10% of the code in Linux really needs those
> capabilities.

Really? Surely all components of the kernel have to be able to handle
the kernel data structures.

>>>> Think about programming languages as tools. C is a chainsaw.
>>> More like a gun that shoots forwards and backwards at the same time ;-).
>> I don't think that's fair. Even with a winking smiley!
>
> Heh, I'm pretty terrified of C these days. Paper after paper comes
> out like the one I mentioned, where someone develops a bug-finding
> tool, runs it over a big FOSS code base, and sure enough hundreds of
> nasty bugs fall out. These get reported and fixed, but there are
> always plenty left for the next tool to find. Now consider that
> besides academic researchers publishing those papers, there are also
> NSA types with even bigger budgets, developing comparable tools in
> secret and stockpiling zero-day exploits. The people who wrote that
> code were not fools, yet those errors keep occurring, many of which
> wouldn't happen in other languages.

We-ell, kinda sorta. The recent security bugs with which I'm familiar
haven't been of that kind. I'd like to see some evidence that
successful security exploits are more common against the Linux kernel
written in C than a comparable lump of other code written in something
else.

> So I think current systems use entirely too much C.

Quite possibly.

> http://www.crash-safe.org/ might be what we really ought to be
> doing. It involved tagged hardware, which might be more
> economically feasible now than it was in the Lisp machine era.

Reinventing the B6700, then.

Andrew.

Bill Richards

unread,

Aug 4, 2013, 7:43:12 AM8/4/13

to

On 2013-08-04, Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
> Paul Rubin <no.e...@nospam.invalid> wrote:
>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>
>> I'm thinking that sane languages for large-scale development should
>> 1) follow the principle of least surprise, and 2) have extensive
>> error detection and diagnostics at compile and run time. C's
>> pointer semantics even prevent it from checking for subscript
>> errors, thus the decades of buffer overflow bugs we've seen in it.
>
> Java, in other words!

Not even close! Think Ada. Other good choices would be languages that don't
use null terminated strings. Counted strings prevent most or all buffer
overflows. Let the compiler do the work. PL/M and variants have been used
successfully to write operating systems. PL/I style language implementations
usually support subscript checking at runtime, etc.

>>> C isn't really a general-purpose programming language: its
>>> properties are useful in the area for which it was designed, viz. a
>>> low-overhead language that can be used instead of assembler for
>>> writing the core parts of an operating system.

Not true of all platforms but close enough given all the world's Intel x86
as far as you know. I'd rather choose the best tools for the job (and that's
never C) than a mediocre tool that can do it all, sortof, more or less
(that's C).

>>
>> This would seem to say it's being misused badly in the real world,
>> since large systems are written in it, like the Linux kernel.

Very true indeed.

> Ah. As Churchill put it, "it has been said that democracy is the
> worst form of Government except all those other forms that have been
> tried from time to time."

I don't agree. Several choices have been tried and did indeed work
better. There is a certain dogma that leads to myopia in anything
UNIX-related and you'll be shouted down if you propose something
better. Because Dennis Ritchie didn't use it, it can't be good.

>
>>> Think about programming languages as tools. C is a chainsaw.

There's no need to be insulting, said the Chainsaw Manufacturers' United...

C is a minefield. There's no reason it had to be this way except as a
surrogate religion. It was good enough for who it was for. It continues in
use in the face of much better alternatives but for the sheer mass of existing
systems and their old crusty interfaces and people who refuse to demand
better. Probably no language has so much baggage as C, and C is far from the
first language still in use. If portability is your goal, C helps, but so
does Ada because it's so rigidly standardized. For other use it really would
have been smarter to either pick a systems programming language (assembly)
for the systems programming parts and a DSL for the rest.

Bill

Andrew Haley

unread,

Aug 4, 2013, 8:13:46 AM8/4/13

to

Bill Richards <bill...@gmx.com> wrote:
> On 2013-08-04, Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>> Paul Rubin <no.e...@nospam.invalid> wrote:
>>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>
>>> I'm thinking that sane languages for large-scale development should
>>> 1) follow the principle of least surprise, and 2) have extensive
>>> error detection and diagnostics at compile and run time. C's
>>> pointer semantics even prevent it from checking for subscript
>>> errors, thus the decades of buffer overflow bugs we've seen in it.
>>
>> Java, in other words!
>
> Not even close!

Which parts of this description does Java not fit?

>>>> C isn't really a general-purpose programming language: its
>>>> properties are useful in the area for which it was designed, viz. a
>>>> low-overhead language that can be used instead of assembler for
>>>> writing the core parts of an operating system.
>
> Not true of all platforms but close enough given all the world's
> Intel x86 as far as you know.

What have all the world's Intel x86es to do with any of this? Of
course, C is not used on every platform, but no-one said it was.

>> Ah. As Churchill put it, "it has been said that democracy is the
>> worst form of Government except all those other forms that have been
>> tried from time to time."
>
> I don't agree. Several choices have been tried and did indeed work
> better.

And where are they now?

>>>> Think about programming languages as tools. C is a chainsaw.
>
> There's no need to be insulting, said the Chainsaw Manufacturers' United...
>
> C is a minefield. There's no reason it had to be this way except as
> a surrogate religion. It was good enough for who it was for. It
> continues in use in the face of much better alternatives

And that's the point: it's good enough, and it's a lingua franca. The
Lingua franca itself was by all accounts a terrible language: it had
only one tense, for starters. But it was good enough, and it allowed
people to communicate.

> but for the sheer mass of existing systems and their old crusty
> interfaces and people who refuse to demand better.

Well, damn the people for wanting to use their existing systems.

> Probably no language has so much baggage as C, and C is far from the
> first language still in use. If portability is your goal, C helps,
> but so does Ada because it's so rigidly standardized. For other use
> it really would have been smarter to either pick a systems
> programming language (assembly) for the systems programming parts
> and a DSL for the rest.

That strikes me as a spectacularly awful idea. I wonder how long it
would take to port Linux to a new platfrom if that advice had been
followed.

Andrew.

Bill Richards

unread,

Aug 4, 2013, 9:25:14 AM8/4/13

to

On 2013-08-04, Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
> Bill Richards <bill...@gmx.com> wrote:
>> On 2013-08-04, Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>>> Paul Rubin <no.e...@nospam.invalid> wrote:
>>>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>>
>>>> I'm thinking that sane languages for large-scale development should
>>>> 1) follow the principle of least surprise, and 2) have extensive
>>>> error detection and diagnostics at compile and run time. C's
>>>> pointer semantics even prevent it from checking for subscript
>>>> errors, thus the decades of buffer overflow bugs we've seen in it.
>>>
>>> Java, in other words!
>>
>> Not even close!
>
> Which parts of this description does Java not fit?

It doesn't fit your #2 and it doesn't fit #1 in many ways as well. This is
clearly relative. Compared to C Java is much better in those areas but Ada
is much better yet than Java. You would really have to take a survey of
languages designed with safety in mind not that there are so many and then
you would agree Ada fits the requirements quite well generally, not just
compared to C. And Ada runs on bare metal and the JVM which is quite an
advantage over Java for writing an OS and many applications.

>
>>>>> C isn't really a general-purpose programming language: its
>>>>> properties are useful in the area for which it was designed, viz. a
>>>>> low-overhead language that can be used instead of assembler for
>>>>> writing the core parts of an operating system.
>>
>> Not true of all platforms but close enough given all the world's
>> Intel x86 as far as you know.
>
> What have all the world's Intel x86es to do with any of this? Of
> course, C is not used on every platform, but no-one said it was.

Right but platforms that don't use C as the OS language aren't suited to C
for systems programming. There aren't many of those but there are
some. OpenVMS is the first that comes to mind.

>
>>> Ah. As Churchill put it, "it has been said that democracy is the
>>> worst form of Government except all those other forms that have been
>>> tried from time to time."
>>
>> I don't agree. Several choices have been tried and did indeed work
>> better.
>
> And where are they now?

Still in service working right along. If you're going to hide behind
popularity contests than you're right back where you started. If you choose
to open your eyes you'll see there are good choices that don't have anything
to do with C or UNIX such as I mentioned. I'm not talking about obsolete
languages or relics but languages that are still in used today for writing
new software. You'll need to pull your head out of the All The World R
Belong 2 Linux hole if you're to find any solutions to the issue here.

>
>>>>> Think about programming languages as tools. C is a chainsaw.
>>
>> There's no need to be insulting, said the Chainsaw Manufacturers' United...
>>
>> C is a minefield. There's no reason it had to be this way except as
>> a surrogate religion. It was good enough for who it was for. It
>> continues in use in the face of much better alternatives
>
> And that's the point: it's good enough, and it's a lingua franca. The
> Lingua franca itself was by all accounts a terrible language: it had
> only one tense, for starters. But it was good enough, and it allowed
> people to communicate.

I don't agree, it's not really good enough. What we got from "good enough"
is a bunch of portable OS, all performing mediocrely on cheap hardware and
all more or less the same. And we got legions of buffer overflows, stack
smashing, subscripts out of range, race conditions, etc. The exploits and
bugs get more numerous with every release and every new application written
in C. UNIX and Linux have all but killed innovation to the point people like
you argue from the viewpoing that nothing else is acceptable and UNIX is
really ok after all. Really it isn't ok. That's what we're saying.

>
>> but for the sheer mass of existing systems and their old crusty
>> interfaces and people who refuse to demand better.
>
> Well, damn the people for wanting to use their existing systems.

They're damning themselves that they'll have no future systems and they're
dealing with various issues today from yesterday's shortsightedness and
wanting to use their existing systems instead of demanding better tools to
write a better OS with. It's rather circular. To escape requires an open
mind and real desire. Else tomorrow will be the same as today, Linux running
halfheartedly on yet another cheap platform. How dreary and bland!

>
>> Probably no language has so much baggage as C, and C is far from the
>> first language still in use. If portability is your goal, C helps,
>> but so does Ada because it's so rigidly standardized. For other use
>> it really would have been smarter to either pick a systems
>> programming language (assembly) for the systems programming parts
>> and a DSL for the rest.
>
> That strikes me as a spectacularly awful idea. I wonder how long it
> would take to port Linux to a new platfrom if that advice had been
> followed.

Portability often gets in the way and is used an excuse not to adopt better
technologies. If your primary goal is portability then you'll never have the
best of anything. By necessity you'll choose inferior but more portable
things. C and UNIX are the best examples of that. Would you rather have the
best OS and languages to choose from that only run on one platform or would
you prefer to have UNIX and C running on everything. IMHO we don't need
Linux running all the places it already is and it hasn't improved the world
at all. If you want better performance and a better development environment
it's sensible to develop hardware and software to work together instead of
the Linux one sits fits all, sortof approach.

Bill

Andrew Haley

unread,

Aug 4, 2013, 11:20:23 AM8/4/13

to

Bill Richards <bill...@gmx.com> wrote:
> On 2013-08-04, Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>> Bill Richards <bill...@gmx.com> wrote:
>>> On 2013-08-04, Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>>>> Paul Rubin <no.e...@nospam.invalid> wrote:
>>>>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>>>
>>>>> I'm thinking that sane languages for large-scale development should
>>>>> 1) follow the principle of least surprise, and 2) have extensive
>>>>> error detection and diagnostics at compile and run time. C's
>>>>> pointer semantics even prevent it from checking for subscript
>>>>> errors, thus the decades of buffer overflow bugs we've seen in it.
>>>>
>>>> Java, in other words!
>>>
>>> Not even close!
>>
>> Which parts of this description does Java not fit?
>
> It doesn't fit your #2 and it doesn't fit #1 in many ways as
> well.

Clearly 1) is a matter of opinion, but in what way does it not fit 2) ?

>>>> Ah. As Churchill put it, "it has been said that democracy is the
>>>> worst form of Government except all those other forms that have been
>>>> tried from time to time."
>>>
>>> I don't agree. Several choices have been tried and did indeed work
>>> better.
>>
>> And where are they now?
>
> Still in service working right along. If you're going to hide behind
> popularity contests than you're right back where you started. If you
> choose to open your eyes you'll see there are good choices that
> don't have anything to do with C or UNIX such as I mentioned.

I'm not going to hide behind anything. I have never asserted anything
beyond the claim that C is good enough, and that most of the example
languages that are touted from time to time aren't.

> I'm not talking about obsolete languages or relics but languages
> that are still in used today for writing new software. You'll need
> to pull your head out of the All The World R Belong 2 Linux hole if
> you're to find any solutions to the issue here.

And if you can refrain from childish insults we might have a
conversation. Will you do so? Are you capable of doing so? We'll
see.

>> And that's the point: it's good enough, and it's a lingua franca. The
>> Lingua franca itself was by all accounts a terrible language: it had
>> only one tense, for starters. But it was good enough, and it allowed
>> people to communicate.
>
> I don't agree, it's not really good enough. What we got from "good
> enough" is a bunch of portable OS, all performing mediocrely on
> cheap hardware and all more or less the same. And we got legions of
> buffer overflows, stack smashing, subscripts out of range, race
> conditions, etc. The exploits and bugs get more numerous with every
> release and every new application written in C. UNIX and Linux have
> all but killed innovation to the point people like you argue from
> the viewpoing that nothing else is acceptable and UNIX is really ok
> after all. Really it isn't ok. That's what we're saying.

OK, I accept that's your opinion. But UNIX, them GNU & Linux have
provided many millions of people with useful and cheap computer
systems, whereas the pie-in-the-sky critics have provided them with
nothing beyond pious words.

>>> Probably no language has so much baggage as C, and C is far from the
>>> first language still in use. If portability is your goal, C helps,
>>> but so does Ada because it's so rigidly standardized. For other use
>>> it really would have been smarter to either pick a systems
>>> programming language (assembly) for the systems programming parts
>>> and a DSL for the rest.
>>
>> That strikes me as a spectacularly awful idea. I wonder how long it
>> would take to port Linux to a new platfrom if that advice had been
>> followed.
>
> Portability often gets in the way and is used an excuse not to adopt
> better technologies. If your primary goal is portability then you'll
> never have the best of anything.

No, cost is the primary goal here. An engineer is a man who can do
for ten shillings what any fool can do for a pound.

For example, UNIX was chosen as the base design for GNU because its
design was already proven and portable, and because compatibility made
it easy for UNIX users to switch from UNIX to GNU. If some other base
had been chosen, IMO it probably would not have been successful.

> By necessity you'll choose inferior but more portable things. C and
> UNIX are the best examples of that. Would you rather have the best
> OS and languages to choose from that only run on one platform or
> would you prefer to have UNIX and C running on everything. IMHO we
> don't need Linux running all the places it already is and it hasn't
> improved the world at all.

It has, and demonstrably so. Without it we'd all be running ... I
don't know. Windows? VMS? VSE? Multics?

> If you want better performance and a better development environment
> it's sensible to develop hardware and software to work together
> instead of the Linux one sits fits all, sortof approach.

OK. Let us know how you get on.

Andrew.

Bill Richards

unread,

Aug 4, 2013, 12:09:24 PM8/4/13

to

On 2013-08-04, Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
> Bill Richards <bill...@gmx.com> wrote:
>> On 2013-08-04, Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>>> Bill Richards <bill...@gmx.com> wrote:
>>>> On 2013-08-04, Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>>>>> Paul Rubin <no.e...@nospam.invalid> wrote:
>>>>>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>>>>
>>>>>> I'm thinking that sane languages for large-scale development should
>>>>>> 1) follow the principle of least surprise, and 2) have extensive
>>>>>> error detection and diagnostics at compile and run time. C's
>>>>>> pointer semantics even prevent it from checking for subscript
>>>>>> errors, thus the decades of buffer overflow bugs we've seen in it.
>>>>>
>>>>> Java, in other words!
>>>>
>>>> Not even close!
>>>
>>> Which parts of this description does Java not fit?

It fails your 1 and 2 as I said. Relative to C perhaps 2 is somewhat valid
but in the grand scheme of things Java is not there.

Java's syntax is crippled by the attempt to decrease the learning curve and
make it like C so it brings some of C's shortcomings and oddities along. It
doesn't have anywhere near the static checking support of Ada, and it
doesn't have nearly the runtime checks of Ada. Ada has a native threading
model that's sufficiently high level to mostly eliminate races. Frustratingly
most of the papers on comparisons are behind paywalls but I found a few
poorly written academic papers with otherwise useful content. If you look
around you can find some information. If you ask in comp.lang.ada I'm sure
they'll point you to some useful comparisons. Perhaps try using Ada for a
midsized project where you would have chosen Java and draw your own
conclusions. Ada's major downside is lack of library support but this is
because it's not very popular. If more people used it there would be more
library support. It's really a very nice language and doesn't require you to
think only OO or only procedural. You can mix and match as fits your problem
space. And it's a real language, not a gigantic scripting platform with
thousands of libraries.

>> I don't agree, it's not really good enough. What we got from "good
>> enough" is a bunch of portable OS, all performing mediocrely on
>> cheap hardware and all more or less the same. And we got legions of
>> buffer overflows, stack smashing, subscripts out of range, race
>> conditions, etc. The exploits and bugs get more numerous with every
>> release and every new application written in C. UNIX and Linux have
>> all but killed innovation to the point people like you argue from
>> the viewpoing that nothing else is acceptable and UNIX is really ok
>> after all. Really it isn't ok. That's what we're saying.
>
> OK, I accept that's your opinion. But UNIX, them GNU & Linux have
> provided many millions of people with useful and cheap computer
> systems, whereas the pie-in-the-sky critics have provided them with
> nothing beyond pious words.

It's true, "free" software has the advantage of being free as in beer
and most often worth price paid. That's what's allowed it to extinguish
almost everything in its path. Not because it's good. Cheap wins. Better
systems exist where people are willing to spend our money. It's not true
that nothing's been provided but it just hasn't been given away for nothing.
That's the myopic view I'm talking about. If you continue insisting only
UNIX and free as in beer software is on the table then you'll remain with
mediocre everything. Enjoy your buffer overflows.

>
>>>> Probably no language has so much baggage as C, and C is far from the
>>>> first language still in use. If portability is your goal, C helps,
>>>> but so does Ada because it's so rigidly standardized. For other use
>>>> it really would have been smarter to either pick a systems
>>>> programming language (assembly) for the systems programming parts
>>>> and a DSL for the rest.
>>>
>>> That strikes me as a spectacularly awful idea. I wonder how long it
>>> would take to port Linux to a new platfrom if that advice had been
>>> followed.
>>
>> Portability often gets in the way and is used an excuse not to adopt
>> better technologies. If your primary goal is portability then you'll
>> never have the best of anything.
>
> No, cost is the primary goal here. An engineer is a man who can do
> for ten shillings what any fool can do for a pound.

Indeed. But the UNIX and Linux guys can't do anything better than anyone
else except maybe Windows. UNIX and Linux break where other better systems
don't. If cost is your primary goal you'll eat whatever they serve you.
You're in no position to make judgements about what's better or worse
because you just said cost is the primary goal. Do you want something better
for nothing? I'll grant you Linux is on the list of the best software you
don't have to pay money for.

>
> For example, UNIX was chosen as the base design for GNU because its
> design was already proven and portable, and because compatibility made
> it easy for UNIX users to switch from UNIX to GNU. If some other base
> had been chosen, IMO it probably would not have been successful.
>
>> By necessity you'll choose inferior but more portable things. C and
>> UNIX are the best examples of that. Would you rather have the best
>> OS and languages to choose from that only run on one platform or
>> would you prefer to have UNIX and C running on everything. IMHO we
>> don't need Linux running all the places it already is and it hasn't
>> improved the world at all.
>
> It has, and demonstrably so. Without it we'd all be running ... I
> don't know. Windows? VMS? VSE? Multics?

You could be quite a bit worse off than running VMS and possibly
multics. Windows, we all agree on. Don't go there! VSE, never heard of
it. There are other proprietary systems in use. They're not free as in beer
so you've already disqualified them. Really not much left to discuss.

>
>> If you want better performance and a better development environment
>> it's sensible to develop hardware and software to work together
>> instead of the Linux one sits fits all, sortof approach.
>
> OK. Let us know how you get on.

We've been doing fine without UNIX or Linux and as long as they keep paying
us that will continue. If things get to the point nobody's willing to pay
for software I'll take up fishing again. I tie good flies and I am willing
to pay for good gear.

Bill

Andrew Haley

unread,

Aug 4, 2013, 12:55:13 PM8/4/13

to

Bill Richards <bill...@gmx.com> wrote:
> On 2013-08-04, Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>> Bill Richards <bill...@gmx.com> wrote:
>>> On 2013-08-04, Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>>>> Bill Richards <bill...@gmx.com> wrote:
>>>>> On 2013-08-04, Andrew Haley <andr...@littlepinkcloud.invalid> wrote:
>>>>>> Paul Rubin <no.e...@nospam.invalid> wrote:
>>>>>>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>>>>>
>>>>>>> I'm thinking that sane languages for large-scale development should
>>>>>>> 1) follow the principle of least surprise, and 2) have extensive
>>>>>>> error detection and diagnostics at compile and run time. C's
>>>>>>> pointer semantics even prevent it from checking for subscript
>>>>>>> errors, thus the decades of buffer overflow bugs we've seen in it.
>>>>>>
>>>>>> Java, in other words!
>>>>>
>>>>> Not even close!
>>>>
>>>> Which parts of this description does Java not fit?
>
> It fails your 1 and 2 as I said. Relative to C perhaps 2 is somewhat valid
> but in the grand scheme of things Java is not there.
>
> Java's syntax is crippled by the attempt to decrease the learning
> curve and make it like C so it brings some of C's shortcomings and
> oddities along. It doesn't have anywhere near the static checking
> support of Ada, and it doesn't have nearly the runtime checks of
> Ada.

Which ones?

> Ada has a native threading model that's sufficiently high level
> to mostly eliminate races. Frustratingly most of the papers on
> comparisons are behind paywalls but I found a few poorly written
> academic papers with otherwise useful content. If you look around
> you can find some information. If you ask in comp.lang.ada I'm sure
> they'll point you to some useful comparisons.

I'm sure they would: I've heard it said before that Ada's model is
superior for real-time systems, and I'm quite happy to believe that.
It's a bit old though, and there are more promising recent concurrency
models such as fork/join, which eliminates explicit threading
altogether. And, of course, software transactional memory.

>> OK, I accept that's your opinion. But UNIX, them GNU & Linux have
>> provided many millions of people with useful and cheap computer
>> systems, whereas the pie-in-the-sky critics have provided them with
>> nothing beyond pious words.
>
> It's true, "free" software has the advantage of being free as in
> beer and most often worth price paid. That's what's allowed it to
> extinguish almost everything in its path. Not because it's
> good. Cheap wins. Better systems exist where people are willing to
> spend our money. It's not true that nothing's been provided but it
> just hasn't been given away for nothing. That's the myopic view I'm
> talking about. If you continue insisting only UNIX and free as in
> beer software is on the table then you'll remain with mediocre
> everything. Enjoy your buffer overflows.

I'm not insisting on anything. I have not seen anything better than
GNU/Linux that delivers what people need, that's all.

>> No, cost is the primary goal here. An engineer is a man who can do
>> for ten shillings what any fool can do for a pound.
>
> Indeed. But the UNIX and Linux guys can't do anything better than
> anyone else except maybe Windows. UNIX and Linux break where other
> better systems don't. If cost is your primary goal you'll eat
> whatever they serve you.

No, my primary goal is to produce useful real software for people who
need it.

> You're in no position to make judgements about what's better or
> worse because you just said cost is the primary goal.

Of course it is, and it always will be, for everyone.

What matters is value for money. If you can produce something that
represents better value for only slightly more money, or something far
better for twice as much, then fine. But please forgive me for being
skeptical.

> Do you want something better for nothing? I'll grant you Linux is on
> the list of the best software you don't have to pay money for.

No, that's not what I want. I write free software. I will not
apologize for that: on the contrary, I am very proud of my role in it.
If I really thought that I could produce more useful things to benefit
the world in some other way, then I would.

>>> By necessity you'll choose inferior but more portable things. C and
>>> UNIX are the best examples of that. Would you rather have the best
>>> OS and languages to choose from that only run on one platform or
>>> would you prefer to have UNIX and C running on everything. IMHO we
>>> don't need Linux running all the places it already is and it hasn't
>>> improved the world at all.
>>
>> It has, and demonstrably so. Without it we'd all be running ... I
>> don't know. Windows? VMS? VSE? Multics?
>
> You could be quite a bit worse off than running VMS and possibly
> multics. Windows, we all agree on. Don't go there! VSE, never heard
> of it. There are other proprietary systems in use. They're not free
> as in beer so you've already disqualified them.

No, I haven't. I don't mind paying for things, and everything has a
cost, even free software. I don't see anything better right now, in
terms of delivering useful software for people at a fair price.

>>> If you want better performance and a better development
>>> environment it's sensible to develop hardware and software to work
>>> together instead of the Linux one sits fits all, sortof approach.
>>
>> OK. Let us know how you get on.
>
> We've been doing fine without UNIX or Linux and as long as they keep
> paying us that will continue. If things get to the point nobody's
> willing to pay for software I'll take up fishing again. I tie good
> flies and I am willing to pay for good gear.

So you have no intention of producing anything: you're just letting us
know how you would do it, in principle, if people wanted it, but they
don't, because they're misguided/ignorant/idiots. Darn.

Andrew.

Paul Rubin

unread,

Aug 4, 2013, 1:17:42 PM8/4/13

to

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
> OK, I accept that's your opinion. But UNIX, them GNU & Linux have
> provided many millions of people with useful and cheap computer
> systems

At the time they were written, C was a reasonable choice.

> whereas the pie-in-the-sky critics have provided them with nothing
> beyond pious words.

Some very good OS's have been written in other languages (think of the
Xerox Parc stuff) but never got traction due to not being free. GNU
itself was originally envisioned as being mostly in Lisp. But, I think
good free Lisp implementations didn't become available til sometime
later.

> No, cost is the primary goal here. An engineer is a man who can do
> for ten shillings what any fool can do for a pound.

http://archive.adaic.com/intro/ada-vs-c/cada_art.html concludes Ada
is cheaper than C when the whole lifecycle is taken into account.
I don't claim to be on the bandwagon yet, but it is interesting.

The good news is almost nobody uses C for systems development any more.
The bad news is they use C++ instead :).

>> IMHO we don't need Linux ...

> Without it we'd all be running ... I don't know.
> Windows? VMS? VSE? Multics?

There's a JVM running directly under Xen right now. That might be an
interesting approach to the user space of an OS if a few improvements
were made to support better languages than Java.

>> it's sensible to develop hardware and software to work together

> OK. Let us know how you get on.

We're entering an era where this starts to be feasible for the average
hacker. FPGA hardware capable of implementing interesting CPU's is
quite affordable. We just need some better free tools.