RfD: Make ENVIRONMENT? obsolescent

[Bernd Paysan]

Make ENVIRONMENT? obsolecent
============================

20120704 Initial proposal

Problem
=======

The Forth-94 standard specified an environmental query system, which
allows to query the system for capabilities and some constants, like PAD
and HOLD buffer sizes and maximum integers (which can be calculated
using standard words). This interface was not common practice when it
was proposed, and it didn't attract followers afterwards. Almost 20
years later, it's time to revisit this word, and look at current
practice.

Current Practice
================

The Forth200x TC has already figured out that wordset queries are not
used and offer no additional value, and so made these environmental
queries obsolescent. However, there is little evidence that other
queries are actually used. In Gforth's sources, only three queries are
used, and these three queries are Gforth-specific and therefore non-
standard (and probably should never have been queries).

Portable libraries don't use ENVIRONMENT?, instead they try to figure
out what Forth system they are running on, and then load a harness for
this system. It is common practise that a Forth system has its own name
defined as a word, so you can write code like

[IFDEF] gforth
require gforth-harness.fs
[ELSE] [IFDEF] vfxforth
require vfx-harness.fs
...
[THEN] [THEN]

The SUBSTITUTE word has not yet been used for system-specific
expansions, but the author of this proposal suggests to use the macro
%forth% to be replaced with the system name.

Proposal
========

Move 6.1.1345 ENVIRONMENT? from CORE to TOOLS EXT

Merge table 3.5 (environmental query) and table 3.6 (obsolescent
environmental queries), declaring both obsolescent. Mark table 3.7
(extension queries) as obsolescent, as well.

Remove the last sentence of 1.4.2

- Using ENVIRONMENT? ...

and add ENVIRONMENT? to the list of obsolescent words.

Add a rationale for 15.6.2.--- [DEFINED]:

A.15.6.2.--- [DEFINED]

[DEFINED] can be used to query if certain features are available. If a
standard system has a definition for a word listed in this standard,
this word behaves accordingly to this document. So when [DEFINED] F+
returns true, it does not only indicate that a word called F+ is
defined, but also that it will behave according to the specification in
this document. Therefore, [DEFINED] supersedes the feature queries of
ENVIRONMENT?.

Furthermore, it is common practice that each Forth system defines a
unique word to identify itself: its own name. [DEFINED] <system-name>
therefore can be used to identify if the program is running under a
particular system, e.g. to load a harness written for this particular
system.

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

[A. K.]

My personal view:

There can be different environments, commonly OS and SYSTEM. It is
sometimes necessary to get and set such variables. And then it is
sometimes necessary to send commands to the environment(s). My problem
with ENVIRONMENT? is that it does not really help within this context.
And it is poorly designed from the beginning, as others have stated.

Conclusion: Move ENVIRONMENT? from CORE somewhere to the backyard,
wherever you like. Anyhow we manage without.

[BruceMcF]

Environmental queries that are at least marginally useful (at least to
the point of bail and warn that script A won't work, some of them
substantially more useful than that), and would be more useful as
reserved constant names:

Non-testables:
/HOLD /PAD RETURN-STACK-CELLS STACK-CELLS FLOATING-STACK #LOCALS
WORDLISTS MAX-FLOATING

Testables:
ADDRESS-UNIT-BITS FLOORED

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:
> In Gforth's sources, only three queries are used

That's a very weak argument, because Gforth's sources generally assume
that they are running on Gforth, so many system queries won't be used
there. Better take a look at the intended-to-be-portable applications
in <http://www.complang.tuwien.ac.at/forth/appbench.zip>. I once
posted statistics on ENVIRONMENT? uses in these programs somewhere,
but I guess you can just as easily redo them.

, and these
> three queries are Gforth-specific and therefore non-standard (and probably

> should never have been queries).
>
> Portable libraries don't use ENVIRONMENT?, instead they try to figure out what
> Forth system they are running on, and then load a harness for this system.

Yes, that seems more common, but I think this system checking is
mostly for doing things that you cannot do with environmental queries
anyway. This practise is actually a testament to the weakness of the
standard: We don't need a standard for writing "portable" programs this
way.

> It
> is common practise that a Forth system has its own name defined as a word, so
> you can write code like
>
> [IFDEF] gforth
> require gforth-harness.fs
> [ELSE] [IFDEF] vfxforth
> require vfx-harness.fs
> ...
> [THEN] [THEN]

[~:77740] gforth
Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
gforth
:1: Undefined word
>>>gforth<<<

So much for "common practise".

> Proposal
> ========
>
> Move 6.1.1345 ENVIRONMENT? from CORE to TOOLS EXT

...
> and add ENVIRONMENT? to the list of obsolescent words.

Also add a sentence about the obsolescence to the glossary entry
of the word itself.

> A.15.6.2.--- [DEFINED]
>
> [DEFINED] can be used to query if certain features are available. If a
> standard system has a definition for a word listed in this standard, this word
> behaves accordingly to this document. So when [DEFINED] F+ returns true, it
> does not only indicate that a word called F+ is defined, but also that it will
> behave according to the specification in this document. Therefore, [DEFINED]
> supersedes the feature queries of ENVIRONMENT?.

There are some Forth200x extensions that tighten the behaviour of some
words (e.g., X:fasinh-lt0), and others that don't deal with defined
words at all (e.g., X:number-prefixes). This cannot be checked with
[DEFINED], and some behavioural properties cannot be checked easily;
and these behavioural properties are cases where we actually really
need to check, because, unlike undefined words, the absence of the
feature does not reveal itself by an "undefined word" error or other
error.

> Furthermore, it is common practice that each Forth system defines a unique
> word to identify itself: its own name.

It's not as common as you want to make us believe, and as mentioned
above, if a standard recommends checking for particular systems,
that's admitting defeat; if that is the way to achieve portability, we
could reduce the standard to four words: [DEFINED] [IF] [ELSE] [THEN].

- 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 2012: http://www.euroforth.org/ef12/

[Bernd Paysan]

Am Donnerstag, 5. Juli 2012, 12:52:05 schrieb Anton Ertl:
> It's not as common as you want to make us believe, and as mentioned
> above, if a standard recommends checking for particular systems,
> that's admitting defeat; if that is the way to achieve portability, we
> could reduce the standard to four words: [DEFINED] [IF] [ELSE] [THEN].

Yes, it's unfortunately not as common as it should be. Some systems
have their own name defined as environment query instead, which makes it
more cumbersome to access. Gforth (up to 0.7.0) and Win32Forth have
their own name only as environmental query. SwiftForth has nothing.
This is not as common as it should be, so my suggestion is to make it
more common. Programs need it, and e.g. FFL addresses the issue by
advicing the user to install the appropriate harnesses depending on the
system he uses.

It's also true that some extensions can't be checked with [DEFINED], but
we have already decided to remove the extesion queries.

Concerning portable programs: I also checked FFL, which is probably a
better example, because it is designed as portable library:

There's a little ENVIRONMENT? usage in FFL, which checks for ADDRESS-
UNIT-BITS and MAX-U (the first is 8 for all platforms supported by FFL,
and can be easily computed, the latter is -1, because one complement
machines died), and for FLOATING-EXT+FLOATING-STACK, where FFL requires
separate floating stack (we made that standard) and floating point words
(which can be done by [IFDEF]).

The way larger ported programs achieve portability, regardless if that
is FFL or MINOS, is to define a harness, which does some necessary
things beyond the standard in system-specific ways (e.g. MINOS needs
Xlib bindings). We can say that the standard failed to address all
issues of a portable program, and this is indeed true. There however is
no point in fundamentalism - the standard is not good enough, but it is
also not that bad that we need to abandon it completely.

ENVIRONMENT? however is ill-designed and therefore little used. I'm not
discussing hypothetical possible uses, I try to discuss what's actually
used - and that is little, and mostly superfluous. More input is
certainly wellcome.

Systems who have put non-standard information into the environmental
query wordlist, and actually use that should put it as non-standard
words into their normal dictionary. Like OS-CLASS, OS-TYPE and GFORTH
in Gforth.

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:
>Concerning portable programs: I also checked FFL, which is probably a
>better example, because it is designed as portable library:

The programs in appbench were designed as portable programs, and were
written by several authors (and I think that's important), so you
should take a look at them as well.

> There however is
>no point in fundamentalism - the standard is not good enough, but it is
>also not that bad that we need to abandon it completely.

That was not my point.

>Systems who have put non-standard information into the environmental
>query wordlist, and actually use that should put it as non-standard
>words into their normal dictionary. Like OS-CLASS, OS-TYPE and GFORTH
>in Gforth.

Maybe. But:

1) There is no point to standardizing a way to supply non-standard
things. A system can define such things in any way it deems
appropriate, and if a program wants to do system-specific things, it
can do it in system-specific ways. E.g., there is no problem if VFX
supplies a word "vfxforth" to be checked with [DEFINED] (except for
programs that want to confine themselves to not using Forth-200x words
like [DEFINED]), while Gforth supplies an environmental query
"gforth". Then your example looks as follows:

s" gforth" environment? [IF]
2drop require gforth-harness.fs
[ELSE] [DEFINED] vfxforth [IF]
include vfx-harness.fs
...
[THEN] [THEN]

[I also fixed two other bugs in your example: [IFDEF] is not
standardized anywhere and is not present in VFX; and VFX has no
REQUIRE (both tested with 4.30).]

So if a system decides to put words for the system name or whatever in
the default search order instead of having an environmental query, the
only issue at hand is which one is more convenient.

It is, however important to have ways to query such things such that
the program can still run on other systems. [DEFINED] and
ENVIRONMENT? provide such ways.

2) In the long run our goal should be to make the standard
sufficiently complete that we can run significant programs without
needing to resort to system-specific harnesses or (worse) having to
fiddle with the code. Or at least that's my goal; some seem to be
happy with the current state of non-portability.

[BruceMcF]

On Jul 5, 12:09 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

> 2) In the long run our goal should be to make the standard
> sufficiently complete that we can run significant programs without
> needing to resort to system-specific harnesses or (worse) having to
> fiddle with the code.  Or at least that's my goal; some seem to be
> happy with the current state of non-portability.

I'd be happy with getting to a single harness that gives access to a
broad library of portable source code.

[Bernd Paysan]

Anton Ertl wrote:
> The programs in appbench were designed as portable programs, and were
> written by several authors (and I think that's important), so you
> should take a look at them as well.

Ok, I did that. The most typical environment query there is to check
for the system name (i.e. nonstandard queries strings like "Gforth",
"bigForth", "iForth"). There are a few queries for MAX-U and ADDRESS-
UNIT-BITS, and for floored division (can check directly) or the presence
of the floating point wordset (equal to [DEFINED] F+).

> Maybe. But:
>
> 1) There is no point to standardizing a way to supply non-standard
> things. A system can define such things in any way it deems
> appropriate, and if a program wants to do system-specific things, it
> can do it in system-specific ways. E.g., there is no problem if VFX
> supplies a word "vfxforth" to be checked with [DEFINED] (except for
> programs that want to confine themselves to not using Forth-200x words
> like [DEFINED]), while Gforth supplies an environmental query
> "gforth". Then your example looks as follows:
>
> s" gforth" environment? [IF]
> 2drop require gforth-harness.fs
> [ELSE] [DEFINED] vfxforth [IF]
> include vfx-harness.fs
> ...
> [THEN] [THEN]

The code reads better (and also writes better) if you have consistent
ways for checking these things. At the moment, you have to remember
both the Forth system's name and how it is supposed to be checked (plus
how many values its environmental query leaves on the stack to be
removed). Do this a hundred times in some code, and you simply add

s" gforth" environment? [IF] 2drop : gforth ; [THEN]

at the start of the program, because it reduces the number of errors you
have to track down.

> [I also fixed two other bugs in your example: [IFDEF] is not
> standardized anywhere and is not present in VFX; and VFX has no
> REQUIRE (both tested with 4.30).]

At least in 4.4 it has a require, but still no [IFDEF]. We didn't
standardize that, but both Gforth and bigForth have it, and I find it
much more convenient than [defined] xxx [if].

> So if a system decides to put words for the system name or whatever in
> the default search order instead of having an environmental query, the
> only issue at hand is which one is more convenient.
>
> It is, however important to have ways to query such things such that
> the program can still run on other systems. [DEFINED] and
> ENVIRONMENT? provide such ways.

Yes, with different usefullness. Querying for an ext wordset is not
particularly helpful, as the implementer can cherry-pick which words he
implements. [DEFINED] can check for each of them, so you could say
something like

[DEFINED] fsin [DEFINED] fcos and [DEFINED] fatan2 and [DEFINED] fsqrt
and 0= [IF] include basic-trigonometry.fs [THEN]

We could argue that we can make ENVIRONMENT? obsolescent, because we now
have [DEFINED], which does - apart from a few constants - a better job
than ENVIRONMENT? ever did.

At least moving it to TOOLS EXT ("bunch of stuff") makes it easier for
system implementers to decide whether they actually want to support it.

> 2) In the long run our goal should be to make the standard
> sufficiently complete that we can run significant programs without
> needing to resort to system-specific harnesses or (worse) having to
> fiddle with the code. Or at least that's my goal; some seem to be
> happy with the current state of non-portability.

Yes, but in the short run we don't achieve the long-run goal, and still
wan to write significant programs that are ported to several systems.

[Albert van der Horst]

In article <2012Jul...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>[~:77740] gforth
>Gforth 0.7.0, Copyright (C) 1995-2008 Free Software Foundation, Inc.
>Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
>Type `bye' to exit
>gforth
>:1: Undefined word
>>>>gforth<<<
>
>So much for "common practise".

80386 ciforth 4.0.6
lina
lina? ciforth ERROR # 12 : NOT RECOGNIZED
ciforth
ciforth? ciforth ERROR # 12 : NOT RECOGNIZED
ENVIRONMENT
OK
NAME TYPE
ciforth OK

: gforth ;
OK
gforth
OK


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

[BruceMcF]

On Jul 5, 7:13 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> The code reads better (and also writes better) if you have consistent
> ways for checking these things.  At the moment, you have to remember
> both the Forth system's name and how it is supposed to be checked (plus
> how many values its environmental query leaves on the stack to be
> removed).  Do this a hundred times in some code, and you simply add
>
> s" gforth" environment? [IF] 2drop : gforth ; [THEN]

I prefer constants to presence tokens, since constants can be provided
for by amending the specification of environmental queries from being
disjoint with the namespace to being conjoint with the namespace.
Declare all the environmental queries regarding wordset names
obsolescent, the ones that are computable can be computed if absent
and needed, the ones the represent non-computable information, if
something more than the absolute minimum is required, can generate a
warning or an abort with a request to define an appropriate value.

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:
>Anton Ertl wrote:
>> The programs in appbench were designed as portable programs, and were
>> written by several authors (and I think that's important), so you
>> should take a look at them as well.
>
>Ok, I did that. The most typical environment query there is to check
>for the system name (i.e. nonstandard queries strings like "Gforth",
>"bigForth", "iForth"). There are a few queries for MAX-U and ADDRESS-
>UNIT-BITS, and for floored division (can check directly) or the presence
>of the floating point wordset (equal to [DEFINED] F+).

PFE makes the Float wordset available if you query for FLOATING-EXT,
but not if you check with [DEFINED] F+:

\ Portable Forth Environment 0.33.34 (Jun 14 2004 01:04:19)
Copyright (C) Dirk Uwe Zoller 1993 - 1995.
Copyright (C) Tektronix, Inc. 1998 - 2003.
ANS/ffa ITC Forth - Please enter LICENSE and WARRANTY.
Running on x86_64 linux-gnu - to quit say BYE. ok
[defined] f+ . 0 ok
s" floating-ext" environment? .s
-1 [FFFFFFFFFFFFFFFF]
1994 [00000000000007CA] ok
[defined] f+ . 46912503573385 ok

Of course, one could modify the systems such that "[DEFINED] F+" makes
F+ available (the way that Albert van der Horst (IIRC) does it with
WANT); but that would require quite a large number of [DEFINED]s to
get the wholes FP wordset. Or if such systems already have the data
to make these words available individually, they could be made
available automatically when encountered in the text interpreter
without WANT or [DEFINED].

>The code reads better (and also writes better) if you have consistent
>ways for checking these things. At the moment, you have to remember
>both the Forth system's name and how it is supposed to be checked (plus
>how many values its environmental query leaves on the stack to be
>removed). Do this a hundred times in some code

Why would you load a hundred compatibility harnesses, and if you do,
why would you need to check for the system every time you load one?

>> It is, however important to have ways to query such things such that
>> the program can still run on other systems. [DEFINED] and
>> ENVIRONMENT? provide such ways.
>
>Yes, with different usefullness. Querying for an ext wordset is not
>particularly helpful, as the implementer can cherry-pick which words he
>implements. [DEFINED] can check for each of them, so you could say
>something like
>
>[DEFINED] fsin [DEFINED] fcos and [DEFINED] fatan2 and [DEFINED] fsqrt
>and 0= [IF] include basic-trigonometry.fs [THEN]

I think this will be as rare as wordset queries, for the same reason.

>We could argue that we can make ENVIRONMENT? obsolescent, because we now
>have [DEFINED], which does - apart from a few constants - a better job
>than ENVIRONMENT? ever did.

Actually even for the constants. Just define them as Forth words in
an extension, and one can check for their presence with [DEFINED], or
(more likely) use them without check.

>> 2) In the long run our goal should be to make the standard
>> sufficiently complete that we can run significant programs without
>> needing to resort to system-specific harnesses or (worse) having to
>> fiddle with the code. Or at least that's my goal; some seem to be
>> happy with the current state of non-portability.
>
>Yes, but in the short run we don't achieve the long-run goal, and still
>wan to write significant programs that are ported to several systems.

Sure, but we shouldn't present this way of writing several-system
specific programs as the only way to achieve portability (it actually
does not achieve real portability at all).

[Bernd Paysan]

Anton Ertl wrote:
> PFE makes the Float wordset available if you query for FLOATING-EXT,
> but not if you check with [DEFINED] F+:

Yes, a pretty weird mechanism to load the floating point wordset.

> Of course, one could modify the systems such that "[DEFINED] F+" makes
> F+ available (the way that Albert van der Horst (IIRC) does it with
> WANT); but that would require quite a large number of [DEFINED]s to
> get the wholes FP wordset.

No, please not. [DEFINED] is there to check, not to make available.

> Or if such systems already have the data
> to make these words available individually, they could be made
> available automatically when encountered in the text interpreter
> without WANT or [DEFINED].

Yepp. There is no requirement to have all words resident if you can
load them on demand. This is what I would consider a standard approach
- the word as such is "there", it just gets loaded and compiled on
demand.

> Why would you load a hundred compatibility harnesses, and if you do,
> why would you need to check for the system every time you load one?

Well, maybe you load one harness, and then you still have places in your
code that need checking for a particular system, because the special-
casing there is not worth to go into a general harness. I've still
several [defined] VFXForth [IF] in MINOS, because VFX needs some tweaks
here and there (deny inlining a word and similar things).

>>We could argue that we can make ENVIRONMENT? obsolescent, because we
>>now have [DEFINED], which does - apart from a few constants - a better
>>job than ENVIRONMENT? ever did.
>
> Actually even for the constants. Just define them as Forth words in
> an extension, and one can check for their presence with [DEFINED], or
> (more likely) use them without check.

Yes.

>>Yes, but in the short run we don't achieve the long-run goal, and
>>still wan to write significant programs that are ported to several
>>systems.
>
> Sure, but we shouldn't present this way of writing several-system
> specific programs as the only way to achieve portability (it actually
> does not achieve real portability at all).

I don't know what you think "real portability" is. This seems to be a
fundamentalistic approach. People will provide additional features in
their Forth systems, and if you want to use that feature in another
Forth system, you have to make it available there, too. It might
require carnal knowledge to do so (like C library bindings).

Example: MINOS runs under two different graphical systems (Win32 and
Xlib), and it runs in two different Forth systems. It achieves the
latter by loading two different harnesses, and the former by being full
of [defined] win32 [if] and [defined] x11 [if] code, because of course,
Xlib and Win32 are not at all compatible. However, they offer a similar
set of features, so a MINOS program itself is portable - it neither
needs to check for VFXForth nor for win32/xlib, it just works.

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:
>Anton Ertl wrote:
>> PFE makes the Float wordset available if you query for FLOATING-EXT,
>> but not if you check with [DEFINED] F+:
>
>Yes, a pretty weird mechanism to load the floating point wordset.

It's a pretty cool mechanism, especially compared to crap like

include Hfp387.fth

Why is it cool?

1) Because all standard systems process it. The program won't fail
because of this check. Every system but one will fail with the
INCLUDE above.

2) It's much easier to remember that, on some systems, I have to check
for FP with the standard mechanism in order to get it loaded than to
remember a weird filename like Hfp387.fth.

>> Actually even for the constants. Just define them as Forth words in
>> an extension, and one can check for their presence with [DEFINED], or
>> (more likely) use them without check.
>
>Yes.

But then your proposal should include making these constants standard
Forth words.

>> Sure, but we shouldn't present this way of writing several-system
>> specific programs as the only way to achieve portability (it actually
>> does not achieve real portability at all).
>
>I don't know what you think "real portability" is.

I can run the program unchanged on every standard system (modulo
memory requirements and wordset presence).

> This seems to be a
>fundamentalistic approach.

I don't think that name-calling leads to a productive discussion.

>People will provide additional features in
>their Forth systems, and if you want to use that feature in another
>Forth system, you have to make it available there, too. It might
>require carnal knowledge to do so (like C library bindings).

Yes, but that's the opposite of portability through a standard. The C
interface is one example of a feature that many Forth systems have,
and that we should standardize. It's like FP before Forth-94.

[Josh Grams]

Bernd Paysan wrote: <jt7p05$eov$1...@online.de>

> Anton Ertl wrote:
>> PFE makes the Float wordset available if you query for FLOATING-EXT,
>> but not if you check with [DEFINED] F+:
>
> Yes, a pretty weird mechanism to load the floating point wordset.

Why is that weird? It's even suggested in the standard (A.3.2.6):

"The other group of queries are for things that may legitimately change
over time. For example an application might test for the presence of
the Double Number word set using an environment query. If it is
missing, the system could invoke a system-dependent process to load the
word set."

>> Or if such systems already have the data
>> to make these words available individually, they could be made
>> available automatically when encountered in the text interpreter
>> without WANT or [DEFINED].
>
> Yepp. There is no requirement to have all words resident if you can
> load them on demand. This is what I would consider a standard approach
> - the word as such is "there", it just gets loaded and compiled on
> demand.

That's problematic, as when you encounter a word you may be in the
middle of building a definition or data structure, and loading code
would break things...

>> Why would you load a hundred compatibility harnesses, and if you do,
>> why would you need to check for the system every time you load one?
>
> Well, maybe you load one harness, and then you still have places in your
> code that need checking for a particular system, because the special-
> casing there is not worth to go into a general harness. I've still
> several [defined] VFXForth [IF] in MINOS, because VFX needs some tweaks
> here and there (deny inlining a word and similar things).

>>>We could argue that we can make ENVIRONMENT? obsolescent, because we
>>>now have [DEFINED], which does - apart from a few constants - a better
>>>job than ENVIRONMENT? ever did.
>>
>> Actually even for the constants. Just define them as Forth words in
>> an extension, and one can check for their presence with [DEFINED], or
>> (more likely) use them without check.

The trouble I see with [DEFINED] is that it just checks for the presence
of a name -- it doesn't check whether it actually conforms to the
standard... Given that almost all of the so-called standard Forth
systems have very noticeable deviations, you can't just assume that
standard word names do what you think they do.

And testing for the proper behavior can be difficult or impossible to do
without crashing the Forth system, so you really want the knowledge to
be built-in or pre-computed and stored in a database.

Of course, as we have seen, most people who write Forth code don't
really care about portability -- just write simple well-factored code
and modify it for new systems, or write a new harness. So it may be
that nobody would use it anyway...

> I don't know what you think "real portability" is. This seems to be a
> fundamentalistic approach. People will provide additional features in
> their Forth systems, and if you want to use that feature in another
> Forth system, you have to make it available there, too. It might
> require carnal knowledge to do so (like C library bindings).
>
> Example: MINOS runs under two different graphical systems (Win32 and
> Xlib), and it runs in two different Forth systems. It achieves the
> latter by loading two different harnesses, and the former by being full
> of [defined] win32 [if] and [defined] x11 [if] code, because of course,
> Xlib and Win32 are not at all compatible. However, they offer a similar
> set of features, so a MINOS program itself is portable - it neither
> needs to check for VFXForth nor for win32/xlib, it just works.

It seems to me that it would be pretty straightforward to build a Forth
package manager even without support from implementations. System
support in the form of making system/version available would be nice.
But even without that, it's easy enough to run each Forth system through
a script which loads that information. Again, building a package
database would be a lot of boring drudgery and probably no one cares
enough to do it, but I don't think it would be difficult.

--Josh

[Albert van der Horst]

In article <jt7p05$eov$1...@online.de>, Bernd Paysan <bernd....@gmx.de> wrote:
>Anton Ertl wrote:
>> PFE makes the Float wordset available if you query for FLOATING-EXT,
>> but not if you check with [DEFINED] F+:
>
>Yes, a pretty weird mechanism to load the floating point wordset.

That may not as weird as you think. ciforth has very little present
out of the box. If some one asks whether COMPARE is defined, he
probably wants to use it. The effect is that loadable extensions
look as if they are defined, without taking up place in the kernel.
So instead of
: [DEFINED] NAME PRESENT ;
I have
: [DEFINED] NAME 2DUP WANTED PRESENT ;

>
>> Of course, one could modify the systems such that "[DEFINED] F+" makes
>> F+ available (the way that Albert van der Horst (IIRC) does it with
>> WANT); but that would require quite a large number of [DEFINED]s to
>> get the wholes FP wordset.
>
>No, please not. [DEFINED] is there to check, not to make available.

I agree. I wouldn't object to replace the documentation like
Anton put in a sbpcp.frt (slightly better prime counting program")
"
\ The program uses the following words
..
\ from EXCEPTION :
\ throw
...
\ from FLOAT :
\ d>f f>d
\ from FLOAT-EXT :
\ fsqrt f**
..
\ from LOCAL :
\ TO
"
by a more formal
( EXCEPTION : ) WANT THROW
( FLOAT : ) WANT D>F F>D
( FLOAT-EXT : ) WANT FSQRT F**
( LOCAL : ) WANT TO
which would allow a so-equipped system to get the maximum
of loadable extensions to prepare for running the program.

But
[DEFINED] THROW DROP
[DEFINED] D>F DROP
[DEFINED] F>D DROP

is plain weird.

>
>> Or if such systems already have the data
>> to make these words available individually, they could be made
>> available automatically when encountered in the text interpreter
>> without WANT or [DEFINED].
>
>Yepp. There is no requirement to have all words resident if you can
>load them on demand. This is what I would consider a standard approach
>- the word as such is "there", it just gets loaded and compiled on
>demand.

This I try with `` lina -t aap.frt ''
It is not as easy as it looks, it gets messy with immediate words,
wordlists and I need a second pass.

It is a good idea to have this facility loaded for interactive
sessions that start with `` lina -e ''

That is where the real challenge is. Note that once it becomes
clear how the API has to look, you have a candidate for
standardization.
>
>--
>Bernd Paysan

[Bernd Paysan]

Anton Ertl wrote:
>>Yes, a pretty weird mechanism to load the floating point wordset.
>
> It's a pretty cool mechanism, especially compared to crap like
>
> include Hfp387.fth
>
> Why is it cool?
>
> 1) Because all standard systems process it. The program won't fail
> because of this check. Every system but one will fail with the
> INCLUDE above.

Well, the problem is the weird name. Why not call the file float.fs or
float.fth or float.fb if it is a block file?

> 2) It's much easier to remember that, on some systems, I have to check
> for FP with the standard mechanism in order to get it loaded than to
> remember a weird filename like Hfp387.fth.

Weird filenames are indeed a nuisance.

require float.fs

doesn't look that weird.

> But then your proposal should include making these constants standard
> Forth words.

Yes, I'll do so.

>>I don't know what you think "real portability" is.
>
> I can run the program unchanged on every standard system (modulo
> memory requirements and wordset presence).
>
>> This seems to be a
>>fundamentalistic approach.
>
> I don't think that name-calling leads to a productive discussion.

IMHO, pragmatic approaches are more likely to get implemented than
strict approaches. I would like to have my programs run unchanged, too,
but it takes time to get there.

>>People will provide additional features in
>>their Forth systems, and if you want to use that feature in another
>>Forth system, you have to make it available there, too. It might
>>require carnal knowledge to do so (like C library bindings).
>
> Yes, but that's the opposite of portability through a standard. The C
> interface is one example of a feature that many Forth systems have,
> and that we should standardize. It's like FP before Forth-94.

Yes, we should, but last time we analyzed the situation, we found that
every Forth system tried to do something minimalistic, which solves its
particular platform's problems, and no more. Problems more portable
systems like Gforth have aren't solved with the other approaches. On
the other hand, Gforth's current approach only specifies the Forth type
of each passed value, and leaves the C type to the C compiler - this
won't work in a system like VFX or bigForth, which needs the C type,
because it generates the binding itself.

In any case, this all won't happen over night, and in the meantime, we
still need a way to facilitate porting programs, even though it is more
cumbersome than we would like.

[Bernd Paysan]

Josh Grams wrote:
> The trouble I see with [DEFINED] is that it just checks for the
> presence of a name -- it doesn't check whether it actually conforms to
> the standard... Given that almost all of the so-called standard Forth
> systems have very noticeable deviations, you can't just assume that
> standard word names do what you think they do.

The words in the standard are more or less "reserved words" - if you
implement them in a standard system, they ought to behave as specified.
If a system is just "so-called standard Forth", it will lie to you with
whatever easy query you do.

If you really need to know that the standard words behave as specified,
your program should probably come with the Hayes tester, and test the
words before it uses them :-).

> And testing for the proper behavior can be difficult or impossible to
> do without crashing the Forth system, so you really want the knowledge
> to be built-in or pre-computed and stored in a database.

Hm, I didn't see the Hayes tester crash, even when it detects wrong
behavior.

[Stephen Pelc]

On Sat, 07 Jul 2012 08:52:58 GMT, an...@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>It's a pretty cool mechanism, especially compared to crap like
>
>include Hfp387.fth

Given your comments about name-calling later, it's a qustion of
the pot calling the kettle black. What you miss with VFX is that
there are *three* floating point packs to choose from, and that
you have not chosen the lead package. This is explained in the
manual.

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

[Bernd Paysan]

Stephen Pelc wrote:

> On Sat, 07 Jul 2012 08:52:58 GMT, an...@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:
>
>>It's a pretty cool mechanism, especially compared to crap like
>>
>>include Hfp387.fth
>
> Given your comments about name-calling later, it's a qustion of
> the pot calling the kettle black. What you miss with VFX is that
> there are *three* floating point packs to choose from, and that
> you have not chosen the lead package. This is explained in the
> manual.

Ndp387.fth is no better name. And the 32 bit library optimized for
OpenGL with mixed stack... fortunately, you added double and float
specifiers to your C bindings, so that I could use the normal FP package
to interface with OpenGL.

If we want to get to Anton's goal of having standard programs unmodified
and agnostic of which Forth system they run on (which *is* a good long-
term goal), and we allow Forth systems to have parts of the standard as
source (which is also a good idea), then we should have a standard
mechanism to load those extensions. Forth-94 suggests to use
ENVIRONMENT? for that, but I don't think that's a good idea. E.g. if I
have a toolbox like FFL, and there's no floating point, I just compile
the parts of the toolbox that don't build on floating point. The user
of that toolbox might also not need the floating point part, and
everything is fine.

I suggest that REQUIRE should be expanded to load features, like

require floating \ we need the floating wordset

No extension, no path, the system can figure out from that query which
file it needs to load. This must be accompanied with

provides floating

in the loaded file so that afterwards, require will not load it again
(regardless of the file name). This can be achieved by having symbolic
links to the files that provide the features - I don't care about how it
is implemented, it's just important to have a standard way to get the
required features that are distributed in source form.

Our long-term plan for the standard is that we will move to a library
model for further extensions, and that means we should have such a
feature, anyways.

[BruceMcF]

On Jul 7, 7:19 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> require floating \ we need the floating wordset

This is far superior to [DEFINED] auto-loading. What if have a more
concise way of accomplishing the specific piece that I need, defined
in the [ELSE] section, but will use a more wide ranging facility if it
happens to be there anyway?

REQUIRE implies that I *need* and and wish to load it if its not
present, and having standardized tokens based on the already-defined
ENVIRONMENT? wordset names is a good kernel.

And its something where "waiting for something to become standard
practice" is highly unlikely to work, since the problem is to have all
implementations settle on the same standardized tokens all at once.

While autoloading with ENVIRONMENT? would be perfectly fine by me, if
Forth was going to settle on that solution, it would have already
happened by now.

[Andrew Haley]

Josh Grams <jo...@qualdan.com> wrote:
>
> The trouble I see with [DEFINED] is that it just checks for the presence
> of a name -- it doesn't check whether it actually conforms to the
> standard... Given that almost all of the so-called standard Forth
> systems have very noticeable deviations, you can't just assume that
> standard word names do what you think they do.

That is a very good point.

Andrew.

[Anton Ertl]

Josh Grams <jo...@qualdan.com> writes:
>Bernd Paysan wrote: <jt7p05$eov$1...@online.de>
>> Anton Ertl wrote:
>>> Or if such systems already have the data
>>> to make these words available individually, they could be made
>>> available automatically when encountered in the text interpreter
>>> without WANT or [DEFINED].
>>
>> Yepp. There is no requirement to have all words resident if you can
>> load them on demand. This is what I would consider a standard approach
>> - the word as such is "there", it just gets loaded and compiled on
>> demand.
>
>That's problematic, as when you encounter a word you may be in the
>middle of building a definition or data structure, and loading code
>would break things...

Of course the system would have to make the things available in a way
that does not break things: Don't put the code HERE, don't change (or
restore afterwards) any other data visible to standard programs. It's
the same when it's done through ENVIRONMENT?, which can also be called
in the middle of building a definition or data structure.

>The trouble I see with [DEFINED] is that it just checks for the presence
>of a name -- it doesn't check whether it actually conforms to the
>standard... Given that almost all of the so-called standard Forth
>systems have very noticeable deviations, you can't just assume that
>standard word names do what you think they do.

Well, that's independent of checking with [DEFINED]; if a word with a
standard name does not conform, the system is non-standard or it has a
bug. In either case we won't get any better results with ENVIRONMENT?.

However, people have suggested using [DEFINED] to check for
non-standard words. In that case your objection certainly has merit;
of course, a dedicated querying mechanism like the Forth200x extension
queries (which are an enhancement of ENVIRONMENT?) won't protect
against deliberate misinformation, but it's less likely to fall prey
to accidental name collisions.

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:
>Anton Ertl wrote:
>>>Yes, a pretty weird mechanism to load the floating point wordset.
>>
>> It's a pretty cool mechanism, especially compared to crap like
>>
>> include Hfp387.fth
>>
>> Why is it cool?
>>
>> 1) Because all standard systems process it. The program won't fail
>> because of this check. Every system but one will fail with the
>> INCLUDE above.
>
>Well, the problem is the weird name. Why not call the file float.fs or
>float.fth or float.fb if it is a block file?

That won't do anything to alleviate this problem. E.g, if you

include float.fs

in Gforth, it redefines a bunch of words that had been present
already. If you

include float.fth

you get a "No such file or directory error"; and likewise for
float.fb.

>Weird filenames are indeed a nuisance.
>
>require float.fs
>
>doesn't look that weird.

This one works (as a NOOP) in Gforth, but fails on VFX. So it still
has the problem above.

>>> This seems to be a
>>>fundamentalistic approach.
>>
>> I don't think that name-calling leads to a productive discussion.
>
>IMHO, pragmatic approaches are more likely to get implemented than
>strict approaches.

In the rationale of a proposal, you can afford a long-term perspective
(or, if you want, idealism) in the suggestions on how to write
programs. In the worst case, everyone will ignore it; OTOH, for a
rationale with a short-term perspective (a pragmatic rationale, if you
want), the worst case is that nobody will ignore it.

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:
>If you really need to know that the standard words behave as specified,
>your program should probably come with the Hayes tester, and test the
>words before it uses them :-).

Testing cannot prove the conformance with a specification, only the
non-conformance.

>Josh Grams wrote:
>> And testing for the proper behavior can be difficult or impossible to
>> do without crashing the Forth system, so you really want the knowledge
>> to be built-in or pre-computed and stored in a database.
>
>Hm, I didn't see the Hayes tester crash, even when it detects wrong
>behavior.

Did you suppress the memories of crashes during building Gforth? We
use --die-on-signal there for a reason.

But a crash on a misbehaving system in the startup tests would be
acceptable. Ok, it would not be so nice if you want to provide a
replacement.

[Anton Ertl]

steph...@mpeforth.com (Stephen Pelc) writes:
>On Sat, 07 Jul 2012 08:52:58 GMT, an...@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>It's a pretty cool mechanism, especially compared to crap like
>>
>>include Hfp387.fth

[...]

>What you miss with VFX is that
>there are *three* floating point packs to choose from, and that
>you have not chosen the lead package. This is explained in the
>manual.

I know there are several FP packages for VFX. I did not know that
there is a lead package, nor do I know what that means (first
association: credit cards have silver, gold, and platinum versions,
maybe VFX has lead, copper and iron FP packages).

But I don't think that it would have made any difference for my
example: replace Hfp387.fth with the name of the lead package, and all
the points still stand.

And your reference to the manual supports my second point:

| 2) It's much easier to remember that, on some systems, I have to check
| for FP with the standard mechanism in order to get it loaded than to
| remember a weird filename like Hfp387.fth.

Everyone who wants to run a program with FP on VFX without already
being in the VFX church will find that VFX has no FP. If they are
especially persevering, they will dig up the manual and find out that
there are several FP packages, that they can load.

I had already gone through all that some time ago, and remembered all
that, but not the actual names of the files. I could have spent
another 5 minutes searching around for the VFX manual and searching
there for the FP stuff, but instead I just googled for a minute or so,
and came up with the include shown above, which is in some way wrong
if I understand you correctly.

[Mark Wills]

On Jul 8, 8:15 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:

And? What you propose to circumvent that 'shortcoming'? Short of
inventing a mechanism to allow words to advertise their stack
signatures, I don't really see what one can do. Isn't this going
slightly into 'mountain out of a mole-hill' land?

At the end of the day, it is up to the implementor to ensure that his
'standard compliant' Forth system complies with the standard. Any word
that is 'claimed' by the standard should conform to the standard,
otherwise, an alternative name should be found for it.

[Stephen Pelc]

On Mon, 09 Jul 2012 15:35:49 GMT, an...@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>But I don't think that it would have made any difference for my
>example: replace Hfp387.fth with the name of the lead package, and all
>the points still stand.

You seem to want a way to ensure that a wordset is present.
This seems to be a big thing for you in particular.

At least VFX has a manual ... <grin>

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:
>I suggest that REQUIRE should be expanded to load features, like
>
>require floating \ we need the floating wordset
>
>No extension, no path, the system can figure out from that query which
>file it needs to load.

REQUIRE has a well-defined meaning: it includes a file, not a wordset.
If you want to have a word that includes a wordset, use a different
name, say, REQUIRE-WORDSET (or, in the tradition of D+ F+, just
WREQUIRE). If they happen to have the same implementation on your
system, one can just call the other one.

>This must be accompanied with
>
>provides floating
>
>in the loaded file so that afterwards, require will not load it again
>(regardless of the file name).

Hmm, if it was loaded with (say) REQUIRE-WORDSET floating, and that
was successful, I would expect the system to be able to remember by
itself that this is now present. At least that works automatically
for the file REQUIRE, why not for REQUIRE-WORDSET?

>This can be achieved by having symbolic
>links to the files that provide the features - I don't care about how it
>is implemented, it's just important to have a standard way to get the
>required features that are distributed in source form.

I am actually pretty happy with systems that have everything loaded on
startup, but yes, if we don't have that, a standard way to get the
system to load the wordsets would help.

>Our long-term plan for the standard is that we will move to a library
>model for further extensions, and that means we should have such a
>feature, anyways.

I think that files are fine for libraries.

The way you describe it makes me fear that we would replace the
fiddling in load files with fiddling with symbolic links in the load
directory, which is not any better.

[Anton Ertl]

BruceMcF <agi...@netscape.net> writes:

>On Jul 7, 7:19=A0pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
>> require floating \ we need the floating wordset
>
>This is far superior to [DEFINED] auto-loading. What if have a more
>concise way of accomplishing the specific piece that I need, defined
>in the [ELSE] section, but will use a more wide ranging facility if it
>happens to be there anyway?

An unlikely scenario, as evidenced by the fact that wordset queries
are rare; also [DEFINED] without auto-loading is not usually used in
that way.

>While autoloading with ENVIRONMENT? would be perfectly fine by me, if
>Forth was going to settle on that solution, it would have already
>happened by now.

True. However, it seems to me that the main reason for not doing it
was that those system implementors who care for running standard
programs without fiddling have everything included from the start, and
those system implementors who don't, do not care about being able to
run programs without fiddling around anyway. So I don't expect any
other solution to succeed, either, unless attitudes change.

[Andrew Haley]

Mark Wills <markrob...@yahoo.co.uk> wrote:
> On Jul 8, 8:15?am, Andrew Haley <andre...@littlepinkcloud.invalid>

> wrote:
>> Josh Grams <j...@qualdan.com> wrote:
>>
>> > The trouble I see with [DEFINED] is that it just checks for the presence
>> > of a name -- it doesn't check whether it actually conforms to the

>> > standard... ?Given that almost all of the so-called standard Forth

>> > systems have very noticeable deviations, you can't just assume that
>> > standard word names do what you think they do.
>>
>> That is a very good point.
>

> And? What you propose to circumvent that 'shortcoming'? Short of
> inventing a mechanism to allow words to advertise their stack
> signatures, I don't really see what one can do. Isn't this going
> slightly into 'mountain out of a mole-hill' land?

Not really, no. As it stands at the moment, a system implementor is
supposed to document the means by which whatever standard wordsets
they provide are to be loaded. You have to read that documentation
and do whatever it says. Simply checking that F+ or nonesuch is
defined and then assuming that the system supports the floating
wordset isn't going to do it.

> At the end of the day, it is up to the implementer to ensure that his

> 'standard compliant' Forth system complies with the standard. Any word
> that is 'claimed' by the standard should conform to the standard,
> otherwise, an alternative name should be found for it.

Forth doesn't have reserved words. There's no barrier to using the
names of words in a wordset for some other purpose if that wordset
isn't loaded. The implementor is entirely free to behave as if those
wordsets they don't implement do not exist, or to implement them in
some nonstandard way as long as they fully implement everything they
claim to implement. That is all.

Andrew.

[BruceMcF]

On Jul 9, 1:08 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

> True.  However, it seems to me that the main reason for not doing it
> was that those system implementors who care for running standard
> programs without fiddling have everything included from the start, and
> those system implementors who don't, do not care about being able to
> run programs without fiddling around anyway.  So I don't expect any
> other solution to succeed, either, unless attitudes change.

Or the broader environment within which those decisions are made
changes. A compelling library collection that was auto-loading after
loading a single implementation harness on both the "big" Forth94
implementations and some of the "small" Forth94 implementations would
exert a network effect on convergence toward the library collection
platform words and library management strategy. After all, that would
shift the many to many two sided coordination problem between
implementations and libraries into two many-to-one coordination
problems, implementation to collection platform, library to collection
platform.

I'd not figure that a short odds chance of happening, but OTOH the
opening for that remains, so you never know.

[BruceMcF]

On Jul 9, 11:54 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

> REQUIRE has a well-defined meaning: it includes a file,
> not a wordset.

Which is, of course, one implementation approach for that version of
require ~ to include files without extensions named after wordsets as
wordset load scripts.

Its a change in REQUIRE if a wordset name preempts the search for the
file under that name.

If, on the other hand, it is specified that if REQUIRE fails to find a
name without a file type, refers to an implementation specific
database of standard wordset queries and attempts to provide that
wordset if found in the database, then it is an extension of REQUIRE
but not a modification of its existing standard semantics.

[Josh Grams]

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

> Of course the system would have to make the things available in a way
> that does not break things: Don't put the code HERE, don't change (or
> restore afterwards) any other data visible to standard programs. It's
> the same when it's done through ENVIRONMENT?, which can also be called
> in the middle of building a definition or data structure.

Oh, good point. It didn't occur to me that ENVIRONMENT? would have to
respect those restrictions as well.

--Josh

[Anton Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:

>Mark Wills <markrob...@yahoo.co.uk> wrote:
>> At the end of the day, it is up to the implementer to ensure that his
>> 'standard compliant' Forth system complies with the standard. Any word
>> that is 'claimed' by the standard should conform to the standard,
>> otherwise, an alternative name should be found for it.
>
>Forth doesn't have reserved words. There's no barrier to using the
>names of words in a wordset for some other purpose if that wordset
>isn't loaded. The implementor is entirely free to behave as if those
>wordsets they don't implement do not exist, or to implement them in
>some nonstandard way as long as they fully implement everything they
>claim to implement. That is all.

Hmm, I thought that, if a word is present in a standard system, it has
to have the standard meaning, but I don't find such wording in
Forth-94 (but maybe I am looking in the wrong place). The
Forth-83 controlled reference words had that property. It would be
funny if Forth-94 provided less guarantees for its fully standardized
words than Forth-83 for its controlled reference words.

|The Controlled Reference Words are word definitions which,
|although not required, cannot be present with a non-standard
|definition in the vocabulary FORTH of a Standard System.

If it is not in the standard already, we should put an analogous
wording in the standard, definitely if we want to replace ENVIRONMENT?
with [DEFINED].

Concerning "reserved words": That term is usually used in languages
with syntax specified in BNF or similar for grammar symbols (other
than "identifier") that are lexically represented by sequences of
letters (e.g., BEGIN in Pascal, or int in C). Forth obviously has no
reserved words, because in a BNF description it would have only
identifiers.

Many other languages don't allow you to redefine names, and have some
names predefined, so a program must not define these names. An
example is INTEGER in Pascal. These names are sometimes called
"reserved names". That concept does not apply to Forth, either,
because a program can redefine every name it likes.

So yes, Forth does not have reserved words in the usual sense, but
that does not say anything about whether a standard system can define
a word with a standard name, but non-standard behaviour.

[Andrew Haley]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>Mark Wills <markrob...@yahoo.co.uk> wrote:
>>> At the end of the day, it is up to the implementer to ensure that his
>>> 'standard compliant' Forth system complies with the standard. Any word
>>> that is 'claimed' by the standard should conform to the standard,
>>> otherwise, an alternative name should be found for it.
>>
>>Forth doesn't have reserved words. There's no barrier to using the
>>names of words in a wordset for some other purpose if that wordset
>>isn't loaded. The implementor is entirely free to behave as if those
>>wordsets they don't implement do not exist, or to implement them in
>>some nonstandard way as long as they fully implement everything they
>>claim to implement. That is all.
>
> Hmm, I thought that, if a word is present in a standard system, it
> has to have the standard meaning, but I don't find such wording in
> Forth-94 (but maybe I am looking in the wrong place). The Forth-83
> controlled reference words had that property. It would be funny if
> Forth-94 provided less guarantees for its fully standardized words
> than Forth-83 for its controlled reference words.

Forth-94 (and even more so, 200x) are too diverse for all of their
words to be treated as reserved. IMO the optional wordsets simply use
too many useful names.

For example, it makes sense to provide a fully IEEE-compatible
floating-point wordset (and I hope that will happen!) It will be much
harder to design if it has to reserve the names of all its words so
that Forth systems can no longer use those names for anything else.

I'm not sure what you mean by "fully standardized". Can an optional
wordset be said to be fully standardized?

Andrew.

[Anton Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:

>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> Hmm, I thought that, if a word is present in a standard system, it
>> has to have the standard meaning, but I don't find such wording in
>> Forth-94 (but maybe I am looking in the wrong place). The Forth-83
>> controlled reference words had that property. It would be funny if
>> Forth-94 provided less guarantees for its fully standardized words
>> than Forth-83 for its controlled reference words.
>
>Forth-94 (and even more so, 200x) are too diverse for all of their
>words to be treated as reserved.

This is not about reserved words. This is about having a guaranteed
meaning for standard-named words supplied by the system, if they are
present.

>IMO the optional wordsets simply use
>too many useful names.
>
>For example, it makes sense to provide a fully IEEE-compatible
>floating-point wordset (and I hope that will happen!) It will be much
>harder to design if it has to reserve the names of all its words so
>that Forth systems can no longer use those names for anything else.

Why would it be much harder?

Even if it is standard for a system to define a word with the name of
an optional standard word, but different behaviour, it is an extremely
bad idea.

>I'm not sure what you mean by "fully standardized". Can an optional
>wordset be said to be fully standardized?

Definitely. Of course one might see the Forth-83 Controlled Reference
Words as optional words that have been fully standardized (the
glossary entries don't look any different from the Required Word Set,
and it would not make sense to require a specific meaning if that
meaning was not specified); anyway, Forth-83 makes that guarantee, and
that's good.

[Anton Ertl]

steph...@mpeforth.com (Stephen Pelc) writes:
>On Mon, 09 Jul 2012 15:35:49 GMT, an...@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>But I don't think that it would have made any difference for my
>>example: replace Hfp387.fth with the name of the lead package, and all
>>the points still stand.
>
>You seem to want a way to ensure that a wordset is present.

What I want is to run a standard program on several (claiming-to-be)
standard systems without fiddling around.

And I want to be able to write such programs, and as easily as
possible. If I need to tell the system that my program uses a
standard wordset, that's not as easy as possible, but if there was a
standard way to do that, it would be better than the status quo.

>At least VFX has a manual ... <grin>

Wow! So let's see:

- System A has a manual and makes all standard words it supports
available by default.

- System B has a manual and makes some words only available through an
ENVIRONMENT? query (and the manual describes that).

- System C has a manual and makes some words only available through
some system-specific INCLUDE (and the manual describes that).

- System D makes some words only available through some
system-specific INCLUDE or somesuch (and the manual is only in
German).

Since these are quality-of-implementation issues, it's up to the users
to evaluate these systems by quality (these are all systems running on
PCs). As a bonus question, which feature would the vendor of system C
emphasize?

[Albert van der Horst]

In article <jt2c4j$c4$1...@online.de>, Bernd Paysan <bernd....@gmx.de> wrote:
>Make ENVIRONMENT? obsolecent
>============================
>
>20120704 Initial proposal
>
>Problem
>=======
>
>The Forth-94 standard specified an environmental query system, which
>allows to query the system for capabilities and some constants, like PAD
>and HOLD buffer sizes and maximum integers (which can be calculated
>using standard words). This interface was not common practice when it
>was proposed, and it didn't attract followers afterwards. Almost 20
>years later, it's time to revisit this word, and look at current
>practice.
>

I introduced WANT some time ago, when Anton Ertl complained that
my REQUIRE didn't follow conventions.
It didn't catch on, but I wonder how good it would be to replace
ENVIRONMENT?
This could be a proposal, but I'm not crazy enough to propose
in earnest something that has not enough current practice.
I can testify though that it works very well in ciforth
to load fine grained (block sized) extensions.

What I like is the very short description and the very short
reference implementation.

""""""""""""""""""""""""""""""""""""""""""""""""""""
WANT "name1".."name#" ...
Documents that the program uses the words following :
name1 ... name# ...

RATIONALE:
WANT can be used in several ways:
1. merely as documentation
2. as an indication for a system to make the words
available, by loading files or blocks
3. to give a warning up front for all missing words at
the same time, instead of one by one
4. as an indication for a system to warn that the words
are present, but not standard conforming
5. names can be restricted to standard word sets, (except
CORE) or to words present in controlled libraries.
Or it can be used to make words available specific
to a particular system, which amounts to documenting
that it will not run except on that particular system.

It is recommended to precede WANT with
a specification where the words are from.
For example

( FILE ) WANT OPEN-FILE READ-FILE CLOSE-FILE
( FSL: bignum ) WANT BNUMBER B* B+
( VFX: carnal ) WANT sleezy-bot
( This program only runs on gforth ) WANT gforth

A minimalist implementation is:
: WANT POSTPONE \ ;

Libraries mentioned in a lot of portable programs would
slowly gain an official status.

""""""""""""""""""""""""""""""""""""""""""""""""""""

Notes:

- The important thing to realize is that only actual words
are allowed.

- If it is used to load automatically, failing loads are not allowed
to break off compilation (!), that would violate the behaviour
of WANT.

- actual words can be dummy words. A dummy word
like EXCEPTION-PRESENT could mean that all words of
exception are present. (It is created after the whole facility
loaded successfully.)
WANT CORE-EXT-PRESENT
would replace
S" CORE-EXT" ENVIRONMENT?
0= [IF] REQUIRE /oops/what/goes/here [THEN]

On a system where the core extensions are not available
the latter probably gives
ENVIRONMENT? Not a word or number
[IF] Not a word or number
REQUIRE Not a word or number
(interspersed with edits to include facilities.)

- in practice WANT F* FSIN will go a long way to guarantee that
the whole floating point is present

- failing loads must not break off, but it is certainly
allowed to give a warning like
"
WARNING can't make F+ available because [
/usr/lib/ciforth/float.fs ERROR #-2 no such file or directory.
]
"

Groetjes Albert

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

[BruceMcF]

On Jul 10, 3:20 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

> Hmm, I thought that, if a word is present in a standard system, it has
> to have the standard meaning, but I don't find such wording in
> Forth-94 (but maybe I am looking in the wrong place).

3 Usage says:
"A system shall provide all of the words defined in 6.1 Core Words. It
may also provide any words defined in the optional word sets and
extensions word sets. No standard word provided by a system shall
alter the system state in a way that changes the effect of execution
of any other standard word except as provided in this Standard. A
system may contain non-standard extensions, provided that they are
consistent with the requirements of this Standard."

Scattered through the "requirement of the standard" is all that about
how parsing works, which feeds through to when you get the
interpretation and compilation semantics, which feeds through to the
individual specifications of interpretation and compilation semantics.
So I read the last sentence of that paragraph that standard words
found must behave as specified, though they may have consistent non-
standard extensions.

[Mark Wills]

Bruce, to be explicit, are you saying (in effect) if a word is named
in the standard, and it is present in a system, its behaviour must be
as specified in the standard?

That is my interpretation, but Andrew has a slightly different
opinion, I think. To quote Andrew:

"Forth doesn't have reserved words. There's no barrier to using the
names of words in a wordset for some other purpose if that wordset
isn't loaded. The implementor is entirely free to behave as if those
wordsets they don't implement do not exist, or to implement them in
some nonstandard way as long as they fully implement everything they
claim to implement. That is all. "

Andrew is arguing that I am free to implement, say, F+ to perform a
reboot, even though the word is specified in the (optional) floating
point wordset.

As usual, the standard is (IMHO) ambiguous, hence the debate, I
suppose!

[Andrew Haley]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>> Hmm, I thought that, if a word is present in a standard system, it
>>> has to have the standard meaning, but I don't find such wording in
>>> Forth-94 (but maybe I am looking in the wrong place). The Forth-83
>>> controlled reference words had that property. It would be funny if
>>> Forth-94 provided less guarantees for its fully standardized words
>>> than Forth-83 for its controlled reference words.
>>
>>Forth-94 (and even more so, 200x) are too diverse for all of their
>>words to be treated as reserved.
>
> This is not about reserved words. This is about having a guaranteed
> meaning for standard-named words supplied by the system, if they are
> present.

Or, in English, reserving them for that purpose: they are treated as
reserved.

>>IMO the optional wordsets simply use too many useful names.
>>
>>For example, it makes sense to provide a fully IEEE-compatible
>>floating-point wordset (and I hope that will happen!) It will be much
>>harder to design if it has to reserve the names of all its words so
>>that Forth systems can no longer use those names for anything else.
>
> Why would it be much harder?

Because you'd have to do a poll of Forth systems with every name, or
those systems would no longer be able to use those names for their own
purpose. It's a really bad idea.

> Even if it is standard for a system to define a word with the name of
> an optional standard word, but different behaviour, it is an extremely
> bad idea.

IYO; not mine.

Andrew.

[Andrew Haley]

Mark Wills <markrob...@yahoo.co.uk> wrote:
> On Jul 10, 3:24?pm, BruceMcF <agil...@netscape.net> wrote:
>> On Jul 10, 3:20?am, an...@mips.complang.tuwien.ac.at (Anton Ertl)

Yeah. More realistically, to do a fixed-point additiom. I may be
wrong, but that's my take on it.

Andrew.

[Anton Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> This is not about reserved words. This is about having a guaranteed
>> meaning for standard-named words supplied by the system, if they are
>> present.
>
>Or, in English, reserving them for that purpose: they are treated as
>reserved.

This is a discussion about a programming language, and in this context
"reserved word" has a specific meaning different from the one you are
using. Actually even in English the programming language meaning
seems to be the primary one; at least it's the one I get when I type
"reserved word" into the English Wikipedia (en.wikipedia.org).

>>>IMO the optional wordsets simply use too many useful names.
>>>
>>>For example, it makes sense to provide a fully IEEE-compatible
>>>floating-point wordset (and I hope that will happen!) It will be much
>>>harder to design if it has to reserve the names of all its words so
>>>that Forth systems can no longer use those names for anything else.
>>
>> Why would it be much harder?
>
>Because you'd have to do a poll of Forth systems with every name, or
>those systems would no longer be able to use those names for their own
>purpose.

We have the RfD system for that. You propose the words with some
names (e.g., PARSE-WORD), and if a significant system already uses that
name with a different meaning, somebody will point that out, and you
can propose a different name (e.g., PARSE-NAME).

It's certainly better to sort these things out during the proposal
stage by naming the new words to avoid conflicts.

Take your example: If some system used F+ for fixed point addition,
and we standardize F+ to mean floating point addition, even if that
system can label itself a standard system, it could then not implement
the float wordset without breaking its user's code. In that case we
should better use a different float prefix, say R+ (to go with the r
stack item descriptor).

That's even before considering the effect of running a compliant
program on a (if you are right) compliant system and getting the wrong
result. Especially since we are about to eliminate the only (already
deficient) way of letting the program check whether the system
provides the wordsets (although, I guess with your approach, the
system might answer true for S" FLOATING" ENVIRONMENT?, but actually,
since it does not implement the float wordset, it could answer
anything to that question). Anyway, instead of sorting the names out
once when working through the proposal, you would have every user of
Forth have to sort such things out every time they want to run a
standard program on a standard system.

>> Even if it is standard for a system to define a word with the name of
>> an optional standard word, but different behaviour, it is an extremely
>> bad idea.
>
>IYO; not mine.

You think it's a good idea if a system claiming to be standard defines
F+ to do fixed point addition or to reboot the system?

Back to searching for the part where I could not find the wording: The

start of section 3 says:

|No standard word provided by a system shall alter the system state in
|a way that changes the effect of execution of any other standard word
|except as provided in this Standard. A system may contain non-standard
|extensions, provided that they are consistent with the requirements of
|this Standard.

Now you might argue that F+ is not a standard word, and that having F+
perform fixed-point addition is a non-standard extension that is
consistent with the requirements of Forth-94, but would others follow
your argument?

[Andrew Haley]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:

>>>> Forth-94 (and even more so, 200x) are too diverse for all of

>>>> their words to be treated as reserved.

>>>
>>> This is not about reserved words. This is about having a guaranteed
>>> meaning for standard-named words supplied by the system, if they are
>>> present.
>>
>>Or, in English, reserving them for that purpose: they are treated as
>>reserved.
>
> This is a discussion about a programming language, and in this context
> "reserved word" has a specific meaning different from the one you are
> using.

Which is why I said "treated as reserved". Please, let's move on.

>>>>IMO the optional wordsets simply use too many useful names.
>>>>
>>>>For example, it makes sense to provide a fully IEEE-compatible
>>>>floating-point wordset (and I hope that will happen!) It will be much
>>>>harder to design if it has to reserve the names of all its words so
>>>>that Forth systems can no longer use those names for anything else.
>>>
>>> Why would it be much harder?
>>
>>Because you'd have to do a poll of Forth systems with every name, or
>>those systems would no longer be able to use those names for their own
>>purpose.
>
> We have the RfD system for that. You propose the words with some
> names (e.g., PARSE-WORD), and if a significant system already uses that
> name with a different meaning, somebody will point that out, and you
> can propose a different name (e.g., PARSE-NAME).
>
> It's certainly better to sort these things out during the proposal
> stage by naming the new words to avoid conflicts.
>
> Take your example: If some system used F+ for fixed point addition,
> and we standardize F+ to mean floating point addition, even if that
> system can label itself a standard system, it could then not implement
> the float wordset without breaking its user's code.

It could, because the float wordset doesn't have to be installed by
default. You couldn't have fixed- and floating-point together, that's
true.

> In that case we should better use a different float prefix, say R+
> (to go with the r stack item descriptor).

I've seen . (as a suffix) used for that.

> That's even before considering the effect of running a compliant
> program on a (if you are right) compliant system and getting the wrong
> result.

I don't think that's possible. If you want a specific wordset, you
have to make sure that wordset is installed, by whatever means
necessary.

> Especially since we are about to eliminate the only (already
> deficient) way of letting the program check whether the system
> provides the wordsets (although, I guess with your approach, the
> system might answer true for S" FLOATING" ENVIRONMENT?, but
> actually, since it does not implement the float wordset, it could
> answer anything to that question).

Why do you say that? Surely it would return false or "don't know".

> Anyway, instead of sorting the names out once when working through
> the proposal, you would have every user of Forth have to sort such
> things out every time they want to run a standard program on a
> standard system.

But it isn't a standard program: it's a "Standard Program requiring
the <blah> wordset". If you don't have the <blah> wordset, all bets
are off.

>>> Even if it is standard for a system to define a word with the name of
>>> an optional standard word, but different behaviour, it is an extremely
>>> bad idea.
>>
>>IYO; not mine.
>
> You think it's a good idea if a system claiming to be standard defines
> F+ to do fixed point addition

Perhaps. I think it depends on the circumstances.

> or to reboot the system?

Probably not! But AFAIK it's not an issue of compliance.

> Back to searching for the part where I could not find the wording: The
> start of section 3 says:
>
> |No standard word provided by a system shall alter the system state in
> |a way that changes the effect of execution of any other standard word
> |except as provided in this Standard. A system may contain non-standard
> |extensions, provided that they are consistent with the requirements of
> |this Standard.
>
> Now you might argue that F+ is not a standard word, and that having F+
> perform fixed-point addition is a non-standard extension that is
> consistent with the requirements of Forth-94,

I might.

> but would others follow your argument?

If a system doesn't implement the FLOATING wordset, is its F+ really a
standard word by the above definition? I wouldn't have thought so.
If the TC had wanted all names in all wordsets to be "reserved" so
that they couldn't be used for anything else it would have been a good
idea to say so. Maybe we should say so now.

Andrew.

[Elizabeth D. Rather]

On 7/10/12 7:06 AM, Andrew Haley wrote:
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:

...

>>>>> IMO the optional wordsets simply use too many useful names.
>>>>>
>>>>> For example, it makes sense to provide a fully IEEE-compatible
>>>>> floating-point wordset (and I hope that will happen!) It will be much
>>>>> harder to design if it has to reserve the names of all its words so
>>>>> that Forth systems can no longer use those names for anything else.
>>>>
>>>> Why would it be much harder?
>>>
>>> Because you'd have to do a poll of Forth systems with every name, or
>>> those systems would no longer be able to use those names for their own
>>> purpose.
>>
>> We have the RfD system for that. You propose the words with some
>> names (e.g., PARSE-WORD), and if a significant system already uses that
>> name with a different meaning, somebody will point that out, and you
>> can propose a different name (e.g., PARSE-NAME).
>>
>> It's certainly better to sort these things out during the proposal
>> stage by naming the new words to avoid conflicts.
>>
>> Take your example: If some system used F+ for fixed point addition,
>> and we standardize F+ to mean floating point addition, even if that
>> system can label itself a standard system, it could then not implement
>> the float wordset without breaking its user's code.
>
> It could, because the float wordset doesn't have to be installed by
> default. You couldn't have fixed- and floating-point together, that's
> true.

Forth is more problematic in this regard than most languages simply
because of the vast extent of its namespace. A full system may have
several thousand words defined. Wordsets are some help in this regard,
but finding unique, meaningful names is always a challenge. A draconian
reserved-word scheme would render this challenge that much more onerous.

>> In that case we should better use a different float prefix, say R+
>> (to go with the r stack item descriptor).
>
> I've seen . (as a suffix) used for that.

Horrors! . suggests output! Don't mess up what mnemonic values we have!


Cheers,
Elizabeth

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

[Andrew Haley]

Elizabeth D. Rather <era...@forth.com> wrote:
> On 7/10/12 7:06 AM, Andrew Haley wrote:
>
>>> In that case we should better use a different float prefix, say R+
>>> (to go with the r stack item descriptor).
>>
>> I've seen . (as a suffix) used for that.
>
> Horrors! . suggests output! Don't mess up what mnemonic values we have!

Erm, wasn't *. in the Forth, Inc, fixed-point package?

Andrew.

[Elizabeth D. Rather]

:-) at one point Chuck liked to use . to suggest fractions, but I
complained bitterly!

[BruceMcF]

On Jul 10, 11:06 am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> Bruce, to be explicit, are you saying (in effect) if a word is named

> in the standard, and it is present in a system, its behavior must be

> as specified in the standard?

Only if you wish to claim compliance with Forth94.

Andrew claim is that "+" can expect two counted strings and
concatenate them in newly taken memory from the heap, freeing the
counted strings originally handed to it, "DUP" can store the top item
on the stack to a previously declared target address, and increment
the target address, without discarding the original value.

If you have license to *modify* the standard behavior of standard
words, then you can declare a fig-Forth system to be a Forth94 system
*just by saying, "with alternate specifications of some standard
words".

The standard does specify it, but not in one spot, since its the
entire aim of the standard that someone can write source and if they
color within the lines, the source does what the standard does on all
standard implementations that provide all words used.

As is well known and worked out in pedantic detail, Forth94 does not
reach that aim in every detail, but it reaches that aim as far as code
like:
: OFF ( addr -- ) 0 SWAP ! ;
: ON ( addr -- ) TRUE SWAP ! ;
...

VARIABLE myvar1 myvar1 OFF
VARIABLE myvar2
...

myvar1 @ 2* 1 OR myvar2 !

... goes, and Andrew's interpretation says, explicitly, that an
implementation can do anything it wants to with SWAP ! TRUE VARIABLE @
2* and OR and so there is no saying what exactly that last line will
do.

[Bernd Paysan]

Anton Ertl wrote:

> Back to searching for the part where I could not find the wording: The
> start of section 3 says:
>
> |No standard word provided by a system shall alter the system state in
> |a way that changes the effect of execution of any other standard word
> |except as provided in this Standard. A system may contain
> |non-standard extensions, provided that they are consistent with the
> |requirements of this Standard.

My interpretation or expectation for this is rather strict. If a
standard system implements a word named in one of the wordsets, it has
to follow the spec there. A system is free to leave wordsets away or
provide them as source code, so F+ might not be ready to use. However,
if there's a word F+ defined, it means it's the floating point worset
F+. And when you implement one word of Floating, you have to implement
all of Floating, but Float ext words are optional (you can cherry pick
which words you want to implement).

Stephens interpretation of documentation requirements ("we have a
manual") seems to be that in order to load the floating point wordset, a
portable program is expected to read the manual, and find out which file
to load. Well, Stephen actually thinks the programmer is portable and
will read this manual (we have ample proof that programmers don't read
manuals, which is also the reason why they don't like to write them -
it's wasted time :-), and then write a harness, which includes
Ndp387.fth from the appropriate library directory. This goes even
further, because in an out-of-the-box installation of VFX Forth, %LIB%
does not actually point at the VFX Forth library directory...

So, *if* we allow people to distribute standard words in source form,
then we also need a way to load that source form in such a way that a
standard program can do this in a portable manner.

require <wordset>

would be my proposal. No file extension (file extensions differ from
system to system), no path (pathes can even differ from one to the next
installation - e.g. Gforth now allows non-conflicting multi-arch
installations on one machine, where e.g. gforth-x86 finds its sources in
a different directory as gforth-x64, and of course, all these
directories also are version-specific, and you can have as many versions
of Gforth you like - all installed in a non-conflicting way).

[BruceMcF]

On Jul 10, 11:11 am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:

> I introduced WANT some time ago, when Anton Ertl complained that
> my REQUIRE didn't follow conventions.
> It didn't catch on, but I wonder how good it would be to replace
> ENVIRONMENT?

Now that I think I finally understand Anton's objection, I think an
extended REQUIRE could be defined that would be upwardly compatible
with the original standardized REQUIRE.

* If the file specified by c-addr u has been INCLUDED or REQUIRED
already, but not between the definition and execution of a marker (or
equivalent usage of FORGET), discard c-addr u; otherwise, perform the
function of INCLUDED.

* If no such file exists, compare the string to an implementation
specific database of words that may be made defined on demand, and if
found load the source required to make the word available.

It can't be done portably on top of an existing REQUIRED, since
REQUIRED does not return an ior, but it would be a compatible
extension of a portable REQUIRED.

[Elizabeth D. Rather]

On 7/10/12 4:02 AM, Anton Ertl wrote:
> steph...@mpeforth.com (Stephen Pelc) writes:
>> On Mon, 09 Jul 2012 15:35:49 GMT, an...@mips.complang.tuwien.ac.at
>> (Anton Ertl) wrote:
>>
>>> But I don't think that it would have made any difference for my
>>> example: replace Hfp387.fth with the name of the lead package, and all
>>> the points still stand.
>>
>> You seem to want a way to ensure that a wordset is present.
>
> What I want is to run a standard program on several (claiming-to-be)
> standard systems without fiddling around.
>
> And I want to be able to write such programs, and as easily as
> possible. If I need to tell the system that my program uses a
> standard wordset, that's not as easy as possible, but if there was a
> standard way to do that, it would be better than the status quo.

The obvious way to achieve this is to publish a standard model that
everyone has to follow. Some languages work this way. However, by
removing the required model of Forth83, we have opened the door to
faster, more powerful implementation techniques. Is this a bad thing,
even though some ambiguities exist as a result?

I ask you, those of you who work with many languages, how does it work
with them? Are there significant C programs, for example, that will
compile on any compiler and run correctly, without any "fiddling
around"? I remember some years ago Stephen told me that MPE had to
maintain at least 5 different C compilers to support their C harnesses.

>> At least VFX has a manual ... <grin>
>
> Wow! So let's see:
>
> - System A has a manual and makes all standard words it supports
> available by default.
>
> - System B has a manual and makes some words only available through an
> ENVIRONMENT? query (and the manual describes that).
>
> - System C has a manual and makes some words only available through
> some system-specific INCLUDE (and the manual describes that).
>
> - System D makes some words only available through some
> system-specific INCLUDE or somesuch (and the manual is only in
> German).
>
> Since these are quality-of-implementation issues, it's up to the users
> to evaluate these systems by quality (these are all systems running on
> PCs). As a bonus question, which feature would the vendor of system C
> emphasize?

Are you suggesting that an implementer shouldn't actually *expect* users
to read the Fine Manual? :-)

Every system provider has a target market in mind, and chooses which
features to include automatically and which to make optional with that
target market in mind, not to mention what language to write the manual
in. Yes, these are all quality-of-implementation issues, but what
constitutes quality depends in the individual needs of the users. The
more you enforce conformity in these matters the more difficult it
becomes to provide an "ideal" product for particular target markets.

[Stephen Pelc]

On Wed, 11 Jul 2012 02:38:26 +0200, Bernd Paysan <bernd....@gmx.de>
wrote:

>Stephens interpretation of documentation requirements ("we have a
>manual") seems to be that in order to load the floating point wordset, a
>portable program is expected to read the manual, and find out which file
>to load.

MPE's interpretation, please.

The standard says nothing about what files are called. Where should
we tell you, or do we rely on telepathy?

> Well, Stephen actually thinks the programmer is portable and
>will read this manual (we have ample proof that programmers don't read
>manuals, which is also the reason why they don't like to write them -
>it's wasted time :-),

In my opinion, undocumented Forths were substantially responsible
for the bad reputation of Forth 20 years ago.

>and then write a harness, which includes
>Ndp387.fth from the appropriate library directory.

This is basically the way that all successful libraries have gone.

> This goes even
>further, because in an out-of-the-box installation of VFX Forth, %LIB%
>does not actually point at the VFX Forth library directory...

It'll get fixed ... even for people who cannot be bothered to read
the installation chapter on how to set up VFX Forth, which is
written for people who have substantial applications to write.

>So, *if* we allow people to distribute standard words in source form,
>then we also need a way to load that source form in such a way that a
>standard program can do this in a portable manner.
>
>require <wordset>
>
>would be my proposal.

REQUIRE REQUIRES and REQUIRED are already claimed in several
systems. How about
load-wordset <name>

If you think this stuff is important, you are spending too much
time comparing systems and not enough time writing applications
that get the best out of the Forth. The guts of Forth are
adequately standardised now. The important job is the provision
of high level libraries. The current standards process is not
the right one for standardising libraries, which should be
defined by a reference implementation and its documentation.

[Rod Pemberton]

"Anton Ertl" <an...@mips.complang.tuwien.ac.at> wrote in message
news:2012Jul1...@mips.complang.tuwien.ac.at...

> And I want to be able to write such programs, and as easily as
> possible. If I need to tell the system that my program uses a
> standard wordset, that's not as easy as possible, but if there was a
> standard way to do that, it would be better than the status quo.
>

Are you saying Hayes Core tests are insufficient to ensure proper compliance
or identical functionality of ANS Forth words? That's heresy ... :-)

If so, write a program testing compliance of all the words you would like to
use. Then, test all the platforms you consider to be respectable. Finally,
use only the words that are identical across multiple platforms. If that's
not possible, you'll need some adaptive code.

Maybe, start first by identifying Forths you respect. ... gForth? MPE?
bigForth?

Next, get copies of them to test with...

Next, get some tests... e.g., from gForth or Hayes Core.


Rod Pemberton

[Rod Pemberton]

"Elizabeth D. Rather" <era...@forth.com> wrote in message
news:D5OdncVxHtlcRGHS...@supernews.com...

> Are there significant C programs, for example, that will
> compile on any compiler and run correctly, without any "fiddling
> around"? I remember some years ago Stephen told me that MPE had to
> maintain at least 5 different C compilers to support their C harnesses.

That seems like alot. Most likely, that's required for supporting different
operating systems APIs and their GUIs, and not a C issue. I.e., probably
should've picked a portable GUI library, e.g., libSDL, GTK+, Qt, Tcl/Tk,
wxWidgets, etc.

In general, I'd think you'd need one C version for ANSI C, and another for C
on POSIX, _if_ POSIX features are used. Using ANSI C should eliminate the
need for some of the other versions. Minimizing use of the C libraries will
also help, i.e., code your own routines... (generally not recommended by C
experts). If ANSI C is not an option, you might also need other versions
for C99, or for C++, etc. 16-bit DOS is also a special case.


Rod Pemberton

[Mark Wills]

On Jul 11, 7:39 am, stephen...@mpeforth.com (Stephen Pelc) wrote:
> On Wed, 11 Jul 2012 02:38:26 +0200, Bernd Paysan <bernd.pay...@gmx.de>

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

load-wordset sounds okay. But, actually (forgive my nieve questions),
I don't understand the concept of loading a wordset. I understand
loading an ASCII text file, which will define a new wordset.

I don't see what the distinction is. How is load-wordset (or whatever)
different from INCLUDED or INCLUDE ?

[Andrew Haley]

Elizabeth D. Rather <era...@forth.com> wrote:
> On 7/10/12 4:02 AM, Anton Ertl wrote:
>> steph...@mpeforth.com (Stephen Pelc) writes:
>>> On Mon, 09 Jul 2012 15:35:49 GMT, an...@mips.complang.tuwien.ac.at
>>> (Anton Ertl) wrote:
>>>
>>>> But I don't think that it would have made any difference for my
>>>> example: replace Hfp387.fth with the name of the lead package, and all
>>>> the points still stand.
>>>
>>> You seem to want a way to ensure that a wordset is present.
>>
>> What I want is to run a standard program on several (claiming-to-be)
>> standard systems without fiddling around.
>>
>> And I want to be able to write such programs, and as easily as
>> possible. If I need to tell the system that my program uses a
>> standard wordset, that's not as easy as possible, but if there was a
>> standard way to do that, it would be better than the status quo.
>
> The obvious way to achieve this is to publish a standard model that
> everyone has to follow. Some languages work this way. However, by
> removing the required model of Forth83, we have opened the door to
> faster, more powerful implementation techniques. Is this a bad thing,
> even though some ambiguities exist as a result?
>
> I ask you, those of you who work with many languages, how does it work
> with them? Are there significant C programs, for example, that will
> compile on any compiler and run correctly, without any "fiddling
> around"?

No.

What we really do require in Forth, though is some way to say

REQUIRE FLOATING

Andrew.

[Andrew Haley]

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

> If you think this stuff is important, you are spending too much time
> comparing systems and not enough time writing applications that get
> the best out of the Forth. The guts of Forth are adequately
> standardised now.

I agree with you. I can't imagine that this is a big deal for any
working programmers using Forth.

Andrew.

[Andrew Haley]

Mark Wills <markrob...@yahoo.co.uk> wrote:

> load-wordset sounds okay. But, actually (forgive my nieve questions),
> I don't understand the concept of loading a wordset. I understand
> loading an ASCII text file, which will define a new wordset.
>
> I don't see what the distinction is. How is load-wordset (or whatever)
> different from INCLUDED or INCLUDE ?

You'd have to standardize filenames and a load path.

Andrew.

[Mark Wills]

On Jul 11, 10:21 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:

So:

load-wordset floating-point

would be standardised, in the sense that "load-wordset" and "floating-
point" are standardised words, and whatever machinations are required
in the background with respect to paths and filenames etc to perform
the operation are system specific.

Okay, got it. Thanks.

[Anton Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>> That's even before considering the effect of running a compliant
>> program on a (if you are right) compliant system and getting the wrong
>> result.
>
>I don't think that's possible. If you want a specific wordset, you
>have to make sure that wordset is installed, by whatever means
>necessary.

And if you don't, what happens? With your system with non-standard F+
you get the wrong result. And yet both system and program are labeled
as standard-compliant.

>> Especially since we are about to eliminate the only (already
>> deficient) way of letting the program check whether the system
>> provides the wordsets (although, I guess with your approach, the
>> system might answer true for S" FLOATING" ENVIRONMENT?, but
>> actually, since it does not implement the float wordset, it could
>> answer anything to that question).
>
>Why do you say that? Surely it would return false or "don't know".

What makes you so sure? If, as you claim, the system is allowed to
produce any behaviour for words outside the wordsets it supports, I
would expect the same to hold for environmental queries. Since the
FLOATING query is defined in the section on the float wordset (in
12.3.4, to be exact), the system wo would have the same liberties for
the query as for F+; e.g., the system could answer true for the
FLOATING query if a fixed-point wordset is present.

>> Anyway, instead of sorting the names out once when working through
>> the proposal, you would have every user of Forth have to sort such
>> things out every time they want to run a standard program on a
>> standard system.
>
>But it isn't a standard program: it's a "Standard Program requiring
>the <blah> wordset". If you don't have the <blah> wordset, all bets
>are off.

So how does the program tell the system that it requires the <blah>
wordset? And how can it ask the system if it has the <blah> wordset?

Leave it to manual labor by the user? Yeah, right!

>> Back to searching for the part where I could not find the wording: The
>> start of section 3 says:
>>
>> |No standard word provided by a system shall alter the system state in
>> |a way that changes the effect of execution of any other standard word
>> |except as provided in this Standard. A system may contain non-standard
>> |extensions, provided that they are consistent with the requirements of
>> |this Standard.
>>
>> Now you might argue that F+ is not a standard word, and that having F+
>> perform fixed-point addition is a non-standard extension that is
>> consistent with the requirements of Forth-94,
>
>I might.
>
>> but would others follow your argument?
>
>If a system doesn't implement the FLOATING wordset, is its F+ really a
>standard word by the above definition? I wouldn't have thought so.

I would. It's defined in the standard.

>If the TC had wanted all names in all wordsets to be "reserved" so
>that they couldn't be used for anything else it would have been a good
>idea to say so. Maybe we should say so now.

Yes.

[Anton Ertl]

Bernd Paysan <bernd....@gmx.de> writes:
>Stephens interpretation of documentation requirements ("we have a
>manual") seems to be that in order to load the floating point wordset, a
>portable program is expected to read the manual, and find out which file
>to load. Well, Stephen actually thinks the programmer is portable and
>will read this manual (we have ample proof that programmers don't read
>manuals, which is also the reason why they don't like to write them -
>it's wasted time :-), and then write a harness, which includes
>Ndp387.fth from the appropriate library directory.

Why would the programmer read the VFX manual? He has written a
standard program, and may not even be a user of VFX. The burden of
fiddling around then falls on every user; well, at least every VFX
user, other systems are designed to eliminate or at least minimize
such burdens.

>So, *if* we allow people to distribute standard words in source form,
>then we also need a way to load that source form in such a way that a
>standard program can do this in a portable manner.
>
>require <wordset>
>
>would be my proposal.

REQIRE is already standardized, with a different meaning. Don't
overload it, use a different name (LOAD-WORDSET has been suggested).
If some implementation implements LOAD-WORDSET as REQUIRE, that's
fine, but is no reason to fail to differentiate between the two.

[Andrew Haley]

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:
>>> That's even before considering the effect of running a compliant
>>> program on a (if you are right) compliant system and getting the wrong
>>> result.
>>
>>I don't think that's possible. If you want a specific wordset, you
>>have to make sure that wordset is installed, by whatever means
>>necessary.
>
> And if you don't, what happens?

You've broken your side of the contract.

>>> Especially since we are about to eliminate the only (already
>>> deficient) way of letting the program check whether the system
>>> provides the wordsets (although, I guess with your approach, the
>>> system might answer true for S" FLOATING" ENVIRONMENT?, but
>>> actually, since it does not implement the float wordset, it could
>>> answer anything to that question).
>>
>>Why do you say that? Surely it would return false or "don't know".
>
> What makes you so sure? If, as you claim, the system is allowed to
> produce any behaviour for words outside the wordsets it supports, I
> would expect the same to hold for environmental queries.

I wouldn't. I don't think this logically follows at all.

> Since the FLOATING query is defined in the section on the float
> wordset (in 12.3.4, to be exact), the system wo would have the same
> liberties for the query as for F+; e.g., the system could answer
> true for the FLOATING query if a fixed-point wordset is present.

But this makes no sense as described.

>>> Anyway, instead of sorting the names out once when working through
>>> the proposal, you would have every user of Forth have to sort such
>>> things out every time they want to run a standard program on a
>>> standard system.
>>
>>But it isn't a standard program: it's a "Standard Program requiring
>>the <blah> wordset". If you don't have the <blah> wordset, all bets
>>are off.
>
> So how does the program tell the system that it requires the <blah>
> wordset? And how can it ask the system if it has the <blah> wordset?

It can't. It's up to the user to read the documentation.

> Leave it to manual labor by the user? Yeah, right!

That's exactly what the standard says. It's like all programming
languages: a language standard doesn't specify a bunch of things,
including how to set up the environmrnt, how to translate a program,
and so on.

Andrew.

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:
>On 7/10/12 4:02 AM, Anton Ertl wrote:
>> steph...@mpeforth.com (Stephen Pelc) writes:
>> What I want is to run a standard program on several (claiming-to-be)
>> standard systems without fiddling around.
>>
>> And I want to be able to write such programs, and as easily as
>> possible. If I need to tell the system that my program uses a
>> standard wordset, that's not as easy as possible, but if there was a
>> standard way to do that, it would be better than the status quo.
>
>The obvious way to achieve this is to publish a standard model that
>everyone has to follow. Some languages work this way. However, by
>removing the required model of Forth83, we have opened the door to
>faster, more powerful implementation techniques. Is this a bad thing,
>even though some ambiguities exist as a result?

That's a red herring. I did not ask for a standard model, I asked for
being able to run a standard program on a standard system without
fiddling around. Since the standard does not require a particular
implementation model, that's possible (and not particularly difficult)
without a standard model. The issues being discussed also have
nothing to do with a standard model, but with ensuring that certain
word(set)s are present.

>I ask you, those of you who work with many languages, how does it work
>with them? Are there significant C programs, for example, that will
>compile on any compiler and run correctly, without any "fiddling
>around"?

Any compiler? I don't know. But for serious compilers, it works
pretty well, much, much, much, much better than in Forth. Not just do
they compile the same source code unchanged, they are compatible at
the OS command line level (Forth systems are very different there),
and that's not covered in the standard. Also directories for #include
works the same way for all serious compilers (also not standardized),
so you can organize your portable source code in directories, unlike
Forth.

The attitude is completely different. Instead of considering source
code compatibility an outlandish idea like some Forth vendors do
(despite taking themselves seriously), it's a major goal, and the
source code in question is not restricted to the C code, but includes
the Makefiles as well (that's why the command line options have to be
compatible).

The C part of Gforth uses lots of GNU C extensions (i.e., it's not
standard C). Compiling that with a different compiler is far beyond
what I am asking for Forth here, yet I tried using a number of
alternative C compilers instead of GCC over the years: The Intel C
compiler crashed (many years ago. maybe it has become better in the
meantime). Tcc did not like some of the GNU C stuff, but that could
be worked around in about the amount of time it takes to get a
standard Forth program to run on a standard Forth system. LLVM did
not like one particular usage of a GNU C extension, and that could be
fixed quickly. Oh, and I certainly did not need to read a PDF manual
for any of this.

>>> At least VFX has a manual ... <grin>
>>
>> Wow! So let's see:
>>
>> - System A has a manual and makes all standard words it supports
>> available by default.
>>
>> - System B has a manual and makes some words only available through an
>> ENVIRONMENT? query (and the manual describes that).
>>
>> - System C has a manual and makes some words only available through
>> some system-specific INCLUDE (and the manual describes that).
>>
>> - System D makes some words only available through some
>> system-specific INCLUDE or somesuch (and the manual is only in
>> German).
>>
>> Since these are quality-of-implementation issues, it's up to the users
>> to evaluate these systems by quality (these are all systems running on
>> PCs). As a bonus question, which feature would the vendor of system C
>> emphasize?
>
>Are you suggesting that an implementer shouldn't actually *expect* users
>to read the Fine Manual? :-)

If a user has to read the manual of a standard system to run a
standard program, there's something wrong with the standard.

>Every system provider has a target market in mind, and chooses which
>features to include automatically and which to make optional with that
>target market in mind, not to mention what language to write the manual
>in. Yes, these are all quality-of-implementation issues, but what
>constitutes quality depends in the individual needs of the users. The
>more you enforce conformity in these matters the more difficult it
>becomes to provide an "ideal" product for particular target markets.

There are many ways in which a product can differentiate itself from
others, while still being able to run standard code without fiddling.
E.g., VFX produces fast code, while SwiftForth is pleasant to use.
And don't tell me that memory in a PC is so limited that VFX omits
floating-point for that reason.

[Alex McDonald]

On Jul 11, 3:04 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

NEEDS floating

[Anton Ertl]

steph...@mpeforth.com (Stephen Pelc) writes:
>On Wed, 11 Jul 2012 02:38:26 +0200, Bernd Paysan <bernd....@gmx.de>
>wrote:

>>and then write a harness, which includes
>>Ndp387.fth from the appropriate library directory.
>
>This is basically the way that all successful libraries have gone.

We don't need a standard for that. So the standard has failed.

>>So, *if* we allow people to distribute standard words in source form,
>>then we also need a way to load that source form in such a way that a
>>standard program can do this in a portable manner.
>>
>>require <wordset>
>>
>>would be my proposal.
>
>REQUIRE REQUIRES and REQUIRED are already claimed in several
>systems.

And in Forth200x.

> How about
> load-wordset <name>

Definitely better.

>If you think this stuff is important, you are spending too much
>time comparing systems

If portability is unimportant, then we are all spending too much time
working on the standard.

[Anton Ertl]

That's exactly the opposite of portability through standards.

[Andrew Haley]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> "Elizabeth D. Rather" <era...@forth.com> writes:
>
>>I ask you, those of you who work with many languages, how does it work
>>with them? Are there significant C programs, for example, that will
>>compile on any compiler and run correctly, without any "fiddling
>>around"?
>
> Any compiler? I don't know. But for serious compilers, it works
> pretty well, much, much, much, much better than in Forth. Not just do
> they compile the same source code unchanged, they are compatible at
> the OS command line level (Forth systems are very different there),
> and that's not covered in the standard. Also directories for #include
> works the same way for all serious compilers (also not standardized),
> so you can organize your portable source code in directories, unlike
> Forth.

So, you've proved that none of this needs to be standardized: it just
needs common practice.

> The attitude is completely different. Instead of considering source
> code compatibility an outlandish idea like some Forth vendors do
> (despite taking themselves seriously), it's a major goal, and the
> source code in question is not restricted to the C code, but
> includes the Makefiles as well (that's why the command line options
> have to be compatible).

Not really, no. Makefiles are a little bit portable across unices,
but even that isn't great. Writing portable makefiles is so hard that
most people don't bother.

>>Are you suggesting that an implementer shouldn't actually *expect* users
>>to read the Fine Manual? :-)
>
> If a user has to read the manual of a standard system to run a
> standard program, there's something wrong with the standard.

IMHO that claim is preposterous. The idea of a language standard is
not to remove the requirement to RTFM. IMHO, YMMV...

Andrew.

[Anton Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>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:
>>>> That's even before considering the effect of running a compliant
>>>> program on a (if you are right) compliant system and getting the wrong
>>>> result.
>>>
>>>I don't think that's possible. If you want a specific wordset, you
>>>have to make sure that wordset is installed, by whatever means
>>>necessary.
>>
>> And if you don't, what happens?
>
>You've broken your side of the contract.

Which contract? As a programmer I have no contract with an arbitrary
Forth system. The only thing I have is the Forth standard, and the
only way the standard has for asking for a specific wordset is a
wordset query (and that's going away).

>>>> Especially since we are about to eliminate the only (already
>>>> deficient) way of letting the program check whether the system
>>>> provides the wordsets (although, I guess with your approach, the
>>>> system might answer true for S" FLOATING" ENVIRONMENT?, but
>>>> actually, since it does not implement the float wordset, it could
>>>> answer anything to that question).
>>>
>>>Why do you say that? Surely it would return false or "don't know".
>>
>> What makes you so sure? If, as you claim, the system is allowed to
>> produce any behaviour for words outside the wordsets it supports, I
>> would expect the same to hold for environmental queries.
>
>I wouldn't. I don't think this logically follows at all.

Could you explain your logical reasoning that leads you to believe
that F+ is not a standard word, yet FLOATING is a standard query
(i.e., that Forth systems without the float wordset must not answer
with "true")?

>> Since the FLOATING query is defined in the section on the float
>> wordset (in 12.3.4, to be exact), the system wo would have the same
>> liberties for the query as for F+; e.g., the system could answer
>> true for the FLOATING query if a fixed-point wordset is present.
>
>But this makes no sense as described.

True, but saying that F+ is not a standard word does not make sense,
either.

>> Leave it to manual labor by the user? Yeah, right!
>
>That's exactly what the standard says. It's like all programming
>languages: a language standard doesn't specify a bunch of things,
>including how to set up the environmrnt, how to translate a program,
>and so on.

And yet in other languages I can drop in one compiler as a replacement
of another when compiling standard programs, and it works. No
fiddling required.

[Andrew Haley]

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:
>>>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>>>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>>>> That's even before considering the effect of running a compliant
>>>>> program on a (if you are right) compliant system and getting the wrong
>>>>> result.
>>>>
>>>>I don't think that's possible. If you want a specific wordset, you
>>>>have to make sure that wordset is installed, by whatever means
>>>>necessary.
>>>
>>> And if you don't, what happens?
>>
>>You've broken your side of the contract.
>
> Which contract?

The one that says that a standard Forth system may not be present and
if you need one it's time to RTFM.

> As a programmer I have no contract with an arbitrary Forth system.
> The only thing I have is the Forth standard,

No, that's not true. If that's a standard system it's documented.

> and the only way the standard has for asking for a specific wordset
> is a wordset query (and that's going away).

>>>>> Especially since we are about to eliminate the only (already
>>>>> deficient) way of letting the program check whether the system
>>>>> provides the wordsets (although, I guess with your approach, the
>>>>> system might answer true for S" FLOATING" ENVIRONMENT?, but
>>>>> actually, since it does not implement the float wordset, it could
>>>>> answer anything to that question).
>>>>
>>>>Why do you say that? Surely it would return false or "don't know".
>>>
>>> What makes you so sure? If, as you claim, the system is allowed to
>>> produce any behaviour for words outside the wordsets it supports, I
>>> would expect the same to hold for environmental queries.
>>
>>I wouldn't. I don't think this logically follows at all.
>
> Could you explain your logical reasoning that leads you to believe
> that F+ is not a standard word, yet FLOATING is a standard query
> (i.e., that Forth systems without the float wordset must not answer
> with "true")?

I think I already explained why I don't believe that F+ is necessarily
a standard word in a system without the FLOATING wordset, so let's
talk about ENVIRONMENT? The standard says

The combination of 6.1.1345 ENVIRONMENT?, 11.6.1.2165 S",
15.6.2.2532 [IF], 15.6.2.2531 [ELSE], and 15.6.2.2533 [THEN]
constitutes an effective suite of words for conditional compilation
that works in interpretation state.

and logically this would not be possible if ENVIRONMENT? returned true
for wordsets that were not loaded.

>>> Leave it to manual labor by the user? Yeah, right!
>>
>>That's exactly what the standard says. It's like all programming
>>languages: a language standard doesn't specify a bunch of things,

>>including how to set up the environment, how to translate a program,

>>and so on.
>
> And yet in other languages I can drop in one compiler as a
> replacement of another when compiling standard programs, and it
> works. No fiddling required.

If you're lucky, maybe. There is no guarantee, but there is a lot of
tradition based on UNIX. Let's try something really simple that is
undoubtedly Standard C:

#include <stdio.h>
#include <math.h>
#include <stdlib.h>

double two = 2.0;

int main(int argc, char **argv) {
printf("%g\n", sqrt(two));
exit(0);
}

$ cc t.c
/tmp/cc644TlH.o: In function `main':
t.c:(.text+0x2c): undefined reference to `sqrt'

What do you do now? The C standard is of no help; your only recourse
is to RTFM. UNIX traditionally does this, but other systems don't,
and it confuses the hell out of people. Portability is not as easy as
you suggest.

Andrew.

[Josh Grams]

Andrew Haley wrote: <-sadnYHCP5XQ2GDS...@supernews.com>

Er...it is a *major* barrier to using Forth for anything where you might
want random users to be able to run your program under a Forth system
that you haven't specifically ported your program to. That is most of
the programming that I'm interested in.

If I want to write a program that runs (with no fiddling around) on
Windows, Linux, MacOS, and Android, Forth is simply out of the question,
no matter how suitable it may be for writing the core functionality of
the program, because the effort involved in porting it to who-knows how
many different Forth systems swamps everything else.

I don't see a plausible way for this to improve other than to have the
Forth user community provide a package manager and package database
which can semi-automatically load dependencies (and maybe even download
and install them). Even if most of the Forth implementors agree on some
proposal, hardly any of the commonly-used free Forth systems are still
making official releases with any sort of frequency, so it will take a
long time to get most people using versions that include the new
feature.

--Josh

[Andrew Haley]

Josh Grams <jo...@qualdan.com> wrote:
> Andrew Haley wrote: <-sadnYHCP5XQ2GDS...@supernews.com>
>> Stephen Pelc <steph...@mpeforth.com> wrote:
>>
>>> If you think this stuff is important, you are spending too much time
>>> comparing systems and not enough time writing applications that get
>>> the best out of the Forth. The guts of Forth are adequately
>>> standardised now.
>>
>> I agree with you. I can't imagine that this is a big deal for any
>> working programmers using Forth.
>
> Er...it is a *major* barrier to using Forth for anything where you
> might want random users to be able to run your program under a Forth
> system that you haven't specifically ported your program to. That
> is most of the programming that I'm interested in.

What application area is this? Something that requires no GUI, no
OS-specific accesses of any kind? Where you can provide your users
with perfectly portable source code?

> If I want to write a program that runs (with no fiddling around) on
> Windows, Linux, MacOS, and Android, Forth is simply out of the
> question,

As is pretty much every other language. Maybe Java is just about
there, but even then it's a stretch. Java does it by having an
enormous library that's intended to provide a portable layer over
operating system services.

Andrew.

[Mark Wills]

On Jul 11, 9:24 pm, Josh Grams <j...@qualdan.com> wrote:
>
> If I want to write a program that runs (with no fiddling around) on
> Windows, Linux, MacOS, and Android, Forth is simply out of the question,
> no matter how suitable it may be for writing the core functionality of
> the program, because the effort involved in porting it to who-knows how
> many different Forth systems swamps everything else.
>

Yeah, but hang on a minute - Forth is by no means the only offender in
that regard!

[Rod Pemberton]

"Anton Ertl" <an...@mips.complang.tuwien.ac.at> wrote in message
news:2012Jul1...@mips.complang.tuwien.ac.at...
> "Rod Pemberton" <do_no...@notemailnot.cmm> writes:
> >"Anton Ertl" <an...@mips.complang.tuwien.ac.at> wrote in message
> >news:2012Jul1...@mips.complang.tuwien.ac.at...
> >
> >> And I want to be able to write such programs, and as easily as
> >> possible. If I need to tell the system that my program uses a
> >> standard wordset, that's not as easy as possible, but if there was a
> >> standard way to do that, it would be better than the status quo.
> >>
> >
> >Are you saying Hayes Core tests are insufficient to ensure proper
> >compliance or identical functionality of ANS Forth words? That's
> >heresy ... :-)
> >
> >If so, write a program testing compliance of all the words you would like
> >to use. Then, test all the platforms you consider to be respectable.
> >Finally, use only the words that are identical across multiple platforms.
> >If that's not possible, you'll need some adaptive code.
> >
> >Maybe, start first by identifying Forths you respect. ... gForth? MPE?
> >bigForth?
> >
> >Next, get copies of them to test with...
> >
> >Next, get some tests... e.g., from gForth or Hayes Core.
>
> That's exactly the opposite of portability through standards.
>

How does a standard ensure portability is compatible across multiple
platforms without the ability to test the implementation(s)?

Do you believe standards describe enough to implement code which is
portable?

1) I don't. They don't contain implementation details, requirements,
historical method of implementation, virtual machine description, etc.
2) At best, only 30% of the code will be portable, unless all platforms are
the exact same platform, e.g., all x86.

Standards abstract the code from the implementation so that it is portable.
However, without those implementation details and without testing,
variations in implementation arise.

Of course, Forth standards were more concrete, e.g., Forth-79 and Forth-83.
Yet, the Forth community seems to hate those early standards because they
were inflexible, or couldn't adapt to changes in architecture.


Rod Pemberton

[Stephen Pelc]

On 11 Jul 2012 20:24:42 GMT, Josh Grams <jo...@qualdan.com> wrote:

>Er...it is a *major* barrier to using Forth for anything where you might
>want random users to be able to run your program under a Forth system
>that you haven't specifically ported your program to. That is most of
>the programming that I'm interested in.

You'll have to be more detailed than that for the Forth200x people
to take any action or make proposals. In particular, I believe
that common practice is important and should emerge for
standardisation. Say what is missing and say what is useful.

Professionally, MPE tends to deal with larger applications
that take advantage of features that are not yet standardised.
Hence, it is not important to us that we have to insert one
line in a build file to get a feature. Many of our commercial
clients are much more interested in getting a really good
string package with parameterisation than in the details of
simplifying load files.

I appreciate that you need simplified load files, but we have
to get further than complaining about other people's file names.

[Mark Wills]

On Jul 11, 1:38 am, Bernd Paysan <bernd.pay...@gmx.de> wrote:

> Anton Ertl wrote:
> > Back to searching for the part where I could not find the wording: The
> > start of section 3 says:
>
> > |No standard word provided by a system shall alter the system state in
> > |a way that changes the effect of execution of any other standard word
> > |except as provided in this Standard. A system may contain
> > |non-standard extensions, provided that they are consistent with the
> > |requirements of this Standard.
>

> My interpretation or expectation for this is rather strict.  If a
> standard system implements a word named in one of the wordsets, it has
> to follow the spec there.  A system is free to leave wordsets away or
> provide them as source code, so F+ might not be ready to use.  However,
> if there's a word F+ defined, it means it's the floating point worset
> F+.  And when you implement one word of Floating, you have to implement
> all of Floating, but Float ext words are optional (you can cherry pick
> which words you want to implement).
>

I agree with this entirely. You cannot define F+ for your own uses.
It's reserved. It's a member of the floating-point wordset. Leave it
alone. If you define it as something else, your system is no longer
compliant. End of. The standard text (200x) should be modified to make
this point clear, so that discussions such as this can be avoided!

I note that Andrew has a different opinion.

> Stephens interpretation of documentation requirements ("we have a
> manual") seems to be that in order to load the floating point wordset, a
> portable program is expected to read the manual, and find out which file
> to load.  Well, Stephen actually thinks the programmer is portable and
> will read this manual (we have ample proof that programmers don't read
> manuals, which is also the reason why they don't like to write them -

> it's wasted time :-), and then write a harness, which includes
> Ndp387.fth from the appropriate library directory.  This goes even

> further, because in an out-of-the-box installation of VFX Forth, %LIB%
> does not actually point at the VFX Forth library directory...
>

If there's no standard way to load a wordset, then clearly the only
thing the *user* can do is RTFM. A *standard program* will be able to
load a wordset in a standard way when a proposal has been made and
ratified/embodied within the standard. In the meantime, I'm with
Stephen. Nothing else you can do.

> So, *if* we allow people to distribute standard words in source form,
> then we also need a way to load that source form in such a way that a
> standard program can do this in a portable manner.
>
> require <wordset>
>

The word require is ambiguous. It doesn't infer that a wordset must
follow. The user might think he can supply a filename (containing
general-purpose Forth source) here.

I would suggest:

WORDSET: <wordset>
or
GET-WORDSET <wordset>

More explicit. Please, let's be explicit.


> No file extension (file extensions differ from
> system to system), no path (pathes can even differ from one to the next
> installation - e.g. Gforth now allows non-conflicting multi-arch
> installations on one machine, where e.g. gforth-x86 finds its sources in
> a different directory as gforth-x64, and of course, all these
> directories also are version-specific, and you can have as many versions
> of Gforth you like - all installed in a non-conflicting way).
>

Agreed. That would be a neat feature. Just supply the wordset name.
The rest is up to the system. Like it.

[Anton Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> "Elizabeth D. Rather" <era...@forth.com> writes:
>>
>>>I ask you, those of you who work with many languages, how does it work
>>>with them? Are there significant C programs, for example, that will
>>>compile on any compiler and run correctly, without any "fiddling
>>>around"?
>>
>> Any compiler? I don't know. But for serious compilers, it works
>> pretty well, much, much, much, much better than in Forth. Not just do
>> they compile the same source code unchanged, they are compatible at
>> the OS command line level (Forth systems are very different there),
>> and that's not covered in the standard. Also directories for #include
>> works the same way for all serious compilers (also not standardized),
>> so you can organize your portable source code in directories, unlike
>> Forth.
>
>So, you've proved that none of this needs to be standardized: it just
>needs common practice.

You have just proved that we don't need standards. We only
standardize common practice, and since (according to you) we don't
need to standardize common practice, we don't need to standardize
anything at all.

Anyway, if we it was common practice that systems are designed to
allow standard programs to run without fiddling, that would be great.
That common practice exists in the C world, but not in the Forth
world. Maybe not in the whole C world, but definitely in Unix, and it
does not exist in Forths running on Unix.

>> The attitude is completely different. Instead of considering source
>> code compatibility an outlandish idea like some Forth vendors do
>> (despite taking themselves seriously), it's a major goal, and the
>> source code in question is not restricted to the C code, but
>> includes the Makefiles as well (that's why the command line options
>> have to be compatible).
>
>Not really, no. Makefiles are a little bit portable across unices,
>but even that isn't great. Writing portable makefiles is so hard that
>most people don't bother.

Not in my experience. Ok, there are some difficulties when you do
advanced things (e.g., we had to insert a "sleep 1" because HP/UX's
make resolves a dependence cycle differently than other makes if the
files have the same time stamp), but by and large writing a portable
Makefile is not difficult.

>>>Are you suggesting that an implementer shouldn't actually *expect* users
>>>to read the Fine Manual? :-)
>>
>> If a user has to read the manual of a standard system to run a
>> standard program, there's something wrong with the standard.
>
>IMHO that claim is preposterous. The idea of a language standard is
>not to remove the requirement to RTFM. IMHO, YMMV...

Where does that alleged requirement come from?

[Anton Ertl]

Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>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:
>>>>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>>>>> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>>>>> That's even before considering the effect of running a compliant
>>>>>> program on a (if you are right) compliant system and getting the wrong
>>>>>> result.
>>>>>
>>>>>I don't think that's possible. If you want a specific wordset, you
>>>>>have to make sure that wordset is installed, by whatever means
>>>>>necessary.
>>>>
>>>> And if you don't, what happens?
>>>
>>>You've broken your side of the contract.
>>
>> Which contract?
>
>The one that says that a standard Forth system may not be present and
>if you need one it's time to RTFM.

I did not sign such a contract, but I can agree with the notion that a
system that does not run a standard program without fiddling is not a
standard system.

And yes, for a non-standard system some fiddling is to be expected
when I want to run a standard program, and that may include reading
the manual. But when a system is claimed to be standard, I expect
better of it.

>> As a programmer I have no contract with an arbitrary Forth system.
>> The only thing I have is the Forth standard,
>
>No, that's not true. If that's a standard system it's documented.

That may be the case, but there is no requirement in the standard that
the programmer of a standard program should read the manual of every
existing standard system. And if there was such a requirement in the
standard, it would be a total failure.

>> Could you explain your logical reasoning that leads you to believe
>> that F+ is not a standard word, yet FLOATING is a standard query
>> (i.e., that Forth systems without the float wordset must not answer
>> with "true")?
>
>I think I already explained why I don't believe that F+ is necessarily
>a standard word in a system without the FLOATING wordset, so let's
>talk about ENVIRONMENT? The standard says
>
> The combination of 6.1.1345 ENVIRONMENT?, 11.6.1.2165 S",
> 15.6.2.2532 [IF], 15.6.2.2531 [ELSE], and 15.6.2.2533 [THEN]
> constitutes an effective suite of words for conditional compilation
> that works in interpretation state.
>
>and logically this would not be possible if ENVIRONMENT? returned true
>for wordsets that were not loaded.

First, it would certainly be possible. I actually don't see any
connection between that statement and wordset queries.

Second, that's a descriptive claim in an informative section of the
standard (A.6.1.1345, and you conveniently did not mention the section
number from which you cited), so it has no normative content.

Third, if for this or some other reason the "FLOATING" environmental
query, which is defined in section 12 of the standard ("The optional
Floating-Point word set") has to be taken into account for systems not
implementing this wordset, the same reasoning applies to the rest of
section 12, including "12.6.1.1420 F+". So F+ is a standard word for
the purposes of

|3. Usage requirements
|
|[...]No standard word provided by a system shall alter the system state in

|a way that changes the effect of execution of any other standard word
|except as provided in this Standard.

>>>That's exactly what the standard says. It's like all programming
>>>languages: a language standard doesn't specify a bunch of things,
>>>including how to set up the environment, how to translate a program,
>>>and so on.
>>
>> And yet in other languages I can drop in one compiler as a
>> replacement of another when compiling standard programs, and it
>> works. No fiddling required.
>
>If you're lucky, maybe.

Not maybe. It works.

>There is no guarantee, but there is a lot of
>tradition based on UNIX. Let's try something really simple that is
>undoubtedly Standard C:
>
>#include <stdio.h>
>#include <math.h>
>#include <stdlib.h>
>
>double two = 2.0;
>
>int main(int argc, char **argv) {
> printf("%g\n", sqrt(two));
> exit(0);
>}
>
> $ cc t.c
>/tmp/cc644TlH.o: In function `main':
>t.c:(.text+0x2c): undefined reference to `sqrt'
>
>What do you do now? The C standard is of no help; your only recourse
>is to RTFM.

Not at all. It's much faster to google for the error message, and the
first hit
<http://cboard.cprogramming.com/c-programming/101188-undefined-reference-`sqrt-when-using-math-h.html>
gives the answer right away.

But you missed the point: Once I have found out how to compile that
program, I can replace cc with any other C compiler, and it still
works:

[c8:~/tmp:31665] cc t.c -lm
[c8:~/tmp:31666] a.out
1.41421
[c8:~/tmp:31667]
[c8:~/tmp:31667] llvm-gcc t.c -lm
[c8:~/tmp:31668] a.out
1.41421

There is no "-lm" for Forth that gives me the floating-point wordset
everywhere (I consider "-lm" a historic wart, though; if they could do
it again, they would probably just add the math stuff to libc like
they did for all the other standard C stuff).

[Anton Ertl]

"Rod Pemberton" <do_no...@notemailnot.cmm> writes:
>How does a standard ensure portability is compatible across multiple
>platforms without the ability to test the implementation(s)?

A proper programming language standard specifies an interface between
a standard program and a standard system/compiler. If a program is
written to comply with that specification, and several
systems/compilers are written to comply with that specification, then
that program will be portable to all these systems.

>Do you believe standards describe enough to implement code which is
>portable?

If they don't then there is something wrong with the standard.

>1) I don't. They don't contain implementation details, requirements,
>historical method of implementation, virtual machine description, etc.

None of which are necessary to write standard programs (they are
actually more conducive to writing non-standard programs, if these
things are not standardized).

>2) At best, only 30% of the code will be portable, unless all platforms are
>the exact same platform, e.g., all x86.

Actually my experience with Forth-94 is that this part is done quite
well. CPU-architecture portability bugs (e.g., byte order or cell
size) are very rare in the code I work with.

[Stephen Pelc]

On Thu, 12 Jul 2012 14:23:12 GMT, an...@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>I did not sign such a contract, but I can agree with the notion that a
>system that does not run a standard program without fiddling is not a
>standard system.

Now we have a problem. If you believe that, you cannot take the
position that it is compliant to supply parts of the system as
source code. The TC has used that position many times in the
history of both ANS Forth and Forth200x.

There is absolutely no way that any vendor is going to force
a client to build a floating point pack into an embedded
system. Compliance by source code is almost essential for
embedded systems.

>And yes, for a non-standard system some fiddling is to be expected
>when I want to run a standard program, and that may include reading
>the manual. But when a system is claimed to be standard, I expect
>better of it.

Your real complaint is that there is no standard way to ensure that
a wordset is present. As yet, there is no common practice for this
operation. Several suggestions have been made. Perhaps you would
like to implement one of them on a range of systems as a
pre-proposal activity?

Mountains, molehills, mumble, mumble ...

[BruceMcF]

On Jul 10, 1:06 pm, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:

> If a system doesn't implement the FLOATING wordset, is
> its F+ really a standard word by the above definition?

Yes. The interpretation and compilation semantics of F+ are specified.

3: "A system may contain non-standard extensions, provided that they

are consistent with the requirements of this Standard."

So upwardly compatible extensions allowed.

3.4.2: "A string matches a definition name if each character in the
string matches the corresponding character in the string used as the
definition name when the definition was created."

From token to definition. The token F+ matches the definition name F+
specified.

3.4.3: "Each Forth definition may have several behaviors, described in
the following sections."

The behavior of the definition F+ is specified.

3.4.3.2: "A system shall be capable of executing, in interpretation
state, all of the definitions from the Core word set *and any
definitions included from the optional word sets or word set
extensions whose interpretation semantics are defined by this
Standard*."

Any *definitions* included, which would include whatever is the
interpretation and compilation behavior when the token F+ is
encountered.

If F+ is included, the system shall be capable of executing it.

> I wouldn't have thought so.

But why not? If the words specified in the standard did not have to be
implemented as specified in the standard when provided, then there
would have been a section in the documentation section requiring a
system to document which definitions are provided in a non-standard-
compliant way.

> If the TC had wanted all names in all wordsets to be
> "reserved" so that they couldn't be used for anything
> else it would have been a good idea to say so.

They did say so:
"1.1 The purpose of this Standard is to promote the portability of
Forth programs for use on a wide variety of computing systems, to
facilitate the communication of programs, programming techniques, and
ideas among Forth programmers, and to serve as a basis for the future
evolution of the Forth language."

Allowing systems to claim to be Forth94 compliant and yet implement
non-compliant definitions does not promote the portabiity of Forth
programs or facilitate the communication of programs.

Its obvious that if S" in interpretation mode has been redefined to
return a counted string, as you would allow, that:
S" /HOLD" ENVIRONMENT? 0= [IF] 33 [THEN]

... will not be portable. So too if CORE-EXT was not stated in the
implementation documentation to be implemented in its entirety, when
you would allow PARSE to be defined to copy the parsed string to PAD
as a counted string, with:

CHAR " PARSE /HOLD" ENVIRONMENT? 0= [IF] 33 [THEN]

... not working because ENVIRONMENT? takes a pointer and count stack
text reference.

>  Maybe we should say so now.

Or maybe just call fixed point addition FP+ ... its not as if the "one
or two letters in front of +" could be reasonably said to be anywhere
close to exhausted.

[Anton Ertl]

steph...@mpeforth.com (Stephen Pelc) writes:
>Professionally, MPE tends to deal with larger applications
>that take advantage of features that are not yet standardised.
>Hence, it is not important to us that we have to insert one
>line in a build file to get a feature. Many of our commercial
>clients are much more interested in getting a really good
>string package with parameterisation than in the details of
>simplifying load files.

You want libraries, but you want to make it hard for people who write
libraries to run (and test) their libraries on your system. Hmm.

[Andrew Haley]

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andr...@littlepinkcloud.invalid> writes:
>>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>> "Elizabeth D. Rather" <era...@forth.com> writes:
>>>
>>>>I ask you, those of you who work with many languages, how does it work
>>>>with them? Are there significant C programs, for example, that will
>>>>compile on any compiler and run correctly, without any "fiddling
>>>>around"?
>>>
>>> Any compiler? I don't know. But for serious compilers, it works
>>> pretty well, much, much, much, much better than in Forth. Not just do
>>> they compile the same source code unchanged, they are compatible at
>>> the OS command line level (Forth systems are very different there),
>>> and that's not covered in the standard. Also directories for #include
>>> works the same way for all serious compilers (also not standardized),
>>> so you can organize your portable source code in directories, unlike
>>> Forth.
>>
>>So, you've proved that none of this needs to be standardized: it just
>>needs common practice.
>
> You have just proved that we don't need standards. We only
> standardize common practice, and since (according to you) we don't
> need to standardize common practice, we don't need to standardize
> anything at all.

Could be. ;-)

It's a bit like the question of whether existence precedes essence.
Must common practice must precede standardization, or can
standardization cause common practice?

> Anyway, if we it was common practice that systems are designed to
> allow standard programs to run without fiddling, that would be
> great. That common practice exists in the C world, but not in the
> Forth world. Maybe not in the whole C world, but definitely in
> Unix, and it does not exist in Forths running on Unix.

Again, I think you're understating a bit how much fiddling is necessary
to get a working C environment, but I take your point.

>>>>Are you suggesting that an implementer shouldn't actually *expect* users
>>>>to read the Fine Manual? :-)
>>>
>>> If a user has to read the manual of a standard system to run a
>>> standard program, there's something wrong with the standard.
>>
>>IMHO that claim is preposterous. The idea of a language standard is
>>not to remove the requirement to RTFM. IMHO, YMMV...
>
> Where does that alleged requirement come from?

What an interesting question! Partly from the nature of Forth: there
always is much more in a system than just the language. Unless all
Forths have the same UI, you'll need to know how to interact with it.
Maybe on a UNIX system you can assume it just starts with "blahforth"
and then you interact using stdio, but on a lot of Forth embedded
targets it's going to very different from that. Partly from the Forth
standard itself, of course, but that's just documenting how things
are.

Andrew.

[Andrew Haley]

Claimed by who, though? Is the vendor claims that by default you have
a standard system, you have a right to expect one. If they only claim
that their Forth supports the standard, you have to find out how to
start it in standard mode. But you're only going to know which if you
RTFM. Just like GCC, and probably every other C compiler: I don't
know that any of them are strictly conforming by default.

>>> As a programmer I have no contract with an arbitrary Forth system.
>>> The only thing I have is the Forth standard,
>>
>>No, that's not true. If that's a standard system it's documented.
>
> That may be the case

Yes, it is.

>>> Could you explain your logical reasoning that leads you to believe
>>> that F+ is not a standard word, yet FLOATING is a standard query
>>> (i.e., that Forth systems without the float wordset must not answer
>>> with "true")?
>>
>>I think I already explained why I don't believe that F+ is necessarily
>>a standard word in a system without the FLOATING wordset, so let's
>>talk about ENVIRONMENT? The standard says
>>
>> The combination of 6.1.1345 ENVIRONMENT?, 11.6.1.2165 S",
>> 15.6.2.2532 [IF], 15.6.2.2531 [ELSE], and 15.6.2.2533 [THEN]
>> constitutes an effective suite of words for conditional compilation
>> that works in interpretation state.
>>
>>and logically this would not be possible if ENVIRONMENT? returned true
>>for wordsets that were not loaded.
>
> First, it would certainly be possible. I actually don't see any
> connection between that statement and wordset queries.

Excuse me? The subject of that statement is obviously wordset

queries.

> Second, that's a descriptive claim in an informative section of the
> standard (A.6.1.1345, and you conveniently did not mention the
> section number from which you cited), so it has no normative
> content.

That's a fair point. However, IMO this language is sufficient clearly
to indicate the intent of the TC.

> Third, if for this or some other reason the "FLOATING" environmental
> query, which is defined in section 12 of the standard ("The optional
> Floating-Point word set") has to be taken into account for systems
> not implementing this wordset, the same reasoning applies to the
> rest of section 12, including "12.6.1.1420 F+".

That's just restating your opinion, surely. There's nothing in the
paragraph above that can reasonably be taken to imply that all words
in all wordsets must only be present if they have the definition in
those wordsets.

>>There is no guarantee, but there is a lot of tradition based on
>>UNIX. Let's try something really simple that is undoubtedly
>>Standard C:
>>
>>#include <stdio.h>
>>#include <math.h>
>>#include <stdlib.h>
>>
>>double two = 2.0;
>>
>>int main(int argc, char **argv) {
>> printf("%g\n", sqrt(two));
>> exit(0);
>>}
>>
>> $ cc t.c
>>/tmp/cc644TlH.o: In function `main':
>>t.c:(.text+0x2c): undefined reference to `sqrt'
>>
>>What do you do now? The C standard is of no help; your only recourse
>>is to RTFM.
>
> Not at all. It's much faster to google for the error message,

That's a distinction without a difference. Googling for an error
message is effectively having to RTFM, as is asking someone. You're
accessing external documentation in order to find out how to get this
system to run a standard program. This is no different from Forth!

> There is no "-lm" for Forth that gives me the floating-point wordset
> everywhere

There isn't for portable C either: it's a bizarre UNIXism.

> (I consider "-lm" a historic wart, though; if they could do it
> again, they would probably just add the math stuff to libc like they
> did for all the other standard C stuff).

Definitely.

Andrew.

[Andrew Haley]

BruceMcF <agi...@netscape.net> wrote:
> On Jul 10, 1:06?pm, Andrew Haley <andre...@littlepinkcloud.invalid>

> wrote:
>> If a system doesn't implement the FLOATING wordset, is
>> its F+ really a standard word by the above definition?
>
> Yes. The interpretation and compilation semantics of F+ are specified.
>
> 3: "A system may contain non-standard extensions, provided that they
> are consistent with the requirements of this Standard."
>
> So upwardly compatible extensions allowed.
>
> 3.4.2: "A string matches a definition name if each character in the
> string matches the corresponding character in the string used as the
> definition name when the definition was created."
>
> From token to definition. The token F+ matches the definition name F+
> specified.
>
> 3.4.3: "Each Forth definition may have several behaviors, described in
> the following sections."
>
> The behavior of the definition F+ is specified.
>
> 3.4.3.2: "A system shall be capable of executing, in interpretation
> state, all of the definitions from the Core word set *and any
> definitions included from the optional word sets or word set
> extensions whose interpretation semantics are defined by this
> Standard*."
>
> Any *definitions* included, which would include whatever is the
> interpretation and compilation behavior when the token F+ is
> encountered.
>
> If F+ is included, the system shall be capable of executing it.

Yes, of course. But what if the word F+ is not included from the
FLOATING wordset, but from some other (nonstandard) wordset? Then
3.4.3.2 does not apply: it only applies if the word F+ is from the
FLOATING wordset, and you dont have any right to expect that the
FLOATING wordset is loaded until you've done whatever the
documentation says you have to do.

>> I wouldn't have thought so.
>
> But why not? If the words specified in the standard did not have to
> be implemented as specified in the standard when provided,

They don't: we already know you only have to have CORE .

> then there would have been a section in the documentation section
> requiring a system to document which definitions are provided in a
> non-standard- compliant way.

There's no need for such a section.

>> If the TC had wanted all names in all wordsets to be
>> "reserved" so that they couldn't be used for anything
>> else it would have been a good idea to say so.
>
> They did say so:
> "1.1 The purpose of this Standard is to promote the portability of
> Forth programs for use on a wide variety of computing systems, to
> facilitate the communication of programs, programming techniques, and
> ideas among Forth programmers, and to serve as a basis for the future
> evolution of the Forth language."
>
> Allowing systems to claim to be Forth94 compliant and yet implement
> non-compliant definitions does not promote the portabiity of Forth
> programs or facilitate the communication of programs.

And neither, presumably, does failing to implement the bulk of the
standard, but it is allowed.

> Its obvious that if S" in interpretation mode has been redefined to
> return a counted string, as you would allow, that:
> S" /HOLD" ENVIRONMENT? 0= [IF] 33 [THEN]
>
> ... will not be portable.

It's portable if you have the FILE wordset, not otherwise.
A.6.1.1345 ENVIRONMENT? admits that this is a known poblem:

The Core word set lacks both a direct method for collecting a string
in interpretation state ( 11.6.1.2165 S" is in an optional word set)
and also a means to test the returned flag in interpretation state
(e.g. the optional 15.6.2.2532 [IF]).

> So too if CORE-EXT was not stated in the
> implementation documentation to be implemented in its entirety, when
> you would allow PARSE to be defined to copy the parsed string to PAD
> as a counted string, with:
>
> CHAR " PARSE /HOLD" ENVIRONMENT? 0= [IF] 33 [THEN]
>
> ... not working because ENVIRONMENT? takes a pointer and count stack
> text reference.

Indeed. It's a problem.

>> ?Maybe we should say so now.

>
> Or maybe just call fixed point addition FP+ ... its not as if the
> "one or two letters in front of +" could be reasonably said to be
> anywhere close to exhausted.

Or, much easier and far more sensibly, just accept that you don't call
or tick a word in an optional wordset without finding out if that
wordset is loaded.

Andrew.

[BruceMcF]

On Jul 10, 8:38 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Anton Ertl wrote:
> > Back to searching for the part where I could not find the wording: The
> > start of section 3 says:

> > |No standard word provided by a system shall alter the system state in
> > |a way that changes the effect of execution of any other standard word

> > |except as provided in this Standard. A system may contain

> > |non-standard extensions, provided that they are consistent with the
> > |requirements of this Standard.

> My interpretation or expectation for this is rather strict.  If a
> standard system implements a word named in one of the wordsets, it has
> to follow the spec there.  A system is free to leave wordsets away or
> provide them as source code, so F+ might not be ready to use.  However,
> if there's a word F+ defined, it means it's the floating point worset
> F+.

That is how I read the standard.

> And when you implement one word of Floating, you have to implement
> all of Floating, but Float ext words are optional (you can cherry pick
> which words you want to implement).

Where is that specified? I know that the three *claims* you can make
are providing the base wordset, providing words from the extension
wordset, and providing the extension wordset, but where is the "one
in, all in" specified for the base wordset?

That is, providing a subset of the CORE is explicitly provided for.
Where is providing a subset of any of the additional base wordsets
explicitly ruled out?

> Stephens interpretation of documentation requirements ("we have a
> manual") seems to be that in order to load the floating point wordset, a
> portable program is expected to read the manual, and find out which file
> to load.

Yes, the Forth94 standard is explicit that words may be provided as
source, and leaves it open what form of source, which implies that for
any implementation, you may well be forced to RTFM to bring it into a
state in which it is ready to be used to compile portable source.

A facility in which a program could request that the implementation
does the implementation specific stuff to compile an implementation
specific machine readable source to provide any of the specified
standard wordsets (and for which purpose, thanks to the ENVIRONMENT?
query, even though nobody uses it, a standardized name already
exists) ... that would be a fine thing.

> Well, Stephen actually thinks the programmer is portable and

> will read this manual ...

This is, however, all that the Forth94 standard requires of an
implementation.

The Forth94 standard requires little enough of implementations and
promises little enough to source code authors that it does not seem
justifiable to me for implementers to try to take away the little that
it does offer to source code authors, such as lying about providing
the interpretation and compiling semantics specified for F+ by
providing something called F+ that is not, in fact, the same a F+.

[Bernd Paysan]

Andrew Haley wrote:
> What we really do require in Forth, though is some way to say
>
> REQUIRE FLOATING

And we should also note that languages like Java *have* a standard way
to access standard libraries. If we develop our standard into the
direction of supporting standard libraries (not wordsets, real
libraries), we definitly need such a thing, too.

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

[Bernd Paysan]

Mark Wills wrote:
> I agree with this entirely. You cannot define F+ for your own uses.
> It's reserved. It's a member of the floating-point wordset. Leave it
> alone. If you define it as something else, your system is no longer
> compliant. End of. The standard text (200x) should be modified to make
> this point clear, so that discussions such as this can be avoided!

Yes, maybe we should make it more clear.

> I would suggest:
>
> WORDSET: <wordset>
> or
> GET-WORDSET <wordset>
>
> More explicit. Please, let's be explicit.

Other languages use IMPORT and PACKAGE (Java). So you would say

import forth.floating; \ all standard wordsets are in FORTH

and the file you get there will say

package forth.floating;

as first statement. In Forth, of course, you don't need the trailing
semicolon. I don't want . as separator, I would suggest / to separate
hierarchies. And I'd rather name things MODULE than PACKAGE, this has
more tradition:

import forth/floating

Well, we can discuss if we need a separate directory for Forth standard
wordsets, or if we just put them into the root directory, and have non-
standard libraries in subdirectories, like

import floating
import unix/sockets \ unix-specific socket bindings
import gui/minos

Any objections to "import"? bigForth has IMPORT, and it can be made
work that way (at the moment you say "import float". Changing the name
and maybe moving it into a directory called forth is a piece of cake).
ATM, it doesn't work well when you import several times, but that's a
bug. It should do nothing when importing again.

A hierarchical namespace for modules/packages will help to organize
larger libraries. Calling it different allows vendors to ship modules
in binary (if they don't want to release the source), their IMPORT then
can load binary modules. bigForth's does. It also could check first if
there was a precompiled binary module, and then for source, or download
it from theforth.net if neither is available.

Names suggested so far:

REQUIRE - already specified with "file" as parameter.
NEEDS - looks good, deviates from what other languages use, but so do
many things in Forth. Has some practice, where exactly?
IMPORT - some practice in bigForth.

We may need a counterpart like PACKAGE, MODULE, or PROVIDES.

> Agreed. That would be a neat feature. Just supply the wordset name.
> The rest is up to the system. Like it.

[Bernd Paysan]

Stephen Pelc wrote:
> In my opinion, undocumented Forths were substantially responsible
> for the bad reputation of Forth 20 years ago.

IIRC, it was more that each Forth differed from all the others so
substantially that you absolutly needed the documentation - and then
found it wasn't even available.

>>and then write a harness, which includes
>>Ndp387.fth from the appropriate library directory.
>

> This is basically the way that all successful libraries have gone.

Yes, because otherwise they won't run.

>> This goes even
>>further, because in an out-of-the-box installation of VFX Forth, %LIB%
>>does not actually point at the VFX Forth library directory...
>

> It'll get fixed ... even for people who cannot be bothered to read
> the installation chapter on how to set up VFX Forth, which is
> written for people who have substantial applications to write.

Apples success is that things work "out of the box". No need for
tinkering, no need for a manual. Well, I did read that, I set up %LIB%
to point to the correct library, I edited .VfxForth.ini to make this
persistent (for whatever reason, the setting that ended up in %LIB% is
called "basepath" there), and then, the next version of VFX didn't load
.VfxForth.ini... I don't want to tinker anymore. Provide working
defaults, please.

People read a manual if everything else fails. First make sure
everything else doesn't fail, and then provide a manual for this case.
The failure of Forth is that everything else fails, and then you don't
find it in the manual, and the source doesn't even have stack comments
;-).

> REQUIRE REQUIRES and REQUIRED are already claimed in several

> systems. How about
> load-wordset <name>

>
> If you think this stuff is important, you are spending too much
> time comparing systems and not enough time writing applications
> that get the best out of the Forth. The guts of Forth are

> adequately standardised now. The important job is the provision
> of high level libraries. The current standards process is not
> the right one for standardising libraries, which should be
> defined by a reference implementation and its documentation.

I've ported MINOS to see how much of a job that is. It's too much. We
are not yet there, the guts are not adequately standardized as is.
Porting MINOS required to considerably change VFX Forth to get all the
necessary features (like C bindings which use the Forth floating point
stack, and have I mentioned the broken source inliner? ;-). I've also
heard complaints from MPE that they now have to maintain yet another OOP
package, and are seeking for standardization there. And I don't buy
into the "take the worst one, and stop using all the nice features you
actually need" approach.

Now, we urgently need more documentation for MINOS, but in fact, MINOS
is more than 10 years old, bases on Xlib, and I rather want something
that bases on OpenGL, and that has learned from the mistakes made when I
did MINOS (factor out the visual parts like strings, shapes, and icons).
Apart from Dancing Monkey's cardbox software shop, OpenGL is *the*
interface to the GPU, and even in Redmond, it's supported (though
sometimes, you need Google's wrapper around DirectX).

The VFX-specific part of MINOS is almost 5k lines. The rest is less
than 10k lines. As a porting endeavor, it's far from a complete
rewrite, but a substantial part of MINOS sources are system-specific.
This tells how much (or little) we have achieved.

Once I can write the OpenGL-based MINOS 2 in standard Forth + standard
libraries, then we are done.

[Bernd Paysan]

Andrew Haley wrote:
> As is pretty much every other language. Maybe Java is just about
> there, but even then it's a stretch. Java does it by having an
> enormous library that's intended to provide a portable layer over
> operating system services.

And the most widely used Java platform is Android... Write once, run on
one platform.

[Bernd Paysan]

BruceMcF wrote:
> Now that I think I finally understand Anton's objection, I think an
> extended REQUIRE could be defined that would be upwardly compatible
> with the original standardized REQUIRE.
>
> * If the file specified by c-addr u has been INCLUDED or REQUIRED
> already, but not between the definition and execution of a marker (or
> equivalent usage of FORGET), discard c-addr u; otherwise, perform the
> function of INCLUDED.
>
> * If no such file exists, compare the string to an implementation
> specific database of words that may be made defined on demand, and if
> found load the source required to make the word available.

Well, we need to be more specific than that (especially that you can use
it to load wordsets), but the principle IMHO is ok.

> It can't be done portably on top of an existing REQUIRED, since
> REQUIRED does not return an ior, but it would be a compatible
> extension of a portable REQUIRED.

What's the need of an ior here? If REQUIRED fails, it can use THROW.

s" foo.bar" required
:1: No such file or directory
s" foo.bar" >>>required<<<

[Albert van der Horst]

In article <jtihu3$c09$1...@online.de>, Bernd Paysan <bernd....@gmx.de> wrote:
>Anton Ertl wrote:
>
>> Back to searching for the part where I could not find the wording: The
>> start of section 3 says:
>>
>> |No standard word provided by a system shall alter the system state in
>> |a way that changes the effect of execution of any other standard word
>> |except as provided in this Standard. A system may contain
>> |non-standard extensions, provided that they are consistent with the
>> |requirements of this Standard.
>
>My interpretation or expectation for this is rather strict. If a
>standard system implements a word named in one of the wordsets, it has
>to follow the spec there. A system is free to leave wordsets away or
>provide them as source code, so F+ might not be ready to use. However,
>if there's a word F+ defined, it means it's the floating point worset

>F+. And when you implement one word of Floating, you have to implement

>all of Floating, but Float ext words are optional (you can cherry pick
>which words you want to implement).

What does everybody think in the context of wordlists?
Can I have an F+ in a different wordlist, or must I refrain
from using that word there too?

<SNIP>

>--
>Bernd Paysan
>

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

[Josh Grams]

Andrew Haley wrote: <vPOdnZHS4u7D6WPS...@supernews.com>

> Josh Grams <jo...@qualdan.com> wrote:
>> Andrew Haley wrote: <-sadnYHCP5XQ2GDS...@supernews.com>
>>> Stephen Pelc <steph...@mpeforth.com> wrote:
>>>
>>>> If you think this stuff is important, you are spending too much time
>>>> comparing systems and not enough time writing applications that get
>>>> the best out of the Forth. The guts of Forth are adequately
>>>> standardised now.
>>>
>>> I agree with you. I can't imagine that this is a big deal for any
>>> working programmers using Forth.
>>
>> Er...it is a *major* barrier to using Forth for anything where you
>> might want random users to be able to run your program under a Forth
>> system that you haven't specifically ported your program to. That
>> is most of the programming that I'm interested in.
>
> What application area is this? Something that requires no GUI, no
> OS-specific accesses of any kind? Where you can provide your users
> with perfectly portable source code?

OK, I'm exaggerating a little bit. But I can write C code which uses
portable libraries to do GUI and OS accesses and have it compile
unchanged on several different platforms, or even cross-compile Windows
binaries from my Linux box using pre-packaged toolchains. And it's
trivial to write Python code which runs pretty much anywhere.
Javascript library availability and support in browsers is getting to
the point where you can do an awful lot of things, again, write once,
run anywhere.

I realize that where Forth really shines is embedded stuff, where you
can reasonably hard-code various decisions and ignore generalities that
you know are never going to come up. And maybe the whole cross-platform
library thing is antithetical to the principles that make Forth
interesting. But I always enjoy it when I get a chance to program in
Forth, and I wish it was more usable for more of the things that I like
to do with computers.

Basically I think the situation for sharing code in Forth sucks, even
within the community. And forget about trying to share a Forth program
with someone who isn't a programmer. I'd like to be able to say,
"Here's my program -- grab any Forth system with the foo.fs package
manager and you should be able to install and run it." instead of having
to say, "OK, find a Linux/x86 system, build the CVS version of PFE,
download and install these libraries, and then if you're lucky, you can
try my program."

--Josh

[Josh Grams]

Stephen Pelc wrote: <4ffe9921...@192.168.0.50>

> On 11 Jul 2012 20:24:42 GMT, Josh Grams <jo...@qualdan.com> wrote:
>
>>Er...it is a *major* barrier to using Forth for anything where you might
>>want random users to be able to run your program under a Forth system
>>that you haven't specifically ported your program to. That is most of
>>the programming that I'm interested in.
>
> You'll have to be more detailed than that for the Forth200x people
> to take any action or make proposals. In particular, I believe
> that common practice is important and should emerge for
> standardisation. Say what is missing and say what is useful.

Oh, I don't need or want the Forth200x people to do anything. I just
want a system to make it easier to share code and port code *without*
going through the whole standardizaion thing. So many of these features
can be easily implemented on a wide range of Forths, but it takes carnal
knowledge of each Forth to do it, so it's too much work to do it for
every feature you want for your application. But if we could share that
work easily...

What I'd love to see is some person (or small group of people) release a
simple package manager which is ported widely enough and has a big
enough package database that people might actually try it and use it. I
was sort of hoping Bruce McF would get his system working and released
and someone would run with it... Then Gerald Wodni came up with
theforth.net, which looked promising but doesn't seem to actually work.

I think that an initial implementation could just be a one-time
file-loading word with path search. That would allow a main directory
of packages, which could be overlaid by a directory containing system
specific implementations of some packages. It would be nice to have a
mangler which converts arbitrary Forth words to valid filenames...so we
could use Forth words as package names.

I think it would need to run on several Forth systems: probably at least
gforth, pfe, ficl, win32forth, pforth, and of course the commercial
systems. That would involve either detecting the Forth system from
within (I have a script for that), or providing a shell-script for each
system to run it with the package manager loaded, and ideally a patch to
build the package manager in.

Then it would need a package database big enough that people might
actually try it. There's a fair amount of free Forth code out there
(how useful it is is another question), but I feel like it's not very
visible and I don't know that many people go to the bother of tracking
it down and trying it. So...the examples from all the free Forth
systems, the FFL, the FSL, David N. Williams's stuff, that sort of
thing. I think it would be really cool to provide a basic graphics
interface on all the systems which support FFI, but that would be a lot
more work.

And it would need a web site, with descriptions for all the packages,
and indices for browsing so that people can see that they exist.

I suspect that to have a chance at success it would need someone to do a
fair chunk of that work on his own initiative, without community
support; to push it to the "critical usefulness" it would need to
attract a community. That's a tall order. I have been avoiding doing
it because I don't feel like I have the time to do it justice (in any
reasonable time frame). But maybe it will have to be me. I guess I'll
start picking away at it. I have a name mangler somewhere. Gforth has
the rest (path search and one-time file-loading), so I could put
together a prototype easily and then be able to either work on package
specifications or porting it to other Forth systems. Hmm...

--Josh

[BruceMcF]

On Jul 12, 10:20 pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:

> What does everybody think in the context of wordlists?
> Can I have an F+ in a different wordlist, or must I refrain
> from using that word there too?

You can *do* anything you damn well want to do, just be honest about
what you are doing. If there is a wordlist provided by an
implementation that has a non-compliant F+ then document that if the
wordlist is brought into context, the result is no longer a Forth94
system. If the wordlist is provided by a userland library, then
document that if the definitions in the source are brought into
context, the result is no longer a Forth94 system.

[BruceMcF]

On Jul 12, 5:45 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> > It can't be done portably on top of an existing REQUIRED, since
> > REQUIRED does not return an ior, but it would be a compatible
> > extension of a portable REQUIRED.

> What's the need of an ior here?  If REQUIRED fails, it can use THROW.

"portably"

"on top of an existing REQUIRED"

There is now way to write a PORTABLE library that will use the
implementation-provided REQUIRED and overlay the extension on top of
it, since there is no PORTABLE way to detect REQUIRED failing because
of an inability to match the name to a file.

The fact that an implementer *could* use THROW doesn't help, since
there's no assurance that every implementer did, nor what throw code
they used, so you can't use that to write a portable extension to
REQUIRED.

> s" foo.bar" required
> :1: No such file or directory
> s" foo.bar" >>>required<<<

OK, but not every implementation does precisely that, so taking
advantage of that would be limited to those implementations that do.
Others would require other implementations of the REQUIRED extension.
Hence, not possible to portably extend REQUIRED.

[BruceMcF]

On Jul 12, 4:58 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:

> import forth.floating; \ all standard wordsets are in FORTH
>
> and the file you get there will say
>
> package forth.floating;
>
> as first statement.  In Forth, of course, you don't need the trailing
> semicolon.  I don't want . as separator, I would suggest / to separate
> hierarchies.  And I'd rather name things MODULE than PACKAGE, this has
> more tradition:

> import forth/floating

> Well, we can discuss if we need a separate directory for Forth standard
> wordsets, or if we just put them into the root directory, and have non-
> standard libraries in subdirectories, like

> import floating
> import unix/sockets \ unix-specific socket bindings
> import gui/minos

> Any objections to "import"?

(1) How do you portably add either a non-standard library, or even a
standard library for that matter, to the system? If a library can be
portably accessed but cannot be portably installed, it seems a bit
like just kicking the can up the road.

(2) how does importing and wordlists interact?

> A hierarchical namespace for modules/packages will help to organize
> larger libraries.  Calling it different allows vendors to ship modules
> in binary (if they don't want to release the source), their IMPORT then
> can load binary modules.

(1) Again ~ if the vendor's IMPORT *can* ship modules in binary, then
some "alternative portable definition of IMPORT" will lose access to
those modules, so it needs to be possible to add non-vendor libraries
into the system.

> Names suggested so far:

> REQUIRE - already specified with "file" as parameter.

Disadvantage: Constrains choice of filename.
Advantage: adding the correct script in the place that REQUIRE looks
for files would add the system to an existing implementation without
requiring addition to the dictionary
Mitigation to Advantage: its a bigger issue for small implementations,
which are less likely to wish to have dictionary overhead of REQUIRE

> NEEDS - looks good, deviates from what other languages use, but so do
> many things in Forth.  Has some practice, where exactly?

Is NEEDS library based or word based?

> IMPORT - some practice in bigForth.

Andrew Haley's concern ~ that's an awfully useful word to be reserving
in the standard. Which, after all, is more or less why we have OPEN-
FILE READ-FILE and CLOSE-FILE instead of OPEN READ and CLOSE.

OPEN-LIBRARY ( "name" -- flag ) success/failure
OPENED-LIBRARY ( ca u -- flag ) non-parsing factor
LIBRARIES ( -- ) print available libaries

[Rod Pemberton]

"Anton Ertl" <an...@mips.complang.tuwien.ac.at> wrote in message
news:2012Jul1...@mips.complang.tuwien.ac.at...

> "Rod Pemberton" <do_no...@notemailnot.cmm> writes:
> >How does a standard ensure portability is compatible across multiple
> >platforms without the ability to test the implementation(s)?
>
> A proper programming language standard specifies an interface between
> a standard program and a standard system/compiler. If a program is
> written to comply with that specification, and several
> systems/compilers are written to comply with that specification, then
> that program will be portable to all these systems.
>

In another thread, I just demonstrated such a case with an EVALUATE that
complies with the Forth standard's definition (ANS) which is both
non-portable and also incorrectly implemented...

> >Do you believe standards describe enough to implement code which is
> >portable?
>
> If they don't then there is something wrong with the standard.
>

Yes, they (standards) are expressed using _words_, which can mean
different things, and with brevity or terseness. If there was mathematics
or pictures or code sequences, I'd think it'd be less of an issue.


Rod Pemberton

[Elizabeth D. Rather]

On 7/12/12 9:31 PM, Rod Pemberton wrote:
> "Anton Ertl" <an...@mips.complang.tuwien.ac.at> wrote in message
> news:2012Jul1...@mips.complang.tuwien.ac.at...
>> "Rod Pemberton" <do_no...@notemailnot.cmm> writes:
>>> How does a standard ensure portability is compatible across multiple
>>> platforms without the ability to test the implementation(s)?
>>
>> A proper programming language standard specifies an interface between
>> a standard program and a standard system/compiler. If a program is
>> written to comply with that specification, and several
>> systems/compilers are written to comply with that specification, then
>> that program will be portable to all these systems.
>>
>
> In another thread, I just demonstrated such a case with an EVALUATE that
> complies with the Forth standard's definition (ANS) which is both
> non-portable and also incorrectly implemented...

It seemed to comply with the Standard's definition of EVALUATE, but
violates other specifications in the Standard regarding TIB and
treatment of the input stream in general.

One style of standard writing is to repeat requirements everywhere, but
that runs the risk of some of the phrasing appearing contradictory to
the way the same concept is articulated elsewhere. The other approach,
which Forth94 took, was to try to say things in only one place, with
references as appropriate. But one needs to follow *all* the
requirements in order to be compliant.

Cheers,
Elizabeth

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

[Rod Pemberton]

"Elizabeth D. Rather" <era...@forth.com> wrote in message
news:CvKdnTLA44HZTGLS...@supernews.com...

> On 7/12/12 9:31 PM, Rod Pemberton wrote:
> > "Anton Ertl" <an...@mips.complang.tuwien.ac.at> wrote in message
> > news:2012Jul1...@mips.complang.tuwien.ac.at...
> >> "Rod Pemberton" <do_no...@notemailnot.cmm> writes:
> >>> How does a standard ensure portability is compatible across multiple
> >>> platforms without the ability to test the implementation(s)?
> >>
> >> A proper programming language standard specifies an interface between
> >> a standard program and a standard system/compiler. If a program is
> >> written to comply with that specification, and several
> >> systems/compilers are written to comply with that specification, then
> >> that program will be portable to all these systems.
> >>
> >
> > In another thread, I just demonstrated such a case with an EVALUATE that
> > complies with the Forth standard's definition (ANS) which is both
> > non-portable and also incorrectly implemented...
>
> It seemed to comply with the Standard's definition of EVALUATE, but
> violates other specifications in the Standard regarding TIB and
> treatment of the input stream in general.
>

I thought we concluded it _did not_ violate the Standards regarding use of
TIB. I.e., valid to write to TIB in system words like EVALUATE, but not
valid for user words.

I've postponed fixing EVALUATE moving back to another non-Forth project of
mine. So, I didn't finish a reply in regards to the other implementations
of EVALUATE that I've found. However, the original version of EVAL by
Martin Tracy directly writes to the TIB buffer. At least ten people who've
posted to c.l.f. in the past, have posted definitions for EVALUATE that use
TIB. Half of them are still posting currently... I noticed that at least
one definition doesn't write to the actual TIB buffer, but changes and
restores TIB's address, i.e., moves the buffer location returned by TIB.
So, before posting that reply, I also wanted to recheck each definition to
make sure that I understood how each worked. At the moment, I believe the
majority of them not only use TIB's address but write to the TIB buffer.


Rod Pemberton

[Stephen Pelc]

Bernd said:

>I've ported MINOS to see how much of a job that is. It's too much. We
>are not yet there, the guts are not adequately standardized as is.
>Porting MINOS required to considerably change VFX Forth to get all the
>necessary features

If you want to make specific attacks in public, then you will have
to expect comments about your code. I don't want to do that. You
know full well that MPE has found bugs in your code.

One important result from the MINOS port is that there is no standard
way to tell the compiler about partitioning words other than with
DOES>. This lack makes some Forth code hard to port.

I and MPE are trying to make Forth more portable - we see benefit
in that. To that end, we have put the EXTERN: interface to shared
libraries into essentially public domain.
http://soton.mpeforth.com/flag/extern
EXTERN: has been adopted by iForth and I am told that others are
planning to adopt it.

>I've also
>heard complaints from MPE that they now have to maintain yet another OOP
>package, and are seeking for standardization there.

True.

>And I don't buy
>into the "take the worst one, and stop using all the nice features you
>actually need" approach.

Neither do I, so why did you say that? Part of the horror of OOP in
Forth is that most of the package authors fight amongst themselves.
The one person who collaborates and adapts is Doug Hoffman, whose
FMS package has been widely ported and is also at FLAG.
http://soton.mpeforth.com/flag/fms
If you want additional features, you can always negotiate with Doug.

People who want their libraries to be ported and used are going to
have to learn to collaborate.

>Now, we urgently need more documentation for MINOS, but in fact, MINOS
>is more than 10 years old

I'm not going to comment.

>The VFX-specific part of MINOS is almost 5k lines. The rest is less
>than 10k lines. As a porting endeavor, it's far from a complete
>rewrite, but a substantial part of MINOS sources are system-specific.
>This tells how much (or little) we have achieved.

By some changes, the majority of the 5k lines of supposedly
VFX-specific code could be reduced by something like a factor
of five.

The port tells me (and I have inspected the code) that MINOS was not
designed to be portable. The port process did not follow a
procedure designed to make the next port easier. Writing code
for porting is a discipline. Talk to Willem about this. He
knows things that you do not know. A lot of what Willem taught
me is expressed in my EuroForth paper:
http://www.complang.tuwien.ac.at/anton/euroforth/ef09/papers/pelc.pdf

MPE has used and incorporated third party Forth source code for
many years. We have experience with coding styles and attitudes
that will and will not work for portable code.

>Once I can write the OpenGL-based MINOS 2 in standard Forth + standard
>libraries, then we are done.

That's an objective worth working towards.

I hope that we can collaborate and negotiate our way towards
achieving the objective.